报错是这么冒出来的。自研模型网关按权重灰度两个上游，配置里新模型权重 10，压测五分钟统计新模型承接了 60% 的请求，重启后比例又变了。
中间走过弯路，把「重试把失败请求又打到新模型，放大了占比」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。权重是按上游实例数分摊的，新模型实例多算出来就偏。另一种情况是一致性哈希的虚拟节点没有按权重设置。
不容易想到的是，配置热更新时旧路由未清，两份权重叠加。
动手时先按上游分别统计实际请求数
python -c "import collections;print(collections.Counter(open('access.log').read().split()))"再往下打印路由表里每个后端的权重与实例数
curl -s http://gateway/admin/routes | jq '.routes[]|{backend,weight,instances}'然后改成按权重分配虚拟节点并重载
curl -X POST http://gateway/admin/reload -d '{"mode":"weighted"}'等前面都确认过，再重跑一轮对比实际比例与配置比例
python probe.py --n 5000 --by backend别只看报错消失，验证要多做一步。实际比例与配置权重的偏差控制在两个百分点内，多次重载结果稳定，重试流量不再集中到新模型。
容易忽略的是，权重只在同一层生效，实例数、虚拟节点、重试策略三层里任何一层单独加权都会把比例带偏。这类问题最好一次改到位，反复小改反而容易把原因搅混。