Poolside 发布代码模型 Laguna S 2.1：仅激活 8B，长程编程叫板万亿模型

Laguna S 2.1 是 Poolside 开源的一个代码大模型，主打在本地或私有算力上扛住长流程、需要反复排错的复杂编程任务。

它的总参数量为 118B，但采用了混合专家（MoE）架构，每个 token 实际只激活 8B 参数。这意味着它的推理计算开销被压得很低，同时还能吃下多达 1M token 的超长上下文，折合大约 70 万字的技术文档或完整项目代码。

官方从启动训练到最终上线只花了不到 9 周时间。目前模型的完整权重已经在 Hugging Face 上开放下载，同时所有评测任务的完整交互轨迹也都公开在了专门的网站上。

它能做到什么程度

这个模型最特别的地方在于它非常擅长做「智能体式的长程编码」，也就是自己写代码、跑命令、看报错，然后自我纠错接着干。

它自带思考模式和非思考模式，默认开启最大思考。在测试长程终端任务的 Terminal-Bench 2.1 上，它跑出了 70.2% 的成绩；在考验综合软件工程能力的 DeepSWE 上，打开思考模式后得分直接从 16.5% 跃升到 40.4%。面对参数量动辄是它几倍甚至上万亿的模型，这个表现也毫不逊色。

官方给出的实测演示也很有说服力。在没有任何人类干预的情况下，它在一个空文件夹里花了 50 分钟、走了 181 步，用纯 JavaScript 从零手写出一套包含解析、排版到渲染的 HTML/CSS 浏览器引擎。由于模型本身没有视觉能力，它甚至自己调起无头 Chromium 截屏并进行像素数值比对来验证渲染结果。

在另一个内部测试里，它连续运行数小时优化 Poolside 自己的测试框架代码，把其中的字符串拼接优化成缓冲区操作，消除了多余内存拷贝，最终让框架提速 5.2%，内存分配直接砍掉了约 70%。甚至在只有 Perl 环境且完全离线的数学挑战中，它耗时 68 分钟独立推导出了数论中未解悬赏问题 Erdős #397 的一组无限解。

硬件要求与已知短板

如果你打算在本地部署，完整 FP16 权重的体积大概是 235 GB，需要多卡或类似 DGX Spark 的高显存工作站。不过社区和官方也准备了量化版本，比如 NVFP4 量化版体积已经压到了 71 GB，部署门槛低了不少。

虽然官方同时也提到了一个仅激活 3B 的 33B 极小版 XS 变体，但根据社区实测，XS 版本的实际代码能力相比同体量的 Qwen 3.6 依然有明显差距，现阶段主力还是推荐跑这个 118B 的 S 版本。

上手时需要留意几个限制：它在适配第三方 Agent 框架（如 Hermes Agent）时偶尔会出现工具接口格式过拟合的问题，需要 harness 在报错后要求它重试才能纠正；另外对于嵌套工具调用以及需要输入复杂 JSON 数组的工具接口，它也容易偶发格式偏差。

为什么重要

对于需要搭建本地编码 Agent、又不想把内部核心代码传到云端闭源 API 的团队来说，Laguna S 2.1 是目前百 B 级别里极少见能真正自主跑完复杂工程任务的开源选手。激活 8B 保证了推理吞吐，1M 上下文保证了喂进整个代码库不爆显存，非常适合做代码库重构和自动化 Bug 修复。

我们认为 Poolside 这一步走得很讨巧：它没有盲目堆总参数去硬碰万亿大模型，而是通过 MoE 结构把推理成本牢牢锁在 8B 级别，把核心精力全花在强化长程规划和工具自纠错上。虽然在接口鲁棒性上还有些粗糙，但只要给它配好执行沙箱和反馈循环，它在自主写代码这件事情上的韧性已经足够给开源阵营带来惊喜。