Inkling 开放权重实测:975B MoE + 1M context + 音频 native 的工程复用笔记

一、起因:又一家美系实验室下场做开放权重

昨天 HN 首页 523 分顶帖是 Thinking Machines Lab(由前 OpenAI 联合创始人 Mira Murati 带队)发布的 Inkling 模型——975B 总参 / 41B active 的 MoE Transformer,1M context,45T tokens 预训练(text / image / audio / video 四模态),开放权重,首发即可在 Tinker 平台 fine-tune。

我看到这条消息的第一反应是把它跟最近半年的开放权重新闻做对照:Nemotron 3 Ultra / Kimi K2.6 / GLM 5.2 / DeepSeek V4 Pro 这些已经在闭源档模型(Claude Opus 4.8 / GPT 5.6 / Gemini 3.1 Pro)外围形成包围,Inkling 是第二个明确把"audio native"和"1M context"作为差异化点的开放权重模型(第一个是 Qwen3-Omni,但中文圈之外认知度有限)。

我跟了一下午的博客原文和 HN 评论区(top 10 长评论),把工程上能复用的部分整理在这篇里,主要回答三个问题:

• 它到底跟现有开放权重模型差在哪(架构 + 训练 pipeline)?
• 实测部署时哪些地方需要留意(serving stack / 量化 / long context)?
• 哪些是它没公开的(局限)。

二、架构:DeepSeek-V3 路线 + 相对位置编码 + short convolutions

Inkling 的 MoE 设计基本沿用 DeepSeek-V3 的范式(博客原文 P64):

• 每层 256 routed experts + 2 shared experts,每 token 激活 6 个 routed expert
• 用 sigmoid 路由器 + auxiliary-loss-free load-balancing bias
• 路由分数 + shared expert 分数联合归一化后加权求和

这个选择本身就是工程信号:DeepSeek-V3 路线在过去半年已经被多家训练基础设施复用(Nemotron 3 / Qwen3 / GLM 系列),说明这套架构在工程上是"被打磨过的",而不是 paper-only 的新奇方案。

两个值得单独拎出来说的工程细节:

1. 相对位置编码(Relative Position Embedding)替代 RoPE(P65):Inkling 团队明确说相对位置编码"performs better and extrapolates better to longer sequences than RoPE"。对于 1M context,长序列外推能力是必考题——RoPE 在 32K 之后通常需要 NTK-aware scaling 或 YaRN 这类补丁,而相对位置编码的 inductive bias 更适配长程依赖。这条改动在博客里只有一小段,但对应到 inference 端意味着:同一个 checkpoint 在 64K / 256K / 1M context 长度下行为更一致,部署时不用做 per-length 的位置编码插值。

2. 滑动窗口 + 全局 attention 5:1 交错 + 8 KV heads(P65):5:1 这个比例跟 Mistral / Gemma 2 接近,但配合 8 KV heads 的设计意味着 GQA 复用率很高——对长 context 的 KV cache 内存压力友好。

3. short convolutions on K 和 V projection 之后(P65):这是个相对小众但有效的 trick,作用是给 attention 之前的 K/V 加一层局部平滑,降低单 token noise。

三、训练 pipeline:45T tokens + Muon/Adam 混合 + 30M+ RL rollouts

训练侧博客 P66 提到几个不寻常的地方:

• 预训练数据规模 45T tokens:这是开放权重模型里目前公开的最大数字之一(Kimi K2.6 / Nemotron 3 / DeepSeek V4 都没有正式公开 pre-train tokens 数,但根据训练 FLOPs 反推大约在 30-50T 区间,Inkling 落在上沿)。
• Muon 优化器用于大矩阵权重 + Adam 用于其他参数:Muon 在小模型上去年已经被广泛验证(Speedrun NanoGPT 之类),但 975B 级别用 Muon 是相对激进的——博客没展开 Muon 在这个规模下的实际稳定性数据,这是我个人比较关心的点(待验证)。
• weight decay 与 learning rate² 耦合(P66):这是个比较"新潮"的做法,博客原文是 "coupled the weight decay strength to the square of the learning rate",引用 Kosson et al 的工作,但具体怎么耦合没有给公式,只能从"kept the overall size of the model weights stable across training horizons"反推。

后训练部分(P67)有一个有趣的描述:"bootstrap accounts for a small fraction of compute, with the majority being employed for large-scale RL on synthetic and human-created environments"。换句话说:SFT 启动只是引导,真正的能力提升来自大规模 RL。

RL 部分 P69 的数字是:30M+ rollouts,reasoning eval reward 从 SFT init 0.264 涨到 released 0.356,reasoning 性能"log-linearly"提升。博客给了一个关键观察:RL 过程中 chain-of-thought 自然变得更紧凑(P71),"dropping grammatical overhead while remaining comprehensible"——这个 emergent compression 不是 reward 直接 target 的,而是 efficiency 驱动的副产品。SWE-1.7 训练时也观察到类似现象,可以对照。

四、音频 / 视觉:encoder-free + dMel + 40x40 patches

多模态部分博客走的是 encoder-free 路线(P46):

• Audio:直接用 dMel spectrogram 作为输入(dMel 是 Richard He Bai et al 2024 的工作,简化了传统 speech tokenization)
• Vision:40x40 pixels 的 patches + 4 层 hMLP(不引入 ViT backbone)

这个设计的好处是"音频 / 视觉 token 直接走同一套 transformer",不需要单独的 encoder 模块做特征提取。代价是 sequence length 会比"encoder 先压缩再进 transformer"更长——博客 P45 给的 audio 基准(Audio MC / MMAU / VoiceBench)显示 Inkling 在开放权重档里属于领先,但跟 Gemini 3.1 Pro / Claude Fable 5 这种闭源档仍有 5-15 个百分点差距。

工程上的实际意义:如果你要做 audio-in / audio-out 的端侧应用,Inkling 是当前开放权重里少数几个原生支持"语音输入 → 推理 → 文本输出"全流程的模型;但指望它做实时多轮语音对话还需要外围 pipeline(blog 没提 streaming latency 数字)。

五、Inkling-Small:同栈 + 更小 active 的预览版

P72-P75 描述了 Inkling-Small(预览版):

• 276B 总参 / 12B active(对比 Inkling 的 975B / 41B)
• 用同一套 post-training stack
• HLE text 29.6%(vs Inkling 29.7%)、HLE with tools 46.6%(vs 46.0%)、AIME 2026 95.1%(vs 97.1%)、GPQA Diamond 88.3%(vs 87.2%)
• 编码 / agentic 任务接近 Inkling,factuality SimpleQA Verified 差距较大(20.9% vs 43.9%)

博客原话:"With 12B active parameters and controllable thinking effort, it is a natural fit for workloads where cost and latency matter such as coding, using LLMs to grade, or generating synthetic data for other models."

这条对工程读者很关键:如果你想做"开放权重 + 12B active 就能本地部署 + 跟 Inkling 同栈"的微调实验,Inkling-Small 是当前最现实的候选。12B active 意味着 24-48GB 显存就能跑(量化到 4-bit 后),单卡 H100 / A100 80G / 4090×2 完全够用。

完整权重暂未发布,博客说"currently finishing the testing of Inkling-Small"——如果你看到第三方在卖/Inkling-Small 完整权重,基本可以判定是 leak,慎用。

六、serving 生态:9 家下游合作伙伴 + NVFP4 量化

博客 P80 列出 serving 生态:

• TogetherAI / Fireworks / Modal / Databricks / Baseten:API 服务
• RadixArk:在 SGLang 和 Miles 里提供 inference + RL 支持
• Inferact:vLLM inference 支持
• Lightseek:TokenSpeed inference 支持
• Unsloth:llama.cpp inference 支持
• Hugging Face:transformers 集成

权重本身在 Hugging Face 上同时提供原始 checkpoint + NVFP4 量化版本(P81)——NVFP4 是 NVIDIA Blackwell 架构原生支持的 4-bit 浮点格式(NVFP4 = FP4 with FP8 scaling),比常见的 GGUF Q4_K_M 推理快很多,但需要 GB300 / B200 这类 Blackwell GPU。

Unsloth 在 HN 评论区直接放出了 llama.cpp 集成分支(segmondy 评论,1121 字符):

Very nice, multi modal, largest open weight model that supports audio. If you want to run locally, checkout github.com/danielhanchen/llama.cpp/tree/add-inkling 和 unsloth.ai/docs/models/inkling + huggingface.co/unsloth/inkling-GGUF

所以本地跑的路径是:NVFP4 → Blackwell GPU(最快)/ GGUF → 任意 CPU+GPU(慢但通用)/ vLLM → 单卡 / 多卡 A100 / H100 标准 serving。

定价方面:P77 说"Inkling is available on Tinker today with context length options of 64K and 256K tokens. We are offering Inkling at a 50% discount for a limited time",完整定价表在 Tinker 文档里。

七、目前还没完全搞清楚的几个点(局限与待验证项)

我自己在整理这些材料时也撞到几个想搞清楚但暂时没找到答案的地方,列出来给大家参考:

1. Muon 在 975B 级别的实际训练稳定性(待验证) —— 博客只说 Muon 用于大矩阵权重 + Adam 用于其他参数,但没给 loss curve / spike 频次 / 最终 loss 数字。Muon 在小模型已经稳定,但 975B 级别我还没看到第三方独立验证。
2. dMel spectrogram tokenizer 对超长音频(>30 分钟)的处理边界(待验证) —— 博客给的 VoiceBench / MMAU 都是短音频(<10 分钟),长会议录音 / 播客场景下的 transcription 质量没有公开数据。
3. safety 评估在 fine-tune 后的"漂移"程度(不足) —— 博客 P59 原话是"continuing to study safety behavior and capability uplift in customizable models, including how safety behavior is impacted by fine-tuning on Tinker"。换句话说:Tinker 用户 fine-tune 完之后,Inkling 内置的 safeguards(尤其是 FORTRESS 78.0% 那个)是会变化的,实际能保留多少是个 open question。
4. Inkling-Small 完整权重的发布时间表(待验证) —— 博客 P75 只说"currently finishing the testing",没有 ETA。12B active 的吸引力很大,但预览版不放出权重的话工程读者只能等。
5. long context(1M)在 agentic 真实任务上的稳定性(不足) —— 博客 P62 给了 reasoning / agentic 基准,但这些 benchmark 都是 256K trajectory 限制下跑的。真正的 1M context 实测(比如"读 80 万 token 的 codebase 然后改一个文件")博客没给数据,需要等第三方 harness 集成后实测。
6. 跨模态推理(audio + vision + text 联合)的工程案例(坑点) —— 博客 P19-P42 列了几个 demo(语音填表单 / 多页 PDF 杂志 / 多人在线 snake 游戏),但 demo 跟生产可用之间差距很大。HN 评论区 Topfi 提到"There is something here, far beyond what the benchmarks suggest",但同时强调"Only ever saw such outperformance of public evals vs my private ones with Anthropic models"——也就是"benchmark 没体现出来的好"目前还是 first-person 体验,没有可复现的第三方 benchmark 数据。

八、适用场景与不适用场景

适合 Inkling 的场景:

• 需要开放权重 + 音频 native 的 agentic 应用(语音助手 / 播客转写 / 会议记录)
• 想在 Tinker 平台做领域微调(尤其是 12B active 的 Inkling-Small 出来之后,中小团队能本地跑)
• 已经在用 DeepSeek-V3 路线 serving stack 的团队(SGLang / vLLM / llama.cpp),可以平滑迁移
• 1M context 的长文档 / 长 codebase 任务

不太适合的场景:

• 实时低延迟对话(<200ms first token):41B active 即使量化到 4-bit 也很难压到实时
• 中文为主 + 强 reasoning 的场景:开放权重里目前中文 reasoning 还是 Kimi K2.6 / GLM 5.2 更强
• 极致 factuality 任务:SimpleQA Verified 43.9% 不算顶尖,factuality 敏感场景建议走 Claude Opus 4.8 / GPT 5.6 闭源档
• 完全本地 + 消费级硬件(<16GB 显存):即使是 Inkling-Small 12B active,Q4 量化也要 8-10GB 显存 + 一定的 CPU RAM,Mac mini M4 24GB / 32GB 勉强能跑但不快

九、参考

• Thinking Machines 官方博客:"Inkling: Our open-weights model": https://thinkingmachines.ai/news/introducing-inkling/
• HN 顶帖(523 分 / 129 评论): https://news.ycombinator.com/item?id=48924912
• Unsloth 集成: github.com/danielhanchen/llama.cpp/tree/add-inkling + huggingface.co/unsloth/inkling-GGUF
• dMel 原始工作:Richard He Bai et al, 2024
• 相对位置编码原始工作:Peter Shaw et al, 2018 / Music Transformer 2018
• 上游 MoE 架构参考:DeepSeek-V3 paper
• Cognition "SWE-1.7":https://cognition.ai/blog/swe-1-7(对照 CoT compression 现象)
• 样本九(OpenAI 财务泄漏):https://www.cnblogs.com/ninghg/p/(自行替换)—— 推理成本曲线参照
• 样本二十一(Jalapeño 推理芯片):—— perf/W 推断未来推理成本参照