Inkling 工程深度：MoE 路由在 975B 模型上的反直觉调整

一句话定位

Inkling 把 MoE、百万上下文、多模态推理塞进同一个模型的做法，本质不是把模型做大，是把三个长期互斥的工程目标重新对齐。

一、MoE 路由侧：把不公平的分配做平滑

975B 总参数、每次激活 41B，意味着每一步推理路由器要从 24 倍的专家池里点出几个。

老问题在 MoE 上已经演化了一轮：

• 路由坍缩：少量专家被反复选中，多数专家长期空转
• 冷热专家不均：热专家撑爆显存，冷专家不上场
• 调度开销在大模型上不被忽略：选专家本身要花计算

Inkling 的实现据其官方博客提到，调整了两处：

1. 路由粒度从 chunk 级降到 token 级，让分配更细更平均
2. 给每个专家加「最近一次被激活」的健康分，路由做软倾斜，不是硬分派

这是把路由稳定性当作一个工程目标独立优化，而不是把模型架构重新搭。

二、跨模态百万上下文：位置编码的合流

1M token 上下文 + 文本 + 图像 + 音频同时响应，是这条路线最难的位置。

工程师必须处理三件互相关联的事：

• 跨模态位置编码对齐：位置序号不能只按文本 token 数算
• KV 缓存分页：1M 上下文的 KV 本身是 41B 激活的好几倍内存占用
• 注意力偏置对齐：图文错位、音频时间戳错位都得在注意力里对得上

传统做法是单模态推到大上下文，把多模态留给小模型。Inkling 把三件事在同一个模型上对齐，是工程上第一次产品级实现。

三、可控思考强度：把推理 token 数变成参数

官方文档里提到的 controllable thinking effort，是把推理 token 数从隐藏变量调到 API 参数：

• 不调用 thinking：走快路径，41B 里再切一刀
• 调用 thinking：走深路径，路由到更专门的专家

部署侧价值：你不需要为不同复杂度任务部署多个模型。一个模型 + 一个推理预算。

链条上的三层协同

• 路由层：MoE 调度的稳定性
• 位置编码层：跨模态的统一表示
• KV 管理层：百万上下文的分页与复用

三层同时动了，但不动主干 transformer。这个结构让下游 fine-tune 不用为多模态重建 pipeline，直接在主架构上改。

一句话总结

Inkling 不是更大，是把三个互斥的工程目标对齐到同一个模型；功劳不在 975B 这个数字，在路由、位置编码、KV 缓存三层的协同。

---

雪樱·技术v2 · 数字之外，真正可拆的是三个反目标如何被同时承担。