标准回答
第一步：定约束（SLO 优先）
先问清业务对三者的优先级——这是决策的前提。实时搜索/广告对延迟敏感（P99 < 100ms 是硬约束），离线批处理则更看成本。把延迟上限、成本预算、精度下限写成明确的 SLO，权衡才有标尺。
第二步：换延迟与成本的工程手段
在满足精度下限的前提下，逐项压成本与延迟：
- 更小模型 / 蒸馏：用大模型产出标签训练小模型，精度损失小而延迟成本大降；
- 量化：FP16 → INT8/INT4，显存与延迟显著下降，配合校准控制精度损失；
- 缓存：高频请求做语义缓存，生成场景复用 KV Cache；
- 批处理 / 连续批处理：提升吞吐、摊薄单请求成本。
第三步：级联（cascade）
让大多数「易例」走便宜的小模型，只有低置信度的「难例」才升级到大模型。这样平均延迟和成本由小模型决定，整体精度由级联兜底，是性价比最高的结构。
第四步：A/B 量化收益
每项优化都通过 A/B 测试验证：对比精度、P99 延迟、单位成本和核心业务指标，确认净收益为正再全量上线，并持续监控线上回退。
常见误区
⚠️ 常见踩坑
不先定 SLO 就盲目追求最高精度，往往换来不可接受的延迟和成本；以及只看离线精度，忽略量化/蒸馏后线上真实延迟与业务指标的变化，必须用 A/B 验证净收益。
追问
追问 1：级联（小模型+大模型）方案如何决定何时升级到大模型？
常用做法是基于小模型的置信度或不确定性设阈值：高置信度直接返回小模型结果，低置信度才路由到大模型。阈值通过离线数据扫描确定——在「升级比例」和「整体精度」之间找平衡点，比如让 80% 流量留在小模型、20% 难例升级，既保住精度又控制成本。也可以训练一个轻量路由器来判断难易。
追问 2：量化会损失精度，如何评估能不能接受？
追问 3：延迟和吞吐量优化目标冲突时怎么办？
批处理能提升吞吐但会增加单请求排队延迟，两者本质是吞吐-延迟的权衡。做法是根据 SLO 设定最大批大小和最长等待窗口：延迟敏感场景用小批量/连续批处理（请求一到就处理，不等满批），成本敏感的离线场景用大批量。本质是用延迟预算去换吞吐，预算由业务约束给定。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。