模型版本与 Runtime 正交：换引擎不等于换模型，数字为什么必须重测

谈 Mr F 方向的 GPU 推理能力时，最容易把三件事揉成一句：「我们支持某某大模型」。真正可验收的说法，要把栈摊开：平台壳、Runtime、模型版本——三者正交。

一、三层地图（先建立共同语言）

1. 1） 平台壳：管拉模型、一键启动、HTTP 入口。常见如 Ollama、部分本地 Studio。它方便，但通常不是 tok/s 竞赛的主战场。
2. 2） Runtime / 推理引擎：真正算 token 的一层——加载器、tokenizer、CUDA kernel、KV/内存、调度、量化执行。SparkInfer、llama.cpp、vLLM、genie-ai-runtime 都落在这一层（各自硬件与场景不同）。
3. 3） 模型版本：名称 + 权重文件 + 量化 tag。例如某一版 Qwen MoE 的 Q4_K_M GGUF。换 tag = 换模型版本；公开倍率不能外推。

记忆口诀：换 Runtime ≠ 换模型；换模型 tag = 数字必须重测。

二、Phase-1 为什么「常常不用重训」

Token / Talk 工厂与不少云主机 PoC 的 Week-1 形态是：

同一份 GGUF + 同一张 GPU → SparkInfer（或约定 Runtime）vs llama.cpp / 现网基线 → 比 tok/s、时延、利用率。

这是 Runtime 替换与测量，不是重新训练。Serving 若 OpenAI 兼容，切流可以低到改 base URL——但「能不能上线」仍取决于客户卡上的 A/B，而不是公开 dashboard。

三、什么时候必须持续适配

下列变化会推动引擎侧工程与复测，而不是「每个小版本都从零重写产品」：

• 新模型架构（MoE 路由、新 attention / DSA 等）
• 新 GPU 代际（如 Blackwell 与 Ada 的 sm 目标不同）
• 新量化格式（GGUF Q 档、AWQ、FP8 等条件变了）
• 新负载（上下文、并发、prefill/decode 比例）
• 满血大模型多卡集群（与单卡 GGUF POC 是另一条故事线）

因此：Runtime 会跟大模型和硬件演进，节奏是「架构级适配 + 按客户模型 bench」，不是「每个版本号都重做一套」。企业侧用 Supported Model Matrix + 新 flagship 纳入时的复测里程碑来管理预期。

四、对客户怎么讲（可引用）

公开示意数字 = 特定模型 × 特定量化 × 特定 GPU × 特定脚本下的可复现结果。贵司环境须同机复测；5090 公开数不能承诺给 4090；Qwen 上的 uplift 不能推断到另一旗舰模型。

相关阅读：#/mrf · 报告 https://www.chainfir.com/talent/reports/ · 《Token工厂为什么换的是推理Runtime》

免责声明：方法说明，不构成性能保证或投资意见；示意≠SLA；开源引用≠合同相对方。合作：contact@chainfir.com