2、大模型基础与部署概览：Transformer架构要点、主流开源模型特点、部署的挑战与解决思路

在正式进入部署实操之前，我们需要先建立对模型本身的“工程认知”。很多部署问题——显存溢出、推理延迟高、并发吞吐低——根源并不在框架配置，而在于对Transformer架构的资源消耗特征、主流开源模型的差异以及部署链路的瓶颈缺乏系统性理解。本章将沿着“架构原理 → 模型选型 → 部署挑战 → 解决思路”这条主线，帮助你构建大模型部署的全局视图。

2.1 Transformer架构的部署关键点

Transformer架构自2017年提出以来，已成为大模型的事实标准。从部署视角看，我们不需要逐行推导注意力公式，但必须理解三个直接影响资源消耗的组件：多头自注意力（Multi-Head Attention）、前馈网络（FFN）以及KV Cache机制。

核心原理：为什么显存和计算量如此之大？

以LLaMA-7B为例，其参数量约70亿。在FP16精度下，仅权重就需要约14GB显存（70亿 × 2字节）。但实际部署时显存占用远不止于此：推理过程中，模型需要缓存每一层的中间激活值（activations），以及自回归生成时不断增长的KV Cache。KV Cache是部署中最容易被低估的显存消耗点——当上下文长度从2K扩展到32K时，KV Cache的显存占用会线性增长16倍。

从计算角度看，Transformer的FLOPs（浮点运算次数）主要由矩阵乘法主导。一次前向传播中，每个需要经过L层（如32层）的注意力计算和FFN计算。部署时我们关心的是计算密度（FLOPs/Byte），即算力与访存带宽的比值。对于7B模型，在A100（80GB）上，计算密度约为150 FLOPs/Byte，这意味着模型处于“访存受限”状态——GPU算力过剩，但显存带宽成为瓶颈。这解释了为什么批处理（batching）能显著提升吞吐：多个请求共享权重，摊薄访存开销。

判断方法：如何估算部署所需显存？

在选型前，建议使用以下公式进行快速估算：

显存需求 ≈ 权重显存 + KV Cache显存 + 激活值显存 + 预留冗余
权重显存 = 参数量 × 精度字节数（FP16为2字节，INT8为1字节，INT4约0.5字节）
KV Cache显存 = 2 × 层数 × 注意力头数 × 头维度 × 上下文长度 × 精度字节数
激活值显存 ≈ 权重显存的10%-20%（取决于batch size和序列长度）

例如，Qwen-7B（32层，28个注意力头，头维度128）在FP16、上下文2048、batch size=1时：权重约14GB，KV Cache约2×32×28×128×2048×2 ≈ 0.94GB，激活值约2GB，总计约17GB。这意味着单卡需要24GB显存（如RTX 3090/4090）才能舒适运行。

案例拆解：从“显存溢出”到“量化落地”

某团队在内部知识库问答场景中，最初尝试在单张A10（24GB）上部署ChatGLM-6B（FP16）。启动后立即报错CUDA out of memory。分析后发现：权重12GB + KV Cache（上下文2048）约0.8GB + 激活值约3GB + PyTorch框架开销约2GB，总计约18GB，但A10的可用显存仅约22GB，加上CUDA context占用，实际可用约20GB，勉强能跑但极易溢出。他们的解决路径是：

1. 将模型转为INT8量化（使用bitsandbytes库），权重降至约6GB；
2. 将上下文限制为1024，KV Cache降至0.4GB；
3. 启用torch.compile和CUDA graphs减少框架开销；
4. 最终显存占用约10GB，稳定运行且延迟从850ms降至420ms。

这个案例说明，量化是解决显存瓶颈最直接的手段，但需要评估精度损失是否在业务可接受范围内。

2.2 主流开源模型特点与选型

当前开源社区最活跃的三大家族是LLaMA（Meta）、Qwen（阿里）和ChatGLM（智谱）。它们各有侧重，选型时需结合硬件条件、许可证和业务场景。

核心原理：模型差异背后的部署影响

词表大小直接影响Embedding层的显存占用和首延迟。Qwen的151K词表意味着Embedding矩阵更大，在相同参数量下，其Transformer层相对更薄。上下文长度决定了KV Cache的上限——ChatGLM4-9B支持128K上下文，但实际部署时若开启长上下文，KV Cache会迅速膨胀，需要配合滑动窗口注意力或稀疏注意力来缓解。

许可证是选型时不可忽视的“硬约束”。LLaMA的商用许可需要向Meta申请，而Qwen和ChatGLM的Apache/MIT协议则更友好。如果项目涉及商业闭源交付，优先选择Qwen或ChatGLM。

判断方法：根据硬件选模型

• 单卡16GB（如T4）：只能部署4B以下模型，且必须INT4量化。推荐Qwen2.5-3B或ChatGLM3-6B（INT4）。
• 单卡24GB（如RTX 3090/4090）：可部署7B-9B模型（INT8），或13B模型（INT4）。推荐Qwen2.5-7B或ChatGLM4-9B。
• 单卡80GB（如A100/H100）：可部署13B-32B模型（FP16/INT8），或70B模型（INT4+多卡）。
• 多卡集群：使用张量并行（Tensor Parallelism）或流水线并行（Pipeline Parallelism）部署70B以上模型。

实战场景：中文客服场景的选型对比

某金融科技公司需要部署一个中文客服助手，要求响应延迟低于2秒，支持并发50路。他们对比了Qwen2.5-7B和ChatGLM4-9B：

• Qwen2.5-7B在中文意图识别上准确率略高（92% vs 90%），但首延迟稍高（因词表大）；
• ChatGLM4-9B在对话流畅度上更优，且其FlashAttention优化使长上下文推理更快；
• 最终选择ChatGLM4-9B（INT8），部署在2张A10上，通过vLLM实现连续批处理，实测并发60路时P95延迟1.8秒。

这个案例表明，选型不能只看benchmark分数，要结合具体业务场景的延迟敏感度和并发要求。

2.3 部署的挑战与解决思路

大模型部署的挑战可以归纳为“三堵墙”：显存墙（模型放不下）、延迟墙（单次推理太慢）、吞吐墙（并发一高就崩）。解决思路则围绕“压缩、并行、缓存、服务化”四个维度展开。

核心原理：为什么部署比训练更难？

训练可以容忍高延迟和低吞吐，但部署必须满足实时性要求。推理时，自回归生成是逐进行的，每个的生成都依赖前一个的输出，这导致无法像训练那样大规模并行。此外，生产环境需要处理动态的请求长度、突发流量和多种业务逻辑，这对推理系统的弹性提出了更高要求。

判断方法：识别你的部署瓶颈

案例拆解：从单卡到多卡的生产级部署

某AI创业公司需要将Qwen2.5-72B部署为API服务，硬件为4张A100（80GB）。初始方案是简单的模型并行（每张卡放18GB权重），但发现GPU利用率仅30%，且并发超过10路时延迟从1.2秒飙升至5秒。他们的优化过程：

1. 第一步：量化。将模型从FP16转为INT8，权重从144GB降至72GB，但单卡仍放不下，需要2卡张量并行。
2. 第二步：推理引擎。从HuggingFace Transformers切换到vLLM，利用PagedAttention管理KV Cache，显存利用率提升3倍。
3. 第三步：批处理。启用vLLM的Continuous Batching，将不同请求的级调度，吞吐从50 tokens/s提升至800 tokens/s。
4. 第四步：负载均衡。部署2个模型副本（各用2卡），前置Nginx负载均衡，支持并发200路。

最终效果：P95延迟2.1秒，吞吐1200 tokens/s，GPU利用率稳定在85%以上。这个案例的启示是：部署优化是系统工程，量化、引擎、批处理、架构缺一不可。

常见误区与总结复盘

• 误区一：认为量化必然损失精度。实际上，对于7B以上模型，INT8量化在大多数任务上损失不超过1%，INT4在对话场景中损失也可控。关键是使用或AWQ等校准量化方法，而非简单的RTN（舍入到最近）。
• 误区二：忽略KV Cache的管理。很多团队只关注权重显存，却忽略了长上下文场景下KV Cache的爆炸式增长。使用PagedAttention或滑动窗口可以显著缓解。
• 误区三：盲目追求低延迟。延迟和吞吐是矛盾的。如果业务允许，适当增加batch size可以大幅提升吞吐，而延迟增加有限。
• 误区四：不做压测就上线。至少要用wrk或locust模拟真实流量，观察GPU显存、利用率、延迟分布，找到系统的拐点。