模型量化与推理引擎底层优化开发短记先确认瓶颈是否在权重量化能减少权重占用但不等于每个模型和每种请求都会更快。推理时还会用到 KV Cache、激活值、临时 workspace 和通信缓冲区因此显存下降、吞吐提高与输出质量的变化需要分别测量。开始前固定模型修订版本、tokenizer、推理引擎、量化方法、GPU 驱动和请求集。请求集至少覆盖短输入、长上下文和不同输出长度。记录 TTFT、TPOT、每秒输出、显存峰值、GPU 利用率和失败请求并保存生成结果用于质量抽查。只比较单个平均值很容易掩盖长请求的退化。如果量化后显存反而紧张先拆分显存构成权重是否减少、KV Cache 是否因并发和上下文长度扩大、引擎是否额外申请了 workspace。若速度没有改善则检查量化 kernel 是否被当前 GPU 支持以及数据是否在格式转换或 CPU-GPU 传输中等待。试验时把并发、最大上下文和批处理窗口作为独立变量。每轮只修改一项保留失败日志和恢复参数。选型不应只问“哪种精度更低”而应在目标模型、请求分布和可接受的输出偏差下选择能稳定运行并便于回退的配置。上线后的告警也应区分容量不足和引擎异常前者常与上下文长度、并发有关后者可能伴随 kernel 报错或进程退出。两类事件的回退动作并不相同值班手册需要分别写明。质量抽查应由熟悉业务的人按固定维度完成例如事实遗漏、格式破坏和工具调用偏差并记录模型输出对应的样本编号。成本统计需同时包含空闲容量和重试消耗。验收时保留可读的输出对照而非只保留性能仪表盘截图这样质量回退能与系统参数变化关联起来。