预算有限，先别急着换硬件或重写服务。模型推理延迟优化策略应从总成本出发：同样的请求量，既要看计算资源花费，也要算内存、排队、延迟目标和后续维护。以下五项可以按顺序评估，适用于文本生成、分类等不同推理服务。
1. 计算资源：每个请求实际占用多少算力
先记录一段代表性流量中的请求数、输入与输出 token 数、设备运行时间和资源利用率。若按云实例时长付费，可估算单位请求成本；若使用自有机器，则把购置、折旧和电力纳入比较。低利用率可能意味着资源闲置，高利用率也不一定理想：突发流量时，排队可能拉高延迟。
评测时固定模型、软件版本和请求样本，对比 CPU 与加速器等部署方式。不要只比较单次耗时，也要观察单位时间完成的请求数，即吞吐量。模型推理延迟优化策略的第一步，是确认瓶颈是否真的在计算，而非先假设算力不足。
2. 内存成本：容量和带宽都要看
模型权重只是内存占用的一部分；运行时缓冲区、并发请求状态以及缓存也会占用空间。内存不足会造成任务无法并行或频繁搬运数据；内存带宽受限时，单纯增加计算资源未必缩短耗时。
记录峰值显存占用（使用 GPU 时）或系统内存占用，并在目标并发度下复测。若请求状态缓存占比高，可先调整最大并发和缓存策略，观察容量、延迟是否同步改善。缓存命中率只有在存在重复前缀或可复用计算时才有参考价值，不应为了提高指标而保留无用数据。
3. 并发与服务开销：吞吐量不是越高越好
并发度增加，通常能提高设备利用率，但也可能加重排队、占用更多内存。批处理有机会摊薄调度开销，却可能让较早到达的请求等待其他请求。适用与否取决于流量是否稳定，以及服务能容忍多长等待。
用真实请求分布建立测试集，依次测试并发度 1、2、4、8 等档位；每档先预热，再持续运行约 10 至 30 分钟，记录吞吐量、平均延迟和 P95 延迟。这个时长是测试安排建议，不代表固定标准；小规模服务可缩短，大流量或资源波动明显时应延长。若吞吐量增加但 P95 明显恶化，就不宜只按吞吐量选配置。
4. 延迟目标：为服务要求付出的成本
先明确业务真正关心的是首个结果返回速度，还是完整响应时间，并设定可接受的延迟区间。交互式问答通常更在意等待体验；离线批量任务则可能更看重总处理时间。二者目标不同，优化方向也不同。
把延迟拆成排队、模型计算和网络传输几部分。可用服务日志或 OpenTelemetry 追踪请求时间线；若时间主要花在排队，增加计算资源或调整并发限制可能有效；若模型计算占主导，再测试模型精简或推理实现改动。没有明确服务目标时，容易花钱压低并不重要的延迟。
5. 工程与维护：一次提速是否值得长期承担
更换推理框架、编译模型或改动数值精度，都可能带来适配、回归测试和部署维护工作。应比较上线前后的实际收益，并检查输出质量、异常恢复和升级难度。复杂方案若只在少数请求上占优，却增加大量维护负担，整体未必省钱。
可以按以下步骤收敛选择：
- 固定模型版本、硬件、软件配置和代表性请求集。
- 记录基线：单位时间请求量、延迟分位数、内存峰值和资源费用。
- 每次只改一个因素，例如并发度、缓存配置或推理实现。
- 在相同负载下复测，并检查输出质量与错误率。
- 按月或按任务量核算节省的资源成本，再减去开发和维护成本。
常见问题
预算有限，应该先加机器吗？
不一定。先确认是计算不足、内存受限还是排队过长；若资源利用率低，加机器可能只会增加闲置成本。
优化时只看平均延迟可以吗？
不够。平均值会掩盖慢请求，至少同时观察 P95 延迟和吞吐量，并使用接近真实的流量测试。
什么时候值得做模型或框架改造？
当基线测试确认计算路径占主要耗时，且改造在质量、稳定性测试中通过，收益又能覆盖维护成本时再做。最终，模型推理延迟优化策略应以可复现的成本对比为依据，而不是单看某项跑分。
