企业官网建设流程全解析

模型量化与推理引擎底层优化开发短记：先确认瓶颈是否在权重

量化能减少权重占用，但不等于每个模型和每种请求都会更快。推理时还会用到 KV Cache、激活值、临时 workspace 和通信缓冲区；因此，显存下降、吞吐提高与输出质量的变化需要分别测量。

开始前固定模型修订版本、tokenizer、推理引擎、量化方法、GPU 驱动和请求集。请求集至少覆盖短输入、长上下文和不同输出长度。记录 TTFT、TPOT、每秒输出、显存峰值、GPU 利用率和失败请求，并保存生成结果用于质量抽查。只比较单个平均值，很容易掩盖长请求的退化。

如果量化后显存反而紧张，先拆分显存构成：权重是否减少、KV Cache 是否因并发和上下文长度扩大、引擎是否额外申请了 workspace。若速度没有改善，则检查量化 kernel 是否被当前 GPU 支持，以及数据是否在格式转换或 CPU-GPU 传输中等待。

试验时把并发、最大上下文和批处理窗口作为独立变量。每轮只修改一项，保留失败日志和恢复参数。选型不应只问“哪种精度更低”，而应在目标模型、请求分布和可接受的输出偏差下，选择能稳定运行并便于回退的配置。

上线后的告警也应区分容量不足和引擎异常：前者常与上下文长度、并发有关，后者可能伴随 kernel 报错或进程退出。两类事件的回退动作并不相同，值班手册需要分别写明。

质量抽查应由熟悉业务的人按固定维度完成，例如事实遗漏、格式破坏和工具调用偏差，并记录模型输出对应的样本编号。

成本统计需同时包含空闲容量和重试消耗。

验收时保留可读的输出对照，而非只保留性能仪表盘截图；这样质量回退能与系统参数变化关联起来。