Inkling 975B 可部署性阶梯：开放权重之后，真正的门槛才开始

发布边界：运行时版本、托管模态与硬件路径需发布前复核；作者容量计算只作理论估算，不得改写为官方验证配置或部署建议。

摘要

Inkling 的 Apache 2.0 权重可以下载，但可获得并不等于可适配、可装载、可运行、可验证多模态，更不等于可运营。本文分开 975B Total 与 41B Active 两本账，并用五级 Deployability Ladder 组织硬件、运行时、模态和服务证据。

关键词

Inkling、MoE、Open Weights、Deployability、容量规划

目录

• 一、975B Total 与 41B Active 是两本账
• 二、五级 Deployability Ladder
• 三、第一级：权重可获得，不等于权重已适配
• 四、第二级：容量要算完整公式，而不是只加显存
• 五、第三级：运行时支持必须绑定版本、硬件与并行策略
• 六、第四级：原生多模态不等于每条服务路径都多模态
• 七、第五级：生产可运营性是独立的工程产品
• 八、自托管、托管 Endpoint 与蒸馏/小模型替代
• 九、一个可执行的上线顺序
• 结论

Inkling 的权重已经可以下载，这件事当然重要：Thinking Machines Lab 以 Apache 2.0 许可发布了 BF16 与 NVFP4 检查点，开发者可以保存、检查、修改并部署这些权重。但“开放权重”只回答了访问权问题，没有自动交付训练数据、训练代码、成熟的多节点推理栈，也没有替使用者承担服务可靠性。[S1][S2]

因此，讨论 Inkling 是否“可部署”，不能把四句话混成一句话：能下载，说明文件可获得；显存数字加起来够，说明某个静态容量不等式也许成立；能启动一次，说明特定版本、特定拓扑、特定请求通过了冒烟测试；能作为多模态生产服务，则要求容量、内核、通信、模态、上下文、并发、尾延迟、故障恢复与质量回归同时过关。四者之间不是语气强弱，而是四种完全不同的证据。

一、975B Total 与 41B Active 是两本账

Inkling 是 66 层稀疏 MoE：每个 Token 从 256 个路由专家中选择 6 个，同时还有 2 个共享专家参与计算。官方给出的两个参数量——975B Total 与 41B Active——分别约束不同问题。[S2]

975B Total 主要决定“必须长期持有什么”。 完整专家集合、注意力层、嵌入、视觉与音频前端以及其他权重都要存在于检查点中，启动时也必须被下载、读取、校验、分片并放到 GPU、CPU 或分层存储所定义的位置。当前 Token 没有访问某个专家，不代表那个专家可以从服务中永久删除；下一个 Token、下一条请求或另一种输入可能会路由到它。总参数量因此直接影响文件大小、下载时间、启动时间、存储、权重驻留和故障恢复。

41B Active 主要决定“当前 Token 实际算什么”。 稀疏路由让一次前向传播不必执行全部 975B 参数，因而计算量和部分内存带宽压力更接近活动路径，而不是密集 975B 模型。但 Active 并不等于完整部署内存，也不等于服务成本。跨卡 Expert Parallel 需要把 Token 发往持有目标专家的设备，再把结果汇合；路由不均衡会造成热点；不同模态还会增加编码与缓存；长上下文的注意力和 KV Cache 也不受“41B Active”这个数字完整描述。

可以把二者概括为：Total 决定权重资产和系统规模下限，Active 决定单步稀疏计算路径。 用 41B 去估算权重容量，会漏掉绝大多数专家；用 975B 去估算每 Token 的密集计算，又会夸大实际活动计算。生产规划必须同时保留两本账。

二、五级 Deployability Ladder

更稳妥的判断方法，是把可部署性拆成五级门禁：

1. weights_available：许可证、检查点、分片、校验信息可以取得，文件能完整下载。
2. weights_fit：在预留运行时、缓存、通信与并发余量后，权重仍能进入目标硬件拓扑。
3. runtime_supported：指定版本的运行时真正实现了该架构、数值格式、内核与并行策略，而不只是能解析配置文件。
4. modalities_verified：文本、图像、音频、工具调用和目标上下文长度分别通过端到端验证。
5. service_operable：在真实负载下，队列、P95、失败率、恢复、成本和质量回归达到上线门槛。

这是一条单向阶梯。前一级通过，只允许进入下一级测试，不能替代后一级证据。一次成功生成最多证明某个非常窄的 runtime_supported 冒烟路径，不能直接跳到 service_operable。

每一级都要有可复核的验收件

阶梯不是五个标签，而是五套不同的交付物。weights_available 至少应保存许可证版本、模型提交号、分片清单、校验结果、完整下载记录和回滚来源；否则“文件在仓库里”仍可能在上线时变成缺片、版本漂移或不可重建。

weights_fit 的验收件不是一张 GPU 总显存表，而是逐 Rank 的常驻权重、峰值保留显存、最长目标上下文、目标并发和安全余量报告。测试时应明确是否发生 CPU Offload、权重按需换入或隐式降低上下文；这些手段可以是设计选择，却不能被隐藏在“已装下”三个字里。

runtime_supported 要交付锁定版本的软硬件清单、启动参数、数值正确性基线、并行拓扑、已验证的量化组合以及已知不支持项。只要更换驱动、CUDA、运行时提交、GPU 代际或并行度，就应视为新的部署组合，而不是沿用旧结论。

modalities_verified 要为文本、图像、音频、工具和长上下文分别保存请求样例、输入约束、错误码、输出校验和边界行为。尤其要验证同一会话中的模态混合、工具 Schema 失败、超长输入拒绝、取消与重试；“接口接受了字段”不等于这条能力可被产品依赖。

service_operable 最终要交付代表性负载曲线、容量上限、P95/P99、排队、失败恢复、质量回归和单位成功任务成本，并说明扩缩容与故障时的降级策略。这样，每一级的结论都有证据对象，也能在版本升级后明确知道哪些门禁必须重跑。

三、第一级：权重可获得，不等于权重已适配

Hugging Face 上的 BF16 仓库约 1.9 TB，NVFP4 仓库约 592 GB；后者还有单独的量化配置、33 个模型分片和约 10.5 GB 的 MTP drafter 文件。[S3][S4] 这些数字已经说明，部署对象不是“41B 模型文件”。

还要区分“格式存在”与“目标运行时支持该格式”。官方模型卡列出 BF16、MXFP8、NVFP4 数值支持，但公开分发的两条主要检查点路径是 BF16 与 NVFP4。[S2] 某个框架能运行 BF16，不自动表示它能正确加载 NVFP4；能识别 NVFP4 元数据，也不表示目标 GPU 有对应 Tensor Core 和成熟内核。权重开放消除了访问门槛，却把格式、版本和硬件兼容责任交给了部署者。

四、第二级：容量要算完整公式，而不是只加显存

生产容量至少应按下面的式子核算：

M_required = M_weights
           + M_quant_metadata
           + M_runtime_static
           + M_KV_cache
           + M_comm_buffers
           + M_fragmentation
           + M_concurrency_headroom

M_usable = Σ(VRAM_i) × u - M_reserved

其中 u 是规划使用率，不是官方常数。为了给 OOM 抖动、碎片和流量尖峰留空间，团队可以在压测前暂用 0.80—0.90 做保守情景，但最终必须用目标运行时实测替换。还要统一十进制 GB/TB 与二进制 GiB/TiB，避免把单位误差伪装成余量。

公式中的每一项怎样得到

M_weights 应以模型加载完成后各 Rank 的实际常驻量为准，仓库文件大小只用于前期校验；文件压缩、分片重复、混合精度和设备间分配都会让二者不同。M_quant_metadata 可以用同架构理想位宽下界与实际检查点、加载后张量之间的差额辅助核对，但不能假定全部差额都是 scale。

M_runtime_static 应在权重加载、内核预热和图捕获完成、但尚未分配业务 KV 的时点记录。M_KV_cache 则通过固定批量、逐步增加上下文长度，测量显存增量并与结构公式交叉验证。M_comm_buffers 要比较不同 TP、EP、PP 组合，因为 NCCL、All-to-All 和流水线缓冲会随拓扑改变。M_fragmentation 不能只看框架的已分配值，还应观察保留值、峰值高水位和长时间运行后的空洞。最后，M_concurrency_headroom 必须来自真实请求长度和模态分布；用“最大并发乘最大上下文”会严重高估，而只用平均长度又会掩盖尾部 OOM。

因此，容量审计至少要保留三个切面：空载预热后的静态基线、单请求随上下文增长的斜率、以及混合模态并发下的峰值。三者合起来，才可能把“偶尔能跑”转化为可重复的容量模型。

1. BF16：裸权重已经接近 2 TB

按参数量粗算：

975 × 10^9 parameters × 2 bytes
= 1.95 × 10^12 bytes
≈ 1.95 TB
≈ 1.77 TiB

这与 BF16 仓库约 1.9 TB、官方要求至少 2 TB 聚合显存相互吻合，但“2 TB”仍只是入口线。H200 每卡 141 GB，裸算 ceil(1950/141)=14；B300 每卡 288 GB，裸算 ceil(1950/288)=7。官方给出的 BF16 配置却是 16×H200 或 8×B300。[S2][S11][S12] 多出来的卡不是浪费，而是在提醒：权重之外还有静态张量、KV、通信、碎片和实际分片约束。

2. NVFP4：4 bit 理想值不是仓库大小

若把全部 975B 参数理想化为纯 4 bit，得到：

975 × 10^9 × 0.5 bytes = 487.5 GB

但官方 NVFP4 仓库约 592 GB，vLLM 文档还明确指出只有路由专家被量化，共享专家与 QKVR 线性层仍保留 BF16；此外还存在量化 scale、元数据、视觉/音频组件和 MTP 权重。[S4][S6] 因此 487.5 GB 只能作为理论下界，不能拿来选卡。官方门槛是至少 600 GB，并给出 W4A4 的 4×B300（要求 SM100+）和 W4A16 的 8×H200 两条配置。[S2]

3. 1M Context 会把“剩余显存”变成硬约束

配置文件显示 Inkling 有 11 个全局注意力层、55 个滑窗层；全局层有 8 个 KV Heads，滑窗层有 16 个 KV Heads，Head Dimension 为 128，滑窗为 512。[S3][S6] 若只做一个便于审计的 BF16 下界估算，单条 1,048,576 Token 序列的全局层 KV 为：

11 layers × 2(K,V) × 8 KV heads × 128 dim
× 2 bytes × 1,048,576 tokens
= 47,244,640,256 bytes
≈ 47.2 GB ≈ 44 GiB

滑窗层在真正按 512 Token 保留时，稳态 KV 约为：

55 × 2 × 16 × 128 × 2 bytes × 512
≈ 0.231 GB ≈ 0.215 GiB

这仍未包括 SConv Cache、视觉/音频 Encoder Cache、分页元数据、临时激活、通信缓冲和 MTP。不同 KV 精度、缓存布局与前缀共享会改变结果，所以这不是官方容量保证，而是说明量级的作者估算。若同时保留 C 条互不共享的 1M 序列，主要缓存项近似随 C 线性增长。于是，“模型最大上下文是 1M”与“服务能以 1M 支持目标并发”是两件事。

4. A6000 的反例：总数够，路径仍不成立

RTX A6000 每卡 48 GB，Ampere 架构，只支持两卡 NVLink，官方标称两卡合计 96 GB、互联 112 GB/s。[S13] 按 BF16 名义权重裸算至少要 41 卡；若用 85% 可用显存情景，要约 48 卡。按 592 GB NVFP4 仓库裸算要 13 卡，85% 情景约 15 卡。

这些数字不能写成部署建议。A6000 没有 Blackwell 的 NVFP4 硬件路径，且两卡桥接不是 13—48 卡的统一高带宽交换域。即使 PCIe 机群能把文件分散放下，也仍可能缺少适配内核、稳定 Expert Parallel、足够的 All-to-All 带宽和可接受的故障域。这个例子恰好证明：聚合显存是必要条件，不是可执行拓扑。

五、第三级：运行时支持必须绑定版本、硬件与并行策略

截至本次访问，证据应严格分成四栏，不能互相升级：

vLLM 的 Inkling Recipe 给出文本/图像/音频、1M Context、TP/DP/EP/PP、Prefix Cache、MTP 等支持说明；NVFP4 要求 B200/GB200，BF16 支持 H200/H20 或 Blackwell，示例配置为 4×GB200。[S6] vLLM 0.26.0 的发布记录列出 Inkling 基础模型、相对注意力、MTP=1、LoRA 与 ModelOpt NVFP4 等支持项。[S7] 这也说明“支持”必须具体到版本：Recipe 所述最多 8 个 MTP Heads，与某个稳定版仅明确 MTP=1，并非同一句承诺。

SGLang 0.5.16 的发布记录列出 Inkling 支持，并记录 Blackwell TP4/TP8、H200 与 AMD MI350X/MI355X 的验证范围。[S8] 这些是运行时项目的验证，不应改写成 Thinking Machines 的模型卡配置，更不能把其中单次性能数字外推到任意集群。

Transformers 已加入 Inkling 模型定义、视觉与音频配置，官方示例可以直接做文本、图像和音频生成。[S5][S9] 但 Transformers 是模型执行库，不等于自动拥有生产服务需要的调度、限流、队列、故障转移和多租户隔离。

llama.cpp 路径由 Thinking Machines 与 Hugging Face 的发布材料明确列出，Unsloth 提供 GGUF 与启动命令，llama.cpp 上游也出现 Inkling 架构接入记录。[S1][S5][S10] 但 GGUF 的量化质量、音频覆盖、完整 1M Context、并发和跨设备性能不能从“命令可运行”推出；尤其 1-bit 路线应视为实验性社区路径，而不是官方生产保证。

运行时层最容易卡住的并非 API 形状，而是以下硬门槛：

• 硬件代际与量化内核：同名 4 bit 格式可能依赖特定架构 Tensor Core、FlashInfer、CUDA 与编译链。
• 并行通信：TP 需要频繁集合通信，EP 还会引入路由与 All-to-All；跨节点网卡、RDMA、拓扑感知和拥塞会直接决定尾延迟。
• 启动与恢复：数百 GB 到近 2 TB 权重需要下载、解压、校验、分片和 CUDA Graph/内核预热；一次冷启动成功不代表节点故障后能在 SLO 内恢复。
• 版本矩阵：驱动、CUDA、PyTorch、FlashInfer、运行时、模型提交和量化配置必须锁定。某个依赖升级可能改变内核、缓存布局甚至数值正确性。
• 故障域：一个请求跨越的 GPU 和节点越多，任一设备、链路或进程故障导致整条副本失效的概率越高。生产容量还要考虑副本与 N+1，而不只是单副本装载。

六、第四级：原生多模态不等于每条服务路径都多模态

模型卡确认 Inkling 接收文本、图像和 16 kHz WAV 音频，输出只有文本；工具使用是其预期场景，但真正执行工具依赖 Harness、模板、Parser 与外部权限系统。[S2] 1M 是模型最大上下文，不是所有 API 的统一配额。逐路径核对后，可以得到下面的状态表：

这张表最重要的不是打勾数量，而是暴露“未知”。生产系统应把每个未知变成测试用例：同一会话混合文本、图片与音频；工具参数的结构化正确率；最大输入长度；长音频边界；图片尺寸边界；多轮前缀复用；取消、超时和重试后是否重复执行副作用。模态能被 Parser 接收，不等于语义质量、错误处理和计费都已就绪。

七、第五级：生产可运营性是独立的工程产品

service_operable 的判断对象不再是模型，而是“模型 + 运行时 + 硬件 + 调度 + 观测 + 回归集”的整体。至少要建立以下门禁：

容量门禁。 在目标上下文分布和并发下，不发生不可恢复 OOM；权重、KV、Encoder Cache、通信和碎片均有监控；冷启动、滚动升级和副本扩容有可复现时间账本。

延迟门禁。 分开记录 Queue Wait、Prefill、TTFT、TPOT/ITL、Tool Wait 与端到端 P95/P99。平均吞吐无法替代单用户尾延迟，离线 Benchmark 也不能替代在线排队曲线。

正确性门禁。 文本、图像、音频、工具参数和长上下文分别有黄金集；升级驱动、运行时、量化格式或模型提交后必须跑质量回归。量化路线只有在任务成功率保持可接受时才算节省成本。

可靠性门禁。 模拟 GPU 进程退出、节点丢失、网络抖动、权重缓存失效和对象存储限速；验证请求是否可重试、工具副作用是否幂等、剩余副本是否能承接流量。单副本多节点服务尤其要计算故障放大。

经济性门禁。 不要只比较每 Token 单价或 GPU 小时。更能指导路线选择的是：

Cost per Successful Task
=（GPU/Endpoint + CPU + 网络 + 存储 + 运维 + 失败重试成本）
 ÷ 满足质量、模态与延迟 SLO 的成功任务数

“成功”必须同时包含输出质量通过、模态处理正确、工具调用可执行且端到端延迟达标。低价但频繁超时、排队或回退的路径，Cost per Successful Task 可能反而更高。

八、自托管、托管 Endpoint 与蒸馏/小模型替代

这里的“小模型替代”不应偷换成“等待 Inkling-Small 即可”。截至官方公告，Inkling-Small 仍是 Preview，完整权重尚待测试完成后发布。[S1] 更现实的策略是先用 Inkling 或托管 Endpoint 建立任务级教师基线，再评估蒸馏、路由或其他已可部署模型；只有当 Cost per Successful Task、P95、队列、模态覆盖和质量回归同时更优，替代路线才成立。

九、一个可执行的上线顺序

第一步，不从 GPU 清单出发，而从工作负载出发：统计文本、图片、音频、工具任务的比例，输入/输出长度分布，真正需要 1M 的请求占比，以及质量不可退化的难例。

第二步，为每条候选路线建立证据档案：检查点提交、运行时版本、CUDA/驱动、GPU 与网络拓扑、支持的数值格式、各模态 API、上下文上限和已知限制。未知项一律写成未知，不用模型原生能力代填。

第三步，逐级过 Ladder：先校验权重，再做带余量的容量模型；然后固定版本完成文本冒烟、图像冒烟、音频冒烟、工具调用和长上下文；最后才上真实并发压测、故障注入和质量回归。

第四步，用任务指标做 Go/No-Go：每种模态的成功率、P95/P99、Queue Wait、OOM/错误率、恢复时间、Cost per Successful Task，以及与参考模型相比的质量回归。任何一项没有证据，就仍停留在“能启动”而不是“能运营”。

结论

Inkling 的开放权重把一个原本封闭的模型资产交到了开发者手中，但没有把 975B 权重、1M Context、原生多模态和多节点服务压缩成一个“显存相加”的问题。975B Total 决定完整权重必须被持有，41B Active 只说明每个 Token 的稀疏活动路径；BF16/NVFP4 文件大小只是容量公式中的第一项；运行时支持必须绑定版本、硬件、内核与并行通信；模型原生能力必须在每条 Endpoint 上重新核对；最终上线则要由 P95、队列、模态覆盖、质量回归和 Cost per Successful Task 决定。

所以，真正准确的说法不是“Inkling 已经可以部署”，而是：Inkling 已经通过 weights_available，并为若干硬件与运行时提供了继续向上验证的路径。至于某个团队能否到达 service_operable，取决于它是否逐级拿出证据，而不是能否把一组显存数字加到 600 GB 或 2 TB。

FAQ

41B Active 能不能用来算显存？

它主要描述当前 token 的活动计算路径，不能替代完整 975B 权重、缓存、通信和运行时开销。

运行时 Recipe 算官方验证配置吗？

不自动算。应标明它属于哪个项目、版本、硬件和测试范围，不能改写成模型提供方承诺。

A6000 拼卡是否可行？

母稿中的 A6000 数字仅用于展示裸容量估算与工程容量的差距，不是生产部署建议。