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 級別，把核心精力全花在強化長程規劃和工具自糾錯上。雖然在介面魯棒性上還有些粗糙，但只要給它配好執行沙箱和反饋迴圈，它在自主寫程式碼這件事情上的韌性已經足夠給開源陣營帶來驚喜。