powered by TechFeed
表示モード
ハウツー

ローカルGPUでGitHub CopilotをオンデバイスAIコーディング環境に — MicrosoftがFoundry LocalとQwen3-8B-27BをRTX 3090/4090クラスで動作可能に

11月5日、Microsoft Foundryが「Bring Agentic Coding On-Device with Foundry Local」と題した記事を公開した。この記事では、MicrosoftのFoundry Localを使ってQwen3-8B-27BをローカルGPU上で動かし、GitHub Copilotのモデルバックエンドをローカルモデルへ差し替えることでオンデバイスのエージェント型コーディング環境を構築する方法について詳しく紹介されている。クラウドのAIコーディング支援は強力だが、コスト、プライバシー、オフライン時の停止という三つの問題が常につきまとう。Foundry Localはこのトレードオフを逆転させるアプローチだ。コードもコンテキストも手元のマシンから外に出さない。構成としてはCopilot自体はクライアントとして動作し続け、推論のバックエンドのみをクラウドからローカルモデルに差し替える点が重要だ。Qwen3-8B-27Bをローカルで動かす意義今回の主役モデルはQwen3-8B-27B(モデルカード)。公開ベンチマークでは、エージェント型のターミナルタスク、...

11月5日、Microsoft Foundryが「Bring Agentic Coding On-Device with Foundry Local」と題した記事を公開した。この記事では、MicrosoftのFoundry Localを使ってQwen3-8B-27BをローカルGPU上で動かし、GitHub Copilotのモデルバックエンドをローカルモデルへ差し替えることでオンデバイスのエージェント型コーディング環境を構築する方法について詳しく紹介されている。

クラウドのAIコーディング支援は強力だが、コスト、プライバシー、オフライン時の停止という三つの問題が常につきまとう。Foundry Localはこのトレードオフを逆転させるアプローチだ。コードもコンテキストも手元のマシンから外に出さない。構成としてはCopilot自体はクライアントとして動作し続け、推論のバックエンドのみをクラウドからローカルモデルに差し替える点が重要だ。

Qwen3-8B-27Bをローカルで動かす意義

今回の主役モデルはQwen3-8B-27B(モデルカード)。公開ベンチマークでは、エージェント型のターミナルタスク、ソフトウェアエンジニアリング、リポジトリ規模のコード生成で幅広い能力を示している。

ベンチマーク スコア
Terminal Bench 2.1(エージェント型ターミナルコーディング) 73.0
SWE-bench Pro(エージェント型コーディング) 61.7
NL2Repo-Bench(リポジトリレベルのコード生成) 42.3
DeepSWE 1.1(エージェント型コーディング) 42.2

4ビット量子化(モデルの重みを低ビット精度に圧縮してメモリ使用量を削減する手法)により、モデルサイズは約18 GBまで削減される。VRAMが24 GB以上のGPUで動作し、RTX 3090/4090クラスを持つ開発者なら手が届く現実的なラインだ。

ただし、後述するパフォーマンス計測のテスト環境はRTX 5090(32 GB VRAM)とDGX Sparkであり、必要最低限の24 GB GPUでのパフォーマンスは計測値より低くなる可能性がある点は留意しておきたい。

推論パイプラインの最適化

推論エンジンにはONNX Runtime GenAIを採用し、以下の最適化を組み合わせている。

  • 推論速度の向上: FlashAttention 2(アテンション計算をタイル分割してHBMアクセスを削減する手法)とCUDAグラフフュージョンを適用。最新のNVIDIA SM121アーキテクチャ向けにカーネルを最適化している。なお元記事では「DFlash2」と表記されており、Foundry Local固有の実装名称である可能性がある。
  • メモリ使用量の削減: INT4重み処理、KVキャッシュの量子化、エンベディングメモリの共有、CPUオフロードを組み合わせる。
  • 長文脈と並列処理: プレフィックスキャッシング(同じプロンプトの先頭部分を再計算せず使い回す仕組み)と連続バッチング(複数リクエストをまとめて処理する手法)により、リポジトリ規模のコンテキストを複数の並行リクエストで効率的に処理する。

パフォーマンス比較では、llama.cppと4ビットQwen3-8B-27Bを同一ハードウェアで比較した結果、Foundry Localはすべてのプロンプト長でllama.cppを上回る生成速度を記録。特に131Kトークン以上の長文脈ではその差が顕著に広がった。テスト環境はNVIDIA GeForce RTX 5090(32 GB VRAM)とNVIDIA DGX Spark(128 GB統合メモリ)の2種類。

最適化レシピはGitHubで公開されている。

GitHub Copilotとの接続手順

Copilot自体はクライアントとして引き続き動作し、モデルバックエンドとしてFoundry Local経由のローカルモデルを参照する構成をとる。セットアップの要点は次のとおりだ。

必要環境: VRAM 24 GB以上のNVIDIA GPU、Foundry Local CLI 0.13.0以降。CUDAとcuDNNは別途インストールが必要(Foundry Localは自動ダウンロードしない)。

1. Foundry Local CLIのインストール

winget install Microsoft.FoundryLocal
foundry --version

バージョンが0.13.0以上であることを確認する。すでに起動中の場合はfoundry server restartを実行すること。

2. モデルのロードとAPIエンドポイントの確認

foundry model load qwen3-8b-27b
foundry server status

foundry model loadは未ダウンロードの場合、自動でモデルをダウンロードする。foundry server statusで表示されるAPIエンドポイント(ポート番号含む)を控えておく。

3. GitHub CopilotへのBYOK接続

GitHub Copilotアプリの設定→「Model providers」→「Add provider」→「Foundry Local」を選択し、前のステップで取得したBase URLを入力する。その後、カタログからQwen3-8B-27Bを検索して追加する。BYOK(Bring Your Own Key)の他クライアントでの設定方法は公式ガイドを参照。

4. モデルの切り替え

GitHub Copilotのモデルピッカーでプロバイダーを「Foundry Local」に切り替え、Qwen3-8B-27Bを選択すればセットアップ完了だ。

注意点:クラウドモデルとの使い分け

記事では「複雑で高度な推論が必要なタスクにはクラウドモデルが依然として強い選択肢」と明記している。ローカルモデルはサイズが小さい分、推論能力に限界がある。日常的なコーディングや局所的なサブタスクの処理に向いており、クラウドモデルと組み合わせたハイブリッド運用が現実的な使い方だ。

今後のロードマップ

現時点ではNVIDIA GPU(Windows)向けのみだが、Mac対応・AMD GPU対応と対応モデルの拡充が計画されている。GitHub Copilotとのより深いインテグレーションも予定されている。

詳細はBring Agentic Coding On-Device with Foundry Localを参照していただきたい。