商汤开源 9B 循环计算模型预览版

9B 参数的模型，能不能接近 27B 模型的任务表现？商汤开源的 SenseNova Loop-9B-Preview 给出的路线，是让部分网络层共享参数、反复计算，以更深的计算过程处理复杂任务。

据 IT之家报道，商汤在 10 月 30 日宣布开源该模型，并公布了部分评测和消融结果。对程序员来说，值得看的是这套设计如何起作用，以及「媲美 27B」距离实际选型依据还有多远。

9B 怎么挑战 27B：同一组参数多算几轮

SenseNova Loop-9B-Preview 采用 Looped Transformer 架构。它以 9B 尺度模型为基座，保留首尾各 4 层原始解码器模块，把中间层改造成参数共享的循环计算模块。

普通的理解方式是：中间这部分网络不只执行一次，而是让同一组参数参与多轮迭代。这样无需按计算轮数复制参数，也能扩展模型的有效计算深度。

参数共享可以控制参数规模，但循环计算仍然需要付出计算成本。

因此，9B 描述的是参数规模，不能单凭这个数字推断响应速度或部署成本。原文没有给出循环次数、推理延迟、吞吐量和显存占用，也没有说明与 27B 模型相比的资源消耗。

这条路线的价值在于探索：小模型能否通过更多计算，完成原本需要更大模型处理的复杂任务。至于是否更划算，还需要另一组数据回答。

mHC 改善信息传递，消融结果有多大说服力

反复计算只是架构的一部分。模型还尝试引入 mHC（Manifold-Constrained Hyper-Connections），通过多路残差连接与受约束的信息混合，增强特征交互，并维持信号传播的稳定性。

可以把它理解为：除了让网络多算几轮，还调整不同计算路径之间如何传递、混合信息，尽量让信息在更深的计算过程中保持稳定。

官方给出的消融实验显示，引入 mHC 后：

• GPQA Diamond 提高了 4.42 分。
• TeamBench 提高了 13.34 分。

消融实验比单纯展示最终成绩更有解释力，因为它试图隔离某项机制的贡献。但报道没有提供基线分数、完整实验配置和重复实验情况，因此能确认的是官方报告了增益，暂时无法仅凭这两个分差判断收益是否普遍、是否稳定。

官方还表示，在当前评测设置下，模型在代码生成、办公场景和智能体任务等方向表现较好，并在 WorkBuddy Bench、RaccoonPPT Bench 和 AutomationBench 上超过 Qwen3.5-27B。

这里应保留「当前评测设置下」这个限定。原文没有列出完整得分、各项差距及运行配置，「媲美 27B」应理解为特定评测中的表现主张，不能扩展成所有任务都达到同一水平。

后续计划探索 DSA、自适应迭代次数等机制，以改善推理效率与任务表现。原文没有展开 DSA 的具体方案，这些也属于后续方向，不能算作当前版本已经具备的能力。

我的判断

我认为，这篇消息最有价值的地方，是提醒模型选型不能只按参数量排队。共享参数、增加有效计算深度，确实提供了一条值得验证的技术路线；mHC 的消融结果也比一句「全面领先」更有参考价值。

但这篇报道不足以支持「9B 可以直接替代 27B」的结论。它没有给出完整对照数据，也没有交代任务成绩背后的时间和资源成本。现有材料是官方评测结果的转述，缺少独立复现。

与直接选用更大参数模型相比，这条路线把关注点转向了计算深度与信息传递。哪种方案更适合团队，要看同等资源预算下能完成多少任务，以及完成得是否可靠。对于代码生成和 Agent，单项榜单排名还不能回答项目约束、工具调用和多步骤执行中的全部问题。

能拿来做什么

• 如果团队正在筛选代码生成模型，可以把 SenseNova Loop-9B-Preview 纳入候选，用同一批前端或 Node 任务比较修改正确率、测试通过情况和完成耗时，验证榜单优势能否迁移到自己的项目。
• 如果准备评估多步骤 Agent，可以固定工具、提示词和执行预算，记录最终任务是否完成及中途失败位置，重点检验原文提到的复杂任务能力。
• 如果看中 9B 的参数规模，应在试跑时同时记录显存、延迟和吞吐量。循环计算的实际成本，是判断它是否适合日常 AI 编程的必要信息。