模型与推理引擎的支持路径

一份新旗舰模型发布，从「决定要用它」到「真的在自己的服务里跑起来」，中间隔着一段常被低估的距离。Inkling 发布当天就宣布获得 Transformers、vLLM、SGLang、llama.cpp、Unsloth 支持，但它的 BF16 权重要约 2TB 显存；而 vLLM 直到十天后的 v0.26.0 才补齐它的完整支持栈。「已支持」不是一个布尔值。

先判断支持深度到了哪一级

把「支持」拆成四级，才问得出有用的问题：

1. 能加载：模型能跑出正确结果，但走的是参考实现路径，性能可能只有原生实现的一个零头。
2. 有原生建模：引擎里有这个架构的专门实现。
3. 有性能路径：注意力核、图捕获策略、量化路径、并行切分都到位。vLLM v0.26.0 为 Inkling 补的正是这四层——基础建模、分段 CUDA Graph、Hopper FA4 相对注意力、MTP 推测解码。
4. 有正确性保障：这一级最容易被跳过。Ollama v0.32.4 当天就支持了 Apple GPU 上的 Laguna，但那条 MLX 路径带着一个会降低 NVFP4 输出质量的缺陷，直到 v0.32.5 才修好。

所以问「支持了吗」得到的答案没有信息量，问「到第几级」才有。能跑起来和跑得对，是两件事。

三条路径，代价不同

• 等原生支持。 历史上要几周到几个月；vLLM 把 Inkling 压到十天已经算快。适合不赶时间、且要吃满性能的场景。
• 走 Transformers 后端。 vLLM 里一个 --model-impl transformers 开关，覆盖 450 多种架构，且在 Qwen3 的单卡稠密、张量并行稠密、专家并行 MoE 三档实测上已追平甚至反超手写原生实现。这条路把「可用时间差」压到接近零——但要先确认你的架构不在例外名单里（线性注意力类当时尚未支持）。
• 换引擎。 llama.cpp、SGLang、MLX 各有各的适配节奏，同一个模型在不同引擎上的支持级别可能差两级。换引擎的代价不在跑起来，而在于并行配置、量化格式和运维习惯全部要重来。

上线前必须落地的三个数

• 显存门槛：按权重加 KV 缓存算，不要按参数量猜。 Inkling 是 1 万亿总参数、41B 激活，但 BF16 要约 2TB、NVFP4 约 600GB——决定你能不能跑的是后面这个数。
• 正确性基线：拿固定输入和参考实现对比，而不是看它能不能出字。 上面那条 MLX 缺陷只有这样才发现得了——输出流畅、语气正常，就是质量掉了。视觉与结构化输出尤其如此。
• 时间窗：承诺的开放权重日期不等于可用日期。 Kimi K3 承诺月内开放权重，但在权重真正落地之前，它对自托管团队的价值是零。

与相邻能力的分工

「旗舰模型发布解读与换代判断」回答该不该换；这一条接在它后面，回答换得了吗、多久换得了、跑得对不对。一旦模型已经在你的栈上正确跑起来，问题就变成排队、批处理与副本数，交给「推理服务容量规划」；如果目标是一台具体的机器而不是一个对外服务，那是「端侧模型部署与硬件适配」的范围。