自托管大模型 API 怎么测：vLLM 的吞吐、显存、批处理和隔离别只看 QPS

自托管模型常被宣传为“更便宜、更可控”，但生产上游并不是把权重加载成功就结束。不同长度的请求如何排队、连续批处理是否拖慢交互请求、显存接近上限时会发生什么、模型重启后如何恢复，都需要在 API 层验证。

单请求跑分快不等于服务稳定

至少同时测试短问答、长上下文、流式输出、工具调用格式和批量任务。记录首 token 时间、每秒 token、总完成时间、P95/P99、显存占用和拒绝率。把请求混合在一起压测，才能看出长任务是否吞掉了短请求的延迟预算。

vLLM 这类高吞吐推理服务强调内存效率和批处理，但参数配置、模型量化、GPU 类型和上下文长度都会改变结果。不要把别人的 benchmark 直接套到自己的业务；同一个模型在不同提示长度、并发和输出上限下可能表现差异很大。

认证与租户边界不能省略

自托管端点仍需要 API Key、请求限额、模型白名单、审计和网络隔离。没有这些边界，内部推理服务很容易成为共享 GPU 的匿名入口。对多租户业务，还要验证缓存、队列、错误信息和 metrics 是否泄露其他项目的模型名称或使用量。

可用性测试应包括 GPU 驱动异常、模型加载失败、实例滚动重启、请求取消和容量耗尽。对于无法立即恢复的模型，应让网关返回清晰的可重试状态或切换到经过批准的替代上游。

top-api.cc 可以将自托管和托管模型放在统一调用面，便于记录路由、成本和回退；但是否启用回退、哪些数据可离开自托管环境，应由业务策略明确决定。

测试指标

• 首 token、吞吐和 P95/P99 延迟；
• 不同上下文长度和并发下的显存曲线；
• 排队、拒绝和取消的错误语义；
• 模型重启、扩缩容和配置变更恢复时间；
• API 认证、租户隔离和指标脱敏；
• 每个可用 token 的基础设施成本。

参考资料：vLLM 项目与 GPU 推理服务文档。性能结论需要标注 GPU、量化、模型快照、上下文上限和压测负载。

把自托管服务接到 top-api.cc 后，建议持续比较真实业务延迟与基准结果，防止只在实验环境中表现良好。