Laguna S 2.1公開初日、118Bモデルの高評価とローカル実行の難しさが交錯

確認できたこと

Poolsideは2026年7月21日、エージェント型コーディングと長時間タスク向けのオープンウェイトモデル「Laguna S 2.1」を公開しました。 総パラメータ数は118B、1トークンごとに約8Bを有効化するMixture-of-Expertsモデルで、テキスト入力専用です。 公式モデルカードでは最大1,048,576トークンのコンテキストと、thinkingの有効・無効を切り替えるモードが案内されています。

PoolsideはTerminal-Bench 2.1で70.2%などの評価値を掲載し、最終評価のtrajectoryも公開しています。 ただし、これはPoolsideのエージェント環境を含むベンダー公表値です。 同社自身も、第三者ハーネスでのツール定義への追従、長すぎるthinking、JSON引数を含むツール呼び出しを既知の制約として挙げています。

ローカル向けにはFP8、NVFP4、INT4、GGUFが用意されています。 公式GGUFのファイルサイズはF16が235GB、Q8_0が128GB、imatrix適用のQ4_K_Mが75GBです。 GGUFは品質面から256Kコンテキスト設定が推奨され、1Mへ拡張した場合は品質低下の可能性があると明記されています。 llama.cppのLaguna対応PRは7月22日にmasterへマージされました。

ライセンスはOpenMDW-1.1です。 モデルカードは商用・非商用での利用と改変を案内する一方、PoolsideのAcceptable Use Policyに従い、安全ガードレールを同等の対策なしに回避しないよう求めています。 したがって、Laguna S 2.1を公式に「非検閲」またはNSFW特化モデルとして扱う根拠はありません。

Redditで目立った利用者報告

公開直後のr/LocalLLaMAでは、118B-A8Bという規模と公式ベンチマークに期待する反応が集まりました。 96GBのRTX Pro 6000で公式NVFP4を試した利用者からは、速度やツール呼び出しを評価する報告がある一方、独自テストでは情報がない場面で事実を作る傾向が見られたという報告もあります。

別の複数の利用者からは、thinkingが長時間終わらない、同じ処理を繰り返す、チャットテンプレートや量子化方式によって出力品質が変わる、という初日報告が出ています。 反対に、thinkingを正しく有効化し、出力上限やsamplingを調整すると改善したという報告もありました。

これらは統一条件の第三者ベンチマークではなく、vLLM、llama.cpp、OpenRouter、NVFP4、INT4、GGUFなどが混在した利用者報告です。 現時点では「公式評価どおりに強い」「モデル自体に問題がある」のどちらかへ一般化できません。 少なくとも、公開初日の使い勝手がモデルだけでなく、thinking設定、テンプレート、量子化、推論バックエンドに強く左右された傾向は複数の独立した議論で確認できます。

llimuの創作・ローカル運用への示唆

Laguna S 2.1は成人向け文章生成を目的にしたモデルではなく、現時点でllimuが注目すべき用途はゲームコード、制作補助ツール、長い仕様を扱うエージェント作業です。 画像入力には対応しないため、画像素材の確認や視覚的な品質管理には別のモデルや人間の確認が必要です。

また、Q4_K_Mだけで75GBあるため、一般的な24GB GPU 1枚へ全ウェイトを載せるモデルではありません。 CPUオフロード、複数GPU、大容量の統合メモリを使う場合も、実際の必要メモリはコンテキスト長、KVキャッシュ、バックエンドで変わります。 「MoEは有効パラメータが8Bだから小型GPUで動く」と単純化せず、保存容量と総ウェイト、長文コンテキストの追加負荷を分けて見積もる必要があります。

創作環境へ導入するなら、最初から1Mコンテキストや長時間の自律実行を狙うより、次の順序が堅実です。

1. 公式推奨の256K以下と対応済みバックエンドで起動する
2. thinkingの有無、出力上限、チャットテンプレートを記録する
3. 実際の短い制作タスクで、ループ、事実の創作、ツール引数を確認する
4. 合格した設定だけでコンテキストと自律実行時間を段階的に延ばす

公開ベンチマークは候補選びには使えますが、創作ワークフローへの採用判断には不十分です。 とくに未公開設定や成人向け企画を扱う場合は、ローカルで動くことに加え、ハーネスの通信、ログ保存、利用条件を確認し、小さな再現テストを残すことが重要です。