LLM 的性能突围战：如何对大模型接口进行全链路压力测试

前言

性能测试领域有一句流传已久的经验：你不压测，用户替你压测。

这句话的残酷之处在于，用户替你压测的代价，是真实的业务损失、真实的用户流失，以及一次很难挽回的信任危机。正因如此，压力测试在传统软件工程中已经形成了相当成熟的方法论：并发用户模拟、吞吐量基准、响应时间分布、资源瓶颈定位——这套打法在电商大促、金融高频交易、直播峰值等场景里已被反复验证。

而今天，当越来越多的产品开始把大语言模型接口（LLM API）纳入核心链路，一个新的性能噩梦悄然成形。

传统接口的压测逻辑，建立在几个稳定的假设之上：响应时间可预测、资源消耗与并发量线性相关、超时边界清晰。LLM 接口把这三个假设全部推翻——响应时间随 Token 数量动态变化、流式输出改变了“响应完成”的定义、上下文长度导致资源消耗高度非线性、多轮对话引入了有状态的负载模式。

这正是本文要正面交锋的核心矛盾：“传统压测迁移”思路与“LLM 全链路压测体系”之间的根本差异。前者把 LLM 接口视为一个“慢一点的普通 HTTP 接口”，套用现有工具和方法论；后者意识到 LLM 接口的性能特征有其独特的物理逻辑，需要从测试建模、指标体系到工具链全面重构。

两种思路的差距，会在第一次生产环境峰值来临时，以最直接的方式呈现。

目录

• 一、从“响应时间”到“Token 吞吐模型”——LLM 性能的度量重构
• 二、从“并发用户”到“上下文感知负载”——压测场景建模的本质差异
• 三、从“单点压测”到“全链路拓扑”——LLM 应用的系统性性能风险
• 四、从“阈值告警”到“性能基线管理”——LLM 接口的持续性能运营
• 五、结语：压测的终点，是对系统边界的清醒认知

主体

一、从“响应时间”到“Token 吞吐模型”——LLM 性能的度量重构

传统压测的核心性能指标，是响应时间（RT）和吞吐量（TPS/QPS）。这两个指标之所以有效，是因为传统接口的处理单元是“一次请求”——无论请求的内容是什么，处理完成就是处理完成，响应时间衡量的是一个明确的开始到结束的区间。

LLM 接口的处理单元，是 Token。一次请求的处理时间，直接取决于输入 Token 数量（影响首字延迟）和输出 Token 数量（决定总响应时长）。两个响应时间都是 3 秒的请求，一个可能输出了 50 个 Token，另一个输出了 500 个 Token——它们消耗的计算资源相差十倍，但在传统 RT 指标下看起来完全相同。

传统压测迁移的做法，是用固定的测试 Prompt 对接口发起并发请求，记录平均响应时间和 P99，设定通过阈值。这套指标体系能发现接口是否超时，但它无法回答以下关键问题：

• 在高并发下，首 Token 延迟（TTFT）是否在用户可感知的阈值内？
• 流式输出的 Token 生成速率（TGS）是否稳定，还是存在明显的卡顿节奏？
• 在不同 Prompt 长度分布下，系统的实际吞吐能力（Token/s）如何变化？
• 当并发请求同时包含长输入和短输入时，资源调度是否公平？

LLM 全链路压测体系需要建立一套以 Token 为中心的性能度量模型，至少包含以下五个核心指标：

• TTFT（Time to First Token）：从请求发出到收到第一个流式 Token 的时间。这是用户感知延迟的核心指标，在流式场景下，TTFT 决定了用户“等待感”的强弱，通常需要控制在 1-2 秒以内。
• TGS（Token Generation Speed）：每秒生成的 Token 数量，反映模型推理的实际吞吐能力。这个指标在并发压力下的衰减曲线，是评估系统容量的关键依据。
• TPOT（Time Per Output Token）：每生成一个输出 Token 的平均耗时，是 TGS 的倒数，在分析流式输出的节奏稳定性时更为直观。
• 端到端延迟（E2E Latency）：完整请求从发出到接收完毕的总时长。这个指标受输出 Token 数量影响巨大，在压测中必须控制测试 Prompt 的输出长度分布，否则数据不具可比性。
• Token 级吞吐量（System-level Token/s）：在特定并发压力下，系统整体每秒处理的 Token 总量。这是评估系统实际服务能力上限的最直接指标。

一个具体的压测发现案例：某 LLM 应用在单并发下 TTFT 约 800ms，TGS 约 60 Token/s，表现优秀。但在 50 并发下，TTFT 飙升至 4.2 秒，而 TGS 仅下降至 45 Token/s——这说明系统的瓶颈不在推理速度，而在请求排队和上下文加载阶段。如果只看整体响应时间，这个瓶颈位置会被完全误判，优化方向也会完全走偏。

度量体系的重构，是 LLM 压测的第一步，也是最容易被跳过的一步。没有正确的度量，后续所有的压测结论都是在沙上建塔。

二、从“并发用户”到“上下文感知负载”——压测场景建模的本质差异

传统压测的负载建模，围绕“并发用户数”展开：模拟 N 个用户同时发起请求，观察系统在不同并发梯度下的性能表现。这个模型足够简单，也足够有效——因为传统接口的每次请求是独立的，用户与用户之间没有状态关联。

LLM 应用打破了这个独立性假设。一个真实用户与 LLM 应用的交互，往往是多轮对话的形式：每一轮回复都建立在前几轮的上下文之上，上下文长度随对话轮次线性增长，而每一轮请求的 Token 消耗也随之增长。

传统压测迁移用单轮固定 Prompt 模拟并发用户，所有请求的 Token 数量完全相同，资源消耗高度均匀。这种负载模式在生产环境中几乎不存在——真实用户的对话长度分布是高度不均匀的，有人三轮结束，有人聊了三十轮，而长对话用户占用的计算资源，可能是短对话用户的十倍甚至更多。

LLM 全链路压测体系的场景建模，需要引入三个维度的真实性：

对话轮次分布建模：基于真实用户行为数据（或合理的业务假设），建立对话轮次的概率分布模型。例如，40% 的用户在 3 轮以内结束对话，40% 在 3-10 轮，20% 超过 10 轮。压测脚本需要模拟这种分布，而非用单轮请求一刀切。

Prompt 长度分布建模：生产环境中的用户输入长度呈长尾分布——大量短输入，少量极长输入。极长输入对系统的冲击远超其数量比例，在压测中必须被显式建模。一个常见的遗漏场景：某 RAG 应用在压测中只模拟了平均长度的 Prompt，上线后发现，当用户上传长文档进行问答时，系统在中等并发下就开始出现超时——因为长文档的上下文注入使单次请求的 Token 消耗是平均值的 5 倍以上。

请求间隔的真实性：真实用户在等待 LLM 回复时，会有自然的阅读和思考时间，请求间隔通常在 10-60 秒之间。压测中常见的“请求完成即发下一条”模式，会高估系统的并发压力，产生与生产场景不符的性能数据。合理的“思考时间”（Think Time）建模，是让压测数据具有业务参考价值的关键。

场景建模的真实性，直接决定压测结论能否指导生产容量规划。一个与真实负载模式严重偏离的压测，可能让你在错误的方向上过度优化，而对真正的性能风险毫无察觉。

三、从“单点压测”到“全链路拓扑”——LLM 应用的系统性性能风险

大多数 LLM 应用不是一个单一的接口调用，而是一条复杂的处理链路。以 RAG（检索增强生成）架构的应用为例，一次用户提问背后，通常涉及：向量化接口调用、向量数据库检索、上下文拼接与截断、LLM 推理接口调用、流式输出处理、结果过滤与格式化。每个节点都有自己的性能特征，任何一个节点的瓶颈，都可能成为整条链路的天花板。

传统压测迁移的做法，是把 LLM 接口作为唯一的压测目标，确认它能扛住并发就认为性能测试完成。这种“单点压测”的盲区，在生产环境里常常以意想不到的方式暴露：

一个真实场景：某知识问答产品在 LLM 接口压测中表现优异，但上线后发现，在中等并发下响应时间异常缓慢。定位后发现，瓶颈不在 LLM 推理，而在向量数据库——并发查询触发了向量索引的热点竞争，P99 延迟从 50ms 飙升至 2 秒，直接拖垮了整条链路的用户感知响应时间。这个瓶颈在单点压测 LLM 接口时，完全不可见。

LLM 全链路压测体系需要将压测视角从“单个接口”扩展到“完整拓扑”：

链路拓扑梳理：在压测设计阶段，先完整梳理一次用户请求经过的所有服务节点、依赖的外部接口（Embedding 服务、向量库、缓存、网关）以及关键的数据流转路径。这张链路拓扑图，是后续压测设计和瓶颈定位的基础。

各节点独立基准测试：在全链路压测之前，先对各关键节点分别建立性能基准。向量检索在不同并发下的延迟分布、Embedding 接口的吞吐上限、流式传输网关的连接数限制——这些基准数据，让全链路压测中发现的瓶颈能够被快速定位和归因。

端到端全链路施压：模拟真实用户行为，对完整链路施加压力，观察各节点在联合负载下的性能表现。特别需要关注的是级联效应——某节点延迟增加导致上游连接堆积，进而引发雪崩式的性能崩溃。这类问题在单节点测试中不可见，只在全链路联合压测中才能被复现。

熔断与降级验证：在压测中主动模拟关键节点的故障或性能劣化（如 LLM 接口响应变慢、向量库超时），验证系统的熔断机制是否能正确触发，降级策略是否能有效保护整体可用性。这不只是性能测试，也是韧性测试的重要组成部分。

全链路视角的建立，让性能测试从“验证接口能扛多少”升级为“理解系统在压力下的真实行为模式”。

四、从“阈值告警”到“性能基线管理”——LLM 接口的持续性能运营

传统性能测试的运营模式，通常是事件驱动的：大促前压一次，重大版本发布前压一次，出了性能故障之后压一次。每次压测设定通过阈值，达标则通过，上线后的性能状态由监控系统的告警覆盖。

LLM 接口的性能状态，比传统接口更难用静态阈值来描述。模型版本的更新、Prompt 模板的调整、RAG 知识库的扩充、用户输入分布的演变——这些变化都可能在不触发任何告警的情况下，悄然改变接口的性能特征。

传统压测迁移的运营思路，设定 P99 < 5s 的告警阈值，监控没有触发告警，就认为性能状态正常。但一个关键的退化可能被完全忽视：TTFT 在过去两周从 900ms 缓慢爬升到 1800ms，始终低于告警阈值，但用户感知体验已经显著下滑，流失率开始上升。

LLM 全链路压测体系需要建立基于性能基线的趋势管理机制：

• 建立多维性能基线：以 TTFT、TGS、E2E Latency、系统 Token 吞吐量为核心，在不同并发梯度下建立完整的性能基线档案。每次模型更新、架构变更或重大配置调整后，重新跑完整的基线测试，将结果与历史基线对比，任何维度的显著偏离都需要被解释和记录。
• 引入性能回归测试：将一组标准化的压测场景纳入 CI/CD 流水线，在每次重要变更合并后自动执行轻量级性能回归测试。这不是替代完整的压测，而是在快速迭代中建立性能退化的早期预警机制。
• 用户体验指标与性能指标联动分析：将 TTFT、TGS 等技术指标与用户行为数据（首次响应放弃率、会话完成率、功能使用频率）关联分析，建立“性能指标变化→用户体验影响”的量化模型。这让性能优化的优先级排序有了业务价值的依据，而不只是技术直觉。
• 容量规划的动态更新：基于历史流量增长趋势和性能基线数据，定期更新系统容量规划，提前识别“在当前增长速度下，哪个资源维度会在几个月后成为瓶颈”。这将性能工作的视野从“当下能不能扛住”延伸到“未来三到六个月的增长是否可持续”。

持续性能运营的核心价值，是把性能管理从“救火”模式变成“预防”模式。在 LLM 应用快速迭代的背景下，这种主动管理的能力差距，会在每一次峰值事件中以倍数级的代价体现出来。

结语：压测的终点，是对系统边界的清醒认知

压力测试从来不是为了证明系统有多好，而是为了找到它在哪里会失败，以及失败的方式是否可控。

在 LLM 接口压测这个命题上，这个目标变得更加深刻——因为 LLM 系统的失败方式往往不是“崩溃”，而是“退化”：响应越来越慢，质量越来越差，用户在没有任何报错的情况下悄悄离开。这种退化，比崩溃更难被感知，也更难被归因。

几点可执行的建议：

• 从建立 Token 度量体系开始：在任何压测工具和场景设计之前，先确保团队有能力正确采集和分析 TTFT、TGS、TPOT 等 LLM 特有指标。没有正确的度量，所有压测结论都无法信任。
• 用真实的 Prompt 分布替代固定测试数据：从生产日志中提取真实的 Prompt 长度分布和对话轮次分布，以此为基础设计压测负载。如果尚无生产数据，至少要基于业务场景建立合理的分布假设，而不是用固定 Prompt 一刀切。
• 把全链路拓扑梳理作为压测前的必要输入：压测设计团队需要能够画出完整的请求链路图，包括每个节点的技术实现和已知的性能特征。任何未被纳入拓扑的节点，都是性能风险的潜在盲区。
• 将性能基线管理纳入工程文化：推动团队把“变更前后的性能基线对比”作为上线 Checklist 的标准项，就像代码审查和单元测试一样，让它成为工程流程的一部分，而不是偶发的专项活动。

LLM 的性能突围战，打的不是一场短期的压测攻坚战，而是一场需要持续投入的工程能力建设。

理解 LLM 接口的物理本质，建立与之匹配的测试方法论，在快速迭代中维持性能状态的可见性与可控性——这是每一个把 LLM 接口纳入核心链路的技术团队，迟早都必须正面回答的工程命题。

早一天回答，就少一次被用户替你压测的代价。