算力与预留
为压低尾部延迟要多留副本，副本在低谷闲置，形成固定支出。为什么矛盾：延迟看高位分位，容量按峰值配。做法：按业务分级设不同目标，非核心业务允许排队；边界是核心交易类业务不能靠排队省成本，需要单独保障。
网络与机房位置
用户与推理节点的距离直接影响首字时间，就近部署会带来多区域资源与流量费用。怎么做：按用户分布选择节点，跨区调用只走必要数据；边界是多区域部署的运维复杂度上升，小规模业务未必划算，先算清运维人力。
缓存与队列
缓存能跳过推理，队列能削峰，两者都影响延迟与成本。为什么放在一起：缓存提高命中会降低算力需求，队列过长则推高等待。做法：为队列设长度上限并配合限流；边界是队列只能平滑波动，不能解决容量不足。
优化工程的投入
量化、蒸馏、推理引擎调参与提示精简都需要工程时间，收益体现在单位请求成本上。怎么做：先做提示与输出长度优化，成本低见效快；边界是量化会带来精度损失，必须用评测集验证后再上线，不能只看跑分。
闲置冗余的取舍
为应对突发而常备的容量，本质是为不确定性付费。为什么值得算清：冗余过少会在高峰崩，过多则长期浪费。做法：用弹性扩容加预热缩短扩容时间；边界是冷启动需要时间，扩容策略要与业务的可接受等待匹配。
适用与不适用
适合谁
- 要为延迟优化申请资源的业务与运维负责人
- 在扩容与降级之间做取舍的技术决策者
- 需要向财务解释单价变化的平台部门
不适合谁
- 调用量很小、延迟波动不影响体验的业务
- 不接受为峰值预留、也不接受排队的核心交易系统
典型场景
某票务平台的智能问询在开票日出现长尾延迟。团队测算后发现，为峰值常备的副本在平日大量闲置，而扩容又来不及。改为平日按基线运行、开票前预热扩容，并把非核心的推荐类请求降级排队，峰值期间的核心问询延迟保持稳定，闲置支出也随之下降。
可执行步骤
- 把延迟目标按业务分级，标出必须保障与允许排队的场景与接口清单
- 测算峰值与平峰的容量差、闲置比例，形成一页可对比的说明材料与图表
- 优化提示词与输出长度，先做成本低、见效快的改造项目清单并排期
- 用评测集验证量化与蒸馏带来的精度损失，再决定上线与否和适用边界
- 设计预热扩容与排队降级策略，明确各自的触发阈值与责任人名单时间
常见坑
- 所有业务都用同一个延迟目标，为低频场景常备容量，长期浪费，投入的资源与成本都收不回来。
- 只加副本而不做容量规划，扩容速度仍赶不上突发流量，峰值时照样排队，闲置成本却先上去了。
- 量化之后未做精度验证，回答质量下降，返工代价远高于节省的算力投入，还可能失去客户信任与续约机会。
- 队列没有设置上限，高峰时请求大量堆积，用户等待时间反而更长，投诉也大多集中在这一时段出现爆发。
自检与验收清单
- 延迟目标是否已经按业务分级，是否留有书面确认记录
- 峰值与平峰的容量差是否测算过，是否已形成留档
- 提示词与输出长度等低成本优化是否已经先行完成
- 量化与蒸馏带来的精度损失，是否已都经过评测验证
- 扩容是否有预热方案，触发阈值与责任人是否都已明确
常见问题
降延迟一定要加卡吗？
不一定。提示精简、输出长度控制、缓存命中与检索条数调整，往往比加卡更快见效且不增加固定成本。加卡解决的是容量不足，先确认瓶颈在排队再投入，否则只是把成本转成闲置。
量化会不会影响质量？
会，幅度取决于模型、任务与量化方式。建议在目标评测集上比较量化前后的通过率与人工接管率，确认可接受后再全量。只用跑分或个例判断风险很大，尤其是需要精确数字与格式的任务。
排队能替代扩容吗？
只能在短时间内平滑波动。队列把请求延后处理，排队长了体验更差，还可能触发超时与重试。真正容量不足时要扩容或降级到小模型，队列只是缓冲，不能当作解决方案。