扩展：从应用需求到推理部署实验
在线 Notebook
对应的交互式版本可在 Google Colab 打开，统一使用方式见 第0章说明。
所属章节： 第 6 章：LLM 应用
原理层内容： 第 5 章推理机制优化
工程闭环： 第 8 章：LLM 工程实践与部署
本节定位
本节不提供跨硬件通用的“最佳框架”或固定加速倍数，而是把第 6 章的应用方案转换成可复现的部署实验。软件版本、模型实现、量化内核和硬件支持变化很快，具体兼容性应以目标版本的官方文档和本地测量为准。
先定义工作负载
比较方案前固定以下条件：
| 条件 | 需要记录的内容 |
|---|---|
| 模型 | 仓库、修订版本、参数规模、精度与 chat template |
| 输入 | prompt 长度分布、RAG 上下文、图像或音频 token 数 |
| 输出 | 生成长度分布、停止条件、是否流式返回 |
| 流量 | 并发、到达率、突发模式、优先级 |
| 硬件 | 设备型号、显存/内存、驱动与运行时版本 |
| 质量 | 业务评估集、允许回退幅度、安全与格式指标 |
没有相同工作负载，吞吐、显存和延迟数字就不能直接比较。
量化不是固定收益表
低比特权重通常能减少模型文件和权重内存，但是否加速取决于推理后端是否有匹配内核。完整实验至少比较：
- 高精度基线，例如 FP16 或 BF16；
- 一种较温和的量化配置；
- 一种面向目标设备的更低比特配置。
每组记录：
模型与量化格式：
推理后端和版本：
峰值内存：
TTFT / TPOT / 端到端延迟分位数：
吞吐：
业务质量指标：
失败样本类型：GPTQ、AWQ、GGUF 等名称描述的是不同量化或模型封装路线，不代表固定精度和速度等级。选择时要同时核对模型支持、目标硬件、内核、校准数据和业务回归结果。
推理后端如何选
可以把候选后端按部署目标分组，而不是按流行度排序：
| 目标 | 重点能力 | 可调研的候选类型 |
|---|---|---|
| 高并发 GPU 服务 | 连续批处理、KV cache 管理、并行与监控 | 服务型推理后端 |
| 本地 CPU / GPU | 模型格式、量化内核、平台兼容性 | 轻量原生运行时 |
| 开发验证 | 安装和模型管理简单 | 本地模型管理工具 |
| 特定加速器或移动端 | 模型转换、算子覆盖、设备 SDK | 设备专用运行时 |
vLLM、TGI、llama.cpp、Ollama 等可以作为候选实例，但功能和兼容范围会随版本变化。不要仅根据框架宣传数字做选型；用同一模型、数据和并发配置运行基准。
批处理与调度
静态批处理实现简单，但长度差异可能造成等待和填充浪费。动态或连续批处理可以提高设备利用率，同时增加调度复杂度，并可能抬高部分请求的排队延迟。
实验时至少画出两条曲线：
- 并发或到达率增加时，吞吐如何变化；
- 同一过程中，TTFT 和端到端 p95/p99 延迟如何变化。
只报告“每秒 token 数”会掩盖排队和交互体验问题。
推测解码
推测解码使用草稿模型提出候选 token，再由目标模型验证。在算法实现正确时，它保持目标模型定义的输出分布；实际收益取决于候选接受率、草稿成本、批大小、序列长度和实现。
应记录：
- 平均接受长度与接受率；
- 草稿和验证各自耗时；
- 不同输入类型下的延迟分布；
- 与不使用推测解码时相同生成配置的对照结果。
API 与自部署成本
盈亏点不能只按月 token 数判断。统一成本口径应包括：
托管 API 还要计入输入/输出价格、缓存规则、重试和限额；自部署还要计入空闲资源、冗余、监控、升级和值班。使用真实流量回放，才能得到当前业务条件下的盈亏点。
最低实践任务
选择同一个模型和固定评估集，比较高精度基线与一种量化配置：
- 固定输入、输出、采样参数和并发；
- 记录峰值内存、TTFT、TPOT、吞吐和质量指标；
- 列出至少三个质量回退样本；
- 说明收益来自权重内存、计算内核还是调度，而不是只报告“更快”。
返回： 第 6 章：LLM 应用