How I Finally Got Microsoft BitNet Running on Windows 11 (After 9 Hours of Pain) #537
kamil-ship-it
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Microsoft released BitNet b1.58 2B4T — a 1.58-bit quantized language model that runs fast on CPU with only ~1GB of storage. No GPU needed. Sounds perfect, right? I thought so too. What followed was one of the most frustrating yet educational days I have ever spent with a Windows machine. This post is the complete story, including every error, every dead end, and ultimately the solution that worked.
What Is BitNet and Why Does It Matter?
Normal AI models store each number (called a weight) using 4 or 8 bits of data. BitNet takes a radically different approach — it stores weights using only 1.58 bits, where every value is essentially either -1, 0, or 1. This sounds too simple to work well, but Microsoft's research shows it performs surprisingly competitively at the 2B parameter scale.
The practical result is extraordinary: a ~1GB model file that runs entirely on CPU with very low heat and power consumption. For anyone running on a laptop with limited VRAM — like my Lenovo IdeaPad Gaming 3 with a GTX 1650 and 16GB RAM — this is genuinely exciting. The catch is that BitNet uses its own custom inference engine called bitnet.cpp, which is completely separate from the popular llama.cpp and Ollama ecosystem.
ℹ Key Fact
As of April 2026, Ollama does NOT support BitNet models. There are open GitHub issues requesting this, but it has not been merged yet. You cannot simply run ollama run bitnet — it will fail with a model load error.
My System Specs
CPU
AMD Ryzen 5 5600H
RAM
16GB (13.9GB usable)
GPU
NVIDIA GTX 1650 (4GB VRAM)
OS
Windows 11 Home
Part 1 — The Windows Build Attempt (Dead End)
The official BitNet GitHub repository says you can build on Windows. In theory, this is true. In practice, it requires a very specific combination of tools that the documentation does not make clear. Here is every problem I encountered trying to build natively on Windows.
Problem 1: CMake Not Found
The first command fails immediately because CMake is not installed. You download it from cmake.org, but critically you must select "Add CMake to the system PATH for all users" during installation. Without this, the terminal still cannot find it even after installation.
Problem 2: The NMake Generator Trap
Once CMake is installed, running the standard configure command picks NMake Makefiles as the default generator on Windows. NMake is not installed, so this fails instantly. The fix is to specify a generator explicitly using the -G flag.
Problem 3: No Build Tool At All
Specifying -G "MinGW Makefiles" fails because MinGW is not installed either. Specifying -G "Ninja" fails because Ninja is not installed. At this point you realize Windows has no build toolchain at all by default, unlike Linux where gcc and make come pre-installed.
Problem 4: MSYS2 + PATH Hell
Installing MSYS2 and using its package manager (pacman) to install Ninja and Clang works — but the installed binaries are not automatically added to the Windows system PATH. So even after installation, PowerShell cannot find them. The fix requires either manually adding C:\msys64\mingw64\bin to System Environment Variables, or refreshing the current PowerShell session using a specific command.
Problem 5: Two Clangs in Conflict
After getting both LLVM's Clang (installed separately) and MSYS2's Clang working, CMake picks the wrong one — LLVM's standalone Clang, which lacks Windows SDK libraries. This causes errors like could not open 'kernel32.lib' because the standalone Clang has no linker support for Windows system libraries.
Problem 6: ClangCL and Visual Studio
BitNet's build script internally calls CMake with -T ClangCL, which is a Visual Studio-specific toolset flag. This means Visual Studio Build Tools are essentially required. Installing them (the "Desktop development with C++" workload, ~6.6GB) eventually gets the configure step working.
Problem 7: CMAKE_GENERATOR Environment Variable Haunting
Earlier in the process I had set $env:CMAKE_GENERATOR = "Ninja" to try to fix the generator problem. This variable persisted in PowerShell sessions and kept overriding BitNet's internal CMake calls, causing the error: "Generator Ninja does not support toolset specification, but toolset ClangCL was specified." The fix was to permanently remove this variable from both Machine and User environment scope.
Problem 8: Source Code Bugs on Windows
After all the toolchain issues were resolved, actual compilation began — and then hit genuine code bugs that only trigger on Windows with ClangCL. Two specific files needed manual fixes in Notepad++. First, in ggml-bitnet-mad.cpp at line 811, a const keyword was missing from a pointer declaration. Second, in llama.cpp/common/common.cpp, a variable named clock conflicted with Windows SDK's C-style clock function — requiring a rename to chrono_clock in four places.
⚠ The Hard Truth
After fixing two source code bugs, a third appeared. BitNet's Windows build path has multiple code-level incompatibilities with the Windows + ClangCL toolchain. Each fix reveals another. This is why the WSL approach below is strongly recommended instead.
Part 2 — The WSL Solution (What Actually Works)
After spending most of the day on the Windows native build, I switched to WSL — Windows Subsystem for Linux. This is a Linux environment that runs inside Windows 11. BitNet was designed for Linux, and on Linux it builds without a single source code modification.
Step 1: Try the Easy Method First
Before anything else, try the simple one-liner in an Admin PowerShell:
wsl --install -d Ubuntu
If your internet connection is stable and Microsoft Store is accessible, this downloads and installs Ubuntu automatically. Skip to Part 3. If this fails or is too slow, continue with the manual method below.
Step 2: Download Ubuntu Manually
Download the Ubuntu WSL rootfs file directly from Canonical's servers. Go to https://cloud-images.ubuntu.com/wsl/jammy/current/ and download ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz. Save it to D:\WSL_Ubuntu.
Step 3: Extract the .tar.gz to Plain .tar
This is the step that most guides skip, and it causes the confusing ERROR_FILE_NOT_FOUND error even when the file clearly exists. WSL's import command requires a plain .tar file, not a compressed .tar.gz. Run this in Admin PowerShell:
$input = "D:\WSL_Ubuntu\ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz"
$output = "D:\WSL_Ubuntu\ubuntu.tar"
[System.IO.Compression.GzipStream]::new(
[System.IO.File]::OpenRead($input),
[System.IO.Compression.CompressionMode]::Decompress) |
% { $dest = [System.IO.File]::OpenWrite($output);
try { $_.CopyTo($dest) }
finally { $dest.Close() } }
Step 4: Create the Destination Folder
Another silent requirement — the destination folder must exist before importing. WSL will not create it automatically, and the error message misleadingly says "file not found" rather than "folder not found":
mkdir D:\Ubuntu_System
⭐ The Critical Command — 9 Hours Led Here
wsl --import Ubuntu-Final D:\Ubuntu_System D:\WSL_Ubuntu\ubuntu.tar --version 1
The --version 1 flag is the most important part. WSL 2 requires Hyper-V virtualization, which may be restricted or unavailable on Windows 11 Home. WSL 1 uses a translation layer approach that works universally on any Windows 11 machine without any additional settings. Without this flag, the import either fails or creates an instance that will not start.
Step 5: Enter Ubuntu
wsl -d Ubuntu-Final
You will see the Ubuntu welcome message. You are now inside a Linux environment running on your Windows machine.
Part 3 — Building BitNet in Ubuntu WSL
Once inside the Ubuntu terminal, the entire process that took 9 hours on Windows takes about 20 minutes on Linux. Every tool installs cleanly, every command works on the first try.
1
Update the system
apt update && apt upgrade -y
2
Install all build dependencies in one command
apt install cmake clang python3 python3-pip git build-essential -y
This single command installs everything that took hours to piece together on Windows.
3
Clone BitNet with submodules — the --recursive flag is critical. Without it, the bitnet-lut-kernels.h file will be missing and the build will fail.
cd /mnt/d/bitnet
git clone --recursive https://github.com/microsoft/BitNet.git
cd BitNet
4
Install Python dependencies and build
pip3 install -r requirements.txt
python3 setup_env.py -md models/BitNet-b1.58-2B-4T -q i2_s
This downloads the ~1GB model and compiles everything automatically. Expect 15-25 minutes depending on your CPU.
✅ Why Linux Works So Smoothly
Linux ships with a complete, cohesive build toolchain. There is no PATH juggling, no generator conflicts, no Visual Studio dependency, no SDK library hunting. The same environment that Microsoft's engineers used to write BitNet is the environment you are building it in.
Complete WSL Setup — Quick Reference
For anyone who wants just the commands without the story, here is the complete sequence from a fresh Windows 11 machine:
Run all of this in Admin PowerShell on Windows
1. Extract the downloaded .tar.gz file
$in = "D:\WSL_Ubuntu\ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz"
$out = "D:\WSL_Ubuntu\ubuntu.tar"
[System.IO.Compression.GzipStream]::new(
[System.IO.File]::OpenRead($in),
[System.IO.Compression.CompressionMode]::Decompress) |
% { $d = [System.IO.File]::OpenWrite($out);
try { $_.CopyTo($d) } finally { $d.Close() } }
2. Create destination folder
mkdir D:\Ubuntu_System
3. Import Ubuntu into WSL (--version 1 is critical!)
wsl --import Ubuntu-Final D:\Ubuntu_System D:\WSL_Ubuntu\ubuntu.tar --version 1
4. Enter Ubuntu
wsl -d Ubuntu-Final
Now inside Ubuntu terminal
apt update && apt upgrade -y
apt install cmake clang python3 python3-pip git build-essential -y
git clone --recursive https://github.com/microsoft/BitNet.git
cd BitNet
pip3 install -r requirements.txt
python3 setup_env.py -md models/BitNet-b1.58-2B-4T -q i2_s
Key Lessons Learned
Ollama cannot run BitNet yet. Do not waste time trying. The model format uses a non-standard GGUF variant that llama.cpp and Ollama do not support. Wait for official integration or use bitnet.cpp directly.
The --version 1 flag is not optional. On Windows 11 Home, WSL 2 frequently fails silently or requires BIOS-level virtualization settings. WSL 1 works everywhere, immediately, with no configuration.
The destination folder must exist before wsl --import. The error message says "file not found" which makes you think the tar file is missing. It is not. The folder is what is missing.
Never set CMAKE_GENERATOR as a permanent environment variable unless you know exactly what you are doing. It will silently break other builds in unexpected ways long after you have forgotten you set it.
If a project's documentation says "supports Windows", check the GitHub issues first. "Supports" often means "technically possible with the right combination of tools" rather than "works out of the box." BitNet on Windows has multiple open issues about build failures.
TL;DR Summary
BitNet does not work with Ollama. Building natively on Windows requires Visual Studio Build Tools, the right Clang version, Ninja, Python 3.11 specifically, manual source code fixes, and careful environment variable management. After 9 hours of this, WSL (Windows Subsystem for Linux) with --version 1 solved everything in 20 minutes. The single most important command was wsl --import Ubuntu-Final D:\Ubuntu_System D:\WSL_Ubuntu\ubuntu.tar --version 1 — and the single most important insight was that the destination folder must be created manually before running it.
Beta Was this translation helpful? Give feedback.
All reactions