两种规模的Agentic AI：Nanbeige4.2-3B和Laguna S2.1

在最新一期的《The Weekly Kaitchup》中，作者Benjamin Marie聚焦了本周最引人注目的两款Agentic AI模型：Nanbeige4.2-3B和Laguna S 2.1。这两款模型都针对代理工作负载进行了优化，包括多步推理、工具使用、与外部环境交互以及需要多步骤完成的任务。然而，它们在规模上截然不同。

Nanbeige4.2-3B是一款紧凑的密集模型，总参数量约40亿，非嵌入参数约30亿。它的设计目标是让强大的代理行为能够运行在消费级和工作站硬件上。该模型采用了循环Transformer架构，而不是传统的多层Transformer。它包含22个物理解码器层，但这些层会被执行两次，实际计算深度相当于44层，而无需存储44个独立层。这种设计减少了权重内存，但推理计算量并未减少到普通22层模型的程度，每个token仍需要两次通过Transformer堆栈。模型有48个注意力头，每个头维度128，以及8个键值头。值得注意的是，循环设计引入了额外的内存考虑，除非实现显式共享KV缓存状态，否则每次循环可能需要单独的键值条目。作者建议，对于循环Transformer模型，命名应更明确，例如采用“3B-2P”表示3B参数和2次通过。

关于内存消耗，一个16GB GPU在谨慎设置下可以运行未量化模型，但中等上下文长度可能受限；24GB GPU则更宽裕。根据模型参数，KV缓存消耗估计为每缓存token约176 KiB。在16K token时，KV缓存约需2.75 GiB；而使用256K上下文时，单个活动序列可能需要约44 GiB，这几乎是Qwen3.6 27B在相同上下文长度下的两倍。部署方面，Nanbeige提供了专门的vLLM分支，支持OpenAI兼容API，并带有推理解析器和工具调用解析器，这对于代理框架至关重要。聊天模板提供了enable_thinking和preserve_thinking选项，用于控制推理过程。性能方面，根据官方评估，Nanbeige在大多数代理、编码和推理任务上超越了Qwen3.5-9B和Gemma 4 12B。

Laguna S 2.1则是一个规模大得多的MoE模型，总参数量1180亿，但每个token仅激活约80亿参数。它包含48个transformer层，其中12层使用全局注意力，36层使用滑动窗口注意力（窗口大小512），两者以约1:3的比例交错。这种设计使得信息能够跨越整个输入上下文，同时降低了长上下文推理的成本。模型有256个路由专家和1个共享专家，每个token选择top 10个路由专家。此外，它采用了每头softplus输出门控，允许每个注意力头拥有独立的音量控制，从而增强有用的注意力头。Laguna还支持交错推理，即模型可以推理、发出工具调用、接收结果后继续推理，然后再选择下一个动作。Poolside还提供了DFlash草案模型用于推测解码。

部署方面，Laguna支持vLLM 0.25.0及以上版本，可在单块B300 GPU上运行。INT4版本消耗低于80 GB，但需要96 GB GPU（如RTX Pro 6000）才能充分利用其上下文长度。对于编码代理工作负载，Poolside也建议保留之前的推理内容。KV缓存方面，256K token时估计消耗约24 GB。Laguna的主要应用场景是长周期软件工程，包括仓库级错误修复、终端交互、shell工作流、多语言代码维护等。尽管其稀疏架构和编码聚焦训练在终端交互和仓库级推理方面表现出色，但社区反馈褒贬不一。

总的来说，这两款模型代表了代理AI的不同路径：Nanbeige通过在小权重组上重复计算实现能力，而Laguna通过稀疏访问更大的参数池。作者表示将花时间测试这两款模型，并可能撰写关于它们用于代理编码的文章。此外，文章还提供了一份与Verda合作的50美元优惠券，用于尝试其GPU服务。