2026-10-30，商汤日日新团队发布并开源了 SenseNova Loop-9B-Preview，一个用"循环计算"换参数规模的实验性大模型：总参数量约 9B，单次前向的计算量却约 14.6B，官方称其在多项评测中表现出"仅 9B 参数规模下媲美 27B 参数模型"的能力。代码托管在 SenseNova Loop 开源仓库，采用 Apache-2.0 许可证，仓库于 2026-10-29 创建，截至 2026-11-03 约 89 颗星；模型权重发布在 HuggingFace，地址是 huggingface.co/sensenova/SenseNova-Loop-9B-Preview，BF16 精度导出。
它的核心卖点一句话就能讲清："存 32 层、算 56 层"。模型权重里只存 32 个不同的解码层，但每次前向传播会实际执行 56 次解码层计算。按照传统路径，想要 27B 级别的表现，参数就得实打实堆到 27B；SenseNova Loop-9B-Preview 走的是另一条路：把"计算深度"从参数里拆出来，当成可以单独分配的资源。商汤在官方技术博客中称，这是面向下一代模型架构的前沿探索——多轮计算如何真正转化为能力提升、信息在循环中如何传递、训练稳定性如何保证，这些问题都还有探索空间。换句话说，这是一个值得认真研究的 Preview，不是一个可以直接抄作业的答案。
为什么不堆参数：计算深度这条新赛道
大模型这几年的主旋律是堆参数：参数越多、能力越强，代价是训练更贵、推理更慢、部署门槛更高。参数量直接决定两样东西：一是权重文件的大小和加载时占用的显存，二是每生成一个 token 要做多少矩阵乘法。27B 模型意味着你得有装得下 27B 权重的卡，还得忍受比 9B 模型更慢的出字速度。
Looped Transformer 架构的想法是把这两件事解耦。参数量决定"存了什么"，循环次数决定"算了多深"。同一个解码层的权重可以反复使用，每循环一次，网络就在原有计算深度上再叠一层变换。理论上，一个 9B 参数的模型可以通过足够多的循环，获得接近更深、更宽模型的函数表达能力，而权重文件和显存占用仍然是 9B 的水平。省下来的是"存"的成本，多花的是"算"的时间——本质上是拿每个 token 的推理时延，去换部署门槛和权重体积的下降。
这条路线并不新，但此前社区的 Looped Transformer 探索大多停留在学术层面：论文不少、可用的开源模型稀少。SenseNova Loop-9B-Preview 的价值在于，它是少数被完整训练出来、公开发布权重、还配套了部署与微调工具链的实践样本。对研究循环架构的人来说，这是第一个可以直接上手复现和改造的量产级参照物；对更广大的开发者来说，它至少回答了一个问题：这条路走得通，而且跑出来的模型能用。
当然要泼一盆冷水：计算深度不是免费的。同样的 14.6B 计算量摊在每个 token 上，出字速度天然慢于一次性算完的稠密 9B 模型，除非配合循环场景下的专用推理优化。商汤在官方博客中也把这一点框定为开放问题——多轮计算到底怎么换来能力，还在探索。所以正确的打开方式不是"9B 的价格买 27B，稳赚"，而是"用时间换空间"这个选项第一次被开源社区认真摆上了货架。
拆开看：32 层怎么跑出 56 层
先看数字怎么对上的。模型总共 32 个不同的解码层，首尾各保留 4 层原始解码器模块不做循环——开头的 4 层负责把输入编码好，结尾的 4 层负责把最终表示解码出来。中间第 4 至第 27 层的连续 24 层是循环段：这 24 层的权重以共享方式循环执行 2 次，等于同样的计算走了两遍。算总账就是 8 层不循环加 24 层乘以 2，单次前向恰好 56 次解码层计算，而参数只按 32 层存一份。"存 32 层、算 56 层"就是从这里来的，约 9B 的总参数量对应约 14.6B 的单次前向计算量，比例大约是 1.6 倍。
注意力机制上它也是混合设计：解码层按 4 层一组循环，组内 3 层用线性注意力、1 层用全注意力。线性注意力在长序列上的计算开销远低于全注意力，穿插使用可以在 256K 量级的上下文里把成本压住。多模态方面，模型接受文本加图像输入、输出文本，面向长上下文与智能体工作流设计，训练序列最长 262,144 个 token，也就是 256K。推理加速方面，模型内置 MTP（多 token 预测）且已可用，权重以 BF16 精度导出。
把这套设计放在一起看，逻辑是自洽的：循环段负责用重复计算榨取深度收益，混合注意力负责让 256K 的长上下文不至于算不起，MTP 负责把出字速度往回拉一点。每一块单独看都不是首创，但组合成一个 9B 级别、权重公开、工具链齐全的模型，这是头一回。
mHC：让循环不掉链子的信息高速
权重循环执行最大的隐患是信息衰减：同一组权重跑两遍，第二遍拿到的输入是第一遍的输出，信号在反复穿过同一组变换时容易丢失或失真。商汤的解法是在循环段引入双流 mHC（Manifold-Constrained Hyper-Connections，流形约束超连接）。
用大白话讲，mHC 维护两条并行的残差流，并通过学习到的映射来管理这两条流之间的信息流动。传统 Transformer 只有一条从底层通向顶层的残差通路，循环架构等于让信息在同一条通路上反复折返，很容易"绕晕"；双流设计相当于给信息修了一条并行高速，每一轮循环都可以在两条流之间做选择性的搬运和融合，既增强了特征交互，也稳定了信号传播。
效果有消融数据支撑。商汤公布的官方消融实验显示，开启 mHC 后，GPQA Diamond 提升 4.42 分，TeamBench 提升 13.34 分，BIRD-Dev 提升 3.60 分，LiveCodeBench V6 提升 2.36 分，Data Analysis 提升 2.22 分。其中 TeamBench 的 13.34 分涨幅尤其值得注意——团队协作类任务最依赖复杂的多步信息传递，恰好是循环架构最容易掉链子、也最需要 mHC 这类机制兜底的地方。这组数字说明 mHC 不是锦上添花的工程装饰，而是让"存 32 层算 56 层"真正成立的关键部件：没有它，循环带来的可能不是更深的能力，而是更糊的信号。
官方成绩单说了什么（标口径）
先立规矩：以下成绩均为商汤官方自报口径，出自其官方技术博客与模型卡，尚无广泛认可的第三方复现，采信程度请自行把握。按官方说法，SenseNova Loop-9B-Preview 在 WorkBuddy Bench、RaccoonPPT Bench（商汤内部自研的演示文稿生成评测基准）、AutomationBench 等评测中超过 Qwen3.5-27B，整体表现"在仅 9B 参数规模下媲美 27B 参数模型"。需要注意这组评测的选型偏向：WorkBuddy Bench 与 AutomationBench 都偏智能体与自动化工作流，RaccoonPPT Bench 直接来自商汤自研业务的场景，这与其"面向长上下文与智能体工作流设计"的定位一致——它不是在跟 27B 模型比通识问答，而是在 agent 场景这个主场作战。
横向参照方面，ai-bot.cn 整理的对比资料给出：SenseNova Loop-9B-Preview 约 9B 参数、单次前向约 14.6B 计算量，对比对象 Qwen3-8B 是 8.2B 参数。也就是说在参数量接近 8B 档的模型里，它用多出来的约 6B 计算量去兑换能力，这笔账划不划算，取决于你的场景对时延是否敏感。
落地案例方面，官方已把模型接入商汤小浣熊客户端实践，展示案例包括"虚构月球任务展示网站"和"冰岛：光与地貌的旅行"等，都属于生成完整网页或演示文稿的智能体任务。这类案例的实际参考价值有限——厂商展示的必然是成功案例——但至少证明模型在真实产品管线里跑过，不是只会刷榜的实验室产物。
诚实的部分也得说：官方自己明确这是 Preview 定位，面向下一代架构的前沿探索，多轮计算如何真正转化为能力提升、信息传递与训练稳定性等问题仍有探索空间。翻译过来就是：评测分数很好看，但"循环计算"与"能力提升"之间的因果链条还没有完全论证清楚，距离"闭眼上生产"有明显距离。
怎么跑起来与适合谁
部署路径还算顺畅。仓库地址是 github.com/OpenSenseNova/SenseNova-Loop，权重在 HuggingFace 的 huggingface.co/sensenova/SenseNova-Loop-9B-Preview。最简单的方式是用 Transformers 直接加载模型权重，开箱即可推理；要上服务化部署，可选用 LightLLM 或 SGLang，其中 SGLang 需要用带相应支持的 PR 分支。模型内置的 MTP 推理加速已可用，配合 BF16 权重，9B 级别的参数量意味着单张消费级或工作站级显卡的显存基本装得下，不需要多卡集群。
想自己动手微调的，官方提供了 fork 的 torchtitan 训练框架，支持 8 卡环境下的 SFT、DPO 和 MTP 训练，等于把预训练之后的主流对齐手段都铺好了。torchtitan 本身是 PyTorch 官方的大模型训练框架，工程质量有保证，二次开发文档也相对齐全。
那么适合谁？三类人值得花时间：一是架构研究者，想复现或改进 Looped Transformer、研究循环深度与能力的关系，这是目前唯一一个权重、代码、训练框架三件套齐全的循环架构开源模型；二是智能体应用开发者，如果你的场景是网页生成、演示文稿生成、自动化工作流这类 agent 任务，且对时延不敏感、对部署成本敏感，可以拿它在自己的评测集上跑一跑，验证官方口径是否在你身上成立；三是推理优化方向的工程团队，"循环执行"给了 KV 缓存管理、计算复用、投机解码等优化技术一个全新的实验场。反过来，如果你只是想要一个稳定好用的通用模型跑日常业务，Qwen3.5 这类成熟模型仍是更稳妥的选择，等非 Preview 版本再来看不迟。
按官方后续规划，这条架构线还会继续演进：更大规模的 Scaling 实验、自适应的"快慢思考"机制（简单问题少循环、复杂问题多循环）、以及 DSA 等机制都在路线图上。如果自适应循环真能落地，"按需分配计算深度"会比现在的固定 56 次执行更有想象力——那才是这条新赛道真正成熟的样子。
常见问题
**Q1：**9B 参数的模型为什么能比肩 27B？计算量不是更大了吗？
A1：它比肩 27B 靠的是循环计算带来的深度，不是参数量。模型只存 32 个解码层（约 9B 参数），但中间 24 层共享权重循环执行 2 次，单次前向共执行 56 次解码层计算，计算量约 14.6B。计算量确实比稠密 9B 大，但这是设计本意：拿推理时延换部署门槛，权重文件和显存占用仍停留在 9B 水平。至于效果，官方口径是在 WorkBuddy Bench 等 agent 向评测中超过 Qwen3.5-27B，属官方自报，建议用自己的真实任务验证。
**Q2：**Loop-9B 是正式版吗？能直接上生产吗？
A2：不是。它明确标注 Preview 定位，是商汤面向下一代模型架构的前沿探索版本。官方自己也承认，多轮计算如何真正转化为能力提升、信息传递与训练稳定性等问题仍有探索空间。可以拿来研究、评测、跑实验，但直接承载生产业务有风险，建议等后续更成熟的版本。
**Q3：**它和 Qwen3-8B 这类同规模模型比，优势在哪？
A3：按 ai-bot.cn 整理的对比，两者参数量接近（约 9B 对 8.2B），但 Loop-9B-Preview 单次前向计算量约 14.6B，等于在相近的部署体积下用了更深的计算。官方评测里它的强项集中在智能体工作流、长上下文任务上，这与其面向 agent 场景的设计定位一致。劣势也明确：每个 token 的推理时延更高，且循环架构的生态成熟度远不如常规 Transformer。
**Q4：**256K 上下文和循环计算有什么关系？
A4：两者是配套设计。训练序列最长 262,144 个 token，注意力层采用 4 层一组的混合结构——组内 3 层线性注意力加 1 层全注意力。线性注意力大幅降低长序列下的计算开销，让 256K 的上下文在工程上算得起；而循环带来的表达能力，则用来弥补线性注意力在精确检索类任务上的损耗。没有混合注意力，256K 配循环的计算成本会很难接受。
**Q5：**我想自己微调，官方给了什么工具？
A5：官方 fork 了 torchtitan 训练框架，支持 8 卡环境下的 SFT、DPO 和 MTP 训练，从指令微调到偏好对齐到多 token 预测的训练路径都覆盖了。推理侧，Transformers 可直接加载权重，LightLLM 和 SGLang（需 PR 分支）可用于服务化部署。仓库和权重的许可证是 Apache-2.0，商用二次开发在协议层面没有障碍，但记得遵守模型卡中的使用规范。