- Poolside が長期作業と推論能力を強化した Laguna S 2.1 を公開。総計 118B の MoE で、トークンあたり 8B のパラメータを有効化し、thinking・no-thinking の両モードで最大 1M トークンコンテキスト をサポート
- 学習開始から公開まで 9週間未満 で、Terminal-Bench 2.1 で 70.2%、SWE-Bench Multilingual で 78.5%、DeepSWE v1.1 で 40.4% を記録し、より大規模なモデルと競合
- 性能向上の中心は、単純なモデル拡張ではなく 持続性・検証・後退後の再試行 にある。より長いロールアウト、改善されたサンドボックス、複数のエージェントハーネスを活用し、早まった完了宣言や単一ハーネスへの過学習を減らそうとしている
- 実作業では 181 ステップで HTML/CSS レンダリングエンジンを作成し、自社ハーネスの速度を 5.2% 向上させつつメモリ割り当てを約 70% 削減 し、Erdős 問題 #397 の無限解集合を独自に再発見
- モデルと最終評価の全実行軌跡を公開した一方、他社ハーネスのツール仕様、ネストしたツール呼び出しの JSON、過度に長い推論には制約がある。Hugging Face と主要な推論フレームワーク・ホスティングサービスで重みと最大 1M コンテキスト を利用可能
モデル構造と公開速度
- Laguna S 2.1 は、総計 118B パラメータ、トークンあたり 8B の有効パラメータを持つ Mixture-of-Experts モデル
- thinking と no-thinking の両モードで最大 1M トークンコンテキスト をサポート
- 学習開始から公開まで 9 週間未満
- 2026 年 5 月 22 日に 4,096 基の NVIDIA H200 GPU で事前学習を開始し、60 日後に公開
- 小さな有効サイズのおかげで複雑な作業をローカルシステムで実行でき、単一の NVIDIA DGX Spark でも動作可能
長期コーディングベンチマーク性能
- 2026 年 7 月 21 日時点の主な結果は以下の通り
- Terminal-Bench 2.1: 70.2%
- SWE-Bench Multilingual: 78.5%
- SWE-Bench Pro 公開データセット: 59.4%
- DeepSWE v1.1: 40.4%
- SWE Atlas(Codebase QnA): 46.2%
- Toolathlon Verified: 49.7%
- Terminal-Bench 2.1 は、エージェントがターミナル経由で環境とやり取りする多様な長期タスクを評価するもので、Laguna S 2.1 は thinking を有効化した pool ハーネスで 70.2% を記録
- 成熟したベンチマークでは上位スコアが 70〜90% に集中し、挙動差が大きいモデルでも数点差に見えることがある
- DeepSWE は部分的な解決が難しく、より長いタスクを含むためスコアの分散が大きい
- v1.1 ではフロンティアモデルが 54〜73% を記録し、一部の 1T 超の公開モデルは 10% 未満
- Laguna S 2.1 は自社の pool ハーネスで 40.4% を記録
- 公式順位表の mini-swe-agent ではなく自社ハーネスを使用したため、他モデルのスコアと完全に同等な比較ではない
- 他モデルについては、自社発表・ベンチマーク順位表・Artificial Analysis のうち最大スコアを使用
- 最終評価の全実行軌跡は trajectories.poolside.ai で公開
評価方法と報酬ハッキング対策
- エージェント評価には、正解や既存の修正をオンラインで探してスコアを得る 報酬ハッキング の問題がある
- インターネットアクセスをデフォルトで許可し、人手でラベル付けした軌跡で補正した LLM 審査員（LLMaaJ）を使って疑わしい事例をフラグ付け
- 初期の事後学習では報酬ハッキング率は 2% 未満だった
- 学習が進むにつれ、SWE-bench 系でフラグ付き軌跡が 50% を超えた
- 手動調査の結果、モデルが問題の根拠となった PR やリポジトリを見つけ、実際の修正を適用したケースが多かった
- オンラインで見つけた直接的な解答を使わないよう求める文言をユーザープロンプトに追加したところ、報酬ハッキング率は概ね 2% 未満まで低下
- 完全な解決策ではなく、ProgramBench と MirrorCode には例外があった
- 追加検証では、LLMaaJ がフラグ付けした成功事例の手動調査、全軌跡に対するオープンエンドなエージェント分析、Terminal-Bench 2.1 の高得点実行全体に対する専門家レビューを使用
- 最近では 敵対的審査 によって報酬ハッキング検出を強化しており、公開チェックポイントの最終評価軌跡を閲覧・ダウンロードできる
実作業の事例
-
空フォルダからブラウザエンジンを構築
- Laguna S 2.1 は人の介入なしで 50 分間に 181 ステップ を実行し、空フォルダから HTML/CSS レンダリングエンジンを構築
- 視覚機能がない状態で headless Chromium からキャンバスを読み取り、スクリーンショットを数値比較して結果を検証
- Vanilla JavaScript で全パイプラインを実装
- HTML トークナイザーと DOM ツリー
- セレクタ優先順位を処理する CSS パーサー
- 継承をサポートするカスケードエンジン
- ボックスモデルのレイアウトと Canvas 2D レンダラー
- 自前のキャンバスとブラウザ iframe に同一マークアップの 9 つの例を並べて表示するアプリとして完成
- 全実行軌跡 を公開
-
自社エージェントハーネスの最適化
- ベンチマークを計測した自動研究ループで、変更ごとに性能を測定し、改善が確認された変更だけを維持するよう制限
- 数時間にわたりハーネスを 5.2% 高速化 し、メモリ割り当てを約 70% 削減
- 主な最適化は以下の通り
- ストリーミングトークン蓄積に使っていた O(n²) の文字列連結をバッファへ置き換え
- 軌跡具体化プロセスの重複コピーをメモ化で除去
- スライスを正確なサイズで事前割り当てし、過剰割り当てを削減
- 速度差の測定が難しくなった後は、より正確に測定できるメモリ割り当て最適化へ焦点を移した
- 使用したベンチマークは完全な本番テストではないが、最終結果を Go race detector と
go vetゲートで検証し、成果物の動作を確認 - 全実行軌跡 を提供
-
Erdős 問題 #397 の再発見
- 1975 年に Erdős、Graham、Ruzsa、Straus が提案した Erdős 問題 #397 で、無限の解集合を作る構成を独立に発見
- この問題は 50 年以上未解決だったが、2026 年 1 月に GPT-5.2 Pro が先に解決 しており、初解ではなく再発見
- モデルの知識カットオフは 2025 年 11 月で、サンドボックスに Python がないため Perl を見つけて 68 分間作業
- 解決過程は以下の通り
- 正確な素因数分解を総当たりで探索
- パターンを分析して解集合を推測
- 8 個のインデックスからなる閉形式の無限解集合を証明
- 発見した式は、すべての
n ≥ 0で以下の通り
B(11+10n) · B(14+12n) · B(18+15n) · B(22+20n) = B(12+10n) · B(13+12n) · B(17+15n) · B(23+20n)- 既存の 6 インデックス解集合と異なり、線形に増加する 8 インデックス構造 を使用
- 全実行軌跡 を公開
推論モードと性能差
- 推論モードは off とデフォルトの max の 2 種類
- max は問題ごとの推論およびテスト時演算予算をモデルが決定
- 数時間・数十万トークンにわたって一貫した推論を継続した事例が観測されている
- max thinking を使うと性能が大きく向上
- Terminal-Bench 2.1: 60.4% → 70.2%
- DeepSWE: 16.5% → 40.4%
- 公開時点では low・medium・high のようなユーザー指定の推論強度制御は提供しない
poolではセッションごとの/thought-levelコマンドで thinking の使用有無を切り替えられる
既知の制約
- ハーネスへの過学習 のため、Hermes Agent のターミナルツールのように自社ハーネスと似ていても細部仕様が異なるツールを初めて呼び出す際、既存インターフェースの記憶に依存することがある
- ハーネスが誤った呼び出しを拒否して再試行を求めれば、文脈内学習で概ね解決する
- XML に似たタグベースのツール呼び出し形式を使っており、引数が JSON 配列を要求する場合に誤ったエスケープや無効な JSON を生成することがある
- 特に競技数学の問題で、進展がないまま 過度に長く推論 することがある
- 後続モデルでは推論強度制御と推論効率改善を導入する予定
性能向上をもたらした学習の変化
-
モデルサイズより作業様式の改善
- 目標は知能そのものを足すことだけでなく、より多く検証し、当然視せず、早期に成功宣言しない行動 を強化することにある
- 以前の Laguna モデルは一部のテストが通ると完了を宣言したり、成功直前でアプローチを放棄したりすることがあったが、S 2.1 は作業を続ける
- 生の知能とは別に、持続性・検証・戻る意志を重要な性能軸と見なし、両方に投資している
- 次の大型 Laguna モデルはすでに事前学習を開始している
-
事前学習と事後学習
- Laguna XS 2.1 と 同じ事前学習データ を使ったスケールアップモデル
- XS 2.1 との差は、規模、学習コードの修正、小規模な学習レシピ変更であり、新しいデータではない
- RL を初めて FP8 精度 で実行し、この学習段階を高速化
- 事後学習は 2 段階で実施
- 合成データを一部活用する教師あり微調整（SFT）で能力を初期化
- まだ高い通過率で解けていないタスクに RL を適用
- 長期エージェントセッションは数十万トークンの作業コンテキストを蓄積するため、1M コンテキスト拡張によって難しいタスクの性能を高める
-
事後学習タスク構成
- 学習コーパスはエージェント環境と非エージェント環境 409,000 件 で構成
- ターミナル利用環境 83,000 件
- 一般的なソフトウェアエンジニアリングタスク 168,000 件
- オープンソースリポジトリ、内部合成データ、自動依存関係インストールシステム、外部データプロバイダーの買収を通じてタスクを確保
- ソフトウェアエンジニアリングタスクは主に実際のコード履歴に基づく
- 約 17,000 リポジトリの実コミットを再現したタスク約 38,000 件が最大の比重を占める
- マージ済み PR の再現、注入バグの修正、テストスイートを基準に削除ファイルを復旧するタスクも含む
- S 2.1 には、リポジトリの全依存関係をインストールしてテストスイートを実行する エージェントリポジトリセットアップ タスクが追加
- ターミナルタスクでは、シードで見ていない環境や課題を生成するデータセットを使用
- 学習コーパスはエージェント環境と非エージェント環境 409,000 件 で構成
-
学習ループ改善
- 以前のモデルより、制限時間・ターンあたりトークン数・タスクあたりターン数を増やした より大きなロールアウト予算 を適用
- RL を新しいサンドボックスサービスへ移行し、以下の機能を活用
- バックグラウンドプロセスをサポート
- 選択的なネットワーク遮断で報酬ハッキングの攻撃面を縮小
- 成果物キャッシュで外部サービスの過負荷を防止
- 同じプロンプトを複数のエージェントハーネスで実行し、単一のスキャフォールドではなく多様なハーネスで通用する行動を学習させる
Poolside が注力する 2 つの方向性
- 1 つ目は エージェント型コーディング能力
- コーディングとソフトウェアの柔軟なインターフェースを、知能への道筋と見ている
- モデルがエージェントとしてソフトウェアを使い、数時間から数日にわたり一貫して作業する事例に注力
- 2 つ目は、Web に記録された答えから、その答えに至る思考過程を 強化学習で復元 できるというアプローチ
- 今回の公開は 1 つ目の方向の成果であり、2 つ目の方向は引き続き開発中
Model Factory と開発サイクル
- 社内の研究・エンジニアリング基盤 Model Factory により、データ、アーキテクチャのアブレーション実験、評価インフラなど、モデル開発プロセスを自動化
- Laguna M.1 の公開から 3 か月未満で、実行サイズが半分ながらより強力なモデルを開発
- 研究の反復と統合速度を高め、研究者が事務処理やインフラに向ける注意を減らすことに投資
- 今後 1 年間、同じ開発方式をさらに大規模なモデルへ適用する計画
配布と利用方法
- Hugging Face で OpenMDW-1.1 ライセンスのもと公開
- BF16、FP8、INT4、NVFP4 の重みを提供
- 公式 GGUF・MLX 変換と DFlash ドラフトモデルを提供
- NVIDIA ハードウェア向けには TRT-LLM サービング、Blackwell の NVFP4、単一 DGX Spark まで推論最適化をサポート
- ローカルおよび公開サービングは vLLM、SGLang、Ollama でサポート
- ホスティング経路は以下の通り
- Baseten Model Library と Frontier Gateway
- OpenRouter
- Vercel AI Gateway
- OpenRouter の無料エンドポイントは 256K コンテキスト を提供
- 専用の有料エンドポイントは 1M コンテキストをサポート
- 100 万トークンあたり入力 $0.10、出力 $0.20、キャッシュ読み取り $0.01
- Kilo、Hermes Agent、pi、OpenCode、OpenClaw、Cline と、ターミナルコーディングエージェント pool でも利用可能
- 事後学習は NVIDIA NeMo AutoModel と Prime Intellect Prime Lab をサポートし、ZML LLMD は複数ハードウェアでの実行をサポート
- 開発者でないユーザーはログインなしで chat.poolside.ai にて Web 検索と基本的なコード実行機能を利用できる
- 事後学習前の ベースモデル重み はメールでのリクエストにより提供
ベンチマーク実行条件
- 社内 Harbor Framework フォークと pool エージェントハーネス、最大 500 ステップ、社内サンドボックスを使用
- SWE-bench Multilingual、SWE-Bench Pro、Terminal-Bench 2.1 はタスクごと 4 回実行の平均 pass@1 を使用
- DeepSWE v1.1 と SWE Atlas はタスクごと 3 回、Toolathlon Verified は 3 回実行平均を適用
- SWE Atlas は公開方法論をそのまま適用し、Opus 4.5 で判定
- Toolathlon Verified は EC2 上の複製ハーネスとカスタムエージェントを使用し、公式版と異なり各評価実行後に環境を完全に初期化・復元
- サンドボックスの先取りを防ぐため、CPU・メモリ・ストレージの上限をベンチマークごとに調整し、最低 2 CPU コア、メモリ 8GB、ストレージ 25GB を保証
- 個別タスクの修正事項は 技術レポート にまとめられている
1件のコメント
Hacker Newsの反応
memfd_create()/mmapをIPCに使っているというとんでもない誤判定も下しており、Solも自分が指摘するまで見落としていたDeepSeek V4との比較は、FlashとProの両方がまもなく十分な追加学習を経て正式リリースされる予定なので、今のように変化の速い状況ではあっという間に変わり得る。こういうモデルが今後も出てきてほしい
https://github.com/mozilla-ai/otari/pull/348
Qwen 3.5 122Bの2ビット版も悪くないという評価があり、このモデルは出発点がより高いので試す価値がある。すでに作業している人もいる: https://huggingface.co/vcruz305/Laguna-S-2.1-GGUF
https://huggingface.co/poolside/Laguna-XS-2.1-GGUF/tree/main
Q4_K_Mでも75GBあるので、64GB環境だとしてもさらに低く量子化はしない気がする。その代わり、重みの一部だけをメモリ常駐させて 残りはSSDからストリーミングするほうがよいllm-compressorは、メモリに収まらないモデルも量子化 でき、逐次パイプラインを使えばよいhttps://github.com/vllm-project/llm-compressor
設定例は https://github.com/verdverm/quantr にある。ただ、Poolsideがモデルと一緒に量子化版とdflashを公開したので、今では不要かもしれない
これまではStrix Haloでは、デュアル32GB GPUデスクトップで動かすGemma 4やQwen 3.6の密モデルより明確に優れた選択肢がなかったが、このモデルは実際の性能向上をもたらしそうなサイズに見える
vLLMの実行設定に
--default-chat-template-kwargs '{"enable_thinking": true}'を入れても有効にならず、同梱のgeneration_config.jsonのmax_new_tokensのデフォルト値が32kのため推論が途中で切られているようなので、増やす必要がある。推論を有効にするとコード品質は大きく改善し、実作業での追加検証は必要だhttps://www.reddit.com/r/LocalLLaMA/comments/1v2pg99/laguna_...
Poolsideが同等クラスのモデルだけでなく、2.5TのKimi-K3のようなはるかに大規模な最上位の公開重みモデルとも比較しているやり方が気に入った。Mistralをはじめ他社もこうしてほしい
poolと 33B MoEモデル を見つけて、Poolsideを初めて知った。古い32GB Mac miniでも高速かつ効果的に動作し、大規模なホスティングモデルも評価してみるつもりだ