商汤开源 SenseNova Loop-9B：32 层权重跑 56 次计算，"9B 打 27B"这笔账怎么算

2026 年 10 月 30 日，商汤开源了日日新 SenseNova Loop-9B-Preview，Apache 2.0 许可，权重在 Hugging Face，代码在 GitHub。这是国内第一个把 Looped Transformer 做到 9B 量级、还带原生多模态的开源模型。

官方口径很直接：仅 9B 参数，媲美 27B 参数模型。在 WorkBuddy Bench、RaccoonPPT Bench、AutomationBench 三个基准上超过 Qwen3.5-27B。

这个说法值得拆。不是因为它是吹牛，而是因为"9B 打 27B"背后有一笔明确的工程账——参数量省了，但计算量没省。省下来的是显存，花出去的是时间和电。

本文按一次前向传播的顺序走一遍：从入口层进去，穿过循环体两遍，从输出头出来。每一站停下来核对一次规格，最后给一份自己就能跑的验收清单。

一、规格表：它到底是个什么东西

先把官方写清的参数摊开。以下全部标注来源档位：**【官方】指仓库 README 或商汤官方发布稿原文；【推算】指本文根据官方参数推导；【未披露】**指公开材料没有说明。

几个数字之间是对得上的，这说明规格表内部自洽，不是拼凑出来的宣传数字：

• 层执行总数 = 入口 4 层 + 循环 24 层 × 2 遍 + 尾部 4 层 = 56，与"56 次层计算"完全吻合。
• 单层参数推算 = (9B − 词表嵌入 248,320 × 4,096 ≈ 1.017B) ÷ 32 ≈ 249.5M/层；56 次执行等效 13.97B，加回嵌入约 15.0B，与官方"推理约 14.6B"同一量级，误差来自实际参数分配与 mHC 参数。【推算】

所以"约 14.6B 推理参数"不是权重体积，是等效计算参数——权重只存 32 层（约 18 GB BF16），但每个 token 要算 56 遍。这句话很容易被误读成"模型其实有 14.6B"，实际不是。

二、为什么"参数不涨、深度涨"成了新战场

Looped Transformer 不是商汤发明的。这条线的历史比多数人以为的长：

有两个结论需要提前记住，因为它们决定你该不该用这类模型：

第一，循环提升的是"操作知识"的能力，不是"存储知识"的容量。 Ouro 团队的控制实验显示，循环模型和普通模型的参数知识容量都在约 2 bit/参数 这个量级，几乎没差别。但循环显著改善了组合事实、多跳推理、模运算这类需要反复加工的活。换句话说：背下来的东西没变多，会用背下来的东西的本事变强了。

第二，循环到底值不值得，取决于你缺什么。 2026 年 10 月那份综述的元分析给出了一个不太讨喜的结论：在算力匹配的比较里，一次循环的价值低于一个全新的参数层。循环真正划算的场景是——参数（也就是显存）是硬约束，而延迟和吞吐可以退让。

把这两条套到商汤这个模型上，官方的"9B 打 27B"就有了合理的解释维度：它不是"同算力打赢 27B"，而是"同显存打赢更大的稠密模型"。如果你的瓶颈是单卡 24 GB，这个交换是合算的；如果你的瓶颈是 QPS 和首 token 延迟，这个交换是亏的。选型判断从这一句就能分流。

三、第 0 站｜入口层：为什么偏偏是 4 层

模型进来先过层 0–3，这 4 层是独立的、不参与循环的。

为什么是 4 而不是 3 或 5？官方没解释。但从注意力结构能反推：解码器以四层为一组，每组三线性 + 一全注意力，循环边界必须与完整的四层组对齐，否则第二遍进来时注意力模式就错位了。所以入口层数必须是 4 的倍数，最小的自然选择就是 1 组 = 4 层。【推断，官方未说明】

尾部同理，层 28–31 也是 4 层，之后接输出头。

一次前向传播的层执行序列
─────────────────────────────────────────────────────
[0 1 2 3]  [4 5 6 7 ... 27]  [4 5 6 7 ... 27]  [28 29 30 31]  → 头
  入口4层        循环第1遍         循环第2遍          尾部4层
  独立权重       24 层共享权重      同一套权重         独立权重
     │                │                 │                │
     └────────────────┴─────────────────┴────────────────┘
                        合计 4 + 24×2 + 4 = 56 次层计算
                        权重只存 32 层
─────────────────────────────────────────────────────

这个结构跟 Huginn 的三段式（prelude / recurrent / coda）是同一套骨架，商汤的差别在于中间这个 recurrent block 是用连续层的权重共享实现的，而不是单独设计一个循环块。好处是不用改 checkpoint 的组织方式，标准 32 层解码器的权重布局就能直接复用。

四、第 1 站｜循环体：用时间换深度

进了层 4，事情开始不寻常。同一个块连着算两遍：

# 官方 README 写法
# B 表示被重复的块（层 4–27），h 是它的输入
h_out = B(B(h))

第一遍的输出直接作为第二遍的输入，权重不变。24 个层做两次，等于 48 次层计算。

这笔账要算清楚，因为它决定了部署成本：

所以"9B 打 27B"这句话，准确的说法是：**用约 9B 的显存，付约 15B 的算力，去争 27B 的效果。**三个数字，缺一不可。营销稿只讲第一个，评测稿只盯第三个，工程落地必须三个一起看。

还有一处细节值得注意：循环两遍会不会需要两套 KV cache？官方规格里没有明说。按 B(B(h)) 的串行语义，第二遍的输入是第一遍的输出，hidden state 不同，KV 理论上不能复用。如果实现上确实各存一套，KV 占用要按 16 个等效层算——这个差别在长上下文下是双倍的。【未披露，本文在第六节给出两种口径】

五、第 2 站｜mHC：把一个 DeepSeek 的稳定性补丁搬进循环体

这是整个模型里技术含量最高、也最容易被略过的一块。

双流 mHC，全称 Manifold-Constrained Hyper-Connections，流形约束超连接。要讲清它，得先讲它的三段前史：

据公开技术解读对 DeepSeek 论文的复述：27B 模型在 60 层复合映射下，原版 HC 的信号增益达到约 3000 倍，训练在约 12k 步时损失突然跳升并持续偏离基线；mHC 把增益压回可控范围，最终损失比基线再低 0.021，n=4 时额外时间开销压到 6.7%。**【交叉】**以上数值来自第三方解读，未逐条回原文核对。

商汤做的事，是把第三步的成果挪到循环计算这个新场景里。

这个挪动不是顺手，是必须。因为循环等于人为把有效层数翻倍——原来 32 层的信号路径，现在要穿过 56 次层计算。而 mHC 恰好就是为解决"多层连乘导致信号发散"设计的。循环越深，这套约束越不可省。

具体到参数上：商汤用 2 条残差流（DeepSeek 实验用的 n=4），Sinkhorn 迭代 20 次。每条流在层计算前后各有可学习映射负责读出、混流、写回，混流矩阵被 Sinkhorn 归一化约束成双随机矩阵——谱范数不超过 1，且双随机矩阵相乘仍是双随机矩阵，所以无论循环多少遍，信号能量都在可控范围内。

消融数据是这块最硬的证据：

前两项由商汤官方文字稿点名，可信度最高。TeamBench 上 +13.34 这个幅度值得单独看一眼——从命名与消融幅度推断，它对应多步骤协作场景，而多步任务正好是循环计算最该受益的地方（每一步都要基于上一步重新加工）。涨 13 分说明 mHC 在长链路上确实稳住了信号，而不只是修了个数值 bug。【推断，官方未公开 TeamBench 的评测构成】

后三个数字来自官方消融图，公开材料里图表的列名与数值对应关系不完整，本文不做逐项归属。【交叉】

六、第 3 站｜混合注意力：四层一组，KV 账在这里

解码器不是全注意力。它按四层一组排布：三层次线性注意力，一次全注意力。

层组结构（重复 8 次，覆盖全部 32 层）
──────────────────────────────────────────
组内第 1 层   线性注意力   ┐
组内第 2 层   线性注意力   ├─ 不存完整 KV，状态大小与序列长度无关
组内第 3 层   线性注意力   ┘
组内第 4 层   全注意力     ← 只有这层需要按 token 存 KV
──────────────────────────────────────────
32 层 ÷ 4 = 8 组 → 8 个全注意力层
──────────────────────────────────────────

这个设计对长上下文是决定性的。全注意力层数和线性层数的比例，直接决定了 256K 上下文的可行性——如果 32 层全是全注意力，KV cache 会翻四倍，单卡根本装不下。

按官方参数推算 KV 占用（head_dim = 4096 ÷ 16 = 256，KV 头 4 个，BF16）：

**【推算】**假设：仅 8 个全注意力层需存 KV、KV 为 BF16、不含激活值与框架开销、循环两遍各存一套。若框架能复用循环两遍的 KV，上表按"单遍"列读。

这解释了为什么官方示例给的是 4 卡 LightLLM 部署（--tp 4），而不是单卡：9B 权重本身单张 24 GB 卡放得下，但配上长上下文就跑不动了。想单卡跑，32K 是相对舒服的上限。

七、第 4 站｜部署：三条路径，三个必须踩的坑

官方给了三条推理路径，成熟度不一样：

第一条路径的坑最容易被低估。官方示例这段代码看着平淡，实际上有三个变量决定能不能跑起来：

model_id = "sensenova/SenseNova-Loop-9B-Preview"
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    trust_remote_code=True,        # 不加这行，循环实现不会被加载
    dtype=torch.bfloat16,
    device_map={"": "cuda:0"},
).eval()

prompt = tokenizer.apply_chat_template(
    messages, tokenize=False, add_generation_prompt=True,
    enable_thinking=False,          # 想要推理模式改成 True
)

三个坑：

1. trust_remote_code=True 不是可选项。 官方明确写了，循环与 mHC 的实现是自定义代码，靠这个开关加载。原样拷 Hugging Face 的通用加载模板会得到一个普通的 32 层模型，输出看着像模像样，实际上没有循环——不报错，只是效果差一截。这是最隐蔽的失败模式。
2. checkpoint 里带着"执行配置"，不是纯权重。 官方规格表点明：循环区间、遍历遍数、mHC 路由参数都属于 checkpoint 的执行配置，兼容的推理实现必须加载这些参数并复现相同的执行顺序。换推理引擎时如果只搬了权重张量、丢了这套配置，跑出来的是个残缺模型。
3. mHC 路由参数是 FP32，主干是 BF16。 混精度转换时如果一刀切成 BF16，Sinkhorn 的 20 次迭代会在低精度下累积误差，双随机约束可能失效——而这个失效是静默的，不会抛异常。

版本号也别省：transformers 5.18.0 是官方核对过的环境，低于这个版本的自定义模型接口未必兼容。

八、第 5 站｜出站之后：微调与加速的边界

微调走的是商汤自己 fork 的 torchtitan，8 卡单节点：

git clone https://github.com/OpenSenseNova/torchtitan.git
cd torchtitan
MODEL_PATH=/path/to/SenseNova-Loop-9B-Preview DATASET=/path/to/train.jsonl \
  bash examples/train/SenseNova-Loop-9B-Preview/mhc2_loop2_titan.sh

脚本名 mhc2_loop2 已经把配置写死了：mHC 2 流、循环 2 遍。要改循环遍数，得连训练脚本和推理实现一起改——这也是循环架构的代价：循环次数不是一个推理期可以随便调的旋钮，它绑在权重上。这一点跟 Huginn 那种"训练时随机采样迭代次数、推理时可自由增减"的设计不同，商汤这版是固定 2 遍。

官方表述里"后续将继续探索自适应迭代次数"也说清了现状：现在不支持。

推理加速三个方案，只有一个能用：

三个加速器里两个还在训练，意味着当前版本的解码速度没有额外红利——56 次层计算的成本要照付。做延迟预算时按无加速算，别按最好的情况算。

九、第 6 站｜验收：五条自建基准

官方口径不能直接当结论用，原因不在真假，在比较方式。给一份可执行的验收清单：

第 3 条最关键，也最难做——循环遍数绑在权重上，不像 Huginn 那样能推理期直接调，想验就得重训一个小尺寸对照。但这一步省不掉：如果第 3 遍开始饱和，那 56 次层计算就是在为边际收益付全价。综述里说的"在算力匹配下循环不如新层"，本质说的就是这个饱和点来得太早。

第 1 条和第 2 条要分开做，因为它们的结论方向相反：同参数下循环大概率赢，同算力下循环大概率输。你的业务落在哪一侧，取决于你缺显存还是缺吞吐。

十、官方没说的部分

把公开材料里缺失的信息列成清单，避免把推测当事实：

另有一条口径需要收窄。商汤官方稿里写"社区尚缺乏可直接面向日常使用的 Looped Transformer 模型"——字节的 Ouro 1.4B/2.6B（2025-10）和 Huginn 3.5B（2025-02）都已开放权重。准确的说法是：9B 量级 + 原生多模态 + 面向 Agent 工作流这个组合此前缺位。前两代开源循环模型要么规模偏小，要么只做纯文本。"首个"这个词用在这里不成立，"首个这一格的"才成立。

十一、结论：五种处境，一句话分流

这个模型的价值不在于"9B 打赢 27B"，而在于它把一条显存换算力的兑换通道做成了可用产品。选不选它，先回答一个问题——你现在缺的是显存，还是时间。