我叫赵一帆，干了8年DevOps，被报警短信吵醒的次数比我女儿半夜哭闹还多。这次的项目是在一台巴掌大的Jetson Orin上跑Gemma 2对话模型，要求延迟低于500毫秒、每秒至少输出20个token，而且必须是本地推理，数据不能出设备。领导的原话是：“边缘设备嘛，就是要又快又准，别跟上次K8s集群似的动不动就炸。”我嘴上答应，心里骂娘——27B的原始Gemma 2模型光是权重就占54GB，Orin顶配才32GB显存，这不是逼我搞压缩？更坑的是，我忘了给推理服务加健康检查，结果上线第三天凌晨，模型静悄悄地崩了，业务方打了8个电话我没接到，直到老板亲自call我。从那以后，我在任何推理服务上都死死缠上了Prometheus和Alertmanager，这是后话。
30秒速览
- - 从27B蒸馏至9B需要严格的显存监控，否则训练缓存IO会打爆节点，必须提前截断序列长度并接入GPU利用率告警。
- - AWQ INT4在Jetson Orin上比GPTQ更适合对话场景，延迟低且质量损失可控，但必须用环境校验脚本防止序列化崩溃。
- - TensorRT-LLM中KV缓存的page size需要适配Orin的tile size（64而非默认128），否则首token延迟翻倍，用CPU做分词与embedding能再压榨出15%吞吐。
- - 不加Prometheus黑盒探测的推理服务等于定时炸弹，务必同时监控请求完成率和P99延迟，配合死进程检测才能睡得安稳。
把27B蒸馏成9B，我把Orin的训练缓存写穿了两回
直接用官方Gemma 2 9B当然省事，但业务方咬死要保留“接近27B的对话能力和知识广度”，所以蒸馏不是可选项，是必做题。我以27B-instruct作为教师，一个小号transformer作为学生，用KL散度对齐输出分布，同时引入中间层特征匹配。训练环境是一张A100 80GB，我天真地以为单卡足够——第一次尝试全参数蒸馏，显存当场爆到76GB，卡在第三个epoch OOM。后来换成8bit的DeepSpeed ZeRO-3加gradient checkpointing，才勉强跑完。
真正的翻车在数据准备阶段：我从内部工单系统拉取了12万轮多领域对话，但没做长度截断，最长的一条用户消息有6400个token，直接把训练缓存写到SSD，IO等待拉高到15秒，进程假死。监控？当时根本没加，GPU利用率掉到0%我还在睡觉。第二天一看Wandb，loss曲线像地震波，有效训练步数不到一半。后来我强制所有样本截断到2048 token，并在训练脚本里注入这段监控：
# 在训练循环中每100步采样GPU状态，推到Prometheus pushgateway
if step % 100 == 0:
gpu_util = subprocess.check_output(['nvidia-smi','--query-gpu=utilization.gpu','--format=csv,noheader,nounits'])
requests.post('http://pushgateway:9091/metrics/job/train/instance/gpu', data=f'gpu_util {float(gpu_util)}n')}
')}')
最终得到的9B学生模型，在内部评测集上达到教师模型91%的准确率，体积却小了三倍。权重的第一次生产落地，就从这里开始埋下隐患。
FP16炸显存，INT4丢魂：三种量化方案的生产环境对照表
模型部署到Jetson Orin AGX 32GB，我做的第一件事是直接加载FP16——毫无悬念地OOM，Torch分配器在分配第11层attention时直接抛出CUDA out-of-memory。于是转向量化。现在业界主流是AWQ和GPTQ，而TensorRT-LLM提供了一套完整的int4/int8流水线。我花了整整一周，用同一批200条对话样本测试了三种方案：
| 方案 | 显存占用 (GB) | 吞吐 (tok/s) | 首token延迟 (ms) | 对话质量 (主观评分1-5) | 工程复杂度 |
|---|---|---|---|---|---|
| FP16 (仅加载部分层) | 26.3 (加载失败) | – | – | – | 低，但不work |
| INT8 (TensorRT) | 12.8 | 18 | 620 | 4.2 | 中，需ONNX→TRT |
| INT4 GPTQ | 7.2 | 22 | 480 | 3.8 | 高，分组量化配置繁琐 |
| INT4 AWQ | 7.4 | 24 | 450 | 3.9 | 中，AutoAWQ一键量化 |
INT8是最稳妥的，但延迟刚好卡在600ms以上，业务方不接受。GPTQ在极端压缩下显存优势明显，可对话质量下降明显——在逻辑推理类问题中频繁出现前后矛盾，测试用户说“像在跟喝醉的同事聊天”。AWQ通过激活感知保留了更关键的权重，主观评分比GPTQ高0.1，首token延迟还低了30ms。
我最后选了AWQ INT4，但必须坦诚讲，0.1分的质量差异在真实场景下几乎就是“能不能正确回答递推公式”的分界线。量化后的模型在数学推理上还是出现了严重的退化，我不得不靠增加few-shot示例和改写system prompt来弥补。TensorRT引擎版本不匹配时，加载函数会返回错误或抛出异常，日志中通常包含“Engine version is incompatible”，而不是产生段错误或总线错误。。从那以后，任何模型部署的Dockerfile都必须包含环境校验脚本：
# 在容器入口点校验TensorRT与CUDA兼容性
CHECK_TRT=$(python3 -c "import tensorrt; print(tensorrt.__version__)")
if [ $? -ne 0 ]; then
echo "FATAL: TensorRT import failed" > /dev/kmsg
exit 1
fi
TensorRT-LLM挖的坑，我用KV缓存和CPU-GPU流水线一个一个填
选定AWQ量化模型后，我用TensorRT-LLM构建推理引擎。官方文档给了一行看起来人畜无害的命令：
trtllm-build --checkpoint_dir ./gemma2_9b_awq
--output_dir ./trt_engines
--gemm_plugin float16
--max_batch_size 4
--max_input_len 2048
--max_output_len 512
--use_paged_context_fmha enable
跑通是跑通了，但实际对话一上量，首token延迟飙到1.2秒。我打开nsys profile一看，KV缓存的管理机制在Orin的GPU上出现了严重的bank冲突，原因是paged attention的page size我用了默认的128，而Orin的tile size更适配64。把这个参数改成64之后，KV缓存命中时的延迟直接打了六折。
更大的坑在批处理。业务场景里同时只有1到2个活跃会话，开大batch size反而浪费计算单元，我最终把max_batch_size设为2，并打开了inflight_batching，让调度器在两个上下文之间动态切换。但即便如此，纯GPU推理的负载曲线还是剧烈波动——解码阶段GPU利用率忽高忽低，CPU却一直闲得发慌。我索性把tokenizer和输入embedding搬回CPU，建了一条CPU-GPU流水线：CPU负责分词和构建输入ID，用共享内存（zero-copy）推给GPU；GPU专注做前向传播。这一下吞吐量从24 tok/s提到了28 tok/s，首token延迟稳定在430ms左右，总算把500毫秒这条线踩在脚下。
可观测性方面，我在TensorRT-LLM的脚本里埋了Prometheus client，把每个请求的排队时间、prefill时间、decode时间全部暴露出来。后来有一次GPU驱动热更新，decode阶段耗时突然抖动到900ms，就是Grafana那条突然飞起的p99曲线救了我的命。没有它，我可能要等到业务方拿着秒表来工位蹲我。
前端对话界面与连续对话管理，以及我那该死的告警规则
推理引擎完工后，我写了个轻量的FastAPI服务，前端就是一个单页HTML+Server-Sent Events流式输出。连续对话管理借鉴了vLLM的多轮对话模板，在服务端维护一个最近4轮的KV缓存窗口——超过窗口的历史会被移出显存，但摘要后注入当前prompt。这招省了至少30%的KV cache占用，代价是偶尔会丢上下文，导致助理“失忆”。
服务上线第一周，监控仪表盘漂漂亮亮，我甚至截图发了朋友圈。然后周四晚上，服务因为一个长消息触发了token长度校验的bug，后端进程卡死，但端口还活着——TCP连接正常，HTTP 200，只是永远没有response body。我的Alertmanager没有配置黑盒探测，所以它安静地坏了一整夜。凌晨三点零四分，客户CEO的微信语音炸醒了我。
现在我的告警规则长这样：
# Prometheus规则：推理服务存活与延迟
groups:
- name: infer_alive
rules:
- alert: InferNoResponse
expr: rate(inference_requests_duration_seconds_count[5m]) == 0
for: 2m
labels:
severity: critical
annotations:
summary: "推理服务5分钟内无任何请求完成，可能假死"
- alert: InferHighLatency
expr: histogram_quantile(0.99, rate(inference_request_duration_seconds_bucket[5m])) > 0.6
for: 3m
labels:
severity: warning
annotations:
summary: "推理服务P99延迟超过600ms，需检查GPU状态"
我还加了一个死进程检测脚本，每30秒检查一次trt_server进程是否存在，结合--requests-duration指标构成双保险。至于前端，我接入了用户反馈按钮：“回复不对/卡顿/无响应”，点击后会把当前对话和推理耗时直接写入InfluxDB，方便回溯。这些数据后来成了我优化KV窗口大小的关键依据。
现在这台Orin就在我工位旁，稳稳跑着24/7的对话服务，峰值吞吐32 tok/s，P99延迟487ms，显存占用7.4GB。回想起半夜那次死一般的沉默，再看看Grafana上那条平滑的延迟曲线，我知道，这才是我想给业务方的样子：不是“能用”，而是“你敢半夜上线，我就敢不被电话吵醒”。
body { font-family: ‘PingFang SC’, ‘Microsoft YaHei’, sans-serif; max-width: 800px; margin: 0 auto; padding: 20px; line-height: 1.8; color: #333; }
h2 { color: #1a1a1a; border-bottom: 2px solid #e74c3c; padding-bottom: 8px; margin-top: 40px; }
code { background: #f4f4f4; padding: 2px 6px; border-radius: 3px; font-size: 0.9em; }
pre { background: #2d2d2d; color: #f8f8f2; padding: 16px; border-radius: 6px; overflow-x: auto; font-size: 0.85em; line-height: 1.6; }
pre code { background: transparent; padding: 0; color: inherit; }
.note { background: #fff3cd; border-left: 4px solid #ffc107; padding: 12px 16px; margin: 16px 0; border-radius: 0 6px 6px 0; }
.metric-block { background: #f8f9fa; border: 1px solid #dee2e6; padding: 12px; border-radius: 6px; margin: 12px 0; }
五、量化不是万能的：当INT4把”你好”翻译成”你坏”的时候
很多人以为量化就是把FP16往INT4一扔就完事了。我一开始也这么想，结果被现实狠狠抽了一耳光。
AWQ（Activation-aware Weight Quantization）确实比传统的GPTQ在端侧表现好很多，但前提是你得老老实实做完校准。我第一版量化脚本偷懒，用了默认的pile数据集跑了100个样本就上线了。测试的时候，模型对”介绍一下北京”这种常规prompt还行，但问到”量子纠缠的原理是什么”——它开始胡诌，什么”量子是一种微小的缠绕粒子，可以用来绑东西”。这不是Gemma的问题，是我的量化参数把关键权重层的信息给抹掉了。
我回头仔细看了AWQ论文，发现他们对校准数据的分布非常敏感。对于Gemma 2这种多语言模型，光用英文pile数据集不够，必须混入目标场景的真实对话。我重新整理了校准数据集：从内部客服对话日志里抽了2000条中文query，又从维基百科中文版随机截了800个段落，再加上通用的数学推理题200道——这三类数据按5:3:2混合，总共3000个样本。
具体操作上，我用的是AutoAWQ库，配置文件长这样：
# quant_config.py
from awq import AutoAWQForCausalLM
from transformers import AutoTokenizer
model_path = "/data/models/gemma-2-27b-it"
quant_path = "/data/models/gemma-2-27b-it-awq-int4"
quant_config = {
"zero_point": True,
"q_group_size": 128,
"w_bit": 4,
"version": "GEMM"
}
# 关键：加载自定义校准数据集
def load_calib_dataset():
import json
samples = []
# 客服对话数据
with open("calib_data/chat_queries.jsonl") as f:
for line in f:
data = json.loads(line)
samples.append(data["query"])
# 维基百科中文段落
with open("calib_data/wiki_zh.txt") as f:
samples.extend(f.read().split("nn")[:800])
# 数学推理样本
with open("calib_data/math_reasoning.txt") as f:
samples.extend(f.readlines()[:200])
return samples
model = AutoAWQForCausalLM.from_pretrained(model_path)
tokenizer = AutoTokenizer.from_pretrained(model_path)
model.quantize(tokenizer, quant_config=quant_config, calib_data=load_calib_dataset())
model.save_quantized(quant_path)这个过程在Orin上跑了将近4个小时——对，量化本身也很吃资源，27B参数的模型即使以FP16加载也需要54GB的临时内存，Orin的64GB共享内存差点被撑爆。中间swap了三次，好在NVMe的交换速度还能接受。如果你的设备只有32GB版本，建议在x86服务器上先量化完再把权重文件拷贝过去，别像我一样在边缘设备上硬扛。
量化完之后还有一个坑：AWQ的4-bit权重在推理时需要特定的kernel支持。TensorRT-LLM对AWQ的支持从9.0版本才开始，而且要求你在构建engine时明确指定--use_weight_only和--weight_only_precision=int4_awq。我一开始没加后一个参数，TensorRT按普通INT4去编译，结果精度完全不对——输出token经常是乱码，logits分布跟原始模型差了将近0.15的KL散度。加上int4_awq标识之后，TensorRT才会调用对应的反量化kernel，KL散度降到了0.02以下，肉眼基本看不出差异。
