128GB本命？Laguna S 2.1の118B-A8Bを検証
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
PoolsideのLaguna S 2.1は117.6B総・8.5B activeのMoE。DGX Spark、RTX PRO 6000、128GB Macでの容量、速度、ベンチマークを検証します。
先に結論
- Laguna S 2.1は総117.6B、1トークン当たり8.5Bを使うMoE。約118Bの重みが品質の土台になり、実際の計算量は小さく抑えられる
- 128GB機へ快適に載るのは、BF16やFP8ではなく約72〜75GBのNVFP4、INT4、Q4_K_M、MLX 4bit。OSとKVキャッシュ用の余白も残せる
- DGX SparkではPoolsideが、Ollamaで約12.6 tok/s、NVFP4＋DFlashで文章約15 tok/s・コード22〜24 tok/sを報告している
- 128GBのApple Siliconは公式報告で約17.6 tok/s。RTX PRO 6000は96GB VRAMへ4bit版が収まるが、同モデルの公式速度はまだ公開されていない
- 公開ベンチマークは同サイズ帯として強い。ただし比較値は各社公表値や別harnessも含み、完全に同じ条件の直接対決ではない
- 「Gemma 4にないサイズ」は正しいが、Lagunaはtext-onlyのcoding agent向け、Gemma 4はmultimodalを含む汎用系で、単純な代替関係ではない
投稿の見立ては概ね妥当です。Laguna S 2.1は、30B級では物足りないが200B超は重すぎるというローカルLLMの空白へ入り、128GB級1台で動かせるcoding agent用モデルとして有力な選択肢です。ただし、量子化形式、推論engine、context長まで選んで初めて「最適サイズ」になります。
情報監査日: 2026年7月22日
数値の扱い: モデル仕様、容量、DGX Spark / Apple Siliconの速度はPoolsideの公式model cardとrelease記事に基づきます。当サイトでの実測ではありません。RTX PRO 6000の速度見通しは、公開されたVRAM容量と帯域からの推定です。
ベンチマークの注意: 比較表はPoolside公開値です。モデルごとにvendor self-report、leaderboard、第三者結果が混在し、agent harness、step上限、internet accessなども統一されていません。
X投稿が紹介したモデル
AI X Satoshi氏（@AiXsatoshi）のX投稿は、DGX Spark、RTX PRO 6000、128GB Macへ適した高性能・高速モデルとして、117.6B total / 8.5B activeのモデルを紹介しています。添付されたベンチマーク図から、対象はPoolsideが2026年7月21日に公開したLaguna S 2.1と確認できます。
Laguna S 2.1は、software engineeringとagentic codingに特化したtext-to-textモデルです。48層のうち12層がglobal attention、36層がwindow幅512のsliding-window attentionです。各MoE層には256のrouted expertと1つのshared expertがあり、1トークンごとに上位10 expertを選びます。
| 項目 | Laguna S 2.1 | 読み方 |
|---|---|---|
| 総パラメータ | 117.6B | 重みとして保存する全体規模 |
| 活性パラメータ | 8.5B / token | 1トークンの計算に使う部分 |
| 層数 | 48 | global 12＋sliding-window 36 |
| routed expert | 256、top-10 | 毎回すべてを計算しない |
| 推奨context | 262,144 tokens | 量子化版の標準設定 |
| native上限 | 1,048,576 tokens | 復元可能だが品質低下の注意あり |
| 主用途 | software engineering、agentic coding | 一般chatよりcoding評価を重視 |
118Bなのに128GBへ収まる理由
MoEでは、総パラメータ数と活性パラメータ数が別の役割を持ちます。117.6Bの重み全体は原則としてmemoryへ置く必要があります。一方、各トークンで計算するのは8.5B相当なので、同規模のdenseモデルよりdecode計算を軽くできます。
ただし「active 8.5Bだから8.5Bモデルと同じ容量」ではありません。容量を決めるのは117.6B側です。BF16重みは約236GB、FP8でも約121GBあり、128GB機ではruntime、KV cache、OSの余地が足りません。128GBへ合うのは4bit前後へ圧縮したvariantです。
| variant | おおよその容量 | 128GB機 | 向く環境 |
|---|---|---|---|
| BF16 | 約236GB | 不可 | multi-GPU、256GB以上 |
| FP8 | 約121GB | 余白不足 | multi-GPU |
| NVFP4＋DFlash | 約73GB | 適合 | DGX Spark、NVIDIA GPU |
| INT4 | 約72GB | 適合 | NVIDIA GPU |
| GGUF Q4_K_M | 約75GB | 適合 | Ollama、llama.cpp系 |
| MLX 4bit | 71.9GB | 適合 | Apple Silicon |
Hugging FaceのNVFP4ページで「68B params」と表示される場合がありますが、これは量子化tensorの保存上の表示で、architectureが68Bへ縮んだという意味ではありません。基盤モデルの仕様は117.6B total / 8.5B activeのままです。
3つのハードウェアでどう動くか
DGX Spark 128GB
最も具体的な公式手順があるのはDGX Sparkです。手軽に試すなら、Poolsideはollama run laguna-s-2.1を案内しています。約75GBのQ4_K_Mを取得し、公式測定は約12.6 tok/sです。
速度を優先する構成は、vLLM 0.25.1、NVFP4本体、DFlash draft model、FlashInferの組み合わせです。Poolsideは、prefill 600〜800 tok/s、decodeは文章で約15 tok/s、コードで22〜24 tok/sを報告しています。DFlashなしの13〜14 tok/sに対し、投機的decodeでコード生成を伸ばす構成です。
ただし初回起動にはkernel compileなどで約15分かかる場合があります。128GBで同時jobを増やすとJITのmemory使用が重なり、OOMし得るため、公式手順も初回のmax parallel jobsを4に抑えています。
RTX PRO 6000 Blackwell 96GB
RTX PRO 6000 Blackwell Workstation Editionは96GB GDDR7 ECC、memory bandwidth 1,792GB/sです。約72〜75GBの4bit weightは1枚へ収まり、約21〜24GBをKV cache、activation、runtimeへ残せます。
DGX Sparkより広いmemory bandwidthを持つため、memory bandwidthの影響を受けやすいdecodeでは高速化が期待できます。ただし、これは仕様からの推定です。PoolsideはRTX PRO 6000での実測TPSを公開していません。また96GBの余白は128GB unified memoryより小さいため、256K contextを大きなbatchや高いconcurrencyで使う場合は、max-model-lenやKV cache精度の調整が必要です。
FP8は約121GBなので1枚には収まりません。RTX PRO 6000に適するという表現も、4bit variantを選ぶことが前提です。
128GB Apple Silicon Mac
PoolsideはOllamaを使ったApple Siliconで約17.6 tok/sとしています。選択肢は約75GBのGGUF Q4_K_M、または71.9GBのMLX 4bitです。128GB unified memoryならweightを置いた後も約50GBの余裕があり、OS、KV cache、coding toolを同居させやすい構成です。
一方、release直後のcommunity報告では、M3 Max 128GB＋Q4_K_M＋DFlashで、thinking時の中央値約14.4 tok/s、non-thinking時の中央値約26.7 tok/sと幅がありました。投機的decodeのacceptanceやpromptで9〜30 tok/s台まで変動しているため、単一の最高値より中央値、TTFT、長文脈での落ち方を確認すべきです。
| 環境 | 推奨variant | 公開速度 | 判断 |
|---|---|---|---|
| DGX Spark 128GB | NVFP4＋DFlash、Q4_K_M | 12.6〜24 tok/s | 公式recipeが最も充実 |
| RTX PRO 6000 96GB | NVFP4、INT4、Q4 | 公式実測なし | 容量は適合、速度は要実測 |
| Apple Silicon 128GB | MLX 4bit、Q4_K_M | 公式約17.6 tok/s | 導入しやすく余白も大きい |
256K推奨と1M対応は分けて考える
Laguna S 2.1のbase architectureは1M contextを持ちますが、NVFP4、GGUF、MLXなどの配布設定は256K前後を推奨しています。公式model cardは、設定を書き換えて1Mへ戻せる一方、最大長付近では品質が低下する可能性を明記しています。
contextを伸ばすほどKV cacheは増え、prefill時間も長くなります。特に96GBのRTX PRO 6000ではweight搭載後の余白が約20GBなので、256Kを常に使えることと、高concurrencyで安定運用できることは別です。まず32Kまたは64Kで速度と品質を測り、128K、256Kと段階的に上げる方が安全です。
ベンチマークは「サイズ当たり強い」と読む
Poolsideのrelease記事では、6種類のcoding / agent benchmarkを公開しています。Terminal-Bench 2.1、SWE-bench Multilingual、SWE-Bench Proは各問題4回、DeepSWE、SWE Atlas、Toolathlon Verifiedは各3回実行し、pass@1を平均しています。
| benchmark | Laguna S 2.1 | 何を見る評価か |
|---|---|---|
| Terminal-Bench 2.1 | 70.2 | terminalを使う複雑な実務task |
| SWE-bench Multilingual | 78.5 | 複数言語のrepository issue修正 |
| SWE-Bench Pro（public） | 59.4 | 難しい実repository修正 |
| DeepSWE | 40.4 | 長い軌跡を含むsoftware engineering |
| SWE Atlas（Codebase Q&A） | 46.2 | codebaseの理解と質問応答 |
| Toolathlon Verified | 49.7 | 複数toolを組み合わせるagent task |
78.5のSWE-bench Multilingualや59.4のSWE-Bench Proは、この容量で手元に置けるモデルとして魅力的です。117.6B total / 8.5B activeという効率まで含めれば、30B級と200B超の間を埋めるという評価に説得力があります。
ただし、画像の棒グラフをそのまま「全モデルへ同条件で勝った順位表」と読むのは危険です。Poolside自身が、比較値にvendor self-report、official leaderboard、third-party runの最大値を使ったと説明しています。Laguna側もPoolsideのHarbor forkとinternal agent harness、最大500 stepで測定しています。internet accessやtool、prompt、retry数が異なればscoreは変わります。
Poolsideは最終評価の全trajectoryを公開viewerへ載せています。単なるscoreより、成功したtask、失敗pattern、toolの使い方まで確認できる点は評価できます。結論は「frontier modelを全面的に上回る」ではなく、ローカルへ置ける約75GBのcoding modelとして強いです。
Gemma 4にないサイズ、は正しいか
Googleの公式資料では、Gemma 4 familyはE2B、E4B、12B、26B-A4B、31Bです。117.6B total / 8.5B activeに相当するsizeはなく、投稿の「Gemma 4に無いサイズ」という指摘は正しいです。
ただし用途は異なります。Laguna S 2.1はtext-onlyでsoftware engineeringとagentic codingへ寄せています。Gemma 4はimage入力も扱うmultimodal familyで、小型端末から汎用assistantまでを広く狙います。code agentの品質を優先して128GBを使い切るならLaguna、visionや軽量deploymentも必要ならGemma、という選び分けです。
release直後に注意したい点
- engine対応: vLLM 0.25.0以降、SGLang、TensorRT-LLM、Ollamaに手順がある。llama.cppはPoolside branchが先行し、mainline対応は統合途中
- DFlashの差: 公式は2.9〜3.1 tokens / stepのacceptanceを報告する一方、DGX Spark利用者から2〜3％程度だったというrelease-day報告もある
- thinkingの保存: interleaved thinkingを保持する設計のため、conversation historyを加工すると性能が変わる可能性がある
- 長文脈: 1Mへ設定できても品質とmemoryの両方を再評価する必要がある
- 比較benchmark: scoreはagent harness込み。別engineへ載せ替えたローカル実行で同じ結果になる保証はない
NVIDIA Developer Forumsでは、公式vLLM recipeを使ってもDFlash acceptanceが低く、生成10〜15 tok/sだったというDGX Sparkの報告があります。公式値との差は、DFlash設定、prompt、code比率、runtimeの成熟度で生じ得ます。公開翌日の段階では、速度を断定せず、同じprompt setでspeculative decodingの有無を比較するのが確実です。
目的別の選び方
- 最短で試す: DGX Sparkまたは128GB MacでOllamaのQ4_K_M
- DGX Sparkの速度を詰める: vLLM＋NVFP4＋DFlash。まず64K context、低concurrencyで測る
- Macへ常駐させる: MLX 4bitまたはQ4_K_M。coding toolを含めたpeak memoryを確認
- RTX PRO 6000を使う: NVFP4またはINT4。256Kを前提にせず、KV cache余白を見ながらcontextを増やす
- 品質を評価する: SWE-bench scoreだけでなく、自分のrepositoryでissue修正、test成功率、tool call、不要な変更を比較
再現記録には、hardware、driver、engine version、model revision、quantization、context上限、thinking、DFlash、input / output token数を残します。速度はprefill、TTFT、decodeを別々に測ると、どこがbottleneckか判断できます。
よくある質問
128GBならFP8版も使えますか？
現実的ではありません。FP8 weightだけで約121GBあり、OS、runtime、KV cacheの余地がほぼ残りません。128GB機では約72〜75GBのNVFP4、INT4、Q4_K_M、MLX 4bitが対象です。
active 8.5Bなら8Bモデルと同じ速度ですか？
いいえ。各tokenのexpert計算は軽くなりますが、attention、expert routing、weightのmemory転送、engine効率が加わります。117.6B分のweightをmemoryから扱うため、通常の8B denseモデルより重いです。
RTX PRO 6000が3機種で最速ですか？
1,792GB/sの帯域から高速化は期待できますが、Laguna S 2.1の公式実測は未公開です。96GBへweightは収まるものの、contextとbatchの余白は128GB機より小さいため、現時点では「最速」と断定できません。
1M contextを設定すべきですか？
まずは256K以下を推奨します。公式配布版も262,144を標準にし、1Mへ戻すと品質が低下する可能性を警告しています。必要なtaskだけ段階的に伸ばし、memory、TTFT、正答率を測ります。
商用利用できますか？
Laguna S 2.1はOpenMDW-1.1で公開され、commercial / non-commercial利用を認めています。ただしlicense本文、acceptable use、組み込むsoftwareやdatasetの条件はdeployment前に確認してください。
まとめ
Laguna S 2.1は117.6Bの総容量で知識と能力を持たせながら、8.5B activeのMoEで計算量を抑えたcoding modelです。約72〜75GBの4bit版なら、DGX Spark、RTX PRO 6000、128GB Apple Siliconへ1台で載せられます。30B級より大きく、DeepSeek V4級より扱いやすい「中間の本命」という投稿の見方は妥当です。
一方、128GBへ合うのは量子化版に限られ、1M contextや高concurrencyまで無条件に快適という意味ではありません。benchmarkも比較条件が完全には揃っていません。4bitで約75GB、256K以下から開始、hardware別に実測という3点を押さえれば、ローカルcoding agentの現実的な候補になります。
参照資料
- AI X Satoshi（@AiXsatoshi）：元投稿のアカウント（2026年7月22日確認）
- Poolside：Introducing Laguna S 2.1（2026年7月21日公開、7月22日確認）
- Poolside：Laguna S 2.1公式model card（2026年7月21日更新版、7月22日確認）
- Poolside：Laguna S 2.1 NVFP4（2026年7月21日更新版、7月22日確認）
- Poolside：Laguna S 2.1 FP8（2026年7月21日更新版、7月22日確認）
- Poolside：Laguna S 2.1 INT4（2026年7月21日更新版、7月22日確認）
- Poolside：Laguna S 2.1 NVFP4 MLX（2026年7月21日更新版、7月22日確認）
- Ollama：laguna-s-2.1 library（2026年7月22日確認）
- NVIDIA：RTX PRO 6000 Blackwell Workstation Edition仕様（2026年7月22日確認）
- Google AI for Developers：Get started with Gemma 4（2026年7月2日更新版、7月22日確認）
- NVIDIA Developer Forums：Laguna S 2.1 on DGX Spark（2026年7月22日確認）
- Hacker News：Apple Siliconでのcommunity測定（2026年7月22日確認）
