こんにちは、マイクロアドでサーバサイドエンジニア 兼 システム開発部の副部長をしている奈良橋です。
最近、多くの開発組織を悩ませているのが「GitHub CopilotをはじめとするAIコーディング支援ツールのライセンス費用増加」ではないでしょうか。
便利だし手放せない、けれど開発メンバー全員分となるとコストがジワジワと重くのしかかってくる…。
「それなら、最近流行りのオープンなローカルLLMを使って、自分たちで専用のコーディング支援サーバーを立てちゃえばいいのでは？」
そんな野望を抱いていた矢先、幸運にも検証用のモンスターマシンをお借りすることができました。 手のひらサイズの超小型AIスパコン、「ThinkStation PGX」です。
今回は、この超小型スパコンを駆使して、GitHub Copilotのローカル代替環境構築に本気で挑んだ（そして、大いに泥臭く試行錯誤した）記録をお届けします。
※ 本検証は2026年6月時点のものです。現在はさらに優れたモデルが登場しているため、最新モデルでの追試には十分な価値があります。
※ NVIDIAは同じ「GB10」を搭載する兄弟機「DGX Spark」を、公式に「世界最小のAIスパコン」と呼んでいるところから、このブログでもAIスパコンと表現しています。
- 1. 弁当箱サイズに「GB10 + 128GBメモリ」というロマン機材
- 2. 最初の壁：Gemma 4 31Bでの「ソロ動作 OK! マルチ動作 NG」
- 3. Docker Imageの罠と、Qwen3 Coder Next 80Bへの挑戦
- 4. vLLM vs SGLang！ボトルネックの正体は「ミドルウェア」だった
- 5. そしてここでタイムアップ
- 6. 結論：GitHub Copilotの代替には…ならない？
- 7. それでも、ThinkStation PGXが示した「圧倒的なポテンシャル」
- おわりに
1. 弁当箱サイズに「GB10 + 128GBメモリ」というロマン機材
今回検証に使った ThinkStation PGX、何がヤバいかというと、そのサイズとスペックのギャップです。
- サイズ: 約 150x150x50.5mm（ほぼ正方形の弁当箱、手のひらサイズ）
- GPU/CPU: NVIDIA Grace Blackwellアーキテクチャを採用した「GB10 Superchip」
- メモリ: 128GB のユニファイド・システム・メモリ（LPDDR5X-8533MT/s）
💡 ここがポイント！
ローカルLLMを動かす上でのボトルネックになりがちな「GPUのVRAM容量」ですが、このサイズで128GBの高速な統合メモリが使えます！ということは、「MacなどのローカルPCなら動かすことすら諦めるようなモデル（80Bクラスなど）が、このマシンがあれば動く」ことを意味します。
「これなら、何名かでシェアしながら使えるAIアシスタントサーバーが作れるのでは？」 胸を高鳴らせて、検証をスタートしました。
2. 最初の壁：Gemma 4 31Bでの「ソロ動作 OK! マルチ動作 NG」
まずは小手調べとして、Googleの「Gemma 4 31B」を動かしてみることにしました。 30B（300億パラメータ）クラスなら、128GBメモリがあれば余裕で動くはずです。
実際に動かしてみると、自分1人で使う分には、それなりに実用的なパフォーマンス（速度）で動いてくれました。 「お、これはいけるか？」と思ったのも束の間、チームの他のメンバーにも繋いでもらい、2名以上で同時にアクセスした瞬間、状況は一変します。
- 1人利用時: スラスラとコードを提案してくれる。
- 2人以上での同時利用時: レスポンスが返ってくるまでに、なんと体感で数十分レベルの遅延が発生。
1人占めする分には優秀ですが、これでは「チーム開発におけるGitHub Copilotの代替」としてはお話になりません。ここから、私たちの長い試行錯誤が始まりました。
3. Docker Imageの罠と、Qwen3 Coder Next 80Bへの挑戦
「30Bクラスで駄目なら、より賢く、かつ並列処理に強そうな巨大モデルを試すしかない」
そう考えた私たちは、よりコーディングに特化した80B（800億パラメータ）クラスのモデル「Qwen3 Coder Next(FP8)」の検証へとシフトします。ここから128GBユニファイドメモリの本領発揮です。
しかし、ここでエンジニアなら誰もが一度は通る「環境構築の罠」にハマりました。
「GB10最適化Image」の存在を見落とすな（戒め）
LLMの高速サービング用ミドルウェアとしてデファクトスタンダードになりつつある vLLM を選択し、Docker環境を構築したのですが、ここで何も考えずに vllm/vllm-openai:latest のようなImageを選んでしまいました。
これだと、ThinkStation PGXに搭載されている最先端のチップ「GB10」のパワーを100%引き出すことができません。
実は、検証のかなり後半（Qwen3 Coder Nextの検証に入った段階）になってようやく、「このチップアーキテクチャに最適化された専用のDocker Image」が存在することに気づきました。それが、NVIDIAがNGCで配布している nvcr.io/nvidia/vllm:26.05-py3 です。
ThinkStation PGXと同じ「GB10」を搭載するDGX Spark向けにチューニングされたビルドで、CUDA 13系をベースに提供されています（2026年6月の検証時点のものなので、実際に試す際は最新のタグを確認してください）。皆さんはDockerのImage選定の際は、くれぐれも気をつけてください。
4. vLLM vs SGLang！ボトルネックの正体は「ミドルウェア」だった
適切なDocker Imageを見つけ、本命の「Qwen3 Coder Next」の検証に移りました。 Image切り替えの効果は確かにあり、パフォーマンスは“微増”しました。…が、複数人で同時に使うにはほど遠い速度のままです。
せっかく128GBのユニファイドメモリがあるので、「メモリをギリギリまで贅沢に使って、少しでも賢い状態で動かそう」という考えで、まずは 8bit量子化モデル をvLLMで走らせてみます。
- 結果： パフォーマンスがいまいち（複数人、並列で実行すると実用レベルの速度に届かない）。
- 仮説： 並列実行時、メモリ使用量が頭打ちになっているように見えた。ボトルネックはメモリ容量のはず…！
- 対策： ならばメモリに余裕を持たせるため、もっと軽量な 4bit量子化モデル に切り替えてみよう！
- 結果： なぜかパフォーマンスが変わらず、速度が出ない。
「なぜ4bitにしても速くならないのか…」と頭を抱えていた時、次なる仮説に行き着きました。 「ミドルウェア（推論エンジン）自体を変えてみたらどうだ？」
そこで、vLLMから近年パフォーマンスの高さで注目を集めている SGLang に切り替え、4bit量子化モデルを走らせてみることに。
すると…。
「これならギリギリ待てるな…」と思える程度のレスポンス速度を叩き出すことに成功しました！ SGLangの持つ効率的なPrefix Caching（Radix Attention）や並列スレッドの捌き方が、マルチユーザー環境で見事にハマった瞬間でした。
ベンチマーク結果
ここまでの話はだいぶ「体感」ベースなので、簡単なベンチマークも取ってみました。 1リクエストあたり512トークンを生成するタスクを、同時接続数を変えながら実行しています。 「1リクエストあたり」は各リクエストの生成速度、「システム全体」はサーバー全体での合算スループット（バッチングの効率）です。
vLLM + unsloth/Qwen3-Coder-Next-FP8-Dynamic（8bit量子化）（3回実行の平均値）
| 同時接続数 | 1リクエストあたり | システム全体 |
|---|---|---|
| 1 | 25.8 tok/s | 25.8 tok/s |
| 3 | 21.2 tok/s | 63.7 tok/s |
| 5 | 17.2 tok/s | 85.8 tok/s |
| 10 | 11.1 tok/s | 111.3 tok/s |
SGLang + RedHatAI/Qwen3-Coder-Next-NVFP4（4bit量子化）（1回実行）
| 同時接続数 | 1リクエストあたり | システム全体 |
|---|---|---|
| 1 | 34.9 tok/s | 34.9 tok/s |
| 3 | 27.6 tok/s | 82.8 tok/s |
| 5 | 21.4 tok/s | 107.0 tok/s |
| 8 | 21.5 tok/s | 172.0 tok/s |
| 10 | 13.4〜21.7 tok/s ※ | 133.5 tok/s |
※10並列では、まず8リクエストが約21.7 tok/sで処理され、残りの2リクエストは約13.4 tok/sまで低下しました。
この結果からは、次の2点が読み取れます。
- vLLM（FP8）: 同時接続数が増えるほど1リクエストあたりの速度が低下し、10並列では11.1 tok/s（1並列時の半分以下）まで落ち込む
- SGLang（NVFP4）: 8並列でも約21.5 tok/sを維持し、システム全体は172 tok/sに到達。vLLMの10並列時（約111 tok/s）を大きく上回る
なお、両者は量子化精度（FP8 / NVFP4）が異なるため、純粋なミドルウェア同士の比較ではありません。ただ、前述の通り「同じ4bit量子化モデルに切り替えてもvLLMでは速度が変わらなかった」ことを踏まえると、この差はSGLangの並列スケジューリングの上手さによるものが大きいと考えています。
5. そしてここでタイムアップ
ここまでの試行錯誤、実はすべて「約2週間」の中での出来事です。 ThinkStation PGXは社内の検証用機材で、6月10日にインフラチームの方に環境を整えてもらい、6月25日に返却。
速度面は「SGLangなら行ける」という手応えを、ようやく掴めたところでした。一方で、この頃にはモデルの「賢さ」の底も見え始めていました。 それでもなおパフォーマンスの改善に食い下がっていたのは、「賢さはともかく、パフォーマンスだけでも結果を出したい」という、エンジニアの意地がそうさせたのだと考えています。
そして迎えたタイムアップ。パフォーマンスは、最後まで「十分」とは言い切れないままでした。
6. 結論：GitHub Copilotの代替には…ならない？
最先端の「ThinkStation PGX」のパワーと「SGLang」の組み合わせにより、80Bクラスの巨大なモデルを、8人同時接続でも1人あたり約21 tok/s という速度で動かすところまでは到達できました。
では、目的の「GitHub Copilotの契約を解約して、これに完全に代替できるか？」という判断につきましては…。
2026年6月時点での正直な評価は、「30B〜80Bクラスのオープンモデルの賢さでは、まだ代替には至らない」です。
速度面のハードルはクリアできそうでしたが、コーディングにおける「複雑な文脈の理解度」や「意図を先回りした高度なコード提案」の精度を比較すると、明確な差が出ました。 やはり本家GitHub Copilotに用意されたClosedモデル（GPT、Claude、Gemini系）の牙城を崩すには、このクラスのモデルの "素の賢さ" では少し力不足でした。
7. それでも、ThinkStation PGXが示した「圧倒的なポテンシャル」
今回の検証で「完全代替」に届かなかったのは、あくまで2026年6月時点の30B〜80Bクラスのオープンモデルの仕様上の限界で、「最近登場したQwen3.8 27Bならまた状況を変えることもあるのでは？」と改めて妄想することもあります。むしろ、この小さな筐体が秘めるポテンシャルには心から驚かされました。
なんと言っても、「128GBのユニファイドメモリ」の存在が偉大すぎます。 今回は行いませんでしたが、このメモリ容量があれば、クラウド上で非常に高価なGPUインスタンスを借りることなく、30B〜80Bクラスのモデルを「ファインチューニング」することもできるようです。
「ローカルでファインチューニングまで見据えた開発環境を、デスクの片隅に置ける」
それだけのパワーをこの弁当箱サイズに詰め込んだ素晴らしい製品です。
おわりに
今回は、弁当箱サイズのAIスパコン「ThinkStation PGX」を使って、GitHub Copilotのローカル代替に挑戦しました。
結果は「完全代替ならず」。しかし約2週間の検証を通じて感じたのは、ミドルウェアやモデル、パラメータなど、まだ「何を選べばいいのかわからない」ことだらけだということでした。だからこそ掘り下げ甲斐があって、エンジニアをワクワクさせる領域なのだと強く感じました。
30B〜80Bクラスではあと一歩届かなかった賢さも、「さらに巨大な、もっと賢いモデル（200B超クラスなど）」で再挑戦していきたい野望があります！
オープンモデルの進化もミドルウェアの進化も日進月歩です。この記事が、「ローカルLLMを自分の手で動かしてみたい」という方の背中を少しでも押せたら幸いです。
