一个 AI 应用从几十名测试用户扩展到数万人时，最先出现的问题往往不是模型答错，而是请求排队、首字等待变长、显存被长上下文占满，某台机器故障后大量会话同时重试。
横向扩展的基本想法是增加更多服务实例分担负载。但大模型推理具有显存高、输出长度不确定、缓存随会话增长等特点，不能照搬普通 Web 服务“多开几台”的经验。
## 先画清一条请求经过哪些层
典型链路包括入口网关、鉴权与限流、请求队列、模型路由、推理副本、外部工具，以及流式结果返回。检索、重排和内容处理也可能拥有独立服务。
每一层的扩展单位不同。网关通常无状态，容易增加副本；向量检索受索引和存储影响；大模型副本受 GPU 数量、显存和模型加载时间限制；外部工具则可能有自己的并发上限。
先记录每层的到达率、服务时间、排队长度和失败方式，才能知道扩容应该发生在哪里。只增加模型 GPU，若瓶颈在数据库连接或工具接口，延迟不会改善。
## 副本扩展与模型并行不是一回事
如果一个模型能放进单张 GPU，可以启动多个相同副本，各自处理不同请求，这是真正的横向复制。优点是故障隔离清楚，也容易按流量增减。
如果模型太大，需要张量并行或流水线并行，让一次推理跨多张 GPU。它解决的是单个模型放不下的问题，却会增加设备间通信。一个多卡副本仍然只是一组调度单元。
实践中常把两者组合：每个副本占若干 GPU，再运行多个副本。拓扑应考虑同一机器、机架和网络互联，避免把通信密集的模型分片跨到慢链路上。
## 连续批处理提高GPU利用率
传统静态批处理要等一批请求全部生成完再换下一批。不同用户输出长度差异很大，短请求完成后留下的计算位置会被浪费。
连续批处理允许新请求在旧请求完成时动态加入。vLLM 等推理引擎还通过 PagedAttention 管理注意力所需的 KV 缓存，把不连续的显存块更灵活地分配给不同序列。
批处理不是越大越好。更大的批次能提高吞吐，却可能让单个请求等待更久。面向交互产品，要同时观察首 token 时间、token 间延迟和总完成时间，而不是只追求每秒 token 总数。
## 队列与背压决定高峰期是否稳定
当请求到达速度持续高于处理速度，任何系统都会积压。没有边界的队列会让用户等待数分钟，并占用大量内存；超时后集体重试，还会放大拥堵。
背压策略要在入口处限制并发、设置队列上限和超时，按用户或任务等级公平调度。对于可以异步完成的长任务，可返回任务状态；对交互请求，则应尽早给出清晰的繁忙反馈。
调度器还可以根据预计 token 数区分长短请求，避免少量超长生成阻塞所有短请求。估计不可能完全准确，因此要在运行中更新预算，并限制异常输出长度。
## 自动扩缩容要看真正领先的指标
CPU利用率对 GPU 推理不一定敏感。更有价值的指标包括等待队列长度、并发序列数、首 token 延迟、GPU KV 缓存占用，以及单位时间输入和输出 token。
Kubernetes 的水平 Pod 自动扩缩容可以根据资源或自定义指标调整副本数。但模型加载可能需要数分钟，扩容命令发出后不会立刻增加容量。系统要预热模型、保留适量余量，并根据流量周期提前扩容。
缩容同样要谨慎。正在流式输出的副本应先停止接收新请求，等待现有会话排空，再释放资源。直接终止会让用户在回答中途断线。
## 模型路由可以减少不必要的昂贵推理
并非所有请求都需要最大模型。简单分类、格式转换和检索重排可以交给较小模型；复杂推理再路由到能力更强的模型。
路由依据可以是任务类型、输入长度、质量要求和实时负载。它必须用真实任务评测，避免为了节省成本把困难请求错误分流。还要准备回退路径：某个模型池不可用时，是降级、排队，还是明确失败。
Ray Serve LLM 提供模型复用、路由和多种并行部署模式，可以把多个模型与预处理、后处理组合成服务图。无论使用哪种框架，关键是让路由决策、模型版本和性能指标可观察。
## 把预填充与解码当作不同工作负载
大模型推理大致分为预填充和解码。预填充处理整段输入，计算密集；解码逐 token 生成，受内存带宽和 KV 缓存影响更明显。
在长上下文和高并发场景中，可以把两阶段放到不同资源池，分别扩展。这种解耦能减少相互干扰，但会增加缓存传输和调度复杂度。只有当监控证明确有瓶颈时，才值得引入。
## 可靠性要以故障域设计
多个副本如果都依赖同一节点、同一存储或同一网关，数量再多也不等于高可用。副本应分散在不同节点和可用区，健康检查要区分“进程存活”与“模型真的能生成”。
部署新版本可采用金丝雀流量，先让少量请求进入新池，比较质量、延迟和显存行为。出现异常时，路由应能迅速回到旧版本，而不重新加载整个集群。
压力测试需要模拟真实输入长度、输出分布、流式连接和突发峰值。平均请求会低估长尾显存占用；短时间压测也看不到缓存碎片、模型加载和节点故障后的连锁反应。
AI设计横向扩展策略的核心，不是简单回答“需要几张卡”，而是让请求、队列、缓存、路由和副本形成可测量的系统。先守住延迟与失败边界，再提高吞吐；先证明瓶颈，再增加复杂架构，扩展才会真正转化为稳定体验。
## 参考资料