はじめに
本来、7GPUを搭載できるマシンを調達するつもりだった。
ローカルでフロンティア級のコーディングエージェントを動かすには、最低でも4GPUへ拡張できる筐体が必要。その横で画像生成、動画生成、TTS、リップシンクも動かす。そう考えて足し算すると、コンシューマー向けPCの拡張性では足りず、7GPUスロットを持つ業務用マシンに行き着いた。
ところが、その構成に必要なメモリの小売価格がコンシューマー向けと比べて法外だった。メーカーへ問い合わせたが、この記事を書いている時点では返事も来ていない。
その待ち時間に、前提の方が壊れた。
poolsideのLaguna S 2.1 NVFP4をRTX PRO 6000 Blackwell Max-Q 1枚で動かしたところ、公式ベンチ上ではDeepSeek V4 Pro級のコーディング・エージェント性能を持ち、手元のリポジトリ修復課題も完走した。しかもMoEなので速い。
「4枚でLLMをどう載せるか」を考えていたはずが、「1枚で完結するLLMを、音声やバッチ生成からどう隔離するか」という別の問題になった。
この記事は、新しいモデルの紹介というより、モデルの進歩によってハードウェア調達計画そのものが変わった記録である。
検証日は2026年7月23日。Laguna S 2.1は公開直後で、チェックポイントも検証中に更新された。数字は将来変わる可能性がある。
なぜ最初は7GPU必要だと思っていたのか
Kotoniaでは、単にチャット用LLMだけを動かしているわけではない。
- キャラクター会話とコーディングエージェント用のLLM
- Qwen3-TTSによるストリーミング音声生成
- Dittoによるリアルタイムのtalking head
- HiDream系の画像生成・編集
- LTX-2系の動画生成
- 実験中のモデルと本番系の退避先
現在のマシンは、GPU 0が96GBのRTX PRO 6000 Blackwell Max-Q、GPU 1が24GBのRTX PRO 4000 Blackwellという構成だ。本番待機時でもGPU 0側は画像・動画・ローカルLLMなどで約72.8GiB、GPU 1側は音声系で約19.2GiBを使っている。
96GBへ何を常駐させ、何をAPIへ逃がしてきたかは、以前の96GB GPUの運用記録にまとめた。その時点でもVRAM容量だけでなく、ワークロードの役割分担が設計の中心だった。
ここへフロンティア級LLMを追加しようとすると、モデルを複数GPUへ分割する前提になる。最低4枚をLLM用として見積もり、他の生成系も物理的に分けようとすると、7GPUスロットは突飛な結論ではなかった。
単一筐体なら高速なGPU間通信、共有ストレージ、一元的な電源管理という利点もある。将来さらに大きなモデルをtensor parallelで動かすなら、今でも正しい選択肢だと思う。
ただし、その判断は「欲しい性能のLLMは1GPUに収まらない」という前提に依存していた。
117.6Bなのに、毎トークン動くのは8.5B
Laguna S 2.1は総パラメータ117.6B、1トークンあたりのactive parameterは8.5BのMoEモデルだ。NVFP4チェックポイント本体は約67GiBで、96GB GPUならKV cacheを含めて単体起動できる。
今回使った構成は次の通り。
| 項目 | 構成 |
|---|---|
| GPU | RTX PRO 6000 Blackwell Max-Q 96GB / SM120 |
| モデル | Laguna S 2.1 NVFP4 |
| vLLM | 0.25.1 |
| PyTorch | 2.11.0+cu130 |
| FlashInfer | 0.6.13 |
| context | 64K |
| max sequences | 4 |
| MoE backend | FLASHINFER_CUTLASS |
| attention decode | flashinfer-native |
| KV cache | FP8 E4M3 |
vLLMは既存本番環境の0.24.0を触らず、Laguna専用venvで0.25.1を用意した。公式のvLLM recipeを基準にしつつ、このGPUではDGX Spark向けのsm_121aではなくsm_120aを指定した。
重みのGPUロードは約15秒だったが、初回engine初期化は957.49秒。そのうち約811秒がBlackwell向けカーネルのprofilingとcold JITだった。一度cacheができた後、64K・4並列構成での再起動は47.35秒まで短縮した。
つまり、インストール直後の「なかなか起動しない」は障害ではなかった。ただし、コンテナを毎回捨てる運用や頻繁な環境更新とは相性が悪い。
公式ベンチは本当に信じてよいのか
モデルカードに掲載された、2026年7月21日時点の主要なエージェント系ベンチはこうなっている。
| Benchmark | Laguna S 2.1 | DeepSeek V4 Pro Max |
|---|---|---|
| Terminal-Bench 2.1 | 70.2 | 64.0* |
| SWE-bench Multilingual | 78.5 | 76.2 |
| SWE-Bench Pro | 59.4 | 55.4 |
| DeepSWE | 40.4 | 9.0* |
| SWE Atlas | 46.2 | 27.2* |
| Toolathlon Verified | 49.7 | 55.9* |
*はモデル提供元ではなく第三者による評価値。Laguna側は実行trajectoryも公開されている。
これだけ見ると革命的だが、ここで「Lagunaはあらゆる意味でV4 Proと同じくらい賢い」と読むのは危険だ。これらが強く示しているのは、主にコードを読み、ツールを使い、複数ステップでリポジトリを修正する能力である。
そこで手元では、短答、厳密形式、長文検索、tool call、コード生成、CLIエージェントによる実リポジトリ修復を分けて測った。
手元の軽量ベンチ
比較対象は、これまでローカルLLMとして使っていたThinkCap。両方ともOpenAI互換APIとしてvLLMで起動し、同じプロンプトを投げた。
速度
| タスク | ThinkCap | Laguna S 2.1 |
|---|---|---|
| code-chat | 111.0 tok/s / TTFB 87ms | 97.5 tok/s / TTFB 26ms |
| character-chat | 65.1 tok/s / TTFB 91ms | 99.8 tok/s / TTFB 31ms |
| studio-enhance | 104.1 tok/s / TTFB 87ms | 98.1 tok/s / TTFB 30ms |
| concurrent x4 | 185.5 tok/s aggregate | 267.9 tok/s aggregate |
| concurrent x4 median TTFB | 3356ms | 50ms |
単発のcode-chatだけならThinkCapの方が少し速い。一方、キャラクターチャットと4並列ではLagunaが大きく伸びた。特に4並列のaggregate 267.9 tok/sとmedian TTFB 50msは、117.6Bという総パラメータ数から想像していた挙動ではない。
MoEはモデル全体をVRAMへ置く必要があるが、毎トークンで全パラメータを計算するわけではない。VRAMは重いが、計算は軽い。96GB GPUとの組み合わせで、この性質がそのまま出た。
能力
| 評価 | ThinkCap | Laguna S 2.1 |
|---|---|---|
| 軽量タスク | 5/6 | 6/6 |
| 拡張能力ベンチ（厳密採点） | 19/28 | 12/28 |
| 長文needle | 2/2 | 2/2 |
| tool use | 3/3 | 3/3 |
| コード生成 | 2/3 | 3/3 |
| kotonia-cli repo修復（hidden込み） | 11/12 | 12/12 |
一見すると、拡張能力ベンチの12/28はかなり悪い。中身を見ると二種類の失点があった。
一つは、答え自体は正しいのに「整数だけ」と指定した問題へ説明を付けてしまう形式違反。reasoningを有効にした4問は意味上すべて正解だったが、厳密一致では0/4になった。もう一つは、コード追跡、組合せ、状態管理などで実際に答えを間違えたケースだ。
したがって、形式違反だけを理由にモデル全体を弱いと判断するのも、意味上の正解だけを拾って満点扱いするのも違う。今回の結果は、Lagunaが短い指示追従の万能モデルではなく、コード生成・tool use・長いエージェント作業に能力が偏ったモデルであることを示している。
kotonia-cliでは満点だった
最も重視したのは、kotonia-cliへ小さな壊れたPythonリポジトリを渡し、複数ファイルを修正させる課題だ。
課題には次の罠を入れた。
- SKUの空白除去と大文字正規化
- 複数行が同じ正規化後SKUになる場合の在庫合算
- 予約処理全体のatomicity
- 売上集計の並び順とtie-break
- 割引境界値のinclusive判定
- banker's roundingではなくround-half-up
エージェントから見えるテストは6件。終了後に追加するhidden test込みで12件とした。
ThinkCapは11/12。正規化すると同じSKUになる複数予約を事前合算できず、在庫不足時のatomicityを1件落とした。
Lagunaは10 iterations、91秒で12/12。DecimalとROUND_HALF_UPまで使い、hidden testの重複SKUも通した。
小さな課題一つで一般化はできない。それでも、短答ベンチでは不器用だったモデルがCLIエージェントでは明確に勝った。この結果を見て、公式のコーディング・エージェントベンチは少なくともモデルの得意分野を正しく表している可能性が高いと判断した。
36Kコンテキストと長いprefill
1200レコードの中から指定IDを探すneedle課題は、入力36,079 tokensで成功し、リクエスト全体は3.17秒だった。
数字だけなら十分速い。ただし、リアルタイム音声と同居させる場合は平均速度よりprefillの瞬間負荷が問題になる。
キャラクターチャット程度の短い履歴なら、LagunaのTTFB 30ms前後はほぼ無視できる。一方、新しいリポジトリを読み込ませる、巨大ファイルを追加する、会話をcompaction後に再構築する、といった場面では長いprefillが発生する。
prefix cacheが効くエージェントの継続ターンなら、毎回全履歴を計算し直すわけではない。それでもcache missは消えない。コーディング需要が増えたとき、Qwen3-TTSのストリーミングを一瞬でも止める可能性がある。
DFlashは今回は外した
Lagunaには約2.1GiBのDFlash draft modelも用意されている。15 speculative tokens、64K、4並列で比較した結果は次の通り。
| タスク | base | DFlash | 差分 |
|---|---|---|---|
| code-chat | 97.5 tok/s | 124.1 tok/s | +27% |
| character-chat | 99.8 tok/s | 55.0 tok/s | -45% |
| studio-enhance | 98.1 tok/s | 93.9 tok/s | -4% |
| concurrent x4 | 267.9 tok/s | 236.7 tok/s | -12% |
DFlashはcode-chat単体では効いたが、短い応答と並列処理ではdraft overheadが勝った。VRAMも約91.4GiBまで増え、他サービスを同居させる余地がほぼ消える。
少なくともKotoniaの現在のワークロードでは、DFlashはデフォルトOFFが正解だった。speculative decodingは「新機能だから速い」ではなく、出力長、並列度、draft acceptance、同居サービスを含めて測る必要がある。
7GPU筐体より、PCをもう1台の方が楽かもしれない
Lagunaを単独でgpu_memory_utilization=0.9にすると、当然ながら96GBの大半を予約する。この状態で現在の音声スタック約19GBを丸ごと同居させるのは無理がある。
しかしDFlashを切り、contextと同時実行数を抑え、LagunaのGPU memory utilizationを0.78〜0.80程度にすれば話が変わる。概算ではLagunaを76〜78GB程度に収め、Ditto約3GBと主系TTS約7GBを置き、7〜10GBほどのheadroomを残せる可能性がある。
これはまだ計測前の仮説だが、追加のRTX PRO 6000はすでに注文した。届いた後の候補構成はこうなる。
| 役割 | 常駐させるもの |
|---|---|
| realtime GPU | Laguna + Ditto + 主系Qwen3-TTS |
| batch GPU | 画像生成 + 動画生成 |
| 既存24GB GPU | 予備TTS、退避先、軽量サービス |
| 外部API | 軽量Vision、長いprefillの一時退避、frontier review |
画像理解はLagunaの主戦場ではないので、軽量なVision APIをsidecarとして使えばよい。すでにKotonia側には、ローカル画像・動画生成を止めてGPU実験している間、Studioへメンテナンス表示を出し、安全な範囲だけAPIへ切り替える仕組みも入れた。
ここまで分離できるなら、巨大な7GPU筐体を1台管理するより、コンシューマー向けPCをもう1台用意した方が案外きれいだ。
- CUDA、vLLM、FlashInferの依存関係をマシン単位で分けられる
- 画像・動画のバッチ負荷をリアルタイム音声から物理的に隔離できる
- 実験失敗や再起動のblast radiusが小さい
- 必要なマシンだけ起動できる
- 単一GPUでモデルが完結するため、筐体をまたぐGPU間通信が不要
もちろん、ネットワーク障害、モデルキャッシュの重複、監視対象の増加というコストはある。将来また1GPUに収まらないモデルをtensor parallelで動かすなら、7GPU機の価値も戻る。
それでも今の問題は、GPU同士を高速につなぐことではない。異なるレイテンシ要件のワークロードを、互いに邪魔させないことになった。
本当に怖いのはVRAMではなく、音声のp99
GPU上でモデルが同時にOOMせず載ることと、サービスとして同居できることは同じではない。
LLM、TTS、DittoはSM、メモリ帯域、キャッシュ、schedulerを共有する。平均utilizationが低く見えても、長いprefillとTTS生成が衝突すればストリーミング音声のchunk間隔が乱れる。Qwen3-TTSはリアルタイム係数の平均が1未満でも、一部のchunkだけ遅れるとユーザーには「カクつき」として聞こえる。
次に測るべきなのは、単純なtokens/sや平均RTFではない。
- TTSのtime to first audio
- 音声chunk間隔のp95 / p99
- playable audio durationと到着時刻の差
- 再生buffer underrun回数
- Dittoの最低fpsとframe latency
- Lagunaのdecode中と長いprefill中の差
条件も、TTS単体、TTS + Ditto、TTS + Laguna decode、TTS + Laguna long prefill、全部同時の順で増やす必要がある。
300〜500ms程度のaudio lookahead bufferで小さな揺れは吸収できるが、その分だけ会話レイテンシは増える。音声ストリーミング中は、短いキャラクターチャットだけをローカルへ通し、たとえば8K tokensを超える新規コーディングprefillは外部APIへ逃がす、といったadmission controlも候補になる。
この部分は、2枚目のRTX PRO 6000が届いてから実測する。
結論：買うべきマシンを、モデルに決め打ちしない
今回のLaguna S 2.1は、少なくともコーディング・tool use用途ではかなり強い。
- 約67GiBのNVFP4重みが96GB GPU 1枚に収まった
- character-chatは約100 tok/s、4並列は267.9 tok/s aggregate
- 36K tokensの長文needleを通した
- kotonia-cliのリポジトリ修復はhidden test込み12/12
- 一方、短い厳密指示追従は12/28で、万能モデルではない
- DFlashは今回のワークロードでは総合的に遅く、VRAMも重かった
公式エージェントベンチの数字は、少なくとも「このモデルはコードとツール利用が得意」という意味ではかなり信用できそうだ。ただし、それを一般知能やすべての会話品質へ拡張してはいけない。
そして一番大きかったのは、モデルの点数ではない。
V4 Pro級のエージェント性能を得るために最低4GPU必要だと思っていた。その前提で7GPUマシンを探し、業務用構成の価格に悩んでいた。ところがMoEの進歩で、問題は1GPUへ収まった。
そうなると最適化対象はGPU密度ではなく、障害分離、音声のtail latency、バッチ処理との境界になる。大きな1台より、小さく分離した2台の方が正解かもしれない。
メーカーから見積もりの返事が来るのが先か、追加GPUが届いて同居ベンチを終えるのが先かは分からない。
ただ、7GPUマシンの発注前に前提が消えてくれたのは、たぶん運がよかった。
次はLaguna、Qwen3-TTS、Dittoを同時に走らせ、長いprefillが音声のp99をどこまで壊すか測る。