Agentic AI の二つのスケール:Nanbeige4.2-3B と Laguna S2.1 を解説
TLDR AI は、Nanbeige4.2-3B と Laguna S2.1 という 2 つの異なるスケールを持つ Agentic AI モデルの発表を報じ、エージェント機能の実装における多様なアプローチを紹介している。
AI深層分析を開く2026年7月28日 00:11
AI深層分析
キーポイント
2 つの異なるスケールのモデル発表
記事は、軽量な Nanbeige4.2-3B と大規模な Laguna S2.1 の 2 つの Agentic AI モデルが同時に発表されたことを伝えている。
スケールに応じたアプローチの違い
Nanbeige4.2-3B は小規模モデルにおけるエージェント機能の有効性を示し、Laguna S2.1 は大規模モデルによる高度な推論能力を追求している。
Agentic AI の実装事例
両モデルは、自律的なタスク実行や複雑な問題解決といったエージェント機能の実装において、異なる技術的アプローチを採用している。
Nanbeige4.2-3Bのアーキテクチャと評価
このモデルはvLLMとの連携により推論内容とツール呼び出しを分離し、Qwen3.5-9BやGemma 4 12Bを上回る性能を示した。ただし、多ターンツールの利用時に過去の推論履歴を保持するとコンテキスト長がすぐに限界に達するリスクがある。
Laguna S 2.1のハイブリッドアーキテクチャ
総パラメータ1180億のうち約80億を活性化させるMoE構造を採用し、グローバルアテンション層とスライディングウィンドウ層を交互に配置して長文コンテキスト処理を最適化している。
重要な引用
Agentic AI at Two Different Scales: Nanbeige4.2-3B and Laguna S2.1
"Per-head softplus output gating gives each attention head its own learned volume control."
"Laguna S 2.1 is more specialized than Nanbeige. Its primary target is long-horizon software engineering."
編集コメントを表示
編集コメント
このニュースは、Agentic AI の分野が特定の規模に偏らず、多様なスケールで進展していることを示す好例である。開発者は自社のユースケースに合わせて、最適なモデルの選択を検討する必要がある。
みなさん、こんにちは。
今週の『The Weekly Kaitchup』では、アジェンティックなワークロードに注目した2 つの注目リリースを取り上げます。それが「Nanbeige4.2-3B」と「Laguna S 2.1」です。
アジェンティックなワークロードとは、多段階の推論やツール利用、外部環境との対話、そして完了までに多数のアクションを要するタスクなどを指します。
- Nanbeige/Nanbeige4.2-3B
- poolside/Laguna-S-2.1
これら 2 つは共通の焦点を持っていますが、規模は大きく異なります。
Nanbeige4.2-3B は、総パラメータ数が約 40 億、埋め込み層を除く非埋め込みパラメータが約 30 億というコンパクトな密結合モデルです。このモデルの目的は、消費者向けやワークステーション向けのハードウェアでも、実用的なアジェンティックな振る舞いを実現することにあります。
一方、Laguna S 2.1 は、パラメータ数が 1,180 億に達する Mixture-of-Experts (MoE) モデルです。トークンごとに約 80 億のパラメータが活性化します。
この 2 つのモデルは、アジェンティック AI を実現するための異なるアプローチを示しています。Nanbeige は比較的小さな重みのセットに対して計算を繰り返す方式を採用しているのに対し、Laguna は学習済みのパラメータの大きなプールからスパースにアクセスする仕組みです。
Nanbeige4.1 では基本的な Llama アーキテクチャが採用されていましたが、Nanbeige4.2-3B では「Looped Transformer」を採用しています。
多数のユニークなトランスフォーマー層を持つのではなく、このモデルは物理的なデコーダー層を 22 層持っており、これを 2 回実行します。同じ重みが 2 回目のパスでも再利用されるため、44 層分の計算深度を実現しながらも、44 個の独立した層を保存する必要はありません。
この設計によりメモリ使用量は削減されますが、推論計算量が通常の 22 レイヤーモデル並みにまで減るわけではありません。各トークンは依然としてトランスフォーマースタックを 2 回通過する必要があります。
このモデルは次元数 128 のアテンションヘッドを 48 個持ち、キー/バリュー(KV)ヘッドも 8 個あります。これは非常に多い数値です。例えば、Qwen3.6 35B A3B では KV ヘッドはわずか 2 つしかありません。
ループ処理を導入すると、さらにメモリに関する考慮点が生じます。実装側で 2 回のパス間で KV キャッシュ状態を明示的に共有しない限り、各ループで個別のキー/バリューエントリが必要になる可能性があります。Nanbeige のデフォルト設定では、ループレベルでの KV 共有は有効化されていないようです。
さらに、Looped Transformer を使用するモデルには、より適切な名前をつけるべきだと考えます。3B モデルを使う際、6B モデル並みに遅いとは誰も期待しません。Qwen3.6 や Gemma 4 のような小規模な MoE モデルでは、アクティブなパラメータ数を名前に含める慣習があります(例:26B-A4B)。Looped Transformer についても同様の命名規則を採用すべきでしょう。例えば「3B-2P」(2 回のパスを意味する)といった具合です。
16GB の GPU でも、量子化なしで適切な設定を行えば、中程度のコンテキスト長であればモデルを実行可能です。24GB の GPU を用意すれば、より長いプロンプトや高い同時実行性、ランタイムのオーバーヘッドに対する余裕が生まれます。
このモデルは物理レイヤー 22 段、ループパス 2 回、KV ヘッド 8 個、次元数 128 のヘッド、BF16 形式の KV 値を採用しています。これらの仕様を踏まえた保守的な見積もりでは、アクティブなシーケンスごとにキャッシュされるトークン 1 つあたり、約 176 KiB の KV キャッシュ消費が必要となります。
以下の記事では、KVキャッシュのメモリ消費量を推定する方法を示します。
16K トークンの場合、KVキャッシュには約 2.75 GiB のメモリが必要です。一方、完全な 256K コンテキストを使用すると、アクティブなシーケンス 1 つあたり約 44 GiB の KVキャッシュメモリが必要になります。
これは非常に大きな容量です。同じコンテキスト長において、Qwen3.6 27B が消費するメモリのほぼ倍に相当します。
リリース時、Nanbeige はこのモデル用に特化した vLLM ブランチを提供しました:
その後、vLLM の OpenAI 互換 API を通じてモデルをサービス化できます:
#use --host 127.0.0.1 if you are running it locally
推論用パーサーとツール呼び出し用パーサーは、エージェントフレームワークにおいて極めて重要です。これらにより、vLLM は通常のアシスタントの応答テキストから、推論内容や構造化されたツール呼び出しを明確に分離できます。
Nanbeige のチャットテンプレートでは、2 つの設定項目が利用可能です。
enable_thinking オプションは、現在の応答に明示的な推論フェーズが含まれるかどうかを決定します。また、preserve_thinking オプションは、過去のアシスタントの応答に含まれていた推論内容を会話履歴に保持するかどうかを制御します。
通常のチャットや質問応答では、推論履歴を保持する必要はあまりありません。しかし、複数回のツール利用やオフィスワークフロー、コーディングエージェントにおいては、開発者は過去の推論内容を残すことを推奨しています。ただ、これが実際にうまく機能するかどうかは私には疑問です。
推論のトレースは非常に長くなる可能性があり、50K トークンを超えることもあります。たとえ一度きりの保持であっても、コンテキストに含めておくと、次のターンでモデルが最大コンテキスト長に達してしまうリスクがあります。
公開された評価結果によると、Nanbeige は Qwen3.5-9B を、主要なエージェント、コーディング、推論タスクのほとんどで上回りました。また、GDPval、SWE-Bench Verified、SWE-Bench Pro、Terminal-Bench 2.0 といったベンチマークでも、Gemma 4 12B を凌駕しています。
エージェントの性能は、ベースモデルだけでなく、推論予算の制限、ツールの定義、プロンプト戦略、会話状態の管理方法、リトライポリシー、そして最大アクション数などによっても大きく影響を受けます。
*参考:Nanbeige4.2-3B: Unlocking Agentic Capabilities in a Compact Model*
Laguna S 2.1 は、コーディングに特化したはるかに大規模な MoE(Mixture of Experts)モデルです。
このモデルの総パラメータ数は 1,180 億ですが、トークンごとに約 80 億のパラメータが活性化されます。推論時にはルーティング機構がエキスパートの一部を選択し、すべてのパラメータを各トークンで実行することなく、大規模な学習済みパラメータプールにアクセスできるようにしています。
Laguna は 48 層のトランスフォーマーで構成されています。そのうち 12 層はグローバルアテンションを、残りの 36 層はウィンドウサイズ 512 トークンのスライディングウィンドウアテンションを採用しています。グローバル層とローカル層は、およそ 1:3 の比率で交互に配置されています。
グローバル層によって、情報は入力コンテキスト全体を跨いで移動できます。一方、スライディングウィンドウ層は近傍のトークンへのアテンションに制限をかけることで、長文コンテキスト推論のコストを削減し、KV キャッシュの成長を抑えています。
このモデルには 256 のルーテッドエキスパートと 1 つの共有エキスパートが含まれています。各トークンに対して、ルーターは共有計算に加え、上位 10 個のルーテッドエキスパートを選択します。
また、Laguna はヘッドごとのソフトプラス出力ゲートも採用しています。
ヘッドごとのソフトプラス出力ゲートとは、各アテンションヘッドに独自の学習済み音量調整機能を与える仕組みです。モデルは各トークンに対して、個々のヘッドの寄与度を推論前に減衰させたり維持したり増幅したりできます。ソフトプラス関数によりゲート値は常に正しく保たれつつ 1 を超えることも可能になるため、有用なアテンションヘッドは単にオンオフするのではなく、強化することが可能です。
推論とツール呼び出しを交互に行う「インタリーブ推論」もサポートしています。モデルは推論を実行し、ツールの呼び出しを行い、その結果を受け取ってから再度推論を再開し、次のアクションを選択できます。
Poolside はさらに、スペキュレティブデコーディング用の DFlash ドラフトモデル も提供しています。このモデルは候補トークンを生成し、メインモデルが並列で検証することで、出力速度の向上が期待できます。
Lagana S 2.1 のサポートは、vLLM 0.25.0 以降で提供されています。
uv pip install -U "vllm>=0.25.0"
このモデルは単一の B300 GPU で動作します。
vllm serve poolside/Laguna-S-2.1 \
--enable-auto-tool-choice \
--tool-call-parser poolside_v1 \
--reasoning-parser poolside_v1 \
--default-chat-template-kwargs '{"enable_thinking": true}'
NVFP4 および INT4 バージョンは 80 GB 未満のメモリで動作しますが、モデルが持つコンテキスト長を最大限に活用するには、RTX Pro 6000 のような 96 GB GPU が必要です。
vllm serve poolside/Laguna-S-2.1-INT4 \
--enable-auto-tool-choice \
--tool-call-parser poolside_v1 \
--reasoning-parser poolside_v1 \
--default-chat-template-kwargs '{"enable_thinking": true}'
コーディングエージェントのワークロードにおいては、Poolside は会話履歴に過去の推論コンテンツ(reasoning_content)を保持することを推奨しています。
KV キャッシュのメモリ消費については、256K トークンで約 24 GB を要します。
Laguna S 2.1 は Nanbeige よりも特化型です。
主なターゲットは長期にわたるソフトウェアエンジニアリングです。これにはリポジトリレベルでのバグ修正、ターミナル操作、シェルベースのワークフロー、多言語コードの保守、コードベースの探索、大規模なソフトウェアリポジトリを理解して質問に応えることが含まれます。
Laguna のスパースアーキテクチャとコーディングに特化したトレーニングは、特にターミナル操作、リポジトリレベルでの推論、そして多言語によるソフトウェアエンジニアリングにおいて効果的です。
非常に優れたモデルに見えるものの、現時点でのコミュニティからの評価は賛否両論です。
今週は Nanbeige と Laguna に触れてみます。うまくいけば、これらを使ってエージェント型コーディングに関する記事も執筆する予定です。
Verda GPU を試すための 50 ドルクーポン
Verda とのコラボレーションにより、アカウントに 5 ドルをチャージした上で発行される 50 ドルのクーポン をご紹介します。このクーポンは Verda アカウントで利用でき、B200、B300、RTX Pro 6000 などの GPU を試すことができます。
クーポンコード: KAITCHUP-50
こちらの手順 に従ってクーポンの交換を行ってください。
*注:私はこのクーポンを紹介していますが、Verda から金銭的な報酬や利用状況に関する情報を一切受けていません。これは私が本当に良い取引だと考えているからです。なお、私の一部の記事に対して Verda が計算リソースのスポンサーシップを提供しています。
これで今週の更新は終了です。
The Kaitchup をお読みいただいている方、ぜひ友人や同僚にもシェアしてください(グループ購読には 20% オフの割引があります):
The Kaitchup – AI on a Budget をシェアする
良い週末を!
原文を表示
Hi everyone,
In this edition of *The Weekly Kaitchup*, I’m looking at two of the week’s most interesting releases for agentic workloads: Nanbeige4.2-3B and Laguna S 2.1.
Agentic workloads include multi-step reasoning, tool use, interaction with external environments, and tasks that may require many actions before completion.
- Nanbeige/Nanbeige4.2-3B
- poolside/Laguna-S-2.1
Despite this shared focus, they operate at very different scales.
Nanbeige4.2-3B is a compact dense model with approximately 4 billion total parameters and 3 billion non-embedding parameters. It is intended to make capable agentic behavior practical on consumer and workstation hardware.
Laguna S 2.1 is a 118-billion-parameter Mixture-of-Experts (MoE) model. It activates approximately 8 billion parameters for each token.
The two models represent different approaches to agentic AI. Nanbeige uses repeated computation over a relatively small set of weights, while Laguna uses sparse access to a much larger pool of learned parameters.
While Nanbeige4.1 used a basic Llama architecture, Nanbeige4.2-3B uses a Looped Transformer.
Instead of containing a large number of unique transformer layers, the model has 22 physical decoder layers that are executed twice. The same weights are reused during the second pass, giving the model the computational depth of approximately 44 layer executions without storing 44 independent layers.
This design reduces weight memory, but it does not reduce inference computation to that of a normal 22-layer model. Each token must still pass through the transformer stack twice.
The model has 48 attention heads with a dimension of 128, and eight key/value heads. This is a lot. For instance, Qwen3.6 35B A3B has only two KV heads.
Looping introduces a further memory consideration. Unless the implementation explicitly shares KV-cache state between the two passes, each loop may require separate key/value entries. Nanbeige’s default configuration does not appear to enable loop-level KV sharing.
Moreover, I think models using the Looped Transformer should be better named. When you use a 3B model, you don’t expect it to be nearly as slow as a 6B model. small MoE models, like Qwen3.6 and Gemma 4, show the number of active parameters in their name, like 26B-A4B. For Looped Transformers, we should adopt a similar convention, like 3B-2P (for “2 passes”), for instance.
A 16GB GPU should be able to run the model, without quantization, at moderate context lengths with careful settings. A 24GB GPU provides more room for longer prompts, greater concurrency, and runtime overhead.
Based on the model’s 22 physical layers, two loop passes, eight key/value heads, 128-dimensional heads, and BF16 KV values, a conservative estimate places KV-cache consumption at approximately 176 KiB per cached token for each active sequence.
*I show in the following article how to estimate the KV cache memory consumption:*
At 16K tokens, this would require roughly 2.75 GiB of KV-cache memory. Using the complete 256K context could require roughly 44 GiB of KV-cache memory for a single active sequence.
This is very large. Almost twice as much as what Qwen3.6 27B would consume for the same context length.
At release, Nanbeige provided a dedicated vLLM branch for the model:
git clone -b nanbeige42 https://github.com/Nanbeige/vllm.git
cd vllm
pip install -e .The model can then be served through vLLM’s OpenAI-compatible API:
vllm serve Nanbeige/Nanbeige4.2-3B \
--host 0.0.0.0 \
--port 8000 \
--enable-auto-tool-choice \
--tool-call-parser nanbeige \
--reasoning-parser nanbeige
#use --host 127.0.0.1 if you are running it locallyThe reasoning and tool-call parsers are important for agent frameworks. They allow vLLM to separate reasoning content and structured tool calls from ordinary assistant text.
Nanbeige’s chat template exposes two controls.
The enable_thinking option determines whether the current response contains an explicit reasoning phase. The preserve_thinking option determines whether reasoning content from previous assistant turns remains in the conversation history.
For normal chat and question answering, preserved reasoning can usually be disabled. For multi-turn tool use, office workflows, and coding agents, the developers recommend retaining earlier reasoning content but I don’t understand how this can work well. Reasoning traces can be very long, like 50K+ tokens. Keeping them in the context, even if it’s just one, means that the model may reach its max context length at next turn.
According to the published evaluation, Nanbeige exceeded Qwen3.5-9B on most of the included agent, coding, and reasoning tasks. It also surpassed Gemma 4 12B on benchmarks including GDPval, SWE-Bench Verified, SWE-Bench Pro, and Terminal-Bench 2.0.
Agent results are influenced not only by the base model but also by the allowed reasoning budget, tool definitions, prompting strategy, conversation-state handling, retry policy, and maximum number of actions.
*Reference: Nanbeige4.2-3B: Unlocking Agentic Capabilities in a Compact Model*
Laguna S 2.1 is a much larger coding-focused MoE model.
It contains 118 billion total parameters but activates approximately 8 billion parameters for each token. A routing mechanism selects a subset of experts during inference, allowing the model to access a large learned parameter pool without executing every parameter for every token.
Laguna contains 48 transformer layers. Twelve use global attention, while the remaining 36 use sliding-window attention with a window of 512 tokens. The global and local layers are interleaved in approximately a one-to-three ratio.
The global layers allow information to move across the complete input context. The sliding-window layers restrict attention to nearby tokens, reducing the cost of long-context inference and limiting KV-cache growth.
The model contains 256 routed experts and one shared expert. For each token, the router selects the top ten routed experts in addition to the shared computation.
Laguna also uses per-head softplus output gating.
Per-head softplus output gating gives each attention head its own learned volume control. For every token, the model can reduce, preserve, or amplify the contribution of individual heads before combining their outputs. The softplus function keeps these gates positive while allowing values above one, so useful attention heads can be strengthened rather than merely switched on or off.
It uses interleaved reasoning. The model can reason, issue a tool call, receive the tool result, and resume its reasoning before selecting another action.
Poolside also provides a DFlash draft model for speculative decoding. These models generate candidate tokens that the main model can verify in parallel, potentially increasing output speed.
Laguna support is documented for vLLM 0.25.0 or newer:
uv pip install -U "vllm>=0.25.0"The model can run on a single B300 GPU:
vllm serve poolside/Laguna-S-2.1 \
--enable-auto-tool-choice \
--tool-call-parser poolside_v1 \
--reasoning-parser poolside_v1 \
--default-chat-template-kwargs '{"enable_thinking": true}'The NVFP4 and INT4 versions consume fewer than 80 GB but you would need a 96 GB GPU, like an RTX Pro 6000, to exploit the context length of the model.
vllm serve poolside/Laguna-S-2.1-INT4 \
--enable-auto-tool-choice \
--tool-call-parser poolside_v1 \
--reasoning-parser poolside_v1 \
--default-chat-template-kwargs '{"enable_thinking": true}'For coding-agent workloads, Poolside also recommends retaining prior reasoning_content in the conversation history.
As for the memory consumption of the KV cache, 256K tokens should consume around 24 GB.
Laguna S 2.1 is more specialized than Nanbeige.
Its primary target is long-horizon software engineering. This includes repository-level bug fixing, terminal interaction, shell-based workflows, multilingual code maintenance, codebase exploration, and answering questions that require understanding large software repositories.
Laguna’s sparse architecture and coding-focused training are particularly effective for terminal interaction, repository-level reasoning, and multilingual software engineering.
It looks like a very good model but so far, I have found community feedback to be mixed.
*reference: Introducing Laguna S 2.1*
I’ll spend some time with Nanbeige and Laguna. If everything goes well, I’ll probably write an article using them for agentic coding.
### A $50 Coupon to Try Verda’s GPUs
In collaboration with Verda, I’m sharing a $50 coupon that you can redeem in your Verda account, after provisionning your account with $5, to try their GPUs (B200, B300, RTX Pro 6000, …).Coupon code: KAITCHUP-50Follow these instructions to redeem it.Note: I share this coupon because I really think it’s a good deal. I don’t receive any form of compensation from Verda, or any usage information, related to this coupon. Verda also provides compute sponsorship for some of my articles.
That’s all for this week.
If you like reading The Kaitchup, consider sharing it with friends and coworkers (there is a 20% discount for group subscriptions):
Share The Kaitchup – AI on a Budget
Have a nice weekend!
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み