模型训练速度与资源消耗的取舍模型评估分数提升未必值得立刻部署。训练集、离线评测和线上请求分布并不完全相同模型大小、上下文长度、批处理方式、推理引擎和硬件都会改变延迟与费用。选择方案时应把效果、尾延迟、显存、吞吐、失败率和单位业务成本放到同一份实验记录中而不是只根据一个准确率指标决定。首先定义业务约束。不同服务对响应时间、稳定性和成本的容忍度不同不能将一套固定 SLA 用在所有模型上。离线评估指标也要与业务目标对应并同时报告样本划分、置信区间或重复实验结果非常小的分数差异可能来自随机性未必代表真实收益。用候选集合替代单一最高分多目标优化适合保留一批可行方案在效果更好、延迟更低、成本更小的维度上若一个方案在所有方面都不差且至少一项更好另一个方案才算被支配。Pareto 前沿不是最终选型它只是告诉团队哪些候选值得继续压测、做鲁棒性测试和灰度观察。def dominated(a, b) - bool: no_worse ( b.quality a.quality and b.p99_ms a.p99_ms and b.cost a.cost ) better_once ( b.quality a.quality or b.p99_ms a.p99_ms or b.cost a.cost ) return no_worse and better_once def frontier(candidates): return [a for a in candidates if not any(b is not a and dominated(a, b) for b in candidates)]该计算依赖指标在相同测试条件下得出。延迟至少区分预处理、排队、模型执行和后处理并使用目标硬件与代表性并发成本要包含加速器闲置、服务副本、数据传输与运维而不是只看一次推理的理论算力。模型版本、驱动、编译选项和数据集版本都应随结果保存。优化之后重新验证量化、剪枝、编译或批处理可能降低内存与延迟但也可能改变数值行为、增加首请求开销或只适用于特定硬件。不要预设某种精度格式一定减少多少显存或提升多少吞吐对每个候选在目标引擎和代表性输入上重新测量质量、延迟、错误和资源曲线。上线前先小范围灰度观察实际输入长度、缓存命中、队列等待和用户结果。若成本或错误异常能够回到已验证版本并保留对比数据。最终选型应写明做出的取舍为何接受某个延迟或费用以及在哪些输入范围内结论有效。这样模型训练不再只是追逐离线分数而是为可运行的服务提供可审查的候选方案。训练资源也需要单独管理。数据加载或检查点写入慢时增加 GPU 往往不会提高有效吞吐先记录数据准备时间、设备利用率与同步等待再决定是否调整 batch、并行策略或存储。对多机任务通信开销和失败恢复同样应进入成本比较。实验结束后释放不再使用的加速器并保存可复现配置才能避免把偶然的资源空闲误当成模型本身的效率。对线上推理而言首请求、长尾输入与峰值并发应分别测量不能只使用稳定批处理的平均值。容量计划也应保留安全余量给版本切换、故障迁移和观测开销留下空间。