JTok 与 xHC:61B 模型省 35% 训练算力的两条扩展轴

上海交通大学严骏驰团队在 CNCC 2026 上给出的大模型新架构探索,给出了一条此前少有人走的路线:不加深加宽主干,不堆训练数据,转而把新增容量放到主干的大规模矩阵乘法之外。一句话结论:JTok 靠给每个 token 挂一张可学习参数表、xHC 靠把残差流从 4 路扩到 16 路,两条路在 61B 与 28B 规模上分别换来约 35% 和约 33% 的训练算力节省,代价是推理端解码吞吐最多下降 7.3%。

为什么要在 Transformer 之外找扩展维度

大模型提升能力通常只有三条路:增加参数加深模型、把模型做宽增加专家、投入更多训练数据。对算力和数据都有限的团队,这三条都不友好。严骏驰给出的判断是,从底层硬件、驱动、算子到上层模型软件,整个生态都沿着 Transformer 展开,改动太大就难以在工业界落地,所以更现实的做法是在现有框架内做有限改动,先观察是否有效。

JTok 与 xHC 的共同设计原则有两条。一是保持简单,人为加入的先验或技巧在小模型上可能有效,但模型和数据规模一扩大,优势就会被吞掉。二是把新增容量放到主干的大规模矩阵乘法之外,因为主干计算量是 Θ(d²) 级别的注意力与前馈网络,把新参数挂在旁边,调用它的代价就能压到线性。

这条路线已有可复现的实验支撑。MIT 权重空间编程那类工作同样在主干之外寻找干预点,两者的差别在于 JTok 干预的是前馈网络的残差增量,作用点更靠前,也更容易做成可以给存量模型加装的旁路模块。

JTok 机制:给每个 token 挂一张参数表

JTok 的做法是在 Transformer 主干旁增加一条分支,为每个 token 配置一个可学习的向量。运行时按 token 编号查表取出向量,经过归一化和一个可学习的逐维缩放,产生调制信号,门控在前馈网络的残差增量上,再加回主干。

关键在于这些新增参数不需要参与大规模矩阵乘法,每 token 每层的额外计算是归一化、一次哈达玛乘法和一次残差写回,都是 O(d)。JTok-M 则借鉴混合专家模型的思路,在查表之外加入路由,动态选择部分分支参与计算,路由本身是一次 O(d·n_e) 的矩阵乘法,混合是 O(K·d),在 n_e 与 K 都是小常数时整体开销相对 Θ(d²) 的主干可以忽略。

工程上的实现策略有三条值得注意。token 频率服从齐普夫分布,因此可以对 micro-batch 内的重复 token 做去重读取,一次 gather 再 scatter 回所有出现位置;参数表大而稀疏访问,适合做 embedding 模型并行,把表切分到多张 GPU 上以降低单卡显存、换取更大 micro-batch;推理阶段还可以把表放在 CPU 内存,只把当前批次需要的少量向量流式传到 GPU,与主干计算重叠。

JTok 成绩单:四个底座的逐项提升

论文用 OpenCompass 框架评测,覆盖知识、推理、代码、数学四类共 14 项任务。规模跨度从 650M(190M 计算参数加 460M 嵌入表)到 61B(17B 加 44B 嵌入),训练 token 数从 300B 到 570B。

任务 1.5B 稠密
底座 → +JTok
1.5B-A250M MoE
底座 → +JTok → +JTok-M
3.2B-A0.5B MoE
底座 → +JTok → +JTok-M
MMLU(5-shot) 32.74 → 37.29 27.91 → 30.98 → 34.07 36.39 → 40.05 → 43.47
TriviaQA(5-shot) 25.72 → 35.22 22.81 → 27.31 → 36.53 39.57 → 41.13 → 46.29
ARC-C(25-shot) 35.74 → 41.58 29.21 → 30.24 → 34.72 39.76 → 43.87 → 47.01
GSM8K(4-shot) 5.76 → 9.07 3.87 → 4.17 → 4.15 13.65 → 16.38 → 19.96
DROP(3-shot) 10.55 → 17.71 6.60 → 7.99 → 8.90 11.86 → 13.27 → 18.44
14 项平均分 22.22 → 26.54 18.87 → 20.51 → 22.78 26.75 → 29.24 → 32.34

三个底座上,JTok 系列的平均分分别提升 4.32、3.91 和 5.59 分。收益随规模放大而没有衰减,这是这类改动最关键的一条证据。论文在 17B-A2B MoE 底座上跑了 570B token 的完整预训练,JTok-M 的领先从训练早期就出现,并在整个过程中持续扩大,MMLU 提升 4.11 分、CMMLU 提升 9.34 分、ARC-C 提升 8.28 分,没有出现收敛到同一水平的情况。

35% 算力节省是怎么算出来的

论文用 isoFLOPs 方法做验证:在五个对数均匀分布的算力预算(3e18、1e19、3e19、1e20、3e20)下扫描不同的模型大小,取损失最低的配置连成算力最优前沿,然后比较两条前沿的位置。JTok-M 固定参数扩展比 η=50、激活稀疏度 ρ=0.25,骨干不变。

结果是同一算力预算下损失稳定降低约 2.2%,达到同样损失所需的训练算力约为底座的 65%,也就是节省约 35%。论文给出了一个形式化的解释:定义有效参数 N_eff = N_c · (1 + η·γ(ρ)),代入 Kaplan 规模定律后,JTok-M 的算力最优前沿相当于对基线前沿做一个乘性下移,于是节省比例在算力最优区间保持不变。

跨规模验证同样给出稳定数字。固定 (η, ρ) = (50, 0.25) 训练 100B token,2.3B-A0.5B 底座最终损失下降 0.059,3.9B-A0.6B 下降 0.064,A9.8B-A1.4B 下降 0.051,对应相对改善 2.7%、3.0% 和 2.55%。

xHC:把残差流从 4 路推到 16 路

xHC 即 Expanded Hyper-Connections,走的是另一条扩展轴:残差流的数量。Hyper-Connections 把 Transformer 的残差流拆成 N 条并行支路,mHC 通过对映射矩阵施加双随机约束(每行每列元素和为 1,配合 Sinkhorn 交替归一化)来稳定训练。

问题在于这一系列方法长期停在 N=4。团队给出了两个瓶颈的解释。一是写回信息供给不足,每层只注入一个写回分量,流数越多,新增支路之间的更新越相关,有效信息维度被限制住。二是残差映射生成的代价随 N 呈立方增长,从 N=4 到 N=16 成本差距很大。实验也印证了这一点:mHC 从 2 路到 4 路收益明显,4 路到 8 路收益变小,再往上开销过高。

xHC 的解法有两个部件。第一个是时序特征增强,在 MLP 输出后引入多尺度因果深度卷积,形成多个增强分量供不同残差流组合。第二个是稀疏残差流:默认配置把残差流扩到 16 路,每层读取全部 16 路的信息,但只激活 4 路参与残差混合与写回,其中 2 路固定激活,另 2 路由路由器动态选择。读取保持稠密是为了不切断跨层信息传播,而映射只基于被激活的流生成,主导代价从 O(N³C) 降到 O(k³C)。

xHC 成绩单与访存优化

指标 18B MoE 28B MoE
mHC 下游平均分 44.8 50.5
xHC 下游平均分 48.8 53.6
相对 mHC 提升 +4.0 +3.1
训练 FLOPs 增幅 +4.1% +3.0%
最终训练损失(xHC / mHC / 原生) 1.758 / 1.776 / 1.799

在 28B 规模上,xHC 在 12 项评测中的 11 项超过 mHC。规模定律层面,达到 xHC 的同一损失,标准 Transformer 需要 1.50 倍算力、mHC 需要 1.19 倍,换算下来相对原生节省约 33%、相对 mHC 节省约 16%。把 N 从 4 扩到 16,xHC 的损失改善 0.012 而训练 FLOPs 只增加 4%,同样的扩展在 mHC 上损失只改善 0.006 却要付出 32% 的 FLOPs 代价。

残差流变宽的真正约束是访存带宽。xHC-Flash 方案把每个 sublayer 的访存量从 73.5C 压回 40C,接近 mHC 在 N=4 时的 34C,同时基本保留完整 xHC 的收益。配合稀疏化、算子融合等优化后,相比 mHC 的吞吐额外开销约 1.3%。这套实现已在 2026 年 10 月以 Megatron-LM 重写并附带 Triton 算子开源,论文被 NeurIPS 2026 接收。

代价在哪里:训练与推理的真实开销

论文在 128 张 H800 上测训练吞吐(batch 1024、序列长 8192、3.2B-A0.5B MoE 底座),在 8 张 H800 上用 SGLang 测推理(batch 16、序列长 4K、CPU offload 方案)。

场景 JTok JTok-M
训练吞吐下降(优化后) 控制在 6.78% 以内
推理 prefill 吞吐下降 0.8% 2.3%
推理 decode 吞吐下降 4.5% 7.3%

朴素实现下训练吞吐掉得更多,原因有两个:额外的查表访存,以及 token 嵌入表推高 HBM 占用导致 micro-batch 变小、MFU 下降。embedding 并行解决后者,token 去重解决前者。推理端 decode 掉得比 prefill 多,是因为 decode 计算量更轻,留给主干的计算不足以掩盖主机到设备的传输延迟。

值得留意的是,这套思路与Zyphra ZHA 稀疏注意力、Clover-35B-A3B 扩散语言模型以及昇桥 AscendBridge 后训练栈指向同一个事实:模型能力与算力之间的兑换率正在从单纯堆 FLOPs 转向架构与系统的联合优化,魔芯 MoWorld 2.0 把推理成本降到 GPU 三成也是同一方向的另一面。

小结

JTok 与 xHC 提供了两个正交的扩展轴。JTok 沿 token 维度挂参数表,xHC 沿残差流维度扩宽度,两者作用在不同位置,具备叠加的可能性。团队自己也提醒,规模定律目前主要是经验公式,不能当成已有完整理论解释;架构越精巧,对训练 token 质量的要求也越高。这些都让它们距离工业界大规模落地还有距离。

但作为方向判断,这两项工作给出的信号是清楚的:在 Transformer 框架内寻找新的容量扩展维度,用较低的额外计算代价换取持续的训练收益,这个思路已经被 61B 与 28B 规模的数据验证过一次。

FAQ

JTok 会不会让训练成本不降反升?不会,但它也不是免费的。参数表带来新增显存与带宽压力,朴素实现下训练吞吐会明显下降,配合 embedding 并行与 token 去重之后,吞吐损失被控制在 6.78% 以内,而同等性能只需底座 65% 的算力。净账是省的。

xHC 的 16 路残差流会不会因为访存开销吃掉收益?会,这是它最现实的约束。完整 xHC 每个 sublayer 的访存量是 73.5C,明显高于 mHC 在 N=4 时的 34C。xHC-Flash 把它压到 40C,配合算子融合后相对 mHC 的吞吐额外开销约 1.3%,收益才真正保住。

这两条路线适合什么样的团队?更偏向有中等规模算力、希望在不改动硬件栈的前提下换取效率的团队。JTok 的旁路结构可以给已训好的存量模型直接加装,不需要重训主干。但把它们当作成熟配方直接上生产仍需谨慎,规模化收益在 61B 以下未经验证,推理端的 7.3% decode 吞吐损失对高并发线上服务也并非可忽略的数字。

相关阅读