多实例负载均衡
把请求分发到多个推理实例，是纵向扩容之外最直接的手段。反向代理层用 upstream 声明实例列表并启用长连接复用；短请求轮询分发即可，流式长连接场景则要关注连接在各实例上的分布，而不是单次请求是否均匀。
基本信息
| 位置 | 反向代理的 upstream |
|---|---|
| 实例列表 | 逐个声明并启用探活 |
| 连接复用 | keepalive 减少握手开销 |
| 短请求 | 轮询分发即可 |
| 流式场景 | 关注连接分布与粘性 |
典型使用场景
- 单实例不够用时的水平扩容
- 实例滚动重启时的平滑摘除与回切
- 把不同规格的机器编入同一组
- 为灰度发布准备两套上游
- 扩容后重新标定整体限流与容量基线
- 让上游列表与实例清单保持一致，避免漏加或漏删
upstream 片段
upstream 片段
upstream llm {
server 127.0.0.1:8000;
server 127.0.0.1:8001;
keepalive 32;
}
location /v1/ { proxy_pass http://llm; }
# 实例状态变化时先改 upstream 再重载，避免新建连接打到正在重启的实例按场景选分发
| 场景 | 分发方式 | 注意 |
|---|---|---|
| 短请求 | 轮询 | 关注整体均衡 |
| 流式长连接 | 按连接分配 | 连接分布比请求分布更重要 |
| 滚动重启 | 先摘再停 | 需要提前设置等待上限 |
实例之间无共享状态时任意转发即可；跨实例重试要求请求可以完整重放，幂等键是前提。
探针要接到实例的真实存活状态：只有健康检查配好了，摘除与回切才是自动的，否则只能靠人工改配置。
实例规格不同时不要简单轮询：处理能力弱的机器会成为长尾来源，可以按权重分配流量。
改完上游列表要先做一次连通性确认：直接放量的话，新实例的配置错误会立刻暴露给用户。
实例清单与监控标签保持一致：否则按实例定位问题时，会对不上是哪一台机器。