Microsoft Shows Qwen3.8-27B in Foundry Local Connected to GitHub Copilot: 24 GB NVIDIA VRAM Allows 64K Context; Specific Speeds Are Absent From the Text and Chart Values and Full Methods Remain Unchecked
On November 5, 2026, Microsoft's Foundry blog showed how to run Qwen3.8-27B locally in Foundry Local and connect it to GitHub Copilot through BYOK. The 4-bit model is about 18 GB, with up to 64K tokens of context on a 24 GB NVIDIA GPU and up to the 262K model maximum on 32 GB or more; Macs and AMD GPUs are listed as future work. Microsoft says it generated faster than llama.cpp at every tested prompt length on an RTX 5090 and a DGX Spark, but the text gives no tokens per second, llama.cpp version or settings. Benchmark scores are linked as published results. The post also cautions that smaller local models may have limited reasoning compared with advanced cloud models.
On November 5, 2026, Microsoft published a post on its Foundry blog showing how to run the open Qwen3.8-27B coding model locally with Foundry Local and connect it to GitHub Copilot through Bring Your Own Key (BYOK). The pitch is that code and context stay on the developer's machine, inference costs are predictable, and work can continue offline. The post is a how-to with a performance claim, and the text gives no specific speed figure; the values in its two charts and the full method were not verified here. We checked the description of local inference and the Copilot endpoint connection only; we did not test whether the entire IDE, authentication, telemetry and toolchain work offline end to end.
The model is Qwen3.8-27B, which the GitHub request thread described below attributes to Alibaba. Microsoft calls it the primary optimization target because it pairs coding ability with a size that suits local use, and shows benchmark scores that it describes as published: 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. The post links them as published benchmarks and does not say that Microsoft ran these tests, and it does not compare the model with cloud models. It says plainly that local models may have limited reasoning compared with advanced cloud models and suggests a hybrid workflow: local for everyday coding and targeted subtasks, cloud for hard, high-reasoning work.
The engineering claims are about fitting the model on consumer hardware. Foundry Local uses ONNX Runtime to optimize the whole inference path on NVIDIA GPUs. For speed, it uses DFlash2 speculative decoding, in which a small drafter model predicts several tokens at once, plus CUDA graph fusions and kernels tuned for the NVIDIA SM121 architecture. For memory, it combines INT4 weights, KV-cache quantization, shared embedding memory and CPU offloading. With 4-bit quantization the model is about 18 GB. A GPU with 24 GB of VRAM can run it with a context window up to 64K tokens, and a GPU with 32 GB or more can support longer contexts up to the model's maximum of 262K tokens. Prefix caching and continuous batching serve repeated prompts and parallel requests.
The comparison with llama.cpp needs a careful reading. Microsoft tested the 4-bit model on an NVIDIA GeForce RTX 5090 with 32 GB of VRAM and on an NVIDIA DGX Spark with 128 GB of unified memory, using a dataset of real GitHub issues, and says Foundry Local generated tokens faster at every tested prompt length, with the gap widening beyond 131K tokens. The post identifies the tested model as 4-bit but gives no tokens-per-second values in text, no exact llama.cpp quantization format, version or full settings, and no measure of answer quality. The charts may show numbers, but we could not check them against a stated method, so the result is a vendor claim about relative generation speed on two machines.
The setup has clear limits. It needs Foundry Local CLI 0.13.0 or later, which the post says includes these optimizations. Installation uses WinGet, the commands are Windows batch commands, and NVIDIA GPU execution needs CUDA and a compatible cuDNN runtime installed separately because Foundry Local does not download them. After `foundry model load qwen3.8-27b`, the user reads the endpoint from `foundry server status`, then adds Foundry Local as a model provider in the GitHub Copilot app and picks Qwen3.8-27B in the model picker. Macs and AMD GPUs are listed as future work, so for now the post is about NVIDIA hardware with at least 24 GB of VRAM.
A support check on GitHub shows the catalog history. A user asked on August 19 for Qwen3.8-27B to be added to the Foundry Local catalog, and a repository collaborator replied on November 4 that it was now available in the catalog. That matches the date of the blog post. The thread is a community request, so it confirms catalog listing but says nothing about the level of support.
Our reading: this is a practical guide for developers with a high-memory NVIDIA GPU who want a private coding assistant, and it notes that smaller local models may have limited reasoning compared with advanced cloud models. Treat the speed claim as unverified, test on your own repository, and check whether the 64K context on a 24 GB card is enough for your tasks before replacing a cloud model.
Sources
FAQ
What hardware do I need to run Qwen3.8-27B this way?
The post asks for an NVIDIA GPU with at least 24 GB of VRAM, Foundry Local CLI 0.13.0 or later, and separately installed CUDA and compatible cuDNN runtimes, because Foundry Local does not download them. Installation uses WinGet. Macs and AMD GPUs are listed as future work, so they are not covered today.
How long can the context window be?
The post says the 4-bit model is about 18 GB. A 24 GB GPU can run it with a context window up to 64K tokens, and a GPU with 32 GB or more can support longer contexts up to the model maximum of 262K tokens. It gives no results on whether this suffices for repository-scale tasks, so test your own.
Is it really faster than llama.cpp?
Microsoft claims faster generation on RTX 5090 and DGX Spark, especially beyond 131K tokens. The text identifies the tested model as 4-bit but omits tokens per second, llama.cpp version, settings, exact quantization format and quality measures. We did not verify the chart values or full method.