1. 大模型与 GPU 的关系全景拆解1.1 为什么大模型离不开 GPU很多人第一次接触大模型部署时脑子里冒出来的第一个问题就是这东西为什么非得用 GPUCPU 不是也能算吗答案是能算但慢到你会怀疑人生。大模型的本质是海量的矩阵乘法一个 7B 参数的模型每生成一个 token就要把约 70 亿个参数全部过一遍。CPU 的核心数通常只有几十个而一块主流 GPU 有几千甚至上万个计算核心两者在并行吞吐上的差距是数量级的。打个比方CPU 像是一个数学教授什么题都会做但一次只能做一道GPU 像是一万个只会做加减乘除的小学生但一万人同时开工处理海量简单运算时反而碾压教授。大模型的推理和训练恰恰就是那种“题目简单但数量爆炸”的场景所以 GPU 成了刚需。这里有个关键概念叫显存带宽。模型参数存在显存里每次计算都要从显存读到计算单元。如果带宽不够计算单元就得干等着数据这叫“内存墙”。所以选 GPU 不只看算力FLOPS更要看显存容量和带宽。很多新手只盯着算力数字结果发现模型根本装不下这就是典型的踩坑。1.2 7B、13B、70B 这些数字到底意味着什么模型名字里的 7B、13B、70B指的是参数量B 是 Billion十亿的缩写。7B 就是 70 亿个参数。这些参数在显存里以什么精度存储直接决定了占用多少显存。常见的精度格式和它们每个参数占用的字节数精度格式每参数字节7B 模型显存占用说明FP324 字节约 28 GB全精度训练常用FP16 / BF162 字节约 14 GB半精度推理常用INT81 字节约 7 GB8 位量化INT40.5 字节约 3.5 GB4 位量化消费级显卡友好这张表是理解一切的起点。你可以看到同样是 7B 模型用 FP16 要 14GB 显存用 INT4 只要 3.5GB。这就是为什么量化技术这么火——它让普通玩家用一张消费级显卡也能跑起来。但要注意这只是权重本身的占用。实际运行时还有 KV Cache、激活值、框架开销等额外占用通常要在权重基础上再留 20% 到 50% 的余量。所以一个 FP16 的 7B 模型实际部署建议至少 16GB 到 20GB 显存。1.3 显存占用的完整构成很多人算显存只算权重结果一跑就 OOMOut Of Memory。完整的显存占用至少包含这几块模型权重就是上面表格算的那部分固定开销。KV Cache推理时缓存历史 token 的 Key 和 Value随上下文长度线性增长这是最容易被忽略的大头。激活值前向传播过程中的中间结果训练时占用更大。框架与运行时开销CUDA 上下文、通信缓冲区等通常 1GB 到 2GB。KV Cache 的估算公式大致是2 × 层数 × 注意力头维度 × 序列长度 × 批大小 × 精度字节。以 7B 模型为例层数约 32隐藏维度约 4096如果序列长度 4096、批大小 1、FP16 精度KV Cache 大约占用 2GB 左右。上下文拉到 32K这个数字会飙升到十几 GB。所以长上下文场景下KV Cache 往往比权重还吃显存。提示部署前一定要用显存估算工具或公式先算一遍别等跑起来才发现装不下。经验法则是权重占用乘以 1.5 作为安全线。2. 单卡部署的实操路径与参数选择2.1 从零估算你的显卡能不能跑假设你手头有一张 24GB 显存的显卡想跑一个 13B 的模型。先算权重FP16 下 13B × 2 字节 26GB直接超了。那退一步用 INT813GB加上 KV Cache 和开销勉强能塞进 24GB但上下文不能太长。再退一步用 INT46.5GB加上各种开销大概 10GB 出头24GB 显卡跑起来很宽裕还能留出空间给长上下文。这个推演过程就是部署决策的核心逻辑。我一般建议按这个顺序决策先确定模型规模7B / 13B / 70B。再确定精度能接受多大精度损失。然后算权重显存。加上 KV Cache 和开销对比显卡容量。装不下就降精度、减上下文、或者上多卡。2.2 量化方案怎么选量化是单卡跑大模型的关键手段。常见的量化方案有 GPTQ、AWQ、GGUF 等各有适用场景。GPTQ训练后量化4 位为主推理速度快适合 GPU 部署。AWQ激活感知量化对精度保留更好同样适合 GPU。GGUF专为 CPU 和混合推理设计支持灵活的层卸载适合显存不足时把部分层放 CPU。选哪个如果你有足够的 GPU 显存优先 AWQ 或 GPTQ速度最快。如果显存紧张GGUF 可以让你把一部分层放到内存里用 CPU 补算速度慢但能跑起来。实测下来7B 模型 INT4 量化后精度损失在多数任务上肉眼几乎看不出来但 70B 模型量化到 INT4 时某些推理任务会有可感知的下降需要权衡。注意量化不是免费的午餐。4 位量化在数学推理、代码生成这类对精度敏感的任务上掉点会比通用对话明显。如果你的场景是写代码或做数学题尽量用更高的精度。2.3 单卡部署的完整操作流程下面给一套可直接参考的单卡部署流程以主流的推理框架为例。第一步确认环境。检查显卡驱动、CUDA 版本、Python 版本是否匹配。CUDA 版本和框架版本不匹配是最常见的报错来源。nvidia-smi这条命令能看到显卡型号、显存总量、驱动版本、当前 CUDA 版本。记下 CUDA 版本后面装框架要对上。第二步创建独立的 Python 环境。强烈建议用 conda 或 venv 隔离避免依赖冲突。conda create -n llm python3.10 conda activate llm第三步安装推理框架。以 vLLM 为例pip install vllm第四步下载模型权重。可以从模型社区获取量化好的权重注意选对量化格式。第五步启动推理服务。关键参数包括模型路径、精度、显存利用率、最大上下文长度。python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --dtype float16 \ --gpu-memory-utilization 0.9 \ --max-model-len 4096这里的gpu-memory-utilization 0.9表示允许框架使用 90% 的显存留 10% 给系统和其他进程。这个值设太高容易 OOM设太低浪费显存0.85 到 0.92 是比较稳的区间。2.4 单卡部署的常见坑第一个坑是上下文长度设太大。很多人一上来就把 max-model-len 设成 32K结果 KV Cache 直接把显存吃满服务起不来。正确做法是先从小上下文起步跑通后再逐步加大观察显存变化。第二个坑是忽略显存碎片。长时间运行后显存会产生碎片导致明明总量够却分配失败。解决办法是设置PYTORCH_CUDA_ALLOC_CONFexpandable_segments:True让分配器更灵活。第三个坑是批处理大小没调优。批处理能提升吞吐但也会增加 KV Cache 占用。需要根据实际并发量做压测找到吞吐和延迟的平衡点。3. 多卡部署的核心原理与实现3.1 为什么需要多卡什么时候该上多卡单卡装不下或者单卡吞吐不够就该考虑多卡了。70B 模型 FP16 需要约 140GB 显存单张消费级显卡根本不可能必须多卡。即便是 7B 模型如果要做高并发服务单卡吞吐到顶了也需要多卡横向扩展。多卡部署分两种目标一种是装得下模型并行一种是跑得快数据并行。这两个目标的实现方式完全不同选错了会事倍功半。3.2 张量并行与流水线并行的区别模型装不下时要把模型切开放到多张卡上这叫模型并行。主流有两种切法张量并行Tensor ParallelismTP把每一层的矩阵运算切开分到多张卡上每张卡算一部分然后通信汇总。切得细通信频繁适合卡间带宽高的场景比如同一台机器内的 NVLink。流水线并行Pipeline ParallelismPP把模型按层切成几段每段放一张卡数据像流水线一样依次流过。通信量小但有“气泡”问题部分卡在等待适合跨机器部署。实际部署中单机多卡优先用 TP因为机内带宽高TP 的通信开销可以接受。跨机部署用 PP 或者 TPPP 混合。并行方式切分维度通信频率适用场景张量并行 TP层内切分高单机多卡高带宽流水线并行 PP层间切分低跨机部署数据并行 DP复制模型中提升吞吐3.3 多卡部署的实操配置以两张 24GB 显卡部署 13B FP16 模型为例。13B FP16 权重约 26GB单卡装不下两张卡 TP2 刚好每卡 13GB加上 KV Cache 和开销24GB 够用。启动命令python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --tensor-parallel-size 2 \ --dtype float16 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192关键参数--tensor-parallel-size 2告诉框架用两张卡做张量并行。框架会自动把模型切分并处理卡间通信。如果是跨机部署还需要配置通信后端。这里涉及网络配置需要确保机器间高速互联否则通信会成为瓶颈。3.4 多卡部署的性能调优多卡不是简单地把卡堆上去就完事调优很关键。第一卡间带宽是命门。TP 的通信非常频繁如果卡间带宽不够加卡反而更慢。同一台机器内用高速互联跨机尽量用高带宽网络。第二并行度要和模型规模匹配。TP 的度数最好是注意力头数的约数否则切分不均。比如 32 个注意力头TP2、4、8 都合适TP3 就会切不匀。第三批处理和并行度要联合调优。多卡下批处理可以开更大但 KV Cache 也会分摊到各卡需要重新算显存。第四监控通信开销。如果发现 GPU 利用率上不去很可能是卡在通信上。用性能分析工具看通信占比超过 30% 就要考虑调整并行策略。提示多卡部署前先用小模型验证通信链路是否正常。我见过太多案例是模型没问题卡在通信配置上排查半天。4. 常见问题排查与避坑经验实录4.1 显存相关问题的排查思路显存问题是最常见的表现就是 OOM 报错。排查顺序建议这样走先看权重占用是否超了。用nvidia-smi看显存占用如果启动瞬间就爆基本是权重太大需要降精度或加卡。再看 KV Cache。如果服务能起来但一处理长文本就崩多半是 KV Cache 超了。减小 max-model-len 或降低并发。最后看碎片和泄漏。如果运行一段时间后逐渐 OOM可能是显存碎片或内存泄漏检查是否有未释放的缓存。现象可能原因解决方向启动即 OOM权重超显存降精度、量化、加卡长文本 OOMKV Cache 超限减上下文、降并发运行中逐渐 OOM碎片或泄漏调分配器、查代码多卡 OOM切分不均调并行度4.2 速度慢的排查与优化速度慢分两种首 token 延迟高和生成速度慢。首 token 延迟高通常是预填充阶段慢和输入长度、批处理有关。优化方向是减少输入长度、用更快的注意力实现。生成速度慢通常是解码阶段慢和显存带宽、批处理有关。优化方向是提高批处理、用量化降低带宽压力。还有一个容易被忽略的点是CPU 瓶颈。如果模型加载、tokenizer 处理在 CPU 上成了瓶颈GPU 再快也没用。用性能分析工具看 CPU 和 GPU 的时间占比别只盯着 GPU。4.3 多卡通信问题的排查多卡部署最容易出问题的就是通信。常见表现是卡间不同步、服务卡死、或者速度远低于预期。排查步骤确认所有卡都能被正确识别。确认通信后端配置正确。用简单的通信测试验证链路。检查是否有防火墙或网络策略阻断。看通信库的日志定位具体卡在哪一步。我踩过的一个坑是两台机器的时钟不同步导致分布式通信超时。后来统一了时间同步问题消失。这种问题很隐蔽日志里不一定直接报时钟但表现就是随机超时。4.4 独家避坑清单别迷信参数表厂商标称的显存和实际可用有差距系统会占用一部分按标称的 90% 估算更稳。先小后大先用小模型、小上下文跑通全流程再逐步放大别一上来就顶配。留足余量显存利用率别设到 0.95 以上留 10% 应对峰值和碎片。版本对齐CUDA、驱动、框架、模型格式四者版本要对齐这是最省时间的做法。压测再上线单卡跑通不等于能扛并发一定要做压力测试找到真实的吞吐上限。记录配置每次成功的配置都记下来包括版本号、参数、硬件出问题时能快速回滚对比。5. 从选型到落地的完整决策链5.1 按场景选配置的决策树不同场景对配置的要求完全不同我整理了一个决策思路如果是个人学习、本地实验7B 模型 INT4 量化一张 8GB 到 12GB 的显卡就够重点是跑通流程不追求速度。如果是小团队内部服务13B 模型 INT8 或 FP16一张 24GB 显卡或两张 16GB 显卡重点是稳定和够用。如果是生产级高并发70B 模型多卡 TPPP重点是吞吐、延迟和容错需要专门的运维。如果是长上下文场景比如文档分析显存预算要重点留给 KV Cache可能需要比常规配置更大的显存。5.2 成本与性能的平衡多卡不是越多越好。加卡能提升吞吐但成本线性增长而吞吐不一定线性提升因为通信开销会吃掉一部分收益。经验上TP 度数超过 8 之后收益递减明显。另一个平衡点是量化。量化能大幅降低显存需求让便宜的卡也能跑大模型但会损失精度。对于精度不敏感的场景比如通用客服大胆用量化对于精度敏感的场景比如代码、数学尽量保精度。5.3 未来扩展的预留部署时最好预留扩展空间。比如现在用单卡跑 7B但预期半年后要上 13B那选卡时就别只买刚好够 7B 的留点余量。软件架构上用支持多卡扩展的框架别用写死了单卡的方案。我个人在实际操作中的体会是大模型部署这件事算清楚显存是第一步选对并行策略是第二步调优是第三步。很多人卡在第一步就放弃了其实只要把显存账算明白后面的路就清晰了。最后再分享一个小技巧每次部署前先用一个最小的模型把整条链路跑通确认环境、通信、框架都没问题再换大模型。这样能把问题定位的范围缩小很多省下大量排查时间。