企业官网建设流程全解析

1. 推理优化与部署的整体思路拆解

1.1 为什么推理优化是模型落地的第一道门槛

训练一个大模型，动辄几十上百张卡跑几周，但真正决定一个模型能不能用起来、用得起、用得稳的，其实是推理阶段。我见过太多团队，模型训得漂漂亮亮，指标刷得飞起，结果一上线就傻眼：单次请求延迟两秒起步，并发一上来显存直接爆，一张A100跑一个7B模型只能扛住个位数的QPS。这不是模型不行，是推理优化没做。

推理优化要解决的核心矛盾就三个字：快、省、稳。快是指延迟低、吞吐高；省是指显存占用小、单位算力成本低；稳是指长跑不崩、并发不抖。这三个目标彼此拉扯，你量化到INT4确实省显存了，但精度可能掉；你上蒸馏确实快了，但学生模型可能学不到老师的全部本事。所以推理优化从来不是单一技术的堆叠，而是一套组合拳，得根据你的业务场景、硬件条件、精度容忍度来动态权衡。

这篇文章我想把量化、蒸馏这两条主流路线讲透，再聊聊模型选型和部署落地的实操细节。适合谁看？如果你正在做模型上线、做端侧部署、做私有化交付，或者单纯想搞清楚为什么别人的模型跑得比你快，那这篇内容应该能帮你省下不少试错时间。

1.2 量化、蒸馏、模型选型三者的关系

很多人把量化、蒸馏、模型选型当成三个独立的话题，其实它们是一条链上的三个环节。模型选型决定你用什么底座，是选Qwen还是选DeepSeek，是选7B还是选72B，这一步决定了你的上限和成本基线。蒸馏决定你能不能把大模型的能力迁移到小模型上，让你在保持可接受精度的前提下，把推理成本降一个数量级。量化决定你最终部署时用什么数值精度，FP16、INT8还是INT4，这一步直接影响显存占用和推理速度。

我通常的建议是：先选型定方向，再蒸馏压规模，最后量化抠细节。顺序反了会很难受，比如你先量化了一个72B模型到INT4，发现还是跑不动，再想蒸馏就得多走一遍流程。反过来，你先蒸馏出一个3B的学生模型，再对它做INT8量化，部署起来就轻松很多。

注意：蒸馏和量化不是互斥的，可以叠加使用。一个蒸馏后的3B模型再做INT8量化，显存占用可以压到2GB以内，消费级显卡就能跑。

1.3 不同场景下的优化策略选择

场景不同，优化策略完全不一样。我大致分三类来说。

云端高并发服务：这种场景下吞吐量是核心指标，延迟可以稍微放宽。优先考虑量化到INT8，配合vLLM这类支持PagedAttention的推理框架，把batch size拉大，把GPU利用率吃满。蒸馏在这里不是必须的，因为云端通常有足够的算力，用大模型直接量化部署反而精度更有保障。

端侧或边缘设备部署：比如RK3588、Jetson这类板子，显存和算力都极其有限。这种场景下蒸馏是刚需，你得先把模型压到1B到3B这个量级，然后再做INT8甚至INT4量化。部署框架也得换，ONNX Runtime或者TensorRT是更常见的选择，vLLM在这种场景下反而太重了。

私有化交付：客户给你一台服务器，可能是4090也可能是A100，你得在有限硬件上跑出可接受的性能。这种场景最考验综合能力，量化、蒸馏、框架选型都得考虑，还得留出余量应对客户的并发波动。我的经验是，私有化交付优先选7B左右的模型，蒸馏到3B做备选，量化到INT8做默认配置，INT4做极限配置。

2. 量化技术深度解析与实操要点

2.1 量化的基本原理：从FP16到INT8到底发生了什么

量化的本质，是把模型权重和激活值从高精度浮点数映射到低精度整数。FP16每个参数占2字节，INT8占1字节，INT4占0.5字节。一个7B模型，FP16需要14GB显存，INT8需要7GB，INT4只需要3.5GB。这就是为什么量化能让大模型跑在消费级显卡上的根本原因。

但量化不是简单的截断。浮点数的动态范围很大，INT8只有256个离散值，直接映射会丢失大量信息。所以量化通常分两步：先统计权重的分布范围，确定一个缩放因子（scale）和零点（zero point），然后把浮点数线性映射到整数区间。推理时再把整数反量化回浮点数参与计算。

这里有个关键概念叫校准（Calibration）。因为激活值的分布是随输入变化的，你没法提前知道每一层的激活范围。所以需要拿一批代表性数据跑一遍模型，统计每层激活的最大值最小值，确定量化参数。校准数据的质量和数量直接影响量化后的精度，我一般建议至少准备500到1000条覆盖真实场景的样本。

2.2 PTQ与QAT：两种量化路线的取舍

量化分两大流派：训练后量化（PTQ）和量化感知训练（QAT）。

PTQ就是拿训练好的模型直接量化，不需要重新训练。优点是快，几十分钟就能搞定；缺点是精度损失可能比较大，尤其是量化到INT4的时候。PTQ适合对精度要求不那么极致的场景，比如对话生成、文本摘要这类任务，掉一两个点用户基本感知不到。

QAT是在训练过程中模拟量化误差，让模型提前适应低精度计算。优点是精度保持得好，INT4量化后精度损失可以控制在1个点以内；缺点是需要重新训练，成本高，而且需要原始训练数据和训练流程。QAT适合对精度敏感的场景，比如分类、检索、金融风控这类任务。

我的建议是：先试PTQ，如果精度达标就用PTQ，不达标再考虑QAT。大部分场景下PTQ的INT8量化精度损失都在可接受范围内，只有INT4才需要认真考虑QAT。

2.3 实操：用GPTQ和AWQ量化一个7B模型

目前主流的PTQ量化方案有GPTQ、AWQ、GGUF几种。GPTQ出现最早，生态最成熟；AWQ在精度上通常略好于GPTQ，尤其是INT4；GGUF是llama.cpp用的格式，适合CPU推理。

我以AWQ为例，走一遍量化流程。假设你有一个Qwen2.5-7B的模型，想量化到INT4。

第一步，安装依赖：

pip install autoawq transformers datasets

第二步，准备校准数据。我一般从训练集里抽512条，覆盖不同长度和不同任务类型：

from datasets import load_dataset dataset = load_dataset("your_dataset", split="train") calib_data = dataset.select(range(512))

第三步，执行量化：

from awq import AutoAWQForCausalLM from transformers import AutoTokenizer model_path = "Qwen/Qwen2.5-7B" quant_path = "Qwen2.5-7B-AWQ" model = AutoAWQForCausalLM.from_pretrained(model_path) tokenizer = AutoTokenizer.from_pretrained(model_path) quant_config = { "zero_point": True, "q_group_size": 128, "w_bit": 4, "version": "GEMM" } model.quantize(tokenizer, quant_config=quant_config, calib_data=calib_data) model.save_quantized(quant_path) tokenizer.save_pretrained(quant_path)

这里有几个参数值得说明。q_group_size是分组量化的组大小，128是常用值，越小精度越高但量化参数越多。w_bit是权重量化位数，4就是INT4。version选GEMM适合GPU推理，选GEMV适合CPU推理。

量化完成后，你可以用lm-eval-harness跑一遍评测，对比量化前后的精度差异。我实测下来，Qwen2.5-7B量化到INT4后，在MMLU上掉大约2个点，在C-Eval上掉大约1.5个点，对话场景基本感知不到差异。

注意：量化后的模型必须用支持对应量化格式的推理框架加载。AWQ模型需要vLLM或AutoAWQ来加载，直接用transformers加载会报错。

2.4 量化避坑指南：精度掉了怎么排查

量化后精度掉得厉害，是最常见的问题。我总结了几条排查思路。

第一，检查校准数据。校准数据如果和真实场景分布差异太大，量化参数就会偏。比如你用英文数据校准一个中文模型，激活分布完全对不上，精度肯定崩。校准数据一定要覆盖真实场景的输入分布。

第二，检查量化配置。q_group_size设太大，比如256或512，精度会明显下降。我一般建议128起步，如果精度还不够就降到64。w_bit从4降到8，精度会大幅提升，但显存占用翻倍，得权衡。

第三，检查敏感层。有些层对量化特别敏感，比如第一层和最后一层，还有attention的某些投影层。AWQ和GPTQ都支持保留部分层为FP16，你可以通过配置把敏感层排除在量化之外。代价是显存占用会增加，但精度能救回来不少。

第四，对比激活量化。权重量化和激活量化是两回事。AWQ主要做权重量化，激活还是FP16。如果你用的是SmoothQuant这类同时量化激活的方案，精度损失会更大，需要更仔细地调参。

3. 蒸馏技术深度解析与实操要点

3.1 蒸馏的核心思想：学生怎么学到老师的本事

蒸馏的概念不复杂：一个大模型叫老师，一个小模型叫学生，让学生去模仿老师的输出分布。关键在于，学生学的不是硬标签（比如分类任务里的0和1），而是老师的软标签（比如老师输出的概率分布）。软标签里包含了类间相似性信息，比如老师告诉你这张图是猫的概率0.7、是狗的概率0.2、是兔子0.1，学生就能学到猫和狗比较像、和兔子不太像这种知识。

对大语言模型来说，蒸馏通常分两种：黑盒蒸馏和白盒蒸馏。黑盒蒸馏只能拿到老师的输出文本，学生去模仿老师的生成结果；白盒蒸馏能拿到老师的logits，学生去拟合老师的概率分布。白盒蒸馏效果更好，但需要能访问老师的内部状态。

还有一种叫特征蒸馏，让学生去拟合老师中间层的特征表示。这种在视觉模型里用得多，大语言模型里也有用，但实现起来更复杂。

3.2 黑盒蒸馏与白盒蒸馏的实操差异

黑盒蒸馏实现简单，你只需要拿老师模型生成一批数据，然后用这批数据去微调学生模型。比如你想蒸馏一个DeepSeek-R1到Qwen2.5-3B，可以这样做：

第一步，用老师模型生成训练数据：

from transformers import AutoModelForCausalLM, AutoTokenizer teacher_path = "deepseek-ai/DeepSeek-R1" teacher = AutoModelForCausalLM.from_pretrained(teacher_path, device_map="auto") tokenizer = AutoTokenizer.from_pretrained(teacher_path) prompts = load_your_prompts() outputs = [] for prompt in prompts: inputs = tokenizer(prompt, return_tensors="pt").to(teacher.device) with torch.no_grad(): generated = teacher.generate(**inputs, max_new_tokens=512) outputs.append(tokenizer.decode(generated[0], skip_special_tokens=True)) save_to_json(outputs, "distill_data.json")

第二步，用生成的数据微调学生模型：

python finetune.py \ --model_name Qwen/Qwen2.5-3B \ --dataset distill_data.json \ --epochs 3 \ --lr 2e-5 \ --batch_size 4

黑盒蒸馏的优点是简单，不需要老师的logits，甚至可以用API调用的方式获取老师输出。缺点是学生只能学到老师的最终输出，学不到老师的推理过程。对于推理类任务，这个损失比较大。

白盒蒸馏需要拿到老师的logits，实现上复杂一些。核心是定义一个KL散度损失，让学生输出的概率分布逼近老师：

import torch.nn.functional as F def distillation_loss(student_logits, teacher_logits, temperature=2.0): student_probs = F.log_softmax(student_logits / temperature, dim=-1) teacher_probs = F.softmax(teacher_logits / temperature, dim=-1) return F.kl_div(student_probs, teacher_probs, reduction="batchmean") * (temperature ** 2)

温度参数temperature控制软标签的平滑程度。温度越高，概率分布越平滑，学生能学到的类间关系越多。但温度太高也会引入噪声，一般2到5之间比较合适。

3.3 蒸馏实操：从72B到7B的完整流程

我拿一个实际项目举例：把Qwen2.5-72B蒸馏到Qwen2.5-7B，目标是保留72B在代码生成任务上80%的能力。

第一步，数据准备。我从代码数据集里抽了5万条指令-响应对，覆盖Python、JavaScript、Go、SQL等语言。然后用72B模型对每条指令重新生成响应，作为蒸馏数据。

第二步，数据过滤。72B生成的响应不一定都对，我用单元测试和语法检查过滤掉明显错误的样本，最终保留约4.2万条高质量数据。

第三步，训练配置。学生模型用Qwen2.5-7B，学习率2e-5，batch size 32，训练3个epoch。损失函数用标准的交叉熵，因为这是黑盒蒸馏，拿不到老师的logits。

第四步，评测。在HumanEval上，72B的pass@1是85%，蒸馏后的7B是68%，保留了80%的能力。在MBPP上，72B是78%，7B是62%，保留率约79%。这个结果基本达到预期。

注意：蒸馏数据里如果混入了老师的错误输出，学生也会学到错误。所以数据过滤这一步不能省，宁可少一点，也要保证质量。

3.4 蒸馏的常见误区与效果评估

蒸馏有几个常见的坑，我一个个说。

误区一：蒸馏就是让小模型变大模型。不是的。蒸馏的本质是知识迁移，学生模型的能力上限受限于自身容量。你把72B蒸馏到0.5B，再怎么蒸馏也达不到7B的水平。学生模型和老师模型的参数量差距最好控制在10倍以内，超过这个比例，蒸馏效果会急剧下降。

误区二：蒸馏数据越多越好。数据质量比数量重要。1万条高质量数据，效果可能好过10万条低质量数据。我一般建议蒸馏数据在1万到5万条之间，具体看任务复杂度。

误区三：蒸馏一次就完事。蒸馏是个迭代过程。第一轮蒸馏后，评测学生模型的弱项，针对弱项补充数据，再蒸馏一轮。我通常至少做两轮，效果比一轮有明显提升。

误区四：只看最终指标。蒸馏后的模型可能在整体指标上不错，但在某些细分场景上崩了。比如代码生成整体pass@1还行，但特定语言的生成质量很差。所以评测要分场景、分维度做，不能只看一个总分。

4. 主流模型选型与部署落地指南

4.1 模型选型的核心维度：不是越大越好

选模型不是选最大的，是选最合适的。我一般从五个维度来评估：任务匹配度、参数量、推理成本、生态成熟度、许可协议。

任务匹配度是第一位。你做代码生成，就选代码能力强的模型；你做中文对话，就选中文语料充足的模型；你做数学推理，就选推理链能力强的模型。别拿一个通用模型硬套所有任务，效果往往不如专用模型。

参数量决定推理成本。7B模型在A100上FP16推理，单卡能跑，延迟可接受；72B模型至少需要4卡，成本高一个数量级。如果你的场景对精度要求不是极致，7B到14B通常是性价比最高的区间。

生态成熟度很重要。模型有没有官方量化版本、有没有vLLM支持、有没有社区微调版本，这些直接影响你的落地效率。有些模型虽然指标好看，但生态不完善，你得自己写推理代码、自己做量化，时间成本很高。

许可协议容易被忽略。商用场景一定要看清楚模型许可，有些模型禁止商用，有些要求署名，有些对用户量有限制。这个坑踩一次就够了。

4.2 不同硬件条件下的模型部署方案

硬件条件直接决定你能选什么模型、用什么部署方案。我分几种常见情况来说。

单卡4090（24GB显存）：这是最常见的私有化部署配置。FP16下能跑7B模型，INT8下能跑14B，INT4下能跑32B。我的建议是7B模型做INT8量化，留出显存给KV Cache和并发。部署框架选vLLM，开启PagedAttention，batch size设到16到32，QPS能到20以上。

单卡A100（80GB显存）：FP16下能跑32B，INT8下能跑72B，INT4下能跑100B以上。这种配置下我建议直接上32B模型做INT8，精度和速度都能兼顾。如果并发要求高，可以降到14B，把batch size拉大。

多卡A100集群：这种配置下可以考虑72B甚至更大的模型。用vLLM的张量并行，4卡跑72B的INT8，吞吐量很可观。但要注意卡间通信开销，张量并行度不是越高越好，一般4到8卡比较合适。

边缘设备（RK3588、Jetson Orin）：这种场景下模型必须压到1B到3B，量化到INT8或INT4。部署框架用ONNX Runtime或TensorRT，vLLM太重了跑不动。RK3588上跑YOLOv8做视觉任务比较常见，大语言模型的话，Qwen2.5-1.5B量化后能跑，但延迟在秒级。

4.3 部署框架选型：vLLM、TensorRT、ONNX Runtime怎么选

部署框架的选择，核心看你的场景和硬件。

vLLM是目前GPU上部署大语言模型最主流的框架。它的核心优势是PagedAttention，把KV Cache分页管理，显存利用率比朴素实现高好几倍。连续批处理（Continuous Batching）让吞吐量大幅提升。vLLM支持AWQ、GPTQ、FP8等多种量化格式，生态很完善。缺点是只支持GPU，CPU场景用不了。

TensorRT是NVIDIA的推理优化框架，能把模型编译成高度优化的引擎。在固定输入形状的场景下，TensorRT的性能通常是最好的。但它对动态形状支持一般，编译过程也比较耗时。适合输入长度相对固定的场景，比如分类、检索。

ONNX Runtime是跨平台的推理框架，CPU、GPU、边缘设备都能跑。性能不如vLLM和TensorRT，但胜在通用性好。边缘设备部署基本都用ONNX Runtime，配合INT8量化，能在有限算力下跑出可接受的性能。

我的选型逻辑很简单：GPU上跑大语言模型，首选vLLM；固定形状的视觉模型，选TensorRT；边缘设备或CPU场景，选ONNX Runtime。

4.4 部署实操：vLLM加载量化模型的完整配置

我以vLLM加载AWQ量化模型为例，走一遍部署流程。

第一步，安装vLLM：

pip install vllm

第二步，启动服务：

python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-AWQ \ --quantization awq \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 32 \ --port 8000

几个关键参数说明。--quantization awq指定量化格式，vLLM会自动识别AWQ模型。--max-model-len是最大上下文长度，设太大显存占用高，设太小长文本会截断。--gpu-memory-utilization控制显存利用率，0.9表示用90%的显存，留10%给系统。--max-num-seqs是最大并发序列数，直接影响吞吐量。

第三步，压测。用locust或wrk做并发测试，观察QPS和延迟：

wrk -t4 -c32 -d60s http://localhost:8000/v1/completions

我实测下来，Qwen2.5-7B-AWQ在4090上，max-num-seqs设32时，QPS能到25左右，P99延迟在800ms以内。如果把max-num-seqs降到16，QPS降到18，但P99延迟降到500ms以内。这个权衡看你的业务需求，是吞吐优先还是延迟优先。

注意：vLLM启动时会预分配显存，如果显存不够会直接报错。启动前先用nvidia-smi确认显存余量，gpu-memory-utilization不要设得太激进。

4.5 部署后的监控与调优：让服务稳定跑下去

部署上线只是开始，后续的监控和调优才是长期工作。我一般关注几个核心指标：QPS、P99延迟、显存占用、GPU利用率、错误率。

QPS和P99延迟反映服务性能，显存占用和GPU利用率反映资源使用效率，错误率反映服务稳定性。这几个指标要持续监控，设置告警阈值。

调优的方向无非几个：如果GPU利用率低但QPS上不去，说明batch size没吃满，可以调大max-num-seqs；如果P99延迟高但GPU利用率不高，说明有排队，可以加实例或调小batch size；如果显存占用高但QPS低，说明KV Cache占太多，可以调小max-model-len或降低并发。

我踩过的一个坑是：max-model-len设了32768，结果显存被KV Cache吃满，并发上不去，QPS只有个位数。后来降到8192，QPS直接翻了3倍。所以参数不是越大越好，得根据实际场景调。

5. 常见问题与排查技巧实录

5.1 量化后精度下降的排查清单

量化后精度下降是最常见的问题，我整理了一个排查清单，按优先级排序。

我遇到过一次精度崩得厉害的情况，排查了半天发现是校准数据用了英文，而实际场景是中文。换中文数据重新校准后，精度就回来了。所以校准数据这一步千万别偷懒。

5.2 蒸馏效果不达预期的调整思路

蒸馏效果不好，通常有几个原因。学生模型容量不够，学不到老师的能力；蒸馏数据质量差，学生学了错误的东西；训练不充分，学生还没收敛；损失函数设计不合理，学生学偏了。

我的调整顺序是：先检查数据质量，再检查训练配置，最后考虑换学生模型。数据质量是第一位，我一般会人工抽检100条蒸馏数据，看看老师的输出是不是合理。如果老师输出本身就有问题，学生肯定学不好。

训练配置方面，学习率是关键。学习率太大，学生学不稳；学习率太小，学生学得慢。我一般从2e-5起步，如果loss震荡就降到1e-5，如果loss下降太慢就升到5e-5。batch size也要注意，太小梯度噪声大，太大显存不够，32到64比较合适。

5.3 部署过程中的显存与并发问题

显存不够和并发上不去，是部署阶段的两大难题。

显存不够，先看模型本身占多少。7B模型FP16占14GB，INT8占7GB，INT4占3.5GB。然后看KV Cache占多少，KV Cache的大小和max-model-len、max-num-seqs、模型层数、注意力头数都有关。如果显存不够，优先降max-model-len，再降max-num-seqs，最后考虑换更小的模型或更低的量化精度。

并发上不去，先看GPU利用率。如果GPU利用率已经90%以上，说明算力吃满了，只能加卡或换更小的模型。如果GPU利用率不高但QPS上不去，说明有瓶颈在别处，可能是CPU预处理慢、网络带宽不够、或者框架的调度有问题。

我遇到过一次并发上不去的情况，排查发现是tokenizer成了瓶颈。tokenizer是Python实现的，单线程处理，并发一高就排队。后来换成了Rust实现的tokenizer，QPS直接翻倍。所以部署时别只盯着GPU，CPU侧的瓶颈也要关注。

5.4 模型选型的常见纠结与决策建议

选模型时最常见的纠结是：选大的还是选小的，选通用的还是选专用的，选新的还是选稳的。

我的建议是：先跑通再优化。别一上来就纠结选哪个模型，先拿一个7B的通用模型跑通全流程，量化、部署、压测都走一遍，心里有数了再根据实际瓶颈来调整。如果7B够用就不折腾，如果不够用再考虑蒸馏或换更大的模型。

选新的还是选稳的，我倾向于选稳的。新模型可能指标好看，但生态不完善，踩坑成本高。稳的模型社区资源多，遇到问题好查。除非新模型有不可替代的优势，否则我一般选发布半年以上、社区活跃的模型。

最后说一句，模型选型没有标准答案，只有适合你场景的答案。别人的推荐只能参考，最终还得自己跑评测、做对比。我一般会选2到3个候选模型，用真实数据跑一遍评测，看哪个最合适。

6. 推理优化与部署的实操心得

6.1 从项目实战中总结的几条经验

做了这么多推理优化和部署的项目，我总结了几条经验，都是踩坑踩出来的。

第一条，量化不是万能的。量化能省显存、提速度，但精度损失是实实在在的。INT8通常没问题，INT4就要小心了。如果业务对精度敏感，宁可多花点显存跑INT8，也别为了省显存跑INT4。

第二条，蒸馏要趁早。如果你确定最终要部署小模型，那在项目初期就应该规划蒸馏流程，而不是等大模型训完了再想蒸馏。蒸馏数据的准备、学生模型的选型、训练流程的设计，这些都需要时间。

第三条，部署框架要匹配量化格式。AWQ模型用vLLM加载，GPTQ模型用vLLM或ExLlama加载，GGUF模型用llama.cpp加载。格式不匹配，要么加载不了，要么性能很差。

第四条，压测要模拟真实场景。别用固定长度的输入压测，真实场景的输入长度是变化的。用真实数据压测，才能发现真正的问题。

第五条，留足余量。显存留20%余量，GPU利用率别超90%，并发别顶到上限。生产环境最怕的就是突发流量，留足余量才能扛住。

6.2 后续可以继续深挖的方向

推理优化这个领域还在快速演进，有几个方向值得继续关注。

FP8量化：H100和4090都支持FP8，精度比INT8好，速度比FP16快。vLLM已经支持FP8，后续可能会成为主流。

投机采样：用一个小模型做草稿，大模型做验证，能在保持精度的前提下提升推理速度。vLLM也支持这个特性，值得试试。

MoE架构：混合专家模型在推理时只激活部分参数，能在保持大模型容量的同时降低推理成本。DeepSeek系列就是MoE架构，部署时要注意专家并行的配置。

端侧推理：随着RK3588、Jetson这些设备性能提升，端侧跑大模型越来越可行。ONNX Runtime和TensorRT的端侧优化也在持续进步。

这些方向我后续会继续跟进，有新的实践心得再分享。推理优化没有终点，只有不断迭代。