MicrosoftがFoundry LocalのQwen3.8-27BをGitHub Copilotに接続：NVIDIAの24 GB VRAMで64Kコンテキスト；本文に具体的な速度はなく、グラフの数値と完全な方法は未確認
2026年11月5日、MicrosoftのFoundryブログは、Foundry LocalでQwen3.8-27Bをローカル実行し、BYOKでGitHub Copilotにつなぐ方法を紹介しました。4ビットのモデルは約18 GBで、VRAM 24 GBのNVIDIA GPUではコンテキスト最大64K、32 GB以上ではモデル上限の262Kまで使え、MacとAMD GPUは今後の課題とされています。RTX 5090とDGX Sparkで、試したすべてのプロンプト長でllama.cppより速かったと述べますが、本文に毎秒トークン数もllama.cppのバージョンや設定もありません。ベンチマーク成績は公開済みの結果へのリンクです。 記事はまた、小規模なローカルモデルは高度なクラウドモデルに比べて推論力が限られる可能性があると注意しています。
2026年11月5日、MicrosoftはFoundryブログで、オープンなコーディングモデルQwen3.8-27BをFoundry Localでローカル実行し、Bring Your Own Key（BYOK）でGitHub Copilotにつなぐ方法を紹介しました。売りは、コードと文脈が開発者のマシンの中にとどまること、推論コストが予測しやすいこと、オフラインでも作業を続けられることです。性能の主張を含む手順解説で、本文に具体的な速度の数字はなく、2つのグラフの数値と完全な方法は今回確認していません。 確認したのはローカル推論とCopilotのエンドポイント接続の説明だけで、IDE全体、認証、テレメトリー、ツールチェーンが完全にオフラインで動くかは実測していません。
モデルはQwen3.8-27Bで、後述のGitHubのリクエストスレッドはAlibabaのものとしています。Microsoftは、コーディング能力とローカル利用に適した大きさを兼ね備えるため、これを主要な最適化対象にしたと述べ、公開済みと位置づけるベンチマークの成績を示しています。Terminal Bench 2.1が73.0、SWE-bench Proが61.7、NL2Repo-Benchが42.3、DeepSWE 1.1が42.2です。記事はこれらを公開されたベンチマークとしてリンクしており、Microsoftがこの試験を実施したとは述べておらず、クラウドのモデルとの比較もしていません。ローカルモデルは高度なクラウドモデルに比べ推論能力が限られる場合があるとはっきり述べ、日常のコーディングや絞った小タスクにはローカル、難しく高い推論が必要な作業にはクラウドというハイブリッドの使い方を勧めています。
技術面の主張は、モデルを一般向けハードウェアに収めることに関するものです。Foundry LocalはONNX Runtimeを使い、NVIDIA GPU上の推論経路全体を最適化します。速度のために、小さなドラフトモデルが複数トークンを一度に予測するDFlash2の投機的デコード、CUDAグラフの融合、NVIDIA SM121アーキテクチャ向けに調整したカーネルを使います。メモリのために、INT4の重み、KVキャッシュの量子化、埋め込みメモリの共有、CPUオフロードを組み合わせます。4ビット量子化でモデルは約18 GBです。VRAM 24 GBのGPUではコンテキストウィンドウ最大64Kトークンで動かせ、32 GB以上のGPUではモデルの上限262Kトークンまでの長いコンテキストに対応できます。プレフィックスキャッシュと連続バッチ処理が、繰り返しのプロンプトと並列リクエストを支えます。
llama.cppとの比較は慎重に読む必要があります。Microsoftは、VRAM 32 GBのNVIDIA GeForce RTX 5090と、128 GBのユニファイドメモリを持つNVIDIA DGX Sparkで、実際のGitHubイシューのデータセットを使って4ビットモデルを試しました。Foundry Localはテストしたすべてのプロンプト長でトークン生成が速く、131Kトークンを超えると差が広がると述べています。記事は比較に4ビットモデルを使ったと明記していますが、本文には毎秒トークン数、llama.cppの具体的な量子化形式、バージョンや設定の全体、回答品質の指標がありません。グラフには数字があるかもしれませんが、明記された方法と突き合わせて確かめることはできなかったため、この結果は2台のマシンでの相対的な生成速度に関するベンダーの主張です。
セットアップには明確な制限があります。Foundry Local CLI 0.13.0以降が必要で、記事はこれらの最適化が含まれると述べています。インストールはWinGetで、コマンドはWindowsのバッチコマンドです。NVIDIA GPUでの実行にはCUDAと互換性のあるcuDNNランタイムを別途入れる必要があり、Foundry Localはそれらをダウンロードしません。`foundry model load qwen3.8-27b`の後、`foundry server status`でエンドポイントを確認し、GitHub CopilotアプリでFoundry Localをモデルプロバイダーとして追加し、モデルピッカーでQwen3.8-27Bを選びます。MacとAMD GPUは今後の課題とされているため、現時点でこの記事が対象にするのはVRAM 24 GB以上のNVIDIAハードウェアです。
GitHubでの裏付け確認から、カタログの経緯がわかります。あるユーザーが8月19日にQwen3.8-27BをFoundry Localカタログへ追加するよう求め、リポジトリのコラボレーターが11月4日に、カタログで利用可能になったと返信しました。これはブログ記事の日付と合っています。このスレッドはコミュニティの要望なので、カタログへの掲載は確認できますが、サポートの水準については何もわかりません。
当方の見方では、これは大容量メモリのNVIDIA GPUを持ち、プライベートなコーディングアシスタントを求める開発者向けの実用的なガイドで、小規模なローカルモデルは高度なクラウドモデルより推論力が限られる可能性があると注意しています。速度の主張は未検証として扱い、自分のリポジトリで試し、クラウドモデルを置き換える前に、24 GBのカードでの64Kコンテキストが作業に足りるかを確かめてください。
Sources
FAQ
この方法でQwen3.8-27Bを動かすのに必要なハードウェアは何ですか？
記事が求めるのは、VRAM 24 GB以上のNVIDIA GPU、Foundry Local CLI 0.13.0以降、そして別途インストールするCUDAと互換性のあるcuDNNランタイムです。Foundry Localはこれらをダウンロードしません。インストールはWinGetを使います。MacとAMD GPUは今後の課題とされており、現時点では対象外です。
コンテキストウィンドウはどこまで長くできますか？
記事によれば4ビットのモデルは約18 GBで、VRAM 24 GBのGPUではコンテキスト最大64Kトークンで動かせ、32 GB以上のGPUではモデル上限の262Kトークンまでの長いコンテキストに対応できます。リポジトリ規模の作業に足りるかどうかの結果は示されていないため、自分の環境で試してください。
本当にllama.cppより速いのですか？
それはベンダーの主張です。MicrosoftはRTX 5090とDGX Sparkで、試したすべてのプロンプト長でFoundry Localの生成が速く、131Kトークンを超えると差が広がると述べています。しかし本文には毎秒トークン数も、llama.cppのバージョン、設定、具体的な量子化形式も（テストモデルが4ビットであることは記載）、品質の指標もなく、数字があるとしてもグラフの中だけです。