Kubernetes Inference Perf：基准测试服务栈，而不只是模型
Kubernetes Inference Perf 让模型服务器比较更加一致，但其结果仍取决于提示词、负载模式、token 数量和集群。
Kubernetes 的 Inference Perf 项目现在拥有一篇经过同行评审的软件论文。《开放源代码软件期刊》于 8 月 27 日发表了这篇论文，为从业者提供了一个可引用的工具描述：该工具旨在让逼真的生成式 AI 流量经过不同的模型服务器和服务栈。
它最有用的承诺是一致性，而不是一个通用排行榜。Inference Perf 可以在团队更换模型服务器、加速器、路由器或 Kubernetes 策略时，保持一个负载生成器和指标契约不变。对于提示词、输出长度、负载模式、token 计数器、预热窗口或服务器设置不同的两次运行，它无法让它们变得可比。
这个边界把“与模型服务器无关”从营销形容词变成了工程要求：冻结工作负载，记录完整的服务栈，并且只比较实验意图改变的那个维度。
Inference Perf 衡量的是部署，而不是模型智能
JOSS 论文介绍了一个模块化基准，包含数据生成、负载生成、服务器客户端、指标收集、JSON 报告和分析。当前的项目文档列出了 vLLM、SGLang 和 Hugging Face TGI 的已验证集成，以及对兼容 OpenAI 风格端点的支持。它可以生成恒定速率、泊松、并发、突发、饱和、共享前缀、多轮和轨迹回放工作负载。
这些功能回答的是服务问题。它们可以显示用户多快能看到第一个 token、后续 token 到达得多稳定、有多少请求满足延迟目标、系统在哪里达到饱和，以及路由器或自动扩缩容器能否从流量变化中恢复。它们无法显示模型的答案是否正确、安全、有依据或有用。
最初的 Kubernetes WG Serving 提案把这一范围说得格外清楚。它想要的是一个“基准即代码”的工具，能够测试模型服务器、加速器和编排，而不绑定于某一个栈。推荐某个获胜的服务器或托管服务明确不在目标之内。
该工作组后来也已完成其章程。CNCF 2 月项目更新称，其工作转入 Kubernetes 的特别兴趣小组，Inference Perf 由 SIG Scalability 负责支持。软件仍在活跃开发：7 月 23 日发布的 v0.6.1 是最新标记版本，而主分支还在持续变化。因此，固定版本是结果的一部分，而不是日常维护。
服务问题决定有用的指标
一个吞吐量数字会隐藏多个不同系统。基准测试应从用户或运营者的承诺开始，然后选择能够证伪该承诺的指标。
| 运行应该回答的问题 | 主要证据 | 结果旁边要保留什么 | 什么可能误导读者 |
|---|---|---|---|
| 用户要等多久才能看到进展？ | 首 token 时间（TTFT），尤其是 p50 和 p95 | 提示词长度分布、缓存状态、并发数、预热处理方式 | 良好的均值可能掩盖缓慢的尾部或冷启动代价 |
| 流式响应有多平滑？ | 每个输出 token 的时间（TPOT）和 token 间延迟（ITL） | 输出长度、流式模式、token 计数来源 | 更短的输出或不同的分词器可能制造出表面上的提升 |
| 服务栈能完成多少工作？ | 每秒请求数以及每秒输入/输出 token 数 | 提供速率、达到速率、失败数和请求长度 | 只计算成功请求可能掩盖过载和被丢弃的工作 |
| 什么容量能满足产品目标？ | 在声明的延迟约束下的请求或 token 有效吞吐量 | 确切的服务级阈值和错误策略 | 在有用的延迟已经崩溃后，原始吞吐量仍可能上升 |
| 路由或自动扩缩容是否有帮助？ | 阶段级延迟、吞吐量、有效吞吐量、错误和基础设施遥测 | 副本数、路由策略、扩缩容事件、队列深度、GPU 和服务器指标 | 稳态快照可能错过该功能原本要改善的转换过程 |
该项目的指标定义区分了端到端请求延迟、TTFT、TPOT、归一化 TPOT 和 ITL，而不是将它们统称为“延迟”。其有效吞吐量计算只计算满足所有已配置延迟约束的成功请求。当产品确实有服务级目标时，这使有效吞吐量成为更有力的容量指标。
即使指标正确，分母也可能不对。Inference Perf 会记录服务器报告的 token 用量和客户端重新分词的结果，因为两者可能由于聊天模板开销、分词器版本修订、工具模式或流式文本而不一致。其报告会暴露回退计数和 token 不匹配。如果一次运行用客户端计数归一化 TPOT，而另一次使用服务器计数，那么比较已经改变了两件事。
三个层次将服务器速度与集群行为分开
有用的 Kubernetes 服务评估会把本地服务器行为与集群行为分开。在一次运行中把一切结合起来，可能产生一张令人印象深刻的图表，却无法揭示究竟是哪个组件造成了结果。
最干净的基线固定模型版本、量化方式、服务器镜像、加速器、副本数、路由路径、提示词分布、输出行为和提供的负载。然后可以通过速率扫描揭示延迟或错误使额外吞吐量变得无用的节点。路由器和自动扩缩容测试又回答一个不同的问题：它们暴露的是转换期间的扩容延迟、队列增长、缓存中断、错误和恢复，而不只是测量最终的稳态。
按交替顺序重复运行，会让这种区分更可信。原始阶段报告和逐请求报告、生成的 config.yaml、服务器和客户端日志，以及集群事件，可以揭示中位数或某次最佳运行会隐藏的不稳定性。
Inference Perf 也能够测试多轮和共享前缀流量，但这些工作负载需要另一个控制：缓存接纳和路由亲和性。落到热前缀缓存上的请求，不能与被路由到冷副本的请求相比较。当服务器提供这些信息时，记录已缓存和未缓存的提示词 token，并把改变缓存命中情况的路由变化视为完整服务栈结果，而不是纯粹的服务器速度结果。
相同的工具并不能保证相同的工作
项目最新的跨工具可比性指南也在提醒人们注意只用 Inference Perf 进行比较时的问题。默认输入和输出分布并不是固定长度。开环速率测试和闭环固定并发测试衡量的是不同的行为。采样参数、分词器行为和提前停止设置都会改变发送给服务器的工作量。
预热尤其容易出问题。该指南称，Inference Perf 没有专门排除预热的阶段：它发送的每个请求都会被测量。会丢弃预热请求的工具观察的是不同窗口，尤其是在编译、缓存或自动扩缩容导致早期请求变慢时。团队可以先预热服务器，或使用一个短的前置阶段并将其排除在比较之外，但必须记录所选择的处理方式。
跨工具比较需要更加谨慎。该指南记录了其他基准客户端中依赖版本的标志含义和默认值，然后建议在比较速率前检查输入和输出 token 总数。当最小值、最大值、到达间隔或 token 来源不同时，仅有相等的平均值还不够。
与服务器无关的测试工具消除了一种变化来源，但不会消除实验设计。
一项由赞助支持的 Kubernetes 比较展示了这种方法的两面
5 月的一份 Principled Technologies 方法报告提供了一个具体例子。测试人员使用 Inference Perf、Llama 3.1 8B Instruct、vLLM 0.11.0、流式响应、共享前缀提示词和泊松速率扫描。他们公开了集群清单、工具配置、软件版本、多个负载阶段，以及选择吞吐量—延迟权衡点所使用的规则。
这些细节让实验可以被检查，也说明了为什么结果无法与其设置分开：报告比较的是已配置的 GKE 和 EKS 系统，而不是抽象的云、通用 Kubernetes 或每一种工作负载。附录称测试于 4 月 14 日结束，项目由 Google 委托。报告还引用了比当前 v0.6.1 发布版本更旧的 Inference Perf 版本。
这项研究适合作为一份经过实际测量的记录，而不是某个平台对另一种模型、地区、加速器、服务器构建版本、提示词分布或路由策略必然更快的中性证明。如果不复现完整环境，只复现它的 YAML，就会创造一个新的实验。
可辩护的结果是一项有边界的主张
在选择服务器或集群策略之前，将目标变化与不变的基线进行比较。如果改变模型服务器，就固定模型、硬件、请求流和 Kubernetes 路径。如果改变路由器，就固定服务器镜像和副本池。如果改变加速器，就披露所有无法保持不变、且可能带来影响的软件和拓扑变化。
然后应在与实验相同的尺度上陈述结论：“策略 B 在这个集群中以 p95 门槛维持了声明的工作负载”，而不是“策略 B 更快”。如果变化可能改变输出，就将服务结果与独立的质量评估配对，并根据测得的资源使用量计算成本，而不只是看加速器标价。
通用的 AI 评估说明说明了为什么指标会成为产品决策的一部分。Gemini 定价分析（中文）从另一个方向提出了同样的警告：当重试和被拒绝的工作消耗账单时，token 吞吐量并不是业务结果。
同行评审让 Inference Perf 更容易引用。使用它的更有力理由是实际的：一个可重复的测试工具可以揭示服务栈在真实流量下从哪里开始弯曲。只有当工作负载、计数器、窗口和环境一同转移时，其中的数字才会成为可迁移的证据。
资料来源
- JOSS: Inference Perf, a benchmarking tool for GenAI inference
- Kubernetes SIGs Inference Perf repository and documentation
- Inference Perf v0.6.1 release
- Inference Perf metric definitions and token-count provenance
- Inference Perf goodput documentation
- Inference Perf cross-tool comparability guide
- Kubernetes WG Serving Inference Perf proposal
- CNCF: Kubernetes WG Serving concludes its work
- Principled Technologies GKE inference study methodology