43 动态负载均衡：当推理节点过载时，如何优雅地转移请求而不丢失配额开篇故事上周三凌晨2点，我正睡得迷迷糊糊，手机突然像被电击一样疯狂震动——PagerDuty告警：生产环境的RT-DETR推理集群中，节点3的GPU温度飙到89°C，推理延迟从15ms暴涨到320ms。更诡异的是，节点3上的请求量并没有增加，但节点1和节点2的负载却降到了30%以下——因为之前的配额管理只做了静态路由，所有免费用户的请求都固定打到节点3上，而节点3的物理散热风扇坏了。我赶紧把节点3从负载均衡池中摘除，结果发现更可怕的事情：那些已经在节点3上消耗了配额的请求，被重新路由到节点1后，配额计数器重置了——免费用户瞬间用光了当天的配额，直接返回403。付费用户也开始报错：“您已消耗了3次推理配额，但实际只成功推理了1次。” 这就是今天我们要解决的问题：当推理节点动态切换时，如何保证配额状态一致且不丢失？痛点拆解常见错误实现：把配额绑定到物理节点很多团队会这样实现配额管理——在本地内存里维护一个node_quota字典：# 错误实现：配额绑定到节点IDnode_quota=