模型 Serving 到底解决什么问题，从单机推理服务到集群化部署完整分析

一个训练完成的模型，如果只能停留在训练脚本或者一个Python进程里，它还不能算一个完整的线上AI服务。业务系统真正需要的是一个能够持续接收请求、执行推理、返回结果，并且能够处理并发、超时、监控、版本切换、资源调度和故障恢复的服务系统。模型Serving解决的就是这一层问题。

因此，Model Serving不能简单理解成“把模型包装成一个API”。API只是最容易看到的外壳，里面还包含模型加载、请求队列、批处理、GPU资源管理、并发控制、模型版本、健康检查、指标监控以及错误处理等一整套运行机制。对于大型语言模型，还要进一步处理KV Cache、Prefill、Decode、Continuous Batching、流式输出以及GPU显存管理等问题。

最简单的Serving系统其实并不复杂。一台服务器、一张GPU、一个模型进程，再加上HTTP或gRPC接口，就可以构成最基本的推理服务。客户端发送输入，服务器执行模型前向计算，再返回预测结果。如果模型较小、请求量有限，这种架构完全可能运行得很好。

例如，一个图像分类模型可能只需要加载一次，然后不断接受图片请求。模型参数长期驻留在GPU显存中，CPU负责网络和请求处理，GPU负责推理计算。此时Serving系统最重要的问题并不是“怎样把模型拆到100张GPU上”，而是怎样避免每个请求都重新加载模型，怎样控制并发，怎样让GPU保持合理利用率，以及发生异常时怎样自动恢复。

随着请求量增加，第一个问题通常是并发。

假设单次推理需要10毫秒，理论上连续处理请求可以达到较高吞吐量，但现实中的请求不会整齐地排队到达。有的请求在这一毫秒进入，有的请求几十毫秒后进入，有的输入尺寸更大，有的执行时间更长。如果每个请求都独占一次GPU执行过程，GPU可能出现大量空闲间隙。

因此，现代Serving系统通常会引入动态批处理。Triton Inference Server提供Dynamic Batching，可以在满足延迟约束的情况下，把多个请求组合起来交给GPU执行。对于大语言模型，vLLM、TensorRT-LLM等系统进一步采用Continuous Batching，也就是在生成过程的迭代级别动态调度请求，使新请求能够加入正在运行的请求集合，而不必等整个静态batch全部结束。

这时候Serving系统已经不只是“调用模型函数”，而是在管理一台计算机上的计算资源。

GPU显存也是另一个核心限制。模型参数需要占用显存，运行时还需要保存激活值、临时workspace以及其他数据结构。对于LLM，KV Cache通常还会随着并发请求数量和上下文长度增长。于是，一个模型即使参数本身能够塞进GPU，也不意味着这张GPU能够无限增加并发请求。

这也是为什么模型Serving必须同时关注吞吐量和延迟。单纯追求QPS可能导致请求在队列里等待，TTFT，也就是Time to First Token，可能明显增加；过度追求低延迟，又可能导致GPU批处理规模过小，计算资源没有充分利用。线上系统通常需要在吞吐量、TTFT、Inter-token Latency以及整体端到端延迟之间寻找合适的平衡。

当一张GPU装不下模型时，问题就从“如何高效使用一张卡”进入了“如何使用多张卡”。

最直接的方法是模型并行。对于Transformer等大型模型，可以把模型参数和计算过程拆分到多张GPU上。例如张量并行可以把某些矩阵运算分布到多个GPU；流水线并行则可以把不同模型层分配到不同GPU阶段。对于MoE模型，还可能使用专家并行，让不同专家分布到不同计算设备。

但多GPU并不意味着性能一定线性增加。

原因很简单：GPU之间需要通信。一个模型层计算完成后，如果下一阶段所需的数据位于另一张GPU，就必须通过GPU互联或PCIe等链路传输。单机多GPU系统可以利用NVLink、NVSwitch等高速互联降低通信成本，而跨服务器部署则可能需要InfiniBand或具备RDMA能力的以太网网络。

这时通信拓扑就会直接影响Serving性能。两张GPU之间如果拥有高速互联，通信开销可能与跨服务器传输完全不同。跨节点模型并行还需要考虑网络带宽、通信延迟、拓扑结构、collective communication以及计算和通信是否能够重叠。

NCCL就是这类系统中的重要基础组件。它针对GPU间通信提供AllReduce、AllGather、ReduceScatter、Broadcast等集合通信操作，并能够利用不同硬件互联方式完成通信。对于分布式推理，模型并行策略和通信库之间的配合会直接影响实际性能。

不过，集群Serving还有另外一种完全不同的扩展方式：复制模型。

如果一个模型能够完整放进一张GPU，而且单卡性能不足以满足业务需求，那么没有必要为了“集群化”强行进行模型切分。可以在多台服务器或者多张GPU上运行多个模型副本，再通过负载均衡把请求分发到不同实例。这属于更典型的横向扩展。

这种架构的优势是简单。每个GPU都有完整模型，节点之间通常不需要为了单个请求进行模型层级的同步通信。请求只需要被分发到某个健康实例即可。对于中小型模型和大量独立请求，这往往比复杂的模型并行更加容易扩展。

所以，“集群部署”并不等于“模型分片”。两者是不同问题。模型太大，单卡放不下，才需要考虑模型并行；模型放得下但请求量太大，则可以优先考虑模型副本、负载均衡和自动扩缩容。实际生产环境甚至可能同时使用这两种方式。

Kubernetes在这里承担的主要任务也不是“运行模型”。Kubernetes负责容器编排、节点调度、健康检查、服务发现以及扩缩容等基础设施工作。GPU通常通过设备插件和相关GPU管理组件暴露给容器，应用层的Serving框架则负责模型加载和推理执行。

这意味着一个成熟的AI推理集群实际上存在多个层次。最底层是GPU、CPU、HBM、PCIe以及GPU互联网络；再往上是CUDA、ROCm、NCCL等运行时和通信组件；然后是TensorRT、PyTorch、vLLM、Triton等推理软件；再往上才是API网关、服务发现、负载均衡、监控、日志和业务系统。

每一层都有自己的瓶颈。

GPU利用率低，并不一定说明GPU不够多，也可能是请求批量太小、CPU准备数据太慢、数据拷贝频繁、KV Cache不足或者调度策略不合理。GPU利用率很高，也不意味着系统性能一定很好，因为请求可能已经在队列中等待很长时间。

显存占满同样不能直接判断系统已经达到最佳状态。对于LLM，KV Cache占用比例、上下文长度和并发请求数量都会影响显存布局。如果参数量化以后释放了大量显存，这些空间可以进一步用于KV Cache和更高并发，而不只是简单地“省了显存”。

模型量化也是Serving优化中的重要技术。FP16、BF16、FP8、INT8、INT4等不同表示方式可以降低模型权重或者部分计算的数据精度，从而减少显存占用和内存带宽压力，并在硬件和软件支持的情况下提高计算吞吐量。但量化并不是无条件加速。不同模型、硬件、kernel和batch规模下，收益差别很大，过度量化还可能造成模型精度下降。

KV Cache则解决另一类问题。在自回归语言模型生成文本时，已经计算过的历史token对应的Key和Value可以保存下来，后续生成不必重新计算所有历史token。这种缓存机制能够显著改变长上下文、多轮对话和高并发Serving的性能特征，但代价是需要持续消耗显存。因此，生产系统必须在上下文长度、并发数量和KV Cache容量之间做资源规划。

模型Serving还必须解决版本管理问题。线上模型不会永远只有一个版本。新模型上线后，系统可能需要进行灰度发布、A/B测试或者快速回滚。如果模型文件、依赖库、GPU运行时和配置全部混在一起，那么模型升级本身就可能变成一次系统级故障。

因此，生产环境通常需要把模型版本、Serving镜像、配置和基础设施配置进行明确管理。监控系统则需要记录请求数量、错误率、延迟、GPU利用率、显存占用、队列长度以及模型相关指标。对于LLM，还应该关注TTFT、token吞吐量、每token延迟、KV Cache使用率和请求长度分布。

自动扩缩容也是集群Serving的重要组成部分。当请求量持续增加时，可以增加模型副本；流量下降后则减少实例，从而降低闲置GPU成本。但GPU扩缩容不像普通Web服务器那么简单，因为加载模型本身可能需要较长时间，模型文件可能很大，GPU实例成本也远高于普通CPU容器。因此，扩缩容策略需要结合启动时间、模型加载时间、节点容量和预测流量进行设计。

到了大规模平台阶段，Serving实际上已经逐渐变成一个独立的基础设施系统。业务开发者只需要提交模型版本和推理配置，平台负责选择GPU、部署副本、建立服务入口、执行健康检查、监控性能以及处理扩缩容。这也是MLOps体系与普通Web部署之间的重要交叉点。

从单机Python推理脚本发展到大型GPU集群，并不是简单地不断增加服务器数量，而是问题本身发生了变化。单机阶段主要关注模型加载、GPU利用率、请求并发和延迟；多GPU阶段开始关注模型并行和GPU通信；多节点阶段又加入网络拓扑、调度、故障恢复和资源隔离；大规模生产阶段则需要进一步考虑版本管理、自动扩缩容、成本控制和可观测性。

因此，Model Serving真正解决的是模型从“能够计算”走向“能够稳定提供计算能力”的工程问题。一个训练好的模型只是AI系统的核心算法资产，Serving则负责把这个资产变成业务能够持续调用的基础设施。小模型可以是一台服务器上的一个进程，大模型可以扩展到多GPU甚至多节点集群，但无论规模如何变化，核心目标始终围绕几个指标展开：请求能否及时得到响应，计算资源是否被有效利用，系统能否随着流量增长而扩展，以及出现故障时能否控制影响范围。

理解这一点之后，模型Serving就不再只是一个“模型API服务器”的概念，而会被看成连接模型、GPU、网络、调度系统和业务应用的一整层基础设施。这也是为什么当AI应用从实验室走向生产环境之后，模型本身往往只是问题的一部分，而如何把模型稳定、经济、高效地运行起来，才逐渐成为整个系统工程的核心。