Inkling 975B 说明“开放权重“与“普通开发者本地运行“已经分离，内容重点应是部署容量和运行时边界

2026-07-24 0

Inkling 975B：开放权重与可部署性的基础设施鸿沟（Thinking Machines 2026-07-15 容量与运行时拆解）

TL;DR

场景：Thinking Machines Lab 2026-07-15 在 huggingface.co/blog/thinkingmachines-inkling 与 thinkingmachines.ai/news/introducing-inkling 同时发布 Inkling：975B 总参 / 41B 激活的多模态稀疏 MoE，许可证 Apache 2.0，权重已开源到 Hugging Face。
结论：开放权重只解决"访问和修改"；权重存储、KV Cache、并行通信、运行时成熟度、集群成本与生态支持共同决定"是否真正可部署"。A6000×8 / H100×8 都不是官方 NVFP4 路径；官方验证配置是 8×B300 或 16×H200（BF16）以及 4×B300 W4A4 或 8×H200 W4A16（NVFP4）。
产出：可下载部署矩阵、官方 vs 理论容量对照、6 个评测指标、12 条错误速查卡与 7 步实施 / 实验方案，目标是让"开放权重"和"普通开发者本地运行"两条线不再被混在一起讲。

版本矩阵

功能 / 事实	状态	说明
Inkling 许可证为 Apache 2.0	✅ 已验证	原文 S13 / S14（thinkingmachines.ai/news/introducing-inkling / thinkingmachines.ai/model-card/inkling/，2026-07-15）
输入：文本 + 图像 + 音频；输出：文本	✅ 已验证	原文 S14 模型卡；预训练还含视频 token，但目前没有视频输出
975B 总参 / 41B 激活 / 1M 上下文	✅ 已验证	原文 S13 / S14 文字描述
Hugging Face 模型卡显示 952B parameters	⚠️ 数字异常	HF 列表页 summary 写 952B，原文 S13 / S14 文字与架构描述均用 975B；本文按原文文字取 975B，但提示读者去 HF 卡 957B 字段二次核验
45T token 预训练（含文本 / 图像 / 音频 / 视频）	✅ 已验证	原文 S13
在 NVIDIA GB300 NVL72 系统上训练	✅ 已验证	原文 S13 "The making of Inkling" 段
超过 30M RL rollouts，2 次长稳态训练	✅ 已验证	原文 S13 图表数据（Szymon Tworkowski，aggregate eval reward 0.264 → 0.356）
BF16 最低配置：8×B300 或 16×H200	✅ 已验证	原文 S14 模型卡
NVFP4 配置：4×B300 W4A4 或 8×H200 W4A16	✅ 已验证	原文 S14 模型卡
运行时：Transformers / SGLang / vLLM / llama.cpp	✅ 已验证	原文 S15（huggingface.co/blog/thinkingmachines-inkling）
实际部署通常需要多节点 + SLURM	✅ 已验证	原文 S15
远程推理音频支持在发布时仍在进行中	✅ 已验证	原文 S15："remote inference audio support in progress at release"
A6000 单卡 48 GB	✅ 已验证	原文 S16（nvidia.com/en-us/products/workstations/rtx-a6000/）
8×H100 聚合 640 GB	✅ 已验证	原文 S17（NVIDIA DGX H100/H200）
8×H200 聚合 1,128 GB	✅ 已验证	原文 S17
8×B200 聚合 1,440 GB	✅ 已验证	原文 S18（NVIDIA DGX B200）
B300 单卡 288 GB	✅ 已验证	原文 S19（NVIDIA DGX B300，2026-01-20 更新）
Tinker 平台提供 64K / 256K 上下文选项	✅ 已验证	原文 S13 "Inkling availability" 段
Tinker 首发 50% 折扣 + Playground	✅ 已验证	原文 S13
部署合作伙伴：Together AI / Fireworks / Modal / Databricks / Baseten	✅ 已验证	原文 S13 "Inkling availability" 段
SGLang 与 Miles 由 RadixArk 维护；vLLM 由 Inferact 维护；TokenSpeed 由 Lightseek 维护；llama.cpp 由 Unsloth 维护	✅ 已验证	原文 S13
StrongREJECT 98.6%（表格） vs "above 99%"（正文）	⚠️ 文档冲突	原文 S13 注释明确"kept per v7 verbatim"，但已留 OPEN ITEMS；本文以表格 98.6% 为准
Inkling-Small 276B 总参 / 12B 激活	✅ 已验证	原文 S13 "Inkling-Small" 段（"preview"）
Inkling-Small 完整权重"will be released once testing is complete"	⚠️ 待发布	原文 S13 明确"finishing the testing"；现在仍是 Preview
1-bit GGUF / 4-bit / FP8 等社区量化的"可装下硬件"	⚠️ 非官方	用户原文提"1-bit GGUF"，原文未做官方背书；任何集成方结果都需独立核
Inkling 是否在所有任务上优于闭源模型	✅ 立场	原文 S13 明确"not the strongest overall model available today, open or closed"，本文不评价
训练数据 / 训练代码完全开源	✅ 立场	用户原文风险段已写明"开放权重 ≠ 训练数据和训练代码完全开源"；本文保留该立场

文章正文

Inkling 975B：开放权重与可部署性的基础设施鸿沟

摘要

Inkling 是 975B 总参数、41B 激活的多模态稀疏 MoE，许可证为 Apache 2.0。虽然每个 Token 只激活部分专家，全部权重仍需存储：官方 BF16 配置至少 2 TB 聚合显存，NVFP4 至少 600 GB。该模型说明"开放权重"与"普通开发者本地运行"已经分离。内容重点应是部署容量和运行时边界，而不是厂商 Benchmark 排名。

读者问题

总参数与激活参数分别影响存储和计算什么？
为什么 41B 激活仍需要存储 975B 权重？
A6000×8、H100×8、B200×8 到底处于什么容量边界？
1M 上下文为什么不能只看权重显存？

已核验事实

Inkling 许可证为 Apache 2.0，输入文本、图像和音频，输出文本；975B 总参数、41B 激活、1M 上下文。（S13、S14）
官方 BF16 最低配置为 8×B300 或 16×H200；NVFP4 为 4×B300 W4A4 或 8×H200 W4A16。（S14）
Hugging Face 文章确认 Transformers、SGLang、vLLM 和 llama.cpp 路径，并指出实际通常需要多节点和 SLURM；远程推理音频支持在发布时仍在进行中。（S15）
A6000 单卡 48 GB；8×H100 共 640 GB；8×H200 共 1,128 GB；8×B200 共 1,440 GB；B300 单卡 288 GB。（S16—S19）

技术机制

容量必须分开计算：

权重存储：975B × 2 Byte ≈ 1.95 TB，接近官方 2 TB BF16 要求。
4-bit 理论权重：975B × 0.5 Byte ≈ 487.5 GB；官方要求 600 GB，反映量化元数据、布局和运行时开销。
激活：41B Active 主要影响每 Token 计算量，不代表其余专家权重可以不加载。
KV Cache：随并发、上下文长度、层数、KV 头数和精度增长；公开模型卡不足以精确计算 1M Token 满上下文配置。
并行通信：Tensor/Expert/节点并行需要高带宽互联，聚合显存满足不代表吞吐可接受。

工程含义

路由器在选择 Inkling 端点前必须确认精度格式、模态支持、最大上下文、节点健康、并发和队列。A6000×8 无法容纳官方 NVFP4 权重；H100×8 虽有 640 GB 原始容量，但缺少足够余量且不是官方 NVFP4 路径；B200×8 容量足够放 600 GB 权重，但未被模型卡列为验证配置；H200×8 和 B300×4才是官方 NVFP4组合。

实现或实验方案

先按权重格式计算理论容量，再保留 Runtime、KV Cache、通信缓冲和碎片余量。
把官方验证配置与"理论可装下"配置分表展示。
对 1M 上下文设置实际 max-model-len，按并发和业务需要逐步放大。
分别验证文本、图像、音频和工具调用，不因模型原生多模态就假设所有服务端均完整支持。
比较托管 Endpoint、专用集群和蒸馏/小模型路线的每成功任务成本。
记录运行时版本、并行策略、量化格式、吞吐、P95、显存峰值和质量回归。

评测指标

Weight Fit Margin：聚合显存减去权重和静态开销后的余量。
KV Headroom：目标上下文和并发下可用 KV Cache 余量。
Tokens/s per Dollar：集群或 Endpoint 的有效吞吐成本。
Inter-node Efficiency：跨节点后相对理想线性扩展的效率。
Modality Coverage：服务端实际支持的文本、图像和音频能力。
Quality Delta：量化后在目标任务上的质量变化，而非单一综合 Benchmark。

反方观点与替代解释

1-bit GGUF 可能让权重在更小硬件上运行，但质量、速度、CPU 内存、模态和工具支持需要独立验证。
开放权重仍具有审计、微调、蒸馏和自托管价值，不能因部署昂贵就称其"没有开放意义"。
托管推理降低进入门槛，却引入数据驻留、成本锁定和供应商可用性问题。

适用边界

本章讨论容量与部署，不评价 Inkling 是否在所有任务上优于闭源或其他开放模型。未实测配置只作理论边界，不给出吞吐承诺。

风险与误读点

把激活参数当成需要加载的全部权重。
把聚合显存等于权重大小视为可运行。
把 B200 写成官方支持配置。
把 1-bit 集成方结果写成官方质量保证。
把开放权重等同于训练数据和训练代码完全开源。

参考来源

S13｜Inkling: Our open-weights model：Thinking Machines Lab，2026-07-15。
S14｜Inkling Model Card：Thinking Machines Lab，2026-07-15。
S15｜Welcome Inkling by Thinking Machines：Hugging Face，2026-07-15。
S16｜NVIDIA RTX A6000 specifications：NVIDIA，持续更新。
S17｜Introduction to NVIDIA DGX H100/H200 Systems：NVIDIA，2026-01-26 更新。
S18｜Introduction to NVIDIA DGX B200 Systems：NVIDIA，持续更新。
S19｜Introduction to NVIDIA DGX B300 Systems：NVIDIA，2026-01-20 更新。

错误速查卡

症状	根因	定位	修复
团队以为"开放权重 = 任何人都能本地跑"	把"可下载"和"可部署"混在一起	算一下聚合显存 vs 权重	区分两件事：开放权重解决访问，可部署性由容量 / KV / 通信 / 集群成本决定
算容量时只算 BF16 权重大小	没有把 Runtime、KV Cache、通信缓冲、碎片余量算进去	检查显存占用曲线	理论容量 = 权重 + Runtime + KV + 通信缓冲 + 碎片余量；官方 2 TB BF16 不是上限而是起点
把 41B 激活当成"只需要 41B 显存"	MoE 推理仍要加载全部专家权重	监控 GPU 显存峰值	激活参数只影响每 Token 计算，不影响权重加载
1M 上下文按权重显存计算 KV 预算	KV Cache 随层数、KV 头数、并发、精度放大	拉一次 1M 压测	用 Runtime 报告的 KV Cache 占用乘并发上界
A6000×8 装不下 NVFP4 还想硬装	把"理论可装"当"可运行"	跑一次加载脚本	改 H200×8 或 B300×4；A6000 路径没官方背书
H100×8 跑 BF16 通过但吞吐极低	BF16 没官方验证路径 + 跨节点通信开销大	检查 Inter-node Efficiency	切到官方 NVFP4 路径或 B200/H200/B300
B200×8 跑 NVFP4 出现精度异常	B200 不是模型卡验证配置	对比官方 BF16 路径输出	改 B300×4 或 8×H200
远程音频推理失败	发布时远程音频仍在进行中	看 SGLang / vLLM / llama.cpp changelog	改走官方伙伴或本地服务，发布前用 Audio MC / MMAU / VoiceBench 验收
用 1-bit GGUF 后质量掉很多	1-bit 量化不是官方背书，是社区方案	对比 BF16 输出	把它当作"硬件容量解"而不是"质量等效"，用 Quality Delta 指标
Tokens/s per Dollar 远低于托管	自建集群利用率不足 / 多租户分摊过高	看集群平均利用率	用 Tinker / Together / Fireworks 等托管做"经济性对照"，不是直接替代
把 B200 写成"官方支持"	看到容量够就写支持	看模型卡 GPU 列表	改回"理论可装、未被模型卡列为验证"
评估指标只看综合 Benchmark	综合分掩盖 Quality Delta	加 Rubric 分解	用专家 Rubric + Quality Delta 在目标任务上单独看

喜欢(0)

03 | 完成节点1 — 抽取关键词

图灵平台：万亿级轨迹数据秒级检索实战