如果把大模型部署比作一场限时竞速量化、稀疏化、知识蒸馏与 vLLM 这四样东西就是我手里最常用的四把改锥。它们各自解决不同层面的效率瓶颈有的在压缩模型本身的体积有的在减少计算时的访存量有的干脆从源头把模型变小还有的负责在推理阶段把硬件资源榨干。很多人一提起效率优化就只想到量化或者只想到上 vLLM其实这四者是互相配合的一套组合拳。这篇内容我会把每个技术的定位、核心原理、实操步骤和踩坑点都拆开讲清楚最后再给出一个把它们串联起来的端到端实施路线希望对正在做模型部署、推理加速或者服务化改造的朋友有实际帮助。1. 内容整体设计与思路拆解1.1 四个技术各自解决什么问题先给这四样东西画一张定位图。量化Quantization解决的是“单个数值的精度冗余”问题。神经网络在训练时默认用 FP3232 位浮点数甚至 FP1616 位浮点数来存储权重和激活值但实际部署时根本不需要这么高的精度。把 32 位压到 8 位整数模型体积直接缩到四分之一推理速度也能明显提升。这个过程本质上是用可控的精度损失换取存储和计算的双重收益。稀疏化Sparsity解决的是“参数中的冗余结构”问题。训练好的大模型里很多权重数值趋近于零这些参数对最终输出的贡献微乎其微。结构化剪枝直接把这些不重要的连接或者通道删掉非结构化剪枝则是把小于阈值的权重置零配合稀疏矩阵运算库来加速。和量化不同稀疏化更像是做减法而且它和量化是正交的可以叠加使用。知识蒸馏Knowledge Distillation和前两者都不一样它不走压缩路线而是重新训练一个小模型。用一个参数量巨大的教师模型Teacher去指导学生模型Student学习让学生模型模仿教师模型的输出分布而不是直接学习硬标签。这样可以用几十分之一的参数量逼近大模型的精度属于“从源头瘦身”。vLLM 解决的则是“推理服务阶段的吞吐瓶颈”。前面三个技术都是让单次推理变得更便宜而 vLLM 通过 PagedAttention 机制和 Continuous Batching让 GPU 在服务多个请求时不再浪费显存也不再因为某个慢请求阻塞整批计算。它的本质是内存管理和调度优化与模型本身的结构无关。1.2 四者之间的关系与选择逻辑这四个技术不是互斥选项而是有清晰的组合逻辑。我通常把它们分成两条路径模型侧优化和服务侧优化。量化和稀疏化作用于已有模型属于“改模型”知识蒸馏属于“重新练模型”成本最高但效果上限也最高vLLM 完全不碰模型只改推理引擎。实际项目里的选型思路大致是这样如果模型已经训练好且不方便重新训练优先考虑量化和稀疏化因为它们是 off-the-shelf 的优化手段如果对模型体积和推理时延有极致要求而且有足够的训练数据和 GPU 预算知识蒸馏是更好的选择无论选了哪条模型侧路径最终上生产服务时都建议搭配 vLLM因为它能显著提升吞吐量甚至可以让量化后的小模型撑住更大的并发压力。这里有个容易被忽视的点vLLM 和量化是协同工作的。量化后的模型体积变小意味着同样的显存可以放更大的 KV CachevLLM 的 Page 命中率会更高连续批处理的有效 batch 也能开得更大。我实测过同一个 7B 模型FP16 版本在 vLLM 里大概只能撑住 8 并发INT8 量化版本可以直接开到 16 并发而不爆显存吞吐几乎翻倍。所以不要孤立地看待任何一个技术。2. 量化压缩精度换取速度与显存2.1 量化的基础原理从浮点到整数的映射量化的核心是一个映射函数。最简单的对称量化Symmetric Quantization公式是q round(r / S)其中 r 是原始浮点值S 是缩放因子q 是量化后的整数。反量化则是 r ≈ q * S。对于 INT8q 的取值范围是 [-128, 127]。对于非对称量化还会引入一个零点偏移 Z公式变成 q round(r / S Z)。为什么能用这么简单的映射而不丢失太多精度因为神经网络的权重和激活值通常符合正态分布绝大多数数值集中在均值附近只有少数极端值。量化要做的就是让缩放因子 S 匹配数值的实际分布范围。如果分布范围取得太大有效精度就会浪费在那些极少出现的极端值上如果取得太小就会频繁截断导致误差爆炸。这也是为什么静态量化需要先校准数据集来统计激活值的分布。我在实际项目里发现很多人对量化有一个误解以为量化只是“把 FP16 转成 INT8”这么简单其实难点在于处理激活值的动态范围。权重的范围是静态的量化校准一次就够但激活值每个 batch 都会变如果分布估算不准量化后的模型精度会断崖式下跌。所以现在的量化方案基本都会做激活值的感知量化Quantization-Aware TrainingQAT或者在推理时动态计算缩放因子。2.2 三种主流量化方案对比代码层面最常用的量化库有三个层次PyTorch 自带的torch.quantization、社区流行的bitsandbytes、以及面向部署的TensorRT/ONNX Runtime。不同方案对应的落地场景完全不同。方案精度工程复杂度典型使用场景Post-Training Quantization (PTQ)较高大模型上可能略有下降低只需校准快速上线、API 服务Quantization-Aware Training (QAT)很高几乎无损高需重训精度敏感场景、边缘设备动态量化Dynamic Quantization中低无需校准CPU 推理、Embedding 层以transformers生态为例现在最常用的 PTQ 工具是AutoGPTQ和AWQ。AutoGPTQ 是 GPU 上做 4-bit 量化的事实标准核心思路是使用二阶信息Hessian 矩阵来寻找最优的量化参数尽量让量化误差最小化。AWQActivation-aware Weight Quantization则另辟蹊径它观察激活值的分布找出对模型输出影响最大的少数权重通道然后在量化时对这些通道单独做保护保留更高的精度。实操经验如果是 7B 级别以上的模型我一般首选 AWQ因为它的精度保持比 GPTQ 更好尤其在多轮对话场景下不会出现上下文越长效果越差的问题。如果是 CPU 部署小模型直接开 PyTorch 的动态量化就行不用折腾校准数据集。2.3 量化实操与避坑标准量化流程可以拆成这几步加载原始 FP16 模型选择量化算子QuantLinear或WQLinear_GEMM准备校准数据集一般 128 到 512 条样本足够覆盖真实业务场景的输入分布运行校准得到每一层的缩放因子 S 和零点 Z保存量化后的模型权重替换原始模型文件在推理阶段加载量化模型验证精度和延迟我在处理一个 13B 模型时发现校准数据集的选择会直接影响最终精度。如果用的是通用语料校准量化后的模型在垂直领域任务上表现会明显退化。解决方案是把校准数据换成业务侧的真实请求采样模型输出质量立刻恢复。这个细节非常值得记下来。第二个坑是量化后模型在某些算子上不支持。比如lm_head层分类头通常不适合量化因为它的输出分布非常尖锐量化误差会被放得很大。解决方法是把这些层单独排除在量化范围之外保持 FP16 精度。还有一个常见问题是 INT8 量化在旧款 GPU 上并不一定更快因为消费级显卡的 INT8 算力提升有限真正拉开差距的通常是服务端 GPU 的 Tensor Core 和专门的 INT8 流水线。部署前务必先看硬件规格表。3. 稀疏化扰动最小化结构只留关键参数3.1 稀疏化的类型从非结构化到结构化稀疏化的基本思想是一个训练好的模型里有大量权重接近 0这些连接可以被移除而不影响模型主要功能。非结构化稀疏也叫细粒度稀疏是指对每一个独立的权重做裁剪达到 90% 以上稀疏率后配合专门的稀疏矩阵运算库仍能加速。但问题在于普通矩阵乘法库对稀疏矩阵并不友好实际加速效果在通用硬件上并不理想。结构化稀疏则是一个重量级的选择。它把权重矩阵按行、列或者整个通道进行裁剪形成一个规则的空洞结构可以直接映射到加速器上的稠密计算不需要专门改造计算内核。比如 2:4 结构化稀疏两个连续元素中保留两个非零元素在 A100 和 H100 上有专门的硬件加速支持稀疏带来的计算加速和显存节省效果非常显著。实际工程里更常用的是剪枝Pruning而不是单纯的置零。剪枝分两种微调式剪枝Fine-tuned Pruning和一次性剪枝One-shot Pruning。微调式剪枝的流程是“剪掉一部分权重-重新训练-再剪掉一部分”每次裁剪后模型会重新适应新的结构精度掉得慢。一次性剪枝则需要一个更聪明的选择标准比如 WandaWeights and Activations方法它不只看权重的大小还结合了激活值的幅度选出真正对输出有影响的关键通道。3.2 稀疏化与大模型的适配问题大模型稀疏化有个天然的难点模型已经训练好梯度信息早已消失想再微调就需要大量算力和数据。所以现在主流的做法是“稀疏化 轻量微调”Sparse Fine-tuning在剪枝后只训练少数可学习的参数来恢复精度。这与 LoRA 的思路异曲同工只是把低秩矩阵换成了稀疏掩码。我实际测试过一个 7B 模型在 50% 稀疏率下的表现一次性剪枝基于 Wanda精度损失大概在几个点以内但如果能做到稀疏化后配合 LoRA 微调几百步精度可以恢复到接近原始水准。这个组合的收益在于模型体积在磁盘上没变但推理时的计算量减半对于长序列生成的加速效果特别可观。需要注意稀疏化和量化叠加时有一个顺序问题。一般建议先做稀疏化再做量化因为量化会把权重映射到整数网格稀疏化再对整数权重做置零会导致误差更大。反过来如果先用稀疏化筛选出关键通道再对这些通道做更精细的量化效果会稳定得多。这个顺序在实践中非常关键。3.3 稀疏化的落地工具老牌的稀疏化工具是NVIDIA APEX的 AMP 功能里的channel_prune以及Intel Neural Compressor。对于大模型现在更常用的是基于torch_pruning做通道剪枝或者用SparseGPT库做一次性权重复原式剪枝。SparseGPT 的核心优势是不需要重新训练直接利用 Hessian 信息来做近似最优的剪枝重建精度可以保持到非常高的水平。实操代码如下以 SparseGPT 剪 50% 稀疏率为例git clone https://github.com/IST-DASLab/SparseGPT cd SparseGPT python main.py --model facebook/opt-1.3b --sparsity 0.5 --prune当然考虑到大模型参数量大SparseGPT 在 CPU 上跑可能很慢建议使用 A100 级别的 GPU 做并行。如果你的业务模型是 70B 级别的单机显存不够可以考虑分块稀疏化也就是按层加载、逐层剪枝完成后把剪枝后的权重存回磁盘。注意稀疏化对大模型的推理加速完全依赖稀疏kernel。如果没有对应的计算库比如 cuSPARSELt单纯把权重置零根本不会带来实际加速反而可能因为非零元素分布不规则导致 cache miss。要么用结构化稀疏要么明确目标硬件支持稀疏计算否则不要轻易上稀疏化。4. 知识蒸馏用大模型教小模型从源头变小4.1 知识蒸馏的核心概念知识蒸馏的本质是迁移学习。用一个大而全的教师模型Teacher的输出作为“软标签”去训练一个参数量小得多的学生模型Student。软标签不是简单的0/1类别而是一个概率分布比如“猫、狗、鸟”的概率分别是 0.7、0.2、0.1。相比硬标签里的确定性软标签保留了类别之间的相似性信息比如“鸟”和“飞机”的概率都比“汽车”高学生模型就能学到这种潜在语义关联。蒸馏损失函数通常由两部分组成L α * L_soft (1 - α) * L_hardL_soft 是学生输出与教师软标签之间的蒸馏损失常带温度参数 TL_hard 是学生输出与真实硬标签之间的交叉熵损失。温度 T 的作用是控制软标签的平滑度温度越高概率分布越均匀相似性信息越明显。这里有个实用的经验温度 T 不宜设置得过高。T 太高会让所有类别的概率趋近均匀教师模型的判断力被稀释T 太低又退化为硬标签失去了蒸馏的意义。我通常在分类任务上用 T4在生成任务上会稍微调低一些并配合最小置信度阈值来过滤不可靠的教师输出。4.2 大模型时代的知识蒸馏场景在生成式大模型领域蒸馏的对象从 logits 变成了生成序列。一个 7B 的教师模型可以蒸馏出一个 1B 甚至 500M 的学生模型典型做法是让学生模型模仿教师模型的生成结果直接用教师输出作为训练数据。这种方式在学界叫“弱监督蒸馏”或者“伪标签蒸馏”工程上非常简单调用教师模型批量生成数据清洗后作为学生的训练集。但这里有一个需要警惕的问题伪标签中教师的幻觉Hallucination会被学生模型全盘吸收。所以蒸馏前最好做一轮数据清洗过滤掉不符合业务规则的输出。另一个方案是使用“蒸馏 奖励模型”的方式额外训练一个奖励模型来评估教师输出质量只有得分高的样本才进入学生训练集。我试过这个组合学生模型的问答质量提升非常明显而且更稳定。蒸馏的收益不是没有代价。第一需要教师模型在训练期间始终保持可用这意味着要维护一个重型服务来在线生成数据第二学生模型的能力上限受限于教师模型的上限如果教师的推理能力本就不足学生只会更差第三蒸馏后的模型做量化、稀疏化的精度损失比大模型更大因为这些压缩手段会进一步牺牲小模型的容量。4.3 蒸馏实操与组合策略蒸馏实操的核心流程是把教师模型“降频”使用而不是一直全速推理。我的做法是先用教师模型离线批量生成一批强标注样本缓存成文件后续多轮训练都复用这批数据学生模型每隔几个 epoch 再做一轮对齐让教师在线输出新的软标签来弥补静态伪标签的偏差。以 Hugging Facetransformers生态为例训练蒸馏模型时可以用 DistilBERT 的做法共享教师和学生的 tokenizer然后只对学生做 forward、教师做 frozen forward同步计算蒸馏损失。代码可以参照with torch.no_grad(): teacher_logits teacher_model(input_ids) student_logits student_model(input_ids) loss nn.KLDivLoss()(F.log_softmax(student_logits / T, dim-1), F.softmax(teacher_logits / T, dim-1)) * (T * T)最后的(T * T)是为了平衡温度缩放带来的梯度变化。很多人会漏掉这个系数导致蒸馏 loss 在低温时过小、高温时过大训练非常不稳定。模型量化与蒸馏的组合也有讲究。实践中我推荐“蒸馏后量化”而不是“量化后蒸馏”。因为量化会打断梯度回传让蒸馏训练变得非常困难尤其对于 INT4 低比特量化的场景。如果非要两者叠加建议采用 QAT量化感知训练的方式在训练过程中就插入伪量化算子这样学生模型在网络前向时已经“适应”了量化误差最终的泛化能力会更好。5. vLLM为推理服务换上高效的调度引擎5.1 vLLM 核心机制PagedAttention 与 Continuous Batching前面讲的技术都在“让单次推理更快、模型更小”而 vLLM 的目标是“让同一块 GPU 服务更多并发请求”。它的成名之作是 PagedAttention思想灵感来自操作系统的虚拟内存分页机制。大模型推理时每次生成一个 token 都要读取历史 token 的 KV Cache键值缓存来计算注意力。这个 Cache 的大小与序列长度成线性关系而且不同请求的长度差异巨大如果预先分配固定大小的显存块会浪费大量空间。PagedAttention 把 KV Cache 切割成固定大小的块Block通过一块逻辑页表Block Table映射到显存中的物理块。这样显存分配不再需要连续的大块空间碎片化的显存都能被利用起来而且多个物理块可以给不同请求复用大大减少了显存浪费。这个机制带来的最直接收益是支持的并发数翻了数倍长上下文请求也不会因 OOM 被拒。Continuous Batching连续批处理则是另一个独立的核心优势。传统的批处理方式必须等一个 batch 中所有序列都生成完毕才能释放显存然后接下一批请求所以慢请求会拖慢整个 batch。Continuous Batching 允许在请求级做到动态调度某个序列生成了终止符 EOS它占用的显存立即被释放新请求马上插入。这个能力让吞吐量的提升非常明显官方测试中比 Hugging Face 原生的生成管线提升了数倍。5.2 vLLM 部署配置与参数说明接入 vLLM 大致只需要三步安装、加载模型、启动服务。如果是用OpenAI兼容的 API 接口可以直接用vllm serve命令它默认暴露一个与 OpenAI 接口格式一致的端点这样你能无缝切换到生产环境。pip install vllm python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --quantization awq \ --max-model-len 4096 \ --tensor-parallel-size 2这里几个关键参数值得展开。--max-model-len决定了 KV Cache 的上限如果业务上不需要超长上下文建议调低因为 KV Cache 会占大量显存。--tensor-parallel-size代表张量并行度当模型单卡放不下时可以跨卡分片比如 2 代表用两张 GPU 同时计算。还有--swap-space参数控制 CPU 显存交换的缓冲分区如果 GPU 显存紧张可以把一部分 KV Cache 换到 CPU 内存但延迟会相应升高不建议业务在线推理场景开启。vLLM 还提供了更细粒度的调度参数比如--max-num-batched-tokens和--max-num-seqs。前者控制每个 batch 内 token 的总数后者控制单个 batch 内最大序列数。如果它们设得太高调度器会把一次性显存占用推高容易 OOM设得太低又会影响吞吐。实际操作时建议先用默认值跑通再用监控工具观察 GPU 显存利用率逐次调大 batch 上限直到显存利用率达到 90% 左右就是比较理想的配置。5.3 vLLM 在量化模型上的搭配经验vLLM 原生支持多种量化格式的加载包括AWQ、GPTQ、FP8等。其中AWQ因为出色的精度表现和相对简单的推理流程是目前最推荐的搭配。实际使用时只需在加载命令里加上--quantization awqvLLM 会自动识别并调用对应的量化内核无需额外写代码。有一个非常大的性能陷阱如果后端的内核不支持某种量化格式vLLM 会自动回退到“反量化后走 FP16 计算”这样不仅没有加速反而因为多了一次反量化操作拖慢了速度。所以在选定量化方案前一定要查清楚目标 GPU 和 vLLM 当前版本对量化 kernel 的支持情况。尤其是在老显卡比如 GTX 1080 Ti 这种没有高效 INT8 pipeline 的卡上AWQ 的收益会大打折扣因为 INT8 Kernel 并不总能比 FP16 Kernel 快。如果服务的是极长上下文的场景比如 RAG检索增强生成的文档问答那么 vLLM 的 PagedAttention 收益会特别显著。此时建议把--max-model-len调到足够大同时搭配 INT8 或 INT4 量化把 KV Cache 进一步压缩这样既能扛住长上下文又能保持高并发。我实测过在相同的 80G 显存卡上跑 32K 上下文的 13B 模型原始 FP16 只能同时处理 2 个请求AWQ INT4 vLLM 可以处理 6 个请求且延迟基本不变这个差距在生产环境里几乎是决定性的。6. 四者结合端到端高效部署路线6.1 模型侧优化从 FP16 到可服务状态把前面的技术串起来一条比较成熟的路线是先做知识蒸馏或直接复用已有大模型然后做 AWQ 量化如果硬件和精度允许再在服务侧用 vLLM 部署。如果模型精度在量化后掉点严重我再补一轮稀疏化 LoRA 微调来恢复精度。以一个实际的 13B 模型部署项目为例我的完整流程是这样用 7B 教师模型蒸馏出一个 1.3B 的学生模型用于高并发、低时延的线上主服务。对学生模型做 AWQ INT4 量化目标是把 FP16 的 2.6GB 权重压缩到约 650MB。量化后用 vLLM 部署启动 4 个 worker 实例负载均衡分发请求。在高峰期观察 GPU 利用率。如果发现吞吐不够就增加--max-num-seqs如果显存不够就先降低--max-model-len或开启--swap-space。6.2 服务侧优化vLLM 的参数调优清单vLLM 参数调优不能盲目照搬。我总结了一份实用清单按优先级排序优先级参数推荐值说明高--max-model-len128~512不服务超长上下文就尽量调低高--quantizationawq / gptq必须匹配模型权重格式中--tensor-parallel-size1~2模型放得下就保持 1中--max-num-seqs16~32需要实测显存利用率后调整低--swap-space0~4显存紧张时使用有延迟代价另外监控指标不能只看 GPU 利用率。vLLM 暴露了vllm:generation_tokens_total、vllm:num_requests_running、vllm:num_requests_waiting这几个关键指标通过 Prometheus 拉取后可以直观看到请求的排队情况。如果 waiting 数值经常大于零说明系统已经超负荷如果 running 一直低于并发上限可能模型计算本身慢了需要回看量化是否有加速效果。6.3 叠加使用时的先后顺序和性能预算最后强调一个容易忽略的点这四个优化手段的收益并不是线性叠加的。量化减了 4 倍体积稀疏化减了 2 倍计算量vLLM 提升了几倍吞吐但叠加起来并非 8 倍收益因为最终瓶颈会转移到访存带宽、算子实现和调度器的开销上。合理的预期是模型体积压缩到原来的四分之一吞吐提升 2~4 倍单请求延迟降低 30%~50%这已经是很好的结果了。跑一次性能基线Benchmark是必须的。我习惯用vllm bench或者自写脚本模拟真实并发曲线分别测 FP16 基线、AHQ 量化、加不加稀疏化这几个版本然后把吞吐曲线画出来。这样不仅能看到平均性能还能看到 p99 延迟分布非常有利于定位“偶发超时”问题。7. 常见问题与排查技巧实录7.1 量化掉点严重、校准无效怎么处理最大的坑往往是模型本身不够健壮比如微调过的 LoRA 权重没有完全 merge 回主模型或者模型中间层存在没有被统一封装的nn.Linear层。此时先检查模型结构把所有需要量化的层单独列出来确认没有遗漏。其次检查校准数据集是否覆盖了真实业务样本。如果业务里全是长尾、异常输入而校准集用的是干净语料量化后的模型基本会“失忆”。解决办法是直接在线上抓最近的请求日志做采样清洗后作为校准集。7.2 vLLM 启动报错 CUDA error: out of memory绝大多数情况是 KV Cache 预估超标。如果模型权重本身能塞进显卡但启动时仍然 OOM可以调低--max-model-len或者调低--max-num-seqs。另外检查是否用了--gpu-memory-utilization参数这个参数用于控制 vLLM 最多占用多少比例的显存建议设置为 0.9 左右给推理过程和调度器留一点余量。如果设置 1.0很容易在峰值显存下崩溃。7.3 量化后模型在 vLLM 中反而变慢遇到这种情况先确认量化格式是不是被原生支持。以 AWQ 为例在较新版本的 vLLM 中sm80 以上的 GPU 已经原生支持 INT4 GEMM但部分旧架构需要回退到 FP16 内核。此时无论怎么调参量化都不会带来加速。另一个可能原因是模型里个别层比如归一化层、Embedding 层做了不必要的量化这些层用 FP16 反而更快因为它们涉及的矩阵乘较小量化的 cache 收益覆盖不了反量化开销。建议对每一层单独做时延 profiling再把慢的层回退到 FP16。7.4 蒸馏后的学生模型即使训练得很好在长上下文场景却效果崩掉这里有一个非常隐蔽的问题教师模型和学生模型的上下文窗口往往不同。比如教师支持 8192 token学生只训练到 2048 token。推理时如果输入超过 2048学生模型会直接忽略某些 token导致输出混乱。解决方法是统一上下文长度在蒸馏训练时就把学生的序列长度顶到与教师一致。如果资源不够至少在服务端限定--max-model-len不超过学生的训练长度宁可截断也不能硬撑。7.5 多卡并行时效果不对、显存不平衡vLLM 的--tensor-parallel-size需要遵循“显存小的卡当瓶颈”的原则。如果一个 70B 模型用 2 张 80G 卡做张量并行而另一张只有 40G会直接失败。建议把同一型号、同一显存容量的卡组成一个 Tensor ParallelTP组。另外TP 组内通信走 NVLink如果卡间没有 NVLink 而是走 PCIe通信开销会暴涨。此时不如考虑 Pipeline ParallelPP虽然实现麻烦一点但跨节点通信压力小得多。8. 从零到一的一键化部署脚本实例8.1 模型准备与目录结构为了让你能直接照着做我给出一个可落地的脚本目录结构。假设你已经有量化好的模型保存目录如下models/ my-awq-model/ config.json model.safetensors quant_config.json tokenizer.json vllm_serve.shquant_config.json是量化过程的输出vLLM 启动时如果模型目录里有它就能自动识别量化格式不需要手动传--quantization参数。这一点非常方便推荐在 AWQ 量化之后就直接把它存到模型目录里。8.2 服务启动脚本与健康检查这里给出一个生产可用的启动脚本模板包括显存设置、调度参数和建议的日志级别#!/bin/bash export CUDA_VISIBLE_DEVICES0,1 python -m vllm.entrypoints.openai.api_server \ --model /data/models/my-awq-model \ --served-model-name my-model \ --tensor-parallel-size 2 \ --max-model-len 2048 \ --max-num-seqs 32 \ --gpu-memory-utilization 0.92 \ --disable-log-requests \ --port 8000启动后可以用curl做一次简单健康检查curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model:my-model,messages:[{role:user,content:你好}]}生产环境中建议再加一层进程守护比如用supervisord或 Docker Compose 管理 vLLM 进程并配置 Prometheus 抓取/metrics端点来采集吞吐、排队等指标。8.3 用 Docker 部署的一致性保障跨环境部署时环境差异是最大的隐性成本。推荐直接用现成的 vLLM 官方镜像保证 CUDA 版本和内核版本一致。Docker 启动时记得加--ipchost和--shm-size1g否则多进程通信时共享内存会不够报奇怪的段错误。docker run --runtime nvidia --ipchost --shm-size1g \ -p 8000:8000 \ -v /data/models:/models \ vllm/vllm-openai:latest \ --model /models/my-awq-model \ --served-model-name my-model \ --tensor-parallel-size 2 \ --max-model-len 2048这个镜像在跑 AWQ 量化模型时特别稳因为内置的 CUDA kernel 版本和模型要求的版本是匹配的。如果自己从源码编译 vLLMCUDA 版本不对会出现非常隐蔽的算术错误排查成本极高。能直接用官方镜像就直接用不要花时间在环境上。我在几次部署实战中得到的最大体会是量化、稀疏化、知识蒸馏和 vLLM 这四个技术单独拎出来都有各自的局限但一旦组合起来效果就不是简单的加法而是“把每一份显存和计算都花在刀刃上”的系统工程。配合可观测指标和充分的性能基线测试这条路线的收益被证明是非常稳定的。希望这篇拆解能帮你少走弯路尤其是校准、内核支持、上下文长度这几个容易踩坑的地方提前规避部署流程会顺畅很多。