用途：测量服务在负载上升时的表现，包括延迟或错误何时开始上升、仍满足延迟预算的最高负载，以及结果未覆盖的范围。最终产出可被他人重跑对比的结果记录，或仅在设计请求下给出测试计划。负载测试回答容量问题，除响应有效性外不评价输出质量。
主要能力：先建立工作负载模型，包括输入长度分布（模型服务按 token 计）、输出长度、请求类型与占比、到达模式（平稳、突发、日峰值）及来源；短输入与长输入常在不同速率饱和，应分别单独测并测混合。区分开环与闭环负载：闭环固定虚拟用户数，服务器变慢时发送减少；开环按计划发送（如泊松到达），队列会堆积。注意协调遗漏，应从预期发送时间测量延迟，并比较实际发送速率与目标速率。用 Little 定律换算并发与 RPS。分步提升到达率或并发，先粗后细，在拐点附近加密，每步保持到延迟与队列深度稳定，丢弃预热与步间过渡。饱和点是延迟百分位或错误上升而成功吞吐不再增长之处；仅在授权范围内可做压力测试或数小时浸泡测试。每步报告目标与实测发送速率、成功吞吐（含输出 token/秒）、p50/p95/p99 与最大值、流式首 token 时间与每 token 时间、按类型错误率、资源使用。只把有效成功响应计入吞吐，超时计为错误，禁用或统计重试。百分位不可跨步平均，应合并原始样本。先声明延迟预算（百分位、阈值、错误上限），运行点取满足预算的最高负载，建议规划值低于它。结论前先排查生成器、网络与前置组件、服务器三处限制。结果绑定环境，记录硬件、引擎与版本、模型修订、量化、批与并发设置、副本数、代码修订、生成器工具与版本。
使用方式：只对用户拥有或运营的系统施压；共享环境与生产需明确授权并约定最大速率或并发、时长、时间窗、中止条件与通知对象。第三方 API 不是负载测试目标。设计或解读请求只返回结论；实际施压需用户请求，已授权环境内可先做低速率冒烟。优先使用项目已有负载生成器，否则可选 k6、Locust、vegeta、wrk2、引擎自带基准客户端或小型异步脚本。负载脚本是测量工具，随结果记录保存，除非用户要求否则不并入测试套件。结果记录应含问题与决策、环境、工作负载模型、方法、步表、饱和点与运行点、生成器与网络检查、结论边界及脚本与原始数据。
适用场景：容量规划、延迟预算验证、不同服务配置在相同负载下的对比（每次只改一个设置）。
限制：不负责诊断变慢原因（属 bug-diagnosis）、不评价模型质量（属评估类技能）、不用于选择模型或量化（属 ml-experiment）。评估运行记录的吞吐与延迟不是容量证据。资料未提供具体安装命令、价格或平台支持信息。