Repository navigation
Build on Windows? #384
Description
Before you start
- I have read the FAQ and my problem is not answered there.
- I have read the Roadmap and this is not already planned there.
- I have searched existing issues and found no duplicate.
- I am on the latest release, or on a freshly rebuilt
mainwhen building from source.
What happened
Curious the desktop exe version works on windows, but wanted to merge some pull requests into own branch and compile and run but hit some snags, cuda13 installed but then this, its possible to compile from windows?
FreeToken uv pip install -e ".[accel]"
× No solution found when resolving dependencies:
╰─▶ Because sglang-kernel==0.4.5+cu130 has no wheels with a matching platform tag (e.g., win_amd64) and only the
following versions of sglang-kernel are available:
sglang-kernel<0.4.5
sglang-kernel>=0.4.5+cu130
we can conclude that sglang-kernel==0.4.5 cannot be used.
And because freetoken[accel]==0.1.2 depends on sglang-kernel==0.4.5, we can conclude that
freetoken[accel]==0.1.2 cannot be used.
And because only freetoken[accel]==0.1.2 is available and you require freetoken[accel], we can conclude that
your requirements are unsatisfiable.
hint: Wheels are available for `sglang-kernel` (v0.4.5+cu130) on the following platforms:
`manylinux2014_aarch64`, `manylinux2014_x86_64`
How did you install FreeToken
Built from source
FreeToken version
latest
OS
Windows 11
OS details
win11
GPU and driver
4090
CPU and system RAM
32core, 64gb
Checkpoint
qwen
Command
FreeToken uv pip install -e ".[accel]"
× No solution found when resolving dependencies:
╰─▶ Because sglang-kernel==0.4.5+cu130 has no wheels with a matching platform tag (e.g., `win_amd64`) and only the
following versions of sglang-kernel are available:
sglang-kernel<0.4.5
sglang-kernel>=0.4.5+cu130
we can conclude that sglang-kernel==0.4.5 cannot be used.
And because freetoken[accel]==0.1.2 depends on sglang-kernel==0.4.5, we can conclude that
freetoken[accel]==0.1.2 cannot be used.
And because only freetoken[accel]==0.1.2 is available and you require freetoken[accel], we can conclude that
your requirements are unsatisfiable.
hint: Wheels are available for `sglang-kernel` (v0.4.5+cu130) on the following platforms:
`manylinux2014_aarch64`, `manylinux2014_x86_64`Full log
Anything else
No response
Activity
clover-supply commentedon Sep 8, 2026
pretty sure sglang doesn't have a windows version
bherald commentedon Sep 19, 2026
I tested the official Windows packaged runtime,
0.1.3+g52322e984, withnvidia/Qwen3.6-35B-A3B-NVFP4and completed text-generation requests using its headless server. The Windows engine and matching kernel packages are available through the official beta release.That establishes a working packaged-runtime path for my tested configuration. It does not resolve the source-build dependency error reported here.
Would a short documentation example distinguishing the Windows packaged-runtime setup from the Linux/source-build instructions be useful? I have retained version, installation and test records if that help.
Prepared with AI assistance from my test records.
YevheniiKotyrlo commentedon Sep 29, 2026
A source build does work on native Windows with a handful of fixes, and I have split them into three PRs so each can be reviewed on its own:
cudartfromlib/x64, cl's flags,__always_inline,.templatedisambiguators, a--ple-backenddefault that exists off Linux)ipc, andzmq.asynciocannot run on the Proactor loop), and stop the server when the frontend listener dies instead of answering nothingO_DIRECT,preadv,posix_fadvise,PROT_READormadvise, keeping the parallel expert readerThe resolution error at the top of this issue is the
[accel]extra: it needssglang-kernel, which is published for manylinux only (0.4.5: x86_64 and aarch64).pip install -e .without it builds with these PRs, and the engine serves on its Triton kernels.Tested on Windows 11 Pro 26200, MSVC 19.51, CUDA 13.3, torch 2.11.0+cu130, triton-windows 3.6.0, RTX 3090 Ti 24 GB, serving
RadixArk/Qwen3.8-Flash-Next-NVFP4. The three PRs' changed tests pass (98, 4 skipped), and the whole suite over them fails only on things they do not touch: a batch-memcpy probe race #414 fixes, a local-checkpoint case, and two real-checkpoint tests that expect novisual.*fromiter_weights, which yields them by default.#285 and #298 also carry Windows fixes, each bundled with other work (sub-byte KV quantisation, a new model); these three are only the port. On Linux the links stay
ipc, the event loop stays uvicorn's choice and O_DIRECT stays the read path; two changes reach every platform - a dead listener now stops the server, and the parallel shard reader is built onread_range_into- and both pass on Linux overmain(WSL2 Ubuntu 22.04, Python 3.10, CUDA 13.0), O_DIRECT reads included.