118B コード特化 MoE 「Laguna S 2.1」 を DGX Spark で動かしてみた
はじめに
こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。
agentic coding 特化の AI 企業 Poolside が、2026 年 7 月 21 日にオープンウェイトの MoE モデル「Laguna S 2.1」を公開しました。総パラメータ 117.6B、Active 8.5B という構成で、発表の中で「単一 DGX Spark で動く」とハードウェアを名指ししているのが目を引きます。100B 超級のコード特化モデルが、公式に DGX Spark をサポート対象として挙げてくるのは初めてではないでしょうか。
公式が名指ししてくれたのなら、実際にそのとおり動くのかを確かめたくなるのが人情です。発表翌日に公式の NVFP4 量子化版を手元の DGX Spark に載せて、起動条件・メモリ・速度・ツール呼び出し・コード修正品質の 5 つの観点で確かめてみました。おまけで日本語の受け答えも見ています。
先に結論を書いておくと、公式 NVFP4 版は vLLM v0.25.1 でそのまま起動して単体 19.5 tok/s、DFlash 投機デコードを足すと最大 31.2 tok/s まで伸びました。ただし公式レシピの --moe-backend triton 指定はそのままでは通らず、投機の深さも公式デフォルトの 15 ではなく 3 が最速という、私の環境ではレシピとは異なる結果になっています。
DGX Spark のパートナー LLM を探す連載としては、Qwen3.6-27B から始めた初回記事（2026-07-06）、Qwen3.6-35B-A3B-NVFP4 の対決記事（2026-07-13）、Gemma 4 NVFP4 の対決記事（2026-07-18）に続く記事になります。
この記事では、Laguna S 2.1 NVFP4 を単一 DGX Spark で動かすための実際の条件と、コード特化モデルならではの実力を実測ベースで紹介します。DGX Spark を開発のお供にしている人に刺さるといいなと思っています。
Laguna S 2.1 の素性
Laguna S 2.1 はコード生成と agentic coding に特化したオープンウェイトモデルです。ファミリーにはローカル向けの XS 系（33B/A3B）とフラッグシップの M.1（225B/A23B）もあり、S 2.1 はその中間に位置します。
アーキテクチャは 256 個の routed experts から top-10 を選ぶ MoE で、共有 expert が 1 つ付きます。48 層のうち 36 層が sliding window attention（window 512）、12 層が global attention という 3:1 の混成です。ネイティブのコンテキスト長は 1M ですが、今回使う NVFP4 版のモデルカードでは 262,144 に設定されています。
公称ベンチマークは Terminal-Bench 2.1 で 70.2%、SWE-bench Multilingual で 78.5%。同じ重量クラスでは大差でもっとも優秀な agentic coding モデルだ、というのが Poolside の主張です。ここは自己申告値なので、手元のタスクで確かめるのが良さそうです。
配布形式が充実しているのはありがたい点です。BF16（約 236GB）のほかに公式の FP8、NVFP4、INT4、GGUF、MLX が最初から揃っていて、DGX Spark 想定の NVFP4 版は約 71GB です。手元のディスクでは 67GiB と表示され、単位を換算するとほぼ公称どおりでした。さらに投機デコード用の draft モデル「DFlash」（約 1B）が精度別に別リポジトリで配布されています。量子化版を自作しなくてよいので、ダウンロードしたらすぐ検証に入れます。
ライセンスは OpenMDW-1.1 という Linux Foundation 系のパーミッシブライセンスで、商用利用も再配布も可能です。NVIDIA が Nemotron ファミリーで採用しているものと同じですね。なおフラッグシップの M.1 は Apache 2.0 と系列内でライセンスが異なるので、混同にはご注意ください。
検証環境と計測条件
検証環境は以下のとおりです。連載の過去記事と条件を揃えています。
| 項目 | 値 |
|---|---|
| ハードウェア | DGX Spark（GB10、aarch64、128GB unified memory）単体 |
| 推論エンジン | vLLM v0.25.1（vllm/vllm-openai:v0.25.1-aarch64 イメージ） |
| モデル | poolside/Laguna-S-2.1-NVFP4（約 71GB、ディスク上 67GiB） |
| drafter | poolside/Laguna-S-2.1-DFlash-NVFP4（2.1GiB） |
| KV cache | fp8 |
| max-model-len | 65,536（262K 検証のみ 262,144） |
| gpu-memory-utilization | 0.80 |
速度は出力長を 256 トークンに固定した single stream の decode tok/s（3 回の median）と、同時 8 リクエストの aggregate tok/s で測っています。公式レシピが vLLM 0.25.0 以上、投機デコードは 0.25.1 で検証済みと明記しているので、イメージは stable の v0.25.1 をそのまま使いました。
起動でいきなり公式レシピの罠を踏んだ
まず素の起動です。公式レシピどおり --tool-call-parser poolside_v1 --reasoning-parser poolside_v1 --enable-auto-tool-choice を付けて起動したところ、こちらは何の問題もなく立ち上がりました。専用パーサーの poolside_v1 が stable の v0.25.1 に既に入っているのは、リリース連携がしっかりしている証拠でかなり好印象です。日本語の応答も正常で、ツール呼び出しのスモークテストも一発で通りました。
つまずいたのは投機デコードです。公式レシピの投機デコード用コマンドには --moe-backend triton が指定されているのですが、これを付けると起動しません。
ValueError: moe_backend='triton' is not supported for NvFP4 MoE. Expected one of
['cutlass', 'flashinfer_trtllm', 'flashinfer_cutlass', 'flashinfer_cutedsl',
'flashinfer_b12x', 'marlin', 'humming', 'emulation'].
vLLM v0.25.1 の NVFP4 MoE パスは triton バックエンドを受け付けないため、レシピのフラグをそのまま貼ると NVFP4 版では門前払いになります。おそらくレシピは BF16 版や FP8 版を想定した記述で、NVFP4 版には当てはまらないのだと思います。対処はシンプルで、--moe-backend の指定ごと外して vLLM の自動選択に任せれば、投機デコード込みで正常に起動しました。
ではどのバックエンドが速いのか。auto、marlin と、明示指定の triton の 3 通りを試した結果は以下のとおりです。
| moe-backend | single decode tok/s | 備考 |
|---|---|---|
| auto | 19.87 | 内部で FLASHINFER_CUTLASS を選択 |
| marlin | 19.86 | auto と同着 |
| triton | — | 上記 ValueError で起動不可 |
auto と marlin は誤差レベルの同着でした。面白いのは auto の解決先で、serve ログを見ると Laguna では FLASHINFER_CUTLASS が選ばれています。Qwen3.6-35B のときは同じ auto が MARLIN を選んでいたので、量子化形式やエキスパート構成によって自動選択の答えが変わるようです。以降の計測はすべて auto で統一しました。
128GB に 118B はこう収まる
「単一 DGX Spark で動く」の実態をメモリ面から見ておきます。gpu-memory-utilization 0.80 で起動した直後の実測は、OS から見える総メモリ 121GB のうち使用 107GB でした。カタログ上の 128GB との差は換算と予約領域ぶんです。重み 67GiB に加えて、vLLM が確保した KV cache が 27.11 GiB。fp8 KV との組み合わせで 977,533 トークン分のキャッシュ容量になり、65,536 トークンのリクエストなら最大 14.92 並列相当を保持できる計算です。
コンテキストを 262,144 まで広げた構成でも起動は成功しました。この設定でも KV 容量は 1,114,602 トークン分あり、262K フルのリクエストを 4.25 本並行で抱えられます。短いプロンプトでの decode 速度は 19.39 tok/s と 65K 設定時と変わらないので、長文コンテキストを見据えた常用も現実的です。発売直後のコミュニティ報告では「1M コンテキストは非現実的、実用は 262K まで」という声がありましたが、262K 上限であれば余裕を持って成立する、というのが手元の結論です。
DFlash 投機デコードは K=3 が最速だった
ここからが本題です。投機デコードは、小さな draft モデルが先の K トークンをまとめて予測し、本体モデルが 1 ステップで一括検証する高速化手法です。予測が当たれば一度に複数トークン進み、外れたぶんは捨てられるので、効き具合は draft の的中率と K の選び方で決まります。
Laguna には専用の draft モデル DFlash が用意されていて、公式レシピは num_speculative_tokens=15、つまり K=15 を提示しています。一方、発表当日の NVIDIA Developer Forums では「spec 15 だと 10〜15 tok/s まで落ちて使い物にならない、7 に減らすと 40〜50 tok/s」という報告が飛び交っていました。どちらが本当なのか、K = 3 / 5 / 7 / 11 / 15 を同一条件で振って確かめました。表の総受理率は draft が提案したトークンのうち本体が採用した割合、平均受理長は 1 回の検証で採用されたトークン数です。
| 構成 | single tok/s | base 比 | 同時 8 aggregate | draft 総受理率 | 平均受理長 |
|---|---|---|---|---|---|
| base（投機なし） | 19.5 | — | 91.0 | — | — |
| DFlash K=3 | 31.15 | 1.60x | 121.9 | 52.1% | 1.56/3 |
| DFlash K=5 | 26.47 | 1.36x | 105.4 | 35.0% | 1.75/5 |
| DFlash K=7 | 30.42 | 1.56x | 106.7 | 29.0% | 2.03/7 |
| DFlash K=11 | 22.42 | 1.15x | 97.2 | 26.3% | 2.89/11 |
| DFlash K=15（公式） | 29.06 | 1.49x | 91.8（≒base） | 13.6% | 2.04/15 |
なお base の 19.5 tok/s は backend 検証時の 19.87 とは serve を立て直した別ランの値で、この程度の serve 間の揺らぎはあります。
K を 3〜15 で振った single decode 速度。ハッチは K+1 が CUDA graph のキャプチャサイズから外れてパディングが発生する構成で、K=5 と 11 だけ谷になる。
結果はフォーラムの報告値とも公式レシピとも違いました。整理すると 3 つのことが言えます。
1 つ目は、公式デフォルトの K=15 は「壊滅」まではしないものの、試した中では一番損な選択だということです。single では 29.06 tok/s と base 比 1.49 倍を保ちますが、同時 8 リクエストでは aggregate 91.8 tok/s と投機なしの 91.0 とほぼ同じ。並列で使うと投機のうまみがそっくり消えてしまいます。フォーラムで報告された 10〜15 tok/s は手元では再現しなかったので、環境要因が大きそうです。
2 つ目は、K を深くしても受理される長さがほとんど伸びないことです。/metrics の位置別受理率を見ると、K=15 では 1 個目 67.4% から始まって 8 個目以降は 4.3% 以下、15 個目は 0.8% まで落ちます。平均受理長は K=7 の 2.03 に対して K=15 でも 2.04 と横ばいで、深読みで稼げる受理は実質 2 トークン強で頭打ちです。K=11 だけ 2.89 と揺れましたが、単体速度は最下位なので反例にはなりません。一方で検証 1 ステップのコストは K に比例して重くなるため、伸びない受理長のために深い K を払うのは割に合わず、浅い K で回転を上げたほうが得。これが K=3 最速の理屈です。
K=7 と K=15 の位置別受理率。両者はほぼ同じカーブを描き、8 個目以降はほとんど当たらない。K を深くしても受理が伸びない構造が見て取れる。
3 つ目は、K=5 と K=11 だけ不自然に凹むことです。31.2（K3）→ 26.5（K5）→ 30.4（K7）→ 22.4（K11）→ 29.1（K15）というジグザグは受理率では説明できません。ヒントは serve ログにありました。CUDA graph は決まったサイズの計算を事前に録画して再生する高速化のしくみで、録画済みサイズに合わない入力は次のサイズまで切り上げてパディングされます。投機デコード時の vLLM はこの CUDA graph を PIECEWISE モードで動かし、キャプチャサイズが 1, 2, 4, 8, 16, 24…という系列になっています。検証ステップが 1 回に処理するのは draft K 個 + 本体 1 個 = K+1 トークンなので、K=3、7、15 はぴったりキャプチャサイズに乗り、K=5 と 11 は次のサイズへのパディングで計算を無駄にします。config からの推定にはなりますが、ジグザグの形とはきれいに一致します。
というわけで、DGX Spark で Laguna の DFlash を使うなら、K は「K+1 が CUDA graph のキャプチャサイズに乗る値」から選ぶのがよさそうです。手元の推奨は K=3 で、起動フラグは以下の形になります。
vllm serve poolside/Laguna-S-2.1-NVFP4 \
--speculative-config '{"method":"dflash","model":"poolside/Laguna-S-2.1-DFlash-NVFP4","num_speculative_tokens":3}' \
--tool-call-parser poolside_v1 --reasoning-parser poolside_v1 --enable-auto-tool-choice \
--kv-cache-dtype fp8 --max-model-len 65536 --gpu-memory-utilization 0.80
連載で実測してきたモデルたちの中に置くと、立ち位置はこうなります。
連載実測モデルとの並び。Laguna S 2.1（★今回）は base 19.5 → DFlash K=3 で 31.1 tok/s。計測時期により vLLM バージョンは v0.24.0〜v0.25.1 と異なる。
poolside_v1 のツール呼び出しは実用水準だった
agentic coding を名乗るからにはツール呼び出しが命です。単発の関数呼び出し 6 問と、擬似ファイルシステムを 3 つのツールで探索させる agentic 課題 1 本を、thinking あり・なしの両モードで流しました。
| 評価項目 | thinking | no-thinking |
|---|---|---|
| 最小の単発呼び出し | ✅ | ✅ |
| 2 ツールからの選択 | ✅ | ❌ タグ崩れ |
| ネスト引数 + enum + 整数型 | ✅ | ✅ |
| 1 発話での並列 2 呼び出し | ❌ 1 件のみ | ✅ |
| 日本語指示 + 日本語引数 | ✅ | ✅ |
| ツール不要問での過剰呼び出し | ✅ 抑制 | ✅ 抑制 |
| agentic 課題（バグ特定） | ✅ 4 ターン | ✅ 4 ターン |
両モードとも単発 6 問は 5 問成功でした。構造化された tool_calls として返ってきた呼び出しは、引数の JSON がすべて健全です。落とした 1 問はモードで異なり、thinking ありは並列 2 呼び出しを 1 件に絞ってしまい、なしは計算ツールの呼び出しタグが崩れて本文側に漏れる形式エラーでした。agentic 課題はどちらも 4 ターンで正しくバグ箇所へ到達しました。ストリーミングでも tool_calls が構造化されたまま届くので、エージェント基盤への組み込みで困ることはなさそうです。
一点、reasoning parser には注意が必要です。非ストリーミング応答で thinking の中身が reasoning_content に分離されず、</think> タグごと content に混ざってくるケースがありました。ツール呼び出しの抽出は正常なので実害は限定的ですが、content を直接表示するアプリでは前処理を入れたほうが安全です。
コード修正で汎用王者の Qwen 35B と対決させてみた
最後に本業のコード修正です。既存 OSS の修正課題だと学習データに答えが入っている可能性を排除できないので、この検証用に Python のミニリポジトリを自作しました。在庫管理 CLI 風の 5 ファイル構成に、境界条件の off-by-one、mutable default argument、例外の握り潰しという定番バグを 3 種類（修正箇所は 4 つ）仕込み、pytest 12 本中 5 本が落ちる状態からスタートします。モデルには read_file、write_file、run_tests の 3 ツールだけを渡し、全テストが通るまで自走してもらいました。
対戦相手は連載でパートナー LLM の座にいる Qwen3.6-35B-A3B-NVFP4 です。同一マシン・同一 vLLM で同じ課題を解かせました。投機デコードはそれぞれの最速構成に合わせ、Laguna は DFlash K=3、Qwen は同梱 MTP の 3 トークン先読みを有効にしています。表で Qwen が thinking のみなのは、対比の代表構成に絞ったためです。
| モデル | 修正結果 | ターン数 | 実時間 | 生成トークン |
|---|---|---|---|---|
| Laguna S 2.1（thinking） | 5/5 全修正 | 5 | 41.7 秒 | 1,176 |
| Laguna S 2.1（no-thinking） | 5/5 全修正 | 6 | 37.4 秒 | 1,038 |
| Qwen3.6-35B-A3B（thinking） | 5/5 全修正 | 10 | 23.4 秒 | 1,804 |
この規模のバグ修正だと、どちらも満点でした。差が出たのは進め方です。Laguna は 5 ターンで済ませました。テストを走らせ、落ちたテストに関係するファイルだけを読み、3 バグをまとめて修正して再テスト、という無駄のない動きです。Qwen は倍の 10 ターンを使い、1 バグずつ直しては確認する石橋を叩くスタイルでしたが、decode が約 88 tok/s と Laguna の 3 倍近く速いため、実時間では 23.4 秒と最速でした。
コード特化 118B の価値は「手数の少なさ」に、汎用 35B の価値は「回転の速さ」に出る、という分かりやすい対比です。今回のミニリポでは実時間で Qwen に軍配が上がりましたが、ターン数の差は課題が複雑になるほど効いてくるはずで、リポジトリ全体を見渡すような重い修正では逆転しそうな気配があります。ここは続編で課題の規模を上げて確かめたいところです。
なお発表直後に一部で報告されていた無限ループ癖は、今回の検証では一度も出ませんでした。20 ターンと 15 分の打ち切りガードを仕込んで臨んだのですが、出番なしでした。
日本語も普通に書ける
コード特化モデルの日本語がどの程度かも、連載定番の 4 問で確認しました。50 字以内の指示遵守、リモートワークの自由記述、重複除去ソートのコード生成、金額の数値推論という構成です。
コード生成と数値推論は文句なしの正答でした。自由記述も自然な日本語で、ビジネス文としてそのまま使える水準です。指示遵守の問題では「東京は日本の首都で、政治・経済の中心地です。世界的な都市として知られています。」という 39 文字の回答に、自分で「(49 文字)」と文字数を添えてくる律儀さでした。数えは外れていますが、50 字以内の指示にはきちんと収まっています。ただし前述の reasoning parser の件で、この正答の前に英語の思考テキストが content に混ざって届いたため、文字数チェックを機械的にかけると誤判定します。日本語能力そのものは、コード特化という肩書きから想像するよりずっと良い感じです。
まとめ
Laguna S 2.1 NVFP4 は、公式の看板どおり単一 DGX Spark で実用的に動きました。発表翌日の時点では「DFlash の受理率が低すぎる」という否定的な報告が目立っていましたが、実際に手を動かしてみると、つまずきの正体はレシピの細部にあって、設定さえ整えれば十分戦えるモデルだというのが正直な所感です。100B 超級のコード特化モデルがこの手軽さで手元のマシンに収まるようになったこと自体、少し感慨深いものがありますね。
触っていて一番印象に残ったのは、コード修正での手数の少なさです。テストを走らせて、読むべきファイルだけ読んで、まとめて直して終わり。この迷いのなさはコード特化を名乗るだけのことはあり、エージェントのバックエンドとして常駐させる選択肢が現実味を帯びてきました。
次はコード修正課題の規模を上げて Qwen 35B との逆転ラインを探るのと、常駐王者の座を賭けた Hermes Agent 実運用での比較を試してみたいところです。
参考リンク
- Introducing Laguna S 2.1 | Poolside
- poolside/Laguna-S-2.1-NVFP4 | Hugging Face
- poolside/Laguna-S-2.1-DFlash-NVFP4 | Hugging Face
- vLLM recipes — Laguna-S-2.1
- OpenMDW License 1.1
- Laguna S 2.1 Config & Benchmarks - DGX Spark / GB10 | NVIDIA Developer Forums — 発表当日の第三者実測スレッド
- r0b0tlab/laguna-s-2.1-nvfp4-sm121-vllm | GitHub — sm_121 向け実行コンテナと検証スクリプト
