2、大模型部署基础：大模型推理服务的基本架构、常见部署方式（在线/离线）、性能瓶颈概述

大模型从训练完成到真正对外提供服务，中间隔着一条名为"部署"的鸿沟。许多团队在模型效果上投入了大量精力，却在部署环节遭遇推理延迟高、吞吐不足、显存溢出、成本失控等问题。要理解API网关在大模型场景下的优化价值，首先必须厘清推理服务的基本架构、部署方式与性能瓶颈。本章将围绕这三个核心问题展开，为后续网关优化策略建立技术坐标系。

2.1 大模型推理服务的基本架构

大模型推理服务与传统Web服务在架构上有本质差异。传统服务通常是"短请求-短响应"模式，而大模型推理是"长请求-流式响应"模式，且每个请求的算力消耗差异巨大。理解这一差异是设计网关策略的前提。

2.1.1 核心架构分层

一个完整的大模型推理服务架构通常包含四个层次：接入层（负责协议转换、鉴权、限流）、调度层（负责请求排队、批处理策略、GPU资源分配）、推理引擎层（负责模型加载、推理计算、KV Cache管理）、模型与硬件层（GPU/CPU/内存资源池）。API网关位于接入层与调度层之间，承担着流量治理的关键职责。

架构层次	核心组件	主要职责	性能敏感点
接入层	API网关、负载均衡	协议转换、鉴权、限流、路由	连接数、转发延迟
调度层	请求队列、批处理调度器	动态批处理、优先级调度、超时管理	排队延迟、批大小
推理引擎层	vLLM、TensorRT-LLM、Triton	模型推理、KV Cache管理、连续批处理	显存带宽、计算效率
模型与硬件层	GPU（A100/H100）、CPU、内存	参数存储、矩阵计算、数据搬运	显存容量、算力利用率

2.1.2 Prefill与Decode两阶段模型

大模型推理的核心特征是两阶段生成。Prefill阶段处理输入Token，并行计算所有输入的注意力分数，属于计算密集型操作；Decode阶段逐Token生成输出，每一步只计算一个Token，属于显存带宽密集型操作。这种不对称性导致推理服务的性能模型远比传统服务复杂。一个请求的延迟由"首Token延迟"（Prefill时间）和"Token间延迟"（Decode时间）共同决定，网关的超时设置、流式响应策略都必须基于这一模型设计。

2.2 常见部署方式：在线推理与离线批处理

根据业务对延迟和吞吐的不同要求，大模型部署分为在线推理和离线批处理两大模式。两种模式在架构设计、资源调度、网关策略上存在显著差异。

2.2.1 在线推理部署

在线推理面向实时交互场景，如智能客服、代码助手、对话机器人。核心要求是低延迟（通常要求首Token延迟小于500ms）和高并发（支持数百甚至数千并发连接）。在线部署通常采用以下技术组合：

• 推理引擎：vLLM（PagedAttention）、TensorRT-LLM（NVIDIA优化）、SGLang（RadixAttention）等，这些引擎通过连续批处理（Continuous Batching）提升GPU利用率。
• 模型并行：当单卡显存不足时，采用张量并行（Tensor Parallelism）或流水线并行（Pipeline Parallelism）将模型分布到多张GPU上。
• 动态伸缩：基于GPU利用率或队列长度指标，通过Kubernetes HPA或自定义调度器实现Pod级别的弹性伸缩。

2.2.2 离线批处理部署

离线批处理面向非实时场景，如批量文档摘要、数据清洗、离线内容审核。核心要求是高吞吐和低成本，对延迟不敏感。离线部署通常采用以下策略：

• 任务队列：使用RabbitMQ、Kafka或Ray集群管理任务分发，支持优先级队列和死信队列。
• 大Batch推理：将大量请求合并为超大Batch（如Batch Size=64或128），最大化GPU算力利用率。
• 异步结果回写：推理完成后将结果写入对象存储或数据库，客户端通过轮询或回调获取结果。

对比维度	在线推理	离线批处理
延迟要求	首Token < 500ms，总延迟 < 5s	分钟~小时级，无严格限制
吞吐目标	QPS 100~1000+	每小时处理百万级请求
批处理策略	动态连续批处理（Batch Size 4~16）	静态大Batch（Batch Size 32~128）
网关策略	流式响应、短超时、并发控制	异步提交、长超时、任务状态查询
资源调度	弹性伸缩、预留GPU	定时任务、错峰使用
典型场景	对话、代码生成、实时翻译	批量摘要、数据标注、内容审核

2.3 性能瓶颈概述：从GPU到网关的端到端分析

大模型推理的性能瓶颈分布在从GPU硬件到API网关的每一个环节。只有准确识别瓶颈所在，才能制定有效的优化策略。

2.3.1 GPU层面的瓶颈

显存带宽是Decode阶段的核心瓶颈。以7B参数模型为例，每生成一个Token需要读取全部7B参数（约14GB FP16），在A100 80GB（带宽2TB/s）上，理论最小TPOT约为7ms。实际部署中，由于KV Cache访问、多请求竞争等因素，TPOT通常在10~30ms之间。显存容量则限制了可并发的请求数量——每个请求的KV Cache占用随上下文长度线性增长，长上下文请求会迅速耗尽显存。

2.3.2 推理引擎层面的瓶颈

推理引擎的调度策略直接影响GPU利用率。早期的静态批处理（Static Batching）要求同一批次的所有请求同时开始、同时结束，导致GPU在批次尾部出现大量空闲。现代引擎采用连续批处理（Continuous Batching），允许请求动态加入或离开批次，显著提升了利用率。但连续批处理也带来了新的问题：请求的优先级调度、抢占策略、KV Cache的碎片化管理等，这些都需要引擎层面的精细控制。

2.3.3 网关层面的瓶颈

API网关在大模型场景下容易成为新的瓶颈点。传统网关（如Nginx、Kong）针对短连接和快速响应设计，面对大模型的长连接、流式响应、高并发场景时，可能出现以下问题：

• 连接数耗尽：每个流式请求占用连接时间长达数十秒，网关的并发连接上限容易被击穿。
• 缓冲延迟：网关默认缓冲整个响应体，导致流式Token无法实时转发给客户端，增加感知延迟。
• 超时误杀：固定超时设置无法区分"请求排队"和"请求处理中"，长文本生成请求容易被误判为超时。
• 缺乏流式感知：传统网关无法识别SSE（Server-Sent Events）或WebSocket流，无法做逐Token的限流和计量。

2.3.4 端到端性能瓶颈排查案例

某互联网公司部署了一个70B参数的对话模型，使用4张A100 80GB GPU，vLLM作为推理引擎，Nginx作为API网关。上线后用户反馈"响应很慢"，但GPU利用率显示只有40%。排查过程如下：

1. 初步现象：用户感知延迟约8秒，其中首Token延迟3秒，Token间延迟约50ms（生成100个Token）。
2. 分析过程：通过链路追踪发现，请求在Nginx处停留了2.5秒。进一步检查发现，Nginx的proxy_buffering默认开启，导致vLLM输出的Token被缓冲，直到积累到一定量才转发给客户端。
3. 关键数据：vLLM实际首Token延迟仅500ms，但Nginx缓冲导致客户端感知延迟增加了2秒。同时，Nginx的worker_connections设置为1024，高峰期出现连接排队。
4. 优化操作：① 关闭Nginx的proxy_buffering，启用SSE流式转发；② 将worker_connections提升至4096，并启用HTTP/2多路复用；③ 在Nginx层增加基于Token速率的限流，防止单个用户占用过多连接。
5. 结果对比：优化后首Token延迟降至600ms，总延迟降至3秒，GPU利用率提升至65%，连接排队现象消失。
6. 复盘经验：网关的流式转发能力、连接数上限、超时策略是影响大模型在线推理体验的三大关键配置。传统网关参数需要针对大模型场景重新调优。

2.4 部署架构选型与网关优化方向

基于上述分析，大模型部署架构的选型应遵循以下原则：

• 延迟敏感型业务（对话、代码生成）：选择在线部署，推理引擎优先考虑vLLM或TensorRT-LLM，网关必须支持流式转发和精细超时控制。
• 吞吐敏感型业务（批量处理）：选择离线部署，使用消息队列削峰填谷，网关侧重任务提交和状态查询接口的设计。
• 混合型业务：将在线和离线资源池物理隔离，避免离线大Batch任务挤占在线推理的GPU资源。

2.5 常见误区与总结复盘

在指导多个团队完成大模型部署后，我总结了以下高频误区，希望帮助读者少走弯路：

误区	后果	正确做法
只关注GPU算力，忽略显存带宽	Decode阶段GPU利用率低，吞吐上不去	同时评估算力、显存带宽、显存容量三个维度
网关沿用传统HTTP配置	流式响应被缓冲，长请求被误杀	针对流式场景调整缓冲、超时、连接数配置
在线离线混部	离线大Batch任务拖垮在线延迟	物理隔离资源池，或使用优先级调度
忽略KV Cache管理	长上下文请求导致显存溢出	使用PagedAttention、KV Cache量化、上下文长度限制
不做压测直接上线	真实流量下性能急剧下降	使用真实请求分布进行压测，覆盖长文本、高并发场景