在实验环境里跑通一个模型并不难，真正困难的是把推理服务稳定地交付给真实用户。F2 Lab 的经验是：性能优化不能只看单次 benchmark， 必须把高峰流量、长尾请求、失败重试和预算约束一起纳入系统设计。
从“快”到“稳”的指标重构
我们将核心目标拆成三组指标：P95/P99 延迟、单位请求成本、成功响应率。单纯降低平均延迟经常掩盖了尾部风险，因此我们在发布评估中优先观察 P99 抖动和错误分布，确保系统在高并发时仍可预测。
队列与降级策略
当请求突增时，最先失效的往往不是模型，而是排队机制。F2 Lab 在网关层做了分级队列：实时交互请求优先，批处理请求延后；当显存和算力逼近阈值时， 系统自动切换到较小模型或低成本路径，以“可用但略降级”的方式维持服务连续性。
可观测性决定恢复速度
我们为推理链路增加了细粒度事件埋点，包括排队耗时、模型加载耗时、解码耗时、重试次数和超时原因。事故发生时，工程师能在几分钟内定位是 GPU 饱和、输入异常还是上游限流问题，从而把恢复时间控制在最小范围。
结论很明确：可靠性不是发布后的补丁，而是推理系统的一等设计目标。未来我们会继续公开 F2 Lab 的调度策略和容量规划方法，让更多团队少踩坑、快迭代。