有效衡量基于大语言模型（LLM）的应用性能，已经成为企业采用 AI 技术的关键因素。来自红帽团队的 Legare Kerrison 与 Cedric Clyburn 近日在 Arc of AI 2026 大会上分享了评估与优化 LLM 推理的实用方法。他们讨论了 RAG（检索增强生成）与 Agentic AI 等 AI 应用中不同工作负载的资源需求与成本影响，同时强调了 Requests Per Second（RPS）、Time to First Token（TTFT）以及 Inter-Token Latency（ITL）等指标在应用评估中的重要性。
演讲一开始，两位讲者回顾了近几年 AI 领域的发展节奏：2023 年属于 LLM 和 Hugging Face 等模型，2024 年是 RAG 的一年，2025 年则聚焦模型微调与 AI Agent，而他们预测 2026 年将成为“LLM 评估之年”。在 AI 部署以及 LLM 模型评估与性能分析方面，他们指出，各类排行榜虽然有参考价值，但通常过于通用。一些网站会使用困难提示词、编程、数学和创意写作等维度评测模型，但这些基准并不能反映企业自身独特的业务问题与数据。因此，在使用这些排行榜时，必须认识到其局限性。软件开发团队需要理解整个 AI 技术生态，才能为具体业务场景选择合适的模型与供应商。
两位讲者还重点提到了他们在真实 LLM 项目落地过程中遇到的常见痛点：当团队尝试交付可用于生产环境的模型时，必须在模型质量（准确率）、响应速度（延迟）与整体成本之间处理一个“权衡三角”。优化其中任意两个维度，都会影响第三个维度。例如，如果同时追求高准确率和低延迟，那么部署成本通常会显著上升；若重点关注低成本和高准确率，则往往意味着更高的延迟；而过度强调低成本和低延迟，则会牺牲模型准确率。因此，在为工作负载选择合适的模型、性能目标与硬件基础设施时，清晰的测量与评估机制至关重要。
他们认为，团队需要从单纯关注“选择哪个模型”，转向关注应用本身的需求与优先级，才能真正为用户提供合适的解决方案。通过定义明确关键性能与质量指标的服务级目标（SLO），不仅能够确保应用对终端用户保持快速、可靠且实用，还能帮助团队在不同模型与硬件之间进行结构化对比，从而优化成本。
其中，Requests Per Second（RPS）用于衡量系统每秒能够处理多少推理请求，可用于评估整体吞吐量以及服务栈在负载下的扩展能力。Time to First Token（TTFT）指从发送请求到接收到第一个生成 token 的时间，用于衡量用户感知到的响应延迟。而 Inter-Token Latency（ITL）则表示首个 token 之后，相邻 token 之间的生成间隔，它反映了流式输出在用户看来是否足够流畅，同时也体现了解码器的效率。
他们展示了不同工作负载下的 SLO 示例，以及对应的使用场景和基准指标。例如，一个电商聊天机器人通常需要快速、具备对话感的响应。在这种场景中，TTFT 通常要求 ≤200ms，ITL 要求在 99% 请求（P99）中 ≤50ms。而基于 RAG 的应用则比单纯的速度更强调准确性与完整性。RAG 场景通常具有更多输入 token、较少输出 token，因此其 TTFT、ITL 与请求延迟指标分别要求在 99% 请求中达到 ≤300ms、≤100ms（在流式输出情况下）以及 ≤3000ms。
在明确应用优先级之后，团队还需要进一步考虑硬件需求。LLM 推理阶段通常包含两个阶段：Prefill（计算密集型）与 Decode（内存密集型）。结构化生成、推测解码、前缀缓存以及会话缓存等技术，都有助于提升 LLM 服务效率。相比依赖后续 token 的 Decode 阶段，使用首个 token 的 Prefill 阶段更容易扩展负载。两位讲者还提到，在适合的场景下，本地运行 LLM 可以避免云端开销，从而在某些使用场景中获得更高效率。
他们将“模型评估”定义为：基于多项标准，评估模型在特定用途下整体性能与适用性的过程，即一个特定模型在某类工作负载和特定硬件上的实际表现。而“模型基准测试”则是基于预定义数据集、任务以及其他模型，对模型性能进行标准化对比。
他们还介绍了团队通常如何在不同工作流模式下衡量 LLM 性能。例如，在标准请求流中，每个新请求都会生成 token，因此端到端请求延迟是重要指标。而在流式请求场景中，LLM 请求往往具有异构性，因此 TTFT 与 ITL 等指标需要被正式跟踪与监控。
LLM 性能指标会受到多种因素影响，包括模型架构与规模、量化（通过降低权重精度压缩模型）、推理服务引擎（如 Ollama、vLLM、TGI、Triton）、硬件条件（例如 GPU 显存）以及批处理与并发策略。
由于模型推理性能评估过程耗时且碎片化，因此 LLM 部署的测量工作并不容易。Kerrison 与 Clyburn 展示了一些团队在规划 LLM 工作负载时需要考虑的问题，例如：“在英伟达 H200 上，我应该使用 Llama 3.1 8B 还是 Llama 3.1 70B Instruct 来构建客服聊天机器人？”或者“为了在最大负载下维持服务运行，我需要多少台服务器？”
他们还介绍了使用开源工具包进行基准测试的方法，例如用于面向 SLO 的 LLM 部署基准测试工具 GuideLLM。GuideLLM 是 vLLM 项目的一部分，它能够模拟真实流量，并测量吞吐量和延迟等指标。其流程包括：选择与定制模型、基于真实数据或合成数据选择数据集、配置工作负载以及执行基准测试。如果模型能够达到预期 SLO 目标，就可以在 vLLM 引擎上部署到生产环境。
Clyburn 展示了使用模拟工作负载进行的 GuideLLM 测试结果，包括同步模式（一次运行单个请求流）和并发模式（并行运行固定数量的同步请求流），并使用了 Hugging Face 的 ShareGPT 数据集、文件型数据集以及内存数据集。他还分享了 Chat、RAG、摘要生成与代码生成等不同工作负载在 P99（99 分位）与 P90（90 分位）延迟指标下的基准结果。
除了 LLM 推理性能之外，模型准确率评估同样重要。LLM 准确率评估场景通常包括：模型准确率、Pipeline 准确率（针对 RAG 与 AI Agent）以及应用准确率。一些常见的开源评估工具包括：
RAG 场景评估：Ragas、LlamaIndex Evals、Haystack Eval framework
人工 + LLM-as-a-judge 评估：人工标注、LLM 评审
领域专项准确率评估：PubMedQA（生物医学）、FiQA（金融）、CaseHOLD（法律）
最后，两位讲者强调，应用团队应重点关注 LLM 优化技术，例如量化——相比一些小众优化技巧，压缩模型往往更加有效。在一个案例中，使用 GPTQModifier 进行量化后，模型体积缩小了 45%。另一个重要技术是 KV Cache，它能够减少重复计算并加速解码，但代价是需要更多内存。在 AI 学习资源方面，他们推荐了 Hugging Face 网站，其中提供经过红帽 AI 验证的语言模型；同时也推荐 deeplearning.ai 的 AI 培训课程，用于系统学习 AI 相关知识。
原文链接：
https://www.infoq.com/news/2026/04/kerrison-clyburn-llm-performance/
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。