上线新模型或新配置时，最怕的不是慢，而是全量一推就出问题再紧急回滚。我们的灰度发布流程分五步，核心是先小流量验证，再逐步放大，每一步都有放行条件和回滚触发点。
一、先定基线再灰度。灰度前先跑通同一批业务用例，记录首 token 延迟、延迟分位、错误率和拒绝率。没有基线，灰度数据好看还是难看都无法判断，放行只能凭感觉。
二、流量分桶要稳定。按用户或请求标识做一致性分桶，保证同一用户在灰度期间始终落在同一版本。先放 5%，观察至少一个业务高峰，确认无异常再放 25%、50%，不要一次跳到全量。
三、放行看三组指标。正确性看业务用例回归和关键字段一致率；稳定性看错误率和超时率的分位变化；成本看单请求 token 消耗和并发占用。任何一组明显恶化都先停放量，查清原因再继续。
四、回滚要提前演练。触发条件写进发布清单，例如错误率连续上升、关键用例回归失败、延迟分位超阈值。回滚路径要一键可达，旧版本和旧配置保留到灰度结束后再清理，回滚本身也要进监控，避免长期跑在降级状态没人发现。
五、灰度结束再复盘。把各阶段指标对照表留档，说明放量节奏、异常处理和最终决策依据，下次发布直接复用同一清单。
这套流程最大的收益，是把上线风险拆成可控的小步。你们团队灰度发布时，放量节奏一般怎么定？回滚触发条件是写死的阈值，还是靠值班人工判断？