Microsoft Runs Qwen3.8 27B Locally for GitHub Copilot on 24 GB GPUs

What Microsoft shipped

Microsoft's Foundry team said on November 5 that Foundry Local can now run Qwen3.8-27B on a developer's own hardware and hand it to GitHub Copilot through Bring Your Own Key. The company's pitch is predictable inference costs, greater privacy, and offline use.

Setup is short. Install the Foundry Local CLI, version 0.13.0 or later, load the model with foundry model load qwen3.8-27b, and read the endpoint from foundry server status. Then add Foundry Local as a model provider in the GitHub Copilot app, paste that address as the base URL, and pick the model.

The model itself is not new. Qwen3.8-27B is the Apache 2.0 release with a native context of 262,144 tokens. When we covered its hardware requirements in August, the smallest official file was a 30.89 GB FP8 build and Qwen published no minimum specification. What changed is the packaging: a supported 4-bit build of roughly 18 GB, wired directly into a mainstream coding tool.

The hardware bar is still high

The Copilot setup needs an NVIDIA GPU with at least 24 GB of VRAM. On that class of card, context stops at 64K tokens. Reaching the full 262K requires 32 GB or more. CUDA and a compatible cuDNN runtime must be installed separately, because Foundry Local does not download them.

That rules out most laptops, and it rules out Macs and AMD GPUs for now. Microsoft lists both as roadmap items rather than shipping targets, and it gives no date. For now, this is a release for owners of high-end NVIDIA desktop cards and workstations.

Microsoft also says Foundry Local generated faster than llama.cpp at every prompt length it tested, on an RTX 5090 and a DGX Spark, with the gap widening beyond 131K tokens. The speedup rests on DFlash speculative decoding, tuned kernels, and quantized KV caches. This is a vendor comparison on Microsoft's own workload of real GitHub issues, so treat it as a claim to reproduce rather than a settled result.

What the benchmarks do and do not show

Microsoft's post quotes 73.0 on Terminal Bench 2.1, 61.7 on SWE-bench Pro, 42.3 on NL2Repo-Bench, and 42.2 on DeepSWE 1.1. Those match the scores on Qwen's model card. Microsoft attributes them to the model's published results and does not present them as measurements of the 4-bit build, so nobody should assume the quantized version scores identically.

Microsoft is also modest about the ceiling. It warns that smaller local models may reason less well than advanced cloud models, and it recommends a hybrid workflow: local for everyday coding and targeted subtasks, cloud for complex work.

A local model is not the same as a silent network

Microsoft says that with this setup, code and context stay on the device. Its post does not describe what other Copilot traffic, if any, still leaves the machine.

That gap matters. For Copilot CLI, GitHub states that choosing a local model does not turn on offline mode or disable GitHub telemetry. Offline mode is a separate choice, made by setting COPILOT_OFFLINE=true. GitHub's documentation adds that full network isolation also requires a model provider that is local or inside the same isolated environment.

Those statements cover the CLI, while Microsoft's walkthrough uses the Copilot app, and we found no equivalent statement for the app. Anyone choosing this setup for confidentiality should watch the actual network traffic rather than assume the model choice settles it.

There may be a practical upside on billing. GitHub's Copilot SDK documentation says Bring Your Own Key requests are tracked by your provider and do not count against Copilot premium request quotas, and it lists Foundry Local as needing no API key. If the app follows the same rule, routine agent work on a GPU you already own would stop drawing on that allowance.