Inkling 的耳朵：一个 790 万参数的查找表

本周 @thinkymachines 发布了 Inkling：一个 975B 的混合专家模型（41B 激活参数），支持 100 万上下文，采用 Apache-2.0 许可证，从头开始在 45 万亿文本、图像、音频和视频 token 上预训练。关于其基准测试已有大量讨论。但作为一个语音研究者，最值得注意的细节小到容易忽略：Inkling 没有音频编码器。

与其他超过 100B 的变体（或 Thinky 的双工交错模型）类似，根据缩放定律研究，编码器并非必需。

整个音频前端如下：

1. 16 kHz 单声道音频转换为 80 通道对数梅尔频谱图，每 50 ms 跳帧一帧

2. 每个梅尔频段量化为 16 个等级之一（dMel，Bai 等人，2024）

3. 每个（频段，等级）对索引 nn.Embedding(80 × 16 = 1280 → 6144) 的一行

4. 80 行相加。这个和就是音频 token。

这大约有 790 万参数。没有卷积，没有 Transformer 塔，没有投影器。音频以每秒 20 个 token 的速率进入，直接送入与读取文本相同的解码器。作为对比，Whisper 风格的前端每秒产生约 50 个 token，并在它们前面携带一个约 1 亿参数的编码器。一分钟的语音消耗 1200 个 token；100 万窗口理论上可以容纳近 14 小时。

• 查找表会牺牲质量吗？

比我们预期的少。根据模型帖子自身的评估表（思考努力度 0.99）：AudioMC 56.6，而下一个开放权重的全模态模型报告为 37.6。MMAU 77.2 和 VoiceBench 91.4，均与 Qwen3.5 Omni-Plus（81.1 和 92.4）差距不大。闭源的 Gemini 3.1 Pro 在所有三项中领先。

我们更信任的数字是可复现的，来自 Tinker cookbook 配方：

• LibriSpeech：零样本 WER 约 0.06，无需特定音频调优

• 医学 ASR（EkaCare，带有印度口音且密集包含药物名称的听写）：经过 12 个 epoch 的 LoRA SFT 后，WER 从 0.157 降至 0.072，医学实体召回率从 0.806 升至 0.915。它能转录训练集中从未出现的药物。

• Expresso 情感：说话风格准确率从 0.361 升至 0.852（SFT，然后使用风格 + WER 奖励进行 GRPO），同时 WER 从 0.095 改善至 0.044

最后一项是我们原本会打赌失败的结果。每个梅尔频段 16 个等级听起来对于韵律来说太粗糙了。但事实并非如此。该表示同时承载了说了什么以及如何说的。

• 服务端才是乐趣所在

在提示词中，整个音频片段是一个哨兵 token。在预填充之前，它会就地扩展为 f = 20 × 秒数 个实际位置，从此解码器不再对音频帧给予特殊处理：滑动窗口和全局注意力以 5:1 交错，使用学习到的相对偏置代替 RoPE，以及宽度为 4 的因果卷积混合每个位置与其前三个位置，文本或音频都一样。

关键在于状态。一个请求现在携带三种不同的状态：全注意力 KV、滑动窗口 KV 和短卷积状态。SGLang 使用具有类型化页面的单一基数缓存来服务所有三种状态（卷积状态借用原本为 Mamba 模型构建的池），并且预填充-解码分离运输所有三种状态。在 B200 节点上，第 0 天堆栈在 batch 32 时达到每秒 71.7k 输入 token。

• 我们未能解决的问题

服务配置将 audio_mode 类型化为 Literal[“dmel”, “flow”]，而 “flow” 未出现在任何公开文档中。模型卡片说明此版本仅输出文本。我猜测存在一个未公开的音频输出路径，这意味 Inkling 最终可能说话，而不仅仅是听。这是一个猜测，已明确标注。

还有未解决的问题：精确的量化器映射（发布配置中的 dmel_min_value 为 -7.0，与代码默认值 -1.5 不一致），以及在长形式、多语言和嘈杂音频上的行为。

完整文章（包含流水线和服务路径的交互式逐步图示，以及每个声明均追溯到原始来源）请见：

https://huckiyang.github.io/blog/inkling-audio-design.html