一、服务器层：词元服务器的3个隐形雷区
1. 设置GPU/NPU的“词元级背压”阈值（可执行建议）：不要等显存OOM才限流。在推理框架（如vLLM、Triton）中配置max_num_batched_tokens，且该值应动态绑定到实时KV Cache利用率，而非固定值。本周某事故正是因静态配置导致缓存穿透，引发连锁重试风暴。
2. 强制启用“慢词元熔断”：为每个推理实例增加token_generation_time_ms的滑动窗口监控（窗口60s，阈值=均值+3σ）。一旦触发，立即摘除该实例的LVS权重，并预热备用实例——记住，AI服务的故障不是“无响应”，而是“响应极慢但不断连”，常规健康检查抓不到。
3. 物理机散热与降频预案：IDC夏季高温叠加AI满载，本周某机房因温控失效导致CPU降频20%。请将coretemp或nvml_temperature指标接入告警，且每台服务器预留10%的电力冗余用于突发降频补偿。若机柜PDU功率已超80%，立即人工疏散离线训练任务。
二、网络层：带宽与拥塞的4个速效策略
4. 给“词元转发”打上DSCP标签（关键动作）：在交换机入口处，将AI推理流量（目标端口如8000-8005）标记为EF（加速转发），其余训练流量标记为AF31。同时，在核心路由器配置PQ队列（严格优先），确保词元包永不排队。实测可降低90%的抖动，但需注意：不要将所有流量都打EF，否则QoS形同虚设。
5. 启用ECMP的“逐流+逐包”混合哈希：默认哈希容易让长尾词元请求集中到某一条物理链路上。升级到支持自适应哈希的固件，并开启flowlet模式（超时阈值设为100μs），可让带宽利用率从40%提升至85%。本周复盘发现，某链路拥塞竟是因哈希极化导致。
6. 部署“带宽预清理”定时任务：在每天业务低峰（如03:00），自动执行一次iperf3全链路压测（双向打满90%带宽持续5分钟），将日志对比基线。若丢包率>0.1%或重传率>2%，则预判次日高峰会拥塞，提前调整流量路径或购买临时带宽。此动作成本极低，但能避免周一早上10点的“惊喜”。
7. 为IDC出口配置“同步洪峰抑制”：当某机柜带宽超过交换机端口能力的70%且持续30秒，自动触发tail-drop保护，优先丢弃低优先级（如日志、监控）包。同时，利用BGP Flowspec向上游通告：对目的IP为AI网关的流量，限速至承诺带宽的90%，防止单一租户打爆出口。
三、软件与流程：复盘后必做的3项固化
（补充）除了硬技术，请在本周内完成：① 将本次事故的应急手册压缩为一页纸“Runbook卡”，贴在工位；② 在告警平台为“AI服务延迟”单独创建路由，禁止合并到普通web告警；③ 安排下周三进行混沌演练：随机拔掉一条机柜级汇聚链路，检验ECMP切换是否真的在30秒内完成。记住，SRE的职责不是预测故障，而是让故障发生后的恢复时间小于用户容忍度。
0 留言