兩種規模的Agentic AI:Nanbeige4.2-3B和Laguna S2.1
本文分析了本週釋出的兩款針對Agentic工作負載的AI模型:Nanbeige4.2-3B和Laguna S 2.1。Nanbeige4.2-3B是一個緊湊的密集模型,採用迴圈Transformer架構,適合消費級硬體;Laguna S 2.1是一個1180億引數的MoE模型,專注於軟體工程任務。文章詳細介紹了它們的架構、推理效率、記憶體消耗以及使用vLLM的部署方式。
在最新一期的《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服務。