68.5B 里塞了 30B 词表：他们说"放大 embedding"比堆专家更划算
- 关联论文：2601.21204
过去两年大模型的扩容故事基本只有一个主角：MoE，加专家。总参数往上堆，单 token 只激活一小部分，能力涨、成本不涨。但边际收益在肉眼可见地衰减，而且 all-to-all 通信、路由均衡、训练稳定性这一套系统复杂度全都挂在专家身上。
美团 LongCat 团队这篇论文（v1 2026-01-29，v2 2026-02-11）提了个不太一样的答案：别只加专家，把预算往 embedding 上倾斜。 他们从零训练了一个总参 68.5B、单 token 激活约 3B 的模型——注意，超过 30B 参数（约 44%）压在 embedding 表上。
为什么重要
传统 scaling law 研究的是深度、宽度、专家数三个轴。这篇把 embedding size 提升为第四条轴，核心观察是：把总参数拆成"embedding 参数"和"非 embedding 参数"两部分时，两者的能力贡献边际曲线不一样。MoE 主要在非 embedding 部分里切专家，是在相同表征容量下增加条件计算路径；而 embedding scaling 直接放大 token 的表示空间本身。
论文给出的结论不是"embedding 永远赢"，而是一个区间条件——在特定参数预算和任务类型下，embedding 扩展能给出更好的能力-成本 Pareto 前沿。而 agentic 和 coding 恰好落在这个区间里。
核心机制
真正支配效果的架构因子有几个：参数预算分配比例（存在 sweet spot，44% 就是他们选的）；与 width 的交互（embedding 变大后 hidden width 太小会成信息瓶颈，太大又把预算挤回去）；与 depth 的交互（深窄 vs 浅宽对 embedding 敏感度不同）；以及和任务类型的耦合——需要更精细 token 区分度的任务（代码、工具调用）收益更大，纯文本生成相对温和。
系统侧同样关键。大 embedding 的访存压力是主要瓶颈，需要专门的查表 kernel 与缓存策略；长序列要做 attention 优化；再叠投机解码（speculative decoding），用小 draft 模型做 token 级投机，把"稀疏性省下的 FLOPs"翻译成真实端到端加速。
证据边界
这里必须克制。能从摘要直接确认的只有四条：68.5B 总参、约 3B 激活、embedding > 30B（约 44%）、从零训练而非蒸馏。作者归属美团 LongCat 团队属于补充说明，非摘要明示。
具体 benchmark 分数一个都没有公开。 HumanEval、LiveCodeBench、SWE-Bench、τ-bench 的数字，训练 token 量、训练算力，全部需要进正文表格才能拿到。"超越同规模 MoE 基线"目前是定性声明，无法判断超越幅度。论文许可为 arXiv perpetual non-exclusive，与代码许可要分别确认。
所以这篇的可信度结构是这样的：核心主张（第四条轴存在且在某区间占优）可信且值得 follow-up；但"优秀到什么程度"目前无数字支撑。
工程局限
embedding heavy 模型的访存瓶颈是新的。 68.5B 按 FP16 粗估：embedding 表约 30B×2 bytes ≈ 60 GB，backbone 约 38.5B×2 bytes ≈ 77 GB，单副本总计约 137 GB，至少要 2×H100 80GB。每次 forward 都要加载 embedding 表，embedding lookup 走的是带宽而非算力，会先于 compute 饱和。serving 侧不能直接套 MoE 的现成经验。
投机解码的 draft 训练成本被低估。 理想设计是共享 embedding 层加独立小 backbone，让 embedding 权重只加载一次——但 draft 模型需要额外训练，不是裁剪就能得到，如何让它和主模型的自回归分布对齐才是主要工程难点。
规模外推完全未知。 200B+ 是否仍然占优、44% 这个激进比例的训练稳定性和收敛曲线如何，摘要都没说。
最现实的一关：能否拿到权重。 如果没有公开 checkpoint 或 API，整个评估从第一步就无从谈起——建议先确认可获取性，再谈选型。
三个标题变体
- 68.5B 模型里 30B 都在词表？embedding scaling 可能是 MoE 之外的新轴
- MoE 撞墙之后：LongCat 团队说"放大 embedding"比堆专家更划算
- 把预算花在词表上：一个正交于 MoE 的扩容思路，以及它的三道坎
小红书卡片文案
MoE 之后，还能往哪扩？
主流扩容故事只有一个主角：堆专家。但边际收益在衰减，all-to-all 通信、路由均衡、训练稳定性全挂在这条线上。
LongCat 团队的思路很直接：embedding scaling 是第四条轴。 传统 scaling law 只看深度、宽度、专家数，他们把词表/输入表征维度提出来当独立变量。观察是——MoE 在相同表征容量下加条件计算路径，embedding scaling 则直接放大 token 的表示空间本身。
模型实例：总参 68.5B、单 token 激活约 3B，超过 30B 参数（约 44%）压在 embedding 上，从零训练非蒸馏。论文给出的不是"永远赢"，而是区间条件——embedding 扩展在特定预算下能给出更好的能力-成本 Pareto 前沿，且对代码生成、工具调用这类需要精细 token 区分度的任务收益更大。
但得泼点冷水： ⚠️ 摘要里一个 benchmark 分数都没有，HumanEval/LiveCodeBench/SWE-bench 全在正文，"超越同规模 MoE"目前只是定性声明 ⚠️ embedding heavy = 访存新瓶颈。FP16 粗估单副本约 137 GB，至少 2×H100 80GB，embedding lookup 先于算力饱和 ⚠️ 投机解码的 draft 模型要额外训练、还要和主模型分布对齐，不是裁剪一下就行 ⚠️ 200B+ 是否仍占优，44% 这个激进比例的收敛稳定性，论文都没说
一句话：核心主张值得认真 follow-up，但"优秀到什么程度"目前缺数字。如果要做选型，第一步先确认权重能不能拿到。