第 12 章 生产级交付：4bit LLM 服务器与端侧视觉管线

最后一章不做新算法，而是把前面 11 章的所有成果组合成两个真实的生产系统：

1. 服务器侧：一个 Qwen2.5-3B-Instruct AWQ 4bit 模型，跑在单张 NVIDIA L4 上，用 vLLM 服务。
2. 端侧：一个 INT8 EfficientNet-Lite0 视觉管线，跑在 Apple M3 上，用 Core ML。

两者都从 checkpoint 一路走到"被观察的线上端点"——预发布测试门禁 + 上线后可观测性。这一章的底色是源码里反复强调的诚实规则（Honesty Rules）：每个数字都必须追溯到真实子进程或真实监控数据，不许估算，没测到的字段就写 null。

原书仓库 ch12/ 目录：ch12_serve_and_load.py、test_ch12.py、device/（vision_pipeline.py、op_placement.py、thermal_loop.py、powermetrics_sampler.py、device_exporter.py、observability/）。

12.1 服务器侧：vLLM + AWQ 4bit

ch12_serve_and_load.py 是服务器侧的总指挥，用 --mode 划分了几个严格阶段：

# 来自 ch12/ch12_serve_and_load.py（核心模式）
def mode_golden(cfg):      # 用 FP16/BF16 参考模型离线生成"黄金"答案
def mode_serve(cfg):       # 启动 vllm serve，等 /metrics 健康，然后常驻
def mode_sweep(cfg):       # 并发扫描 + 质量金丝雀（canary）
def mode_all(cfg):         # 一次跑完整个流程

第一步：golden（黄金基准）。 在上 4bit 模型之前，先用 FP16/BF16 的参考模型，用固定的金丝雀提示集（canary prompt set）、关闭采样（greedy）离线生成一组"标准答案"。这组答案就是 4bit 模型上线后要对比的基准。

第二步：serve。 启动 vllm serve 服务 AWQ 4bit 模型，阻塞到 /metrics 健康（_wait_metrics）。注意它先等 metrics 而不是等 ready——因为可观测性是上线的前提。

第三步：sweep（并发扫描）。 _drive_concurrency 以不同并发度压测，同时用 greedy 解码跑金丝雀提示，对比 4bit 输出和 golden 答案。这里的**质量金丝雀（quality canary）**非常关键：并发上去之后，不能只看吞吐，还要看质量有没有崩（某些推理系统在重载下会用近似解码，悄悄牺牲质量）。

mode_all 把 golden → serve → sweep 串成一条流水线，所有结果写进 results_serving.json。源码的诚实规则明确写着：vLLM metric names are VERSION-DEPENDENT——vLLM 的指标名会随版本变，所以脚本会先对 live /metrics 校验指标名再抓取，绝不硬编码。

12.2 可观测性：Prometheus + Grafana + DCGM

第 12 章把第 9 章"打包交付"往前推进到了运行时可观测性。ch12/device/observability/ 目录提供了一整套：

• Prometheus：抓取指标。
• Grafana：可视化仪表盘（gen_configs.py 生成配置，snapshot_dashboard.py 导出）。
• DCGM（服务器侧）：NVIDIA 的 GPU 监控，抓 GPU 利用率、显存、温度。
• Pushgateway + device_exporter.py（端侧）：device_exporter.py 是手写的端侧指标导出器，把 M3 上的数据推给 Prometheus。

这套栈回答了生产推理最核心的三个问题：

1. 服务健康吗？ 请求延迟、错误率、吞吐。
2. 硬件吃得住吗？ GPU 利用率、显存水位、温度（thermal_loop.py）。
3. 量化模型真的省了吗？ 对比 FP16 vs AWQ 的 tokens/sec、每 token 能耗、质量成本——这是第 1 章"为什么要量化"在生产侧的最终验收。

12.3 端侧：EfficientNet-Lite0 视觉管线的逐阶段分解

ch12/device/vision_pipeline.py 把第 11 章的发现放大了——用逐阶段计时器把端到端延迟拆开：

# 来自 ch12/device/vision_pipeline.py（核心）
@dataclass
class StageTimes:
    decode: float = 0.0      # 图片解码
    resize: float = 0.0      # 缩放
    normalize: float = 0.0   # 归一化
    infer: float = 0.0       # Core ML 推理
    post: float = 0.0        # 后处理（argmax）

def run_pipeline(...):
    # 对 N 张图片跑完整管线，记录每阶段耗时，输出端到端 p95
    ...

核心结论（第 11.4 节的正式验证）：EfficientNet-Lite0 的推理在 M3 上小于 5 毫秒，所以"亚秒级响应"的预算完全由前后处理决定，而不是前向推理。vision_pipeline.py 的源码注释直接写了这句话："infer is sub-5 ms on this device, so the sub-second budget is decided by pre/post, not the forward pass"。

这是全书最有代表性的"打脸"时刻——如果你只优化模型、忽略管线其他环节，你的亚秒目标永远完不成。

12.4 算子放置与热管理：Apple Silicon 上的硬约束

算子放置（op placement）：ch12/device/op_placement.py 用 MLComputePlan 精确统计 EfficientNet-Lite0 的算子落在 ANE / GPU / CPU 的比例：

# 来自 ch12/device/op_placement.py（核心）
_DEVICE_TO_UNIT = {
    "MLNeuralEngineComputeDevice": "ane",
    "MLGPUComputeDevice":          "gpu",
    "MLCPUComputeDevice":          "cpu",
}
# 用 MLComputePlan 读取编译后 .mlmodelc 的算子放置，统计各单元占比

它的价值在于：Apple 的硬件调度是"沉默"的——没有日志告诉你算子跑在哪。MLComputePlan 是唯一能程序化确认"模型实际跑在哪"的手段。这和第 9 章"验证实际跑在哪个引擎上"、第 11 章"检查放置情况"一脉相承：不轻信宣称，用工具看真相。

热管理与持续吞吐：thermal_loop.py 和 powermetrics_sampler.py 测量的是端侧推理的另一个硬约束——散热。笔记本/手机没有数据中心那种散热条件，持续推理会让芯片升温、降频，吞吐随之下降。thermal_loop.py 跑长时压力测试，观察吞吐随温度的衰减曲线；powermetrics_sampler.py 用 macOS 的 powermetrics 采真实功耗。

这一节的结论很实际：端侧推理不仅要看"峰值多快"，更要看"能持续多久不掉速"。量化让芯片负载更低、发热更少，间接提升了持续吞吐——这是量化在边缘端的另一层收益。

12.5 预发布门禁：GPU 无关的 pytest 套件

test_ch12.py 实现了预发布测试套件——它特意做成 GPU-free（不需要 GPU 就能跑），因为发布门禁应该在 CI 里随时能跑，而不是依赖一台 L4。

# 来自 ch12/test_ch12.py（设计意图）
# 每个测试校验一个"上线前必须为真"的断言，例如：
# - 量化后的模型能正常加载、输入输出 shape 正确
# - 配置的并发/批次参数在合法范围
# - 金丝雀对比逻辑能正确运行
# - 各类配置（路径、模型名、端口）拼装正确

这套门禁回答的是第 4 章"校准验证"在生产侧的放大版问题：上线前，哪些断言必须为真？ 把答案写成自动化测试，每次发布都跑一遍。它不是替代真机验证，而是用低成本的方式拦住低级错误。

12.6 全书收官：量化的完整价值闭环

第 12 章把整本书串成了一条完整的价值链：

graph LR
    A[第1-4章 量化原理] --> B[第5-6章 QAT 与工具链]
    B --> C[第7-8章 LLM 量化]
    C --> D[第9章 部署管线]
    C --> E[第10章 GGUF/llama.cpp]
    B --> F[第11章 边缘移动端]
    D --> G[第12章 生产交付]
    E --> G
    F --> G

1. 原理（1-4）让你知道量化怎么工作、误差从哪来；
2. 工具链（5-6）让你能用现成的轮子；
3. LLM 量化（7-8）解决大模型的特有问题；
4. 部署（9-12）把量化模型变成真正能上线、能观察、能验收的系统。

回到第 1 章的那个问题——"为什么要量化？"第 12 章给出了最终答案：量化不只让你"装得下、跑得快、花得少"，它还让你能"验证得到、观察得到、交付得出去"。一个 3B 模型用 4bit 装进 24GB 的 L4、配上一套可观测性栈，从 checkpoint 到被监控的端点，这就是现代 AI 工程把效率落到实处的完整样貌。

---

作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。