Microsoft says Foundry Local outpaced llama.cpp in local coding tests
The Qwen3.8-27B comparison accompanies a Copilot setup guide requiring at least 24GB of graphics memory. Microsoft still recommends cloud models for complex reasoning.
Loading page…
The Qwen3.8-27B comparison accompanies a Copilot setup guide requiring at least 24GB of graphics memory. Microsoft still recommends cloud models for complex reasoning.
Listen to this story
Microsoft’s benchmark positions Foundry Local as a faster option than llama.cpp for running Qwen3.8-27B on local NVIDIA hardware, particularly with long inputs. The results could make whole-repository coding workflows more practical on supported GPUs, but they are Microsoft’s own tests on two systems, and local models may be less capable at complex reasoning than cloud alternatives. The accompanying Copilot setup offers a way to try the model through Bring Your Own Key, with substantial memory and runtime requirements.
Microsoft tested a 4-bit Qwen3.8-27B on an RTX 5090 and a DGX Spark using real GitHub issues; it reported Foundry Local was faster at every prompt length.
Microsoft says the model needs about 18GB of memory, with context windows up to 64K tokens on 24GB GPUs and 262K on GPUs with at least 32GB.
Foundry Local uses ONNX Runtime, DFlash2 speculative decoding, prefix caching, and continuous batching to improve inference performance.
Microsoft says developers can generate coding-model output faster with Foundry Local than with llama.cpp, based on its tests on two NVIDIA systems. Its November 5, 2026 comparison used Qwen3.8-27B and accompanied a guide to connecting the model to GitHub Copilot. That local setup requires at least 24GB of graphics memory.
The evaluation used a dataset of real GitHub issues and a 4-bit version of Qwen3.8-27B. Microsoft compared the two software engines on a GeForce RTX 5090 with 32GB of graphics memory and a DGX Spark with 128GB of unified memory.
Foundry Local was faster at every tested prompt length, Microsoft says, with its generation-speed advantage widening beyond 131K tokens of input. The company connects that long-input result to coding workflows involving whole repositories.
Foundry Local uses ONNX Runtime to optimize model execution. One technique, DFlash2 speculative decoding, uses a lightweight drafting model to predict multiple tokens at once. Prefix caching reuses previously computed context, while continuous batching processes concurrent requests.
Compression is only part of fitting the workload onto a GPU. Microsoft also compresses the cache that stores working context, shares embedding memory and offloads work to the CPU. Configurable, memory-aware inference lets users balance memory consumption against performance.
Microsoft cautions that smaller local models may have less reasoning ability than advanced cloud models. It positions local execution for everyday coding and targeted subtasks, while recommending cloud models as a strong option for complex reasoning.
Microsoft’s setup guide uses GitHub Copilot’s Bring Your Own Key, or BYOK, connection. It requires Foundry Local CLI 0.13.0 or later, plus separately installed CUDA and compatible cuDNN runtimes. Foundry Local does not download those dependencies.
After loading Qwen3.8-27B, users retrieve their local API endpoint with foundry server status. In Copilot’s Model providers settings, they add Foundry Local, enter that endpoint as the Base URL and add Qwen3.8-27B from Browse Catalog before selecting it in the model picker.
Microsoft plans to extend Qwen3.8-27B support to Macs and AMD GPUs, add more coding-optimized local models and deepen its Copilot integration.
Loading discussion...
Join the conversation
Explain which coding tasks would make that trade worthwhile.
Be the first to share a perspective or an experience.
Reader comments
Newest comments first. Replies stay oldest first.