大模型基础与部署挑战：LLM原理、计算特性与核心瓶颈
大语言模型（Large Language Model, LLM）的部署与传统软件服务有本质区别。传统Web应用主要受限于CPU计算和IO吞吐，而LLM服务同时受制于GPU显存容量、计算密度、内存带宽和网络通信。要设计合理的云原生架构，首先必须理解Transformer架构下的显存占用机制、自回归生成的计算特性，以及由此引发的延迟、吞吐量、成本之间的复杂权衡。本章从模型原理出发，系统拆解部署LLM时必然面对的四类核心挑战，并给出量化评估方法和架构应对思路。
2.1 Transformer架构与LLM计算特性
所有主流大模型（GPT系列、Llama、Qwen、DeepSeek等）均基于Transformer架构。理解其核心计算单元是分析部署瓶颈的前提。Transformer由多层堆叠的Block组成，每个Block包含两个核心子层：多头自注意力（Multi-Head Self-Attention）和前馈网络（Feed-Forward Network, FFN），并在每个子层后应用LayerNorm和残差连接。
2.1.1 自注意力机制的计算与存储开销
自注意力机制的核心公式为：Attention(Q, K, V) = softmax(QK^T / √d_k) V。在推理过程中，Q、K、V均由输入序列与权重矩阵相乘得到。这一过程产生两个关键的计算和存储特征：
- QK^T矩阵乘法：计算复杂度为O(n²·d)，其中n为序列长度，d为隐藏维度。当序列长度从1K增长到32K时，计算量呈平方级增长，这是长上下文场景下延迟飙升的根本原因。
- KV Cache：在自回归生成中，每个新Token需要与之前所有Token的K和V向量计算注意力。为避免重复计算，推理框架会将历史Token的K、V矩阵缓存在显存中，即KV Cache。其显存占用为2×n_layers×n_kv_heads×d_head×sequence_length×batch_size×precision_bytes。
2.1.2 Prefill与Decode两阶段计算特性
LLM推理过程分为两个截然不同的阶段，对硬件资源的需求完全不同：
| 阶段 | 计算模式 | 瓶颈类型 | 典型耗时占比 |
|---|---|---|---|
| Prefill（预填充） | 并行处理整个输入Prompt | 计算密集（Compute-bound） | 约10%-20% |
| Decode（解码） | 逐Token串行生成 | 访存密集（Memory-bound） | 约80%-90% |
Prefill阶段一次性处理所有输入Token，GPU计算单元利用率高，但需要大量显存存储中间激活值。Decode阶段每次仅生成一个Token，权重矩阵和KV Cache需要从HBM（高带宽内存）加载到计算单元，此时GPU的计算单元大量空闲，而内存带宽成为主要瓶颈。这也是为什么增加batch_size能显著提升Decode阶段吞吐量的原因——多个请求可以共享权重加载开销。
2.2 显存占用模型与容量规划
部署LLM时，显存规划是架构设计的第一步。显存占用主要由四部分构成：模型权重、KV Cache、激活值、运行时开销（CUDA context、框架缓存等）。
2.2.1 模型权重显存计算
模型权重显存 = 参数量 × 每个参数的字节数。FP16精度下每个参数占2字节，INT8量化后占1字节，INT4量化后占0.5字节。例如：
7B模型 FP16：7×10⁹ × 2B = 14GB
7B模型 INT8：7×10⁹ × 1B = 7GB
13B模型 FP16：13×10⁹ × 2B = 26GB
70B模型 FP16：70×10⁹ × 2B = 140GB（需多卡分片）值得注意的是，实际部署时还需要考虑CUDA context（约500MB-1GB）、PyTorch/推理框架的显存池、以及推理引擎预留的临时缓冲区。通常建议预留20%-30%的显存余量，避免因显存碎片化导致OOM。
2.2.2 KV Cache动态增长与容量估算
KV Cache是推理过程中动态增长的显存占用，其大小与并发请求数、序列长度直接相关。在云原生架构中，需要根据业务SLA（服务等级协议）估算最大并发数和最大序列长度，从而预留足够的KV Cache空间。
2.2.3 激活值显存
激活值（Activations）在Prefill阶段占用显著。对于batch_size=b、序列长度=n、隐藏维度=d的输入，单层Transformer的激活值约为b×n×d×34字节（包含注意力计算中的中间矩阵）。当batch_size=32、n=2048、d=4096时，单层激活值约1GB，32层模型总计约32GB。这解释了为什么大batch推理时，即使权重和KV Cache都放得下，激活值也可能成为瓶颈。
2.3 延迟与吞吐量的核心矛盾
延迟（Latency）和吞吐量（Throughput）是LLM部署中最核心的性能指标，但二者往往相互制约。理解其内在关系是进行架构调优的基础。
2.3.1 延迟指标拆解
LLM服务的端到端延迟由两部分组成：
- TTFT（Time To First Token）：从请求发出到收到第一个Token的时间。主要受Prefill阶段影响，包括网络传输、排队等待、模型Prefill计算。用户体验上，TTFT应控制在1-2秒以内。
- TPOT（Time Per Output Token）：生成每个输出Token的平均时间。主要受Decode阶段影响，由显存带宽决定。对于流畅的流式输出体验，TPOT应小于50ms（即每秒生成20个Token以上）。
端到端延迟 = TTFT + TPOT × 输出Token数。例如，输出500个Token，TPOT=50ms时，生成阶段耗时25秒，加上TTFT 1.5秒，总延迟约26.5秒。
2.3.2 吞吐量指标与批处理策略
吞吐量通常以每秒生成的Token数（Tokens/s）或每秒处理的请求数（QPS）衡量。提升吞吐量的核心手段是增大batch_size，让GPU在Decode阶段同时处理更多请求。但增大batch_size会带来两个问题：
- 显存压力增大：KV Cache和激活值随batch_size线性增长。
- 单请求延迟增加：由于GPU资源被多个请求共享，每个请求的TPOT会变长。
现代推理框架（如vLLM、TensorRT-LLM）采用Continuous Batching（连续批处理）技术，在序列级别动态调度：当一个请求生成完毕，立即将新请求加入batch，而不是等待整个batch全部完成。这能将GPU利用率从静态批处理的60%左右提升到90%以上。
2.4 部署挑战的架构应对策略
针对上述显存、延迟、吞吐量挑战，云原生架构需要从硬件选型、模型优化、推理引擎、弹性调度四个层面综合应对。
2.4.1 硬件选型与多卡并行策略
当单卡显存无法容纳模型权重和KV Cache时，需要采用多卡并行。常见的并行策略包括：
| 并行策略 | 适用场景 | 通信开销 | 典型框架 |
|---|---|---|---|
| 张量并行（TP） | 单机多卡，模型过大 | 高（每层需AllReduce） | Megatron-LM |
| 流水线并行（PP） | 多机多卡，降低通信 | 中（仅层间传输） | DeepSpeed |
| 数据并行（DP） | 模型可单卡容纳，提升吞吐 | 低（仅梯度同步） | PyTorch DDP |
对于70B以上模型，通常采用TP+PP组合。例如，使用8张A100-80GB部署Llama-2-70B（FP16，权重140GB），可采用TP=8（单机8卡）或TP=4+PP=2（两机各4卡）。TP=8时每层计算需要跨卡AllReduce，通信延迟约50-100μs；PP=2时仅需在流水线阶段间传输激活值，通信压力较小。
2.4.2 模型量化与显存压缩
量化是降低显存占用、提升推理速度的有效手段。主流方案包括：
- INT8量化（W8A8）：权重和激活均用INT8，显存减半，速度提升约1.5-2倍，精度损失通常小于1%。
- INT4量化（GPTQ/AWQ）：仅权重用INT4，显存降至FP16的1/4，但需要额外的反量化计算，且精度损失在复杂任务上可能达到2%-5%。
- FP8量化：H100/H200原生支持，兼顾精度和速度，是新一代硬件的推荐方案。
2.4.3 推理引擎选型与性能对比
推理引擎的选择直接影响延迟和吞吐量表现。当前主流的开源推理框架包括：
| 框架 | 核心特性 | 最佳场景 | 显存优化 |
|---|---|---|---|
| vLLM | PagedAttention + Continuous Batching | 高并发在线服务 | KV Cache分页管理 |
| TensorRT-LLM | NVIDIA官方优化，算子融合 | 追求极致性能 | 图优化 + 量化 |
| Text Generation Inference (TGI) | HuggingFace生态，易集成 | 快速原型验证 | 动态批处理 |
| llama.cpp | CPU/GPU混合推理 | 边缘设备部署 | GGUF量化 |
根据MLPerf基准测试，TensorRT-LLM在A100上通常比vLLM快10%-20%，但vLLM在动态请求场景下更灵活。生产环境建议同时部署多个引擎，通过路由层根据请求特征（如序列长度、并发量）动态选择最优引擎。
2.4.4 弹性伸缩与GPU资源管理
云原生架构下，GPU资源的弹性伸缩比CPU应用复杂得多。主要挑战包括：
- 冷启动延迟：加载一个7B模型需要10-30秒，70B模型需要2-5分钟。Kubernetes默认的HPA（Horizontal Pod Autoscaler）无法满足秒级弹性需求。
- GPU资源碎片化：不同规格的GPU（A10、A100、H100）混部时，调度器需要处理异构资源。
- 推理状态管理：长连接会话（WebSocket/SSE）的请求无法简单迁移，扩容时需要会话亲和性。
推荐的架构模式是：GPU节点池 + 自定义调度器 + 请求队列缓冲。将推理Pod部署在专用的GPU节点池，使用KEDA（Kubernetes Event-driven Autoscaling）基于请求队列长度（如Kafka/RabbitMQ中的积压消息数）进行弹性伸缩。同时，利用vLLM等框架的优雅缩容功能，在Pod终止前完成正在处理的请求，避免连接中断。
背景与约束：某金融科技公司需要部署一个基于Llama-2-13B的智能客服系统，要求TTFT < 2秒，TPOT < 80ms，支持200并发请求，业务高峰期为工作日上午9-11点。
初始方案与问题：团队最初使用4张A10-24GB GPU，采用PyTorch原生推理，batch_size固定为8。上线后发现：TTFT平均3.5秒（超标），TPOT约120ms，GPU利用率仅45%，高峰期大量请求排队超时。
分析与诊断：通过NVIDIA Nsight分析发现：①A10的显存带宽仅600GB/s，远低于A100的2TB/s，导致Decode阶段访存瓶颈严重；②固定batch_size=8导致GPU计算单元在低峰期大量空闲；③PyTorch原生推理没有KV Cache复用，每个请求重复计算历史Token。
优化措施：①将推理引擎切换为vLLM，启用PagedAttention和Continuous Batching；②将batch_size改为动态调整（4-32），根据请求队列长度实时变化；③将模型量化至INT8，显存占用从26GB降至13GB，允许在A10上部署更大batch；④增加KEDA自动伸缩，配置基于队列长度的伸缩规则（队列积压>50时扩容，<10时缩容）。
结果对比：优化后TTFT降至1.2秒，TPOT降至65ms，GPU利用率提升至82%，单卡吞吐量从120 Tokens/s提升至450 Tokens/s。高峰期通过自动扩容至8个Pod，成功支撑了300并发请求。
风险与代价：INT8量化导致模型在金融术语理解上准确率下降约1.8%，团队增加了针对金融领域的LoRA微调补偿；vLLM的PagedAttention在极端长序列（>8K）下存在轻微性能回退，需设置max_seq_len=4096作为保护。
复盘经验：①硬件选型时，显存带宽比显存容量更关键；②推理引擎的优化空间远大于硬件升级；③弹性伸缩必须结合业务流量特征设计，不能简单依赖CPU指标。
2.5 常见误区与设计复盘
在LLM部署实践中，以下误区需要特别警惕：
- 误区一：只关注模型参数量，忽略KV Cache。很多团队在规划显存时只计算权重大小，导致上线后因KV Cache溢出而频繁OOM。正确做法是同时估算最大并发数下的KV Cache需求。
- 误区二：盲目追求低延迟，牺牲吞吐量。对于非交互式场景（如离线批量生成、数据标注），高吞吐比低延迟更重要。应根据业务SLA设置合理的batch_size上限。
- 误区三：忽略Prefill与Decode的资源竞争。当多个请求同时到达时，Prefill阶段会抢占大量计算资源，导致正在Decode的请求TPOT飙升。建议在架构上分离Prefill和Decode的GPU资源池，或使用优先级调度。
- 误区四：量化后不做精度验证。量化模型的精度损失在不同任务上差异巨大，必须用业务真实数据构建评测集，对比量化前后的输出质量。
- 误区五：弹性伸缩只关注Pod数量。GPU推理Pod的伸缩粒度太粗，冷启动时间长。更精细的做法是结合模型副本数、请求队列深度、GPU利用率三个维度综合决策。