Foundry Local、手元のGPUでQwen3.8-27Bを高速化

社内のコードを外に出さずにAIのコーディング支援を使いたい人に、選択肢が増えました。Microsoftは11月5日、手元のパソコンでモデルを動かすツールFoundry Localで、AlibabaのQwen3.8-27Bを最適化したと発表しました。GitHub Copilotから接続すれば、通信なしでも手元のモデルでコードを書かせられます。

ただし、今は条件があります。動くのはVRAMが24GB以上のNVIDIA製GPUで、MacとAMD製GPUへの対応はこれからです。Foundry LocalのCLIは0.13.0以降が必要で、この版はプレビューです。CUDAとcuDNNも別に入れる必要があります。

VRAMで使える文脈の長さが変わる

モデルは4ビットに量子化して約18GBまで小さくしました。VRAMが足りるかどうかで、一度に読ませられる量が変わります。

GPUのVRAM	コンテキストの上限
24GB	6万4,000トークン
32GB以上	26万2,000トークン

そのため、大きなリポジトリを丸ごと読ませたいなら、32GB以上が前提になりそうです。

llama.cppより速いのは、長い入力のときに目立つ

Microsoftは、実際のGitHubのissueのデータで、同じ4ビットのモデルをllama.cppと比べました。次の表は1秒あたりに生成したトークン数で、「/」の左がFoundry Local、右がllama.cppです。

入力の トークン数	RTX 5090	DGX Spark
4,096	266 / 1511.77倍	45 / 271.64倍
3万2,768	234 / 1521.54倍	42 / 261.59倍
6万5,536	200 / 1471.36倍	41 / 211.95倍
13万1,072	212 / 1101.94倍	34 / 152.28倍
26万	187 / 961.95倍	30 / 132.36倍

RTX 5090のVRAMは32GB、DGX Sparkの統合メモリは128GBです。Microsoftが測った値で、第三者の検証ではありません。速さの主な理由は、小さなモデルが次の数トークンを先に予測するDFlash2という手法と、NVIDIAの最新のGPU向けの調整です。プレフィックスキャッシュと同時実行のまとめ処理で、長い文脈や複数の依頼も扱います。

GitHub Copilotからの使い方

手順は短く、wingetでFoundry Localを入れてfoundry model load qwen3.8-27bでモデルを読み込み、foundry server statusで出るURLをGitHub Copilotアプリの設定Model providersに入れます。GitHubの資料によると、自分で接続先を設定するこの方式（BYOK）は、Copilotの契約が無くても使えます。ただ、Copilot BusinessとEnterpriseでは、IDEでの設定が組織の方針で無効な場合があります。