常见陷阱与反模式

推理部署的教训永远比技巧更有价值——本页收集的每个陷阱，都来自真实项目的痛苦时刻。

LLM 推理部署项目失败，很少是因为引擎不够先进，而是因为在看不见的地方犯了一个低级错误：量化前后没跑业务评测就上线、预处理与训练时口径不一致、单 batch 测延迟就当成品级延迟、KV cache 容量算错上线直接 OOM、用 GPU 利用率当唯一指标判断性能……这些错误不写进任何引擎文档的"快速开始"里，却决定了部署是上线还是返工。

本文按"模型 / 数据 / 调度 / 监控 / 工程"五层整理 15 个高频陷阱。每个陷阱都用统一格式给出「症状 / 根因 / 修复 / 相关页」，文末附一张可以直接勾选的自检清单。建议把本文当作"手术前核对表"：每次部署前过一遍，能帮你躲掉九成以上的返工。

先建立坐标系

如果你还没有系统的部署框架，建议先读 从零部署一个推理服务 与 部署设计原则，把"业务 SLA → 显存预算 → 引擎选型 → 调参 → 上线"的整体图景装进脑子里，再来看本文的"反面清单"会更有效。

一、量化与精度层陷阱

量化是 LLM 推理优化最有效的手段，也是最容易翻车的环节——它的副作用不在 MMLU 上显现，而在业务 prompt 分布上悄悄暴露。

陷阱 1：量化前后精度没对齐验证（评测集都没跑就上线）

把 AWQ INT4 模型上线，只看了 MMLU 几乎不变就放行，业务上线后才发现输出格式坏了。

• 症状：MMLU 下降不到 1 分，看着"几乎无损"。但业务场景（代码生成、JSON 输出、长文档摘要）的质量大幅下降——JSON 字段格式坏了、代码语法错了、摘要漏关键信息。最隐蔽的是用户报告"变笨了"但量化前后的 MMLU 几乎一样。

• 根因：MMLU 是多选题评测，看的是"哪个选项概率最高"。INT4 量化让所有 token 的 logits 整体偏移，最高分选项不变但绝对概率分布变——这种偏移在多选题里看不出来，但在"生成完整 token 序列"的任务里被放大。代码、JSON 这类对格式严格依赖的场景，单 token 错一个就整体崩。

• 后果：上线后业务质量悄悄掉，团队以为是"模型本身能力不足"，去换更大的模型——结果问题没解决，反而引入新复杂度。最坏的情况是用户先发现问题，团队被动响应。

• 修复：量化前后必须跑业务评测集——不是 MMLU，是你的真实 prompt 分布上的准确率、格式合法率、人工评分。最小评测集：

  # 业务评测脚本（伪代码）
  prompts = load_business_prompts(n=200)  # 真实业务 prompt 抽样
  for prompt in prompts:
      bf16_out = bf16_model.generate(prompt)
      awq_out = awq_model.generate(prompt)
      # 三指标
      bleu = compute_bleu(bf16_out, awq_out)         # 字符相似度
      json_valid = check_json(awq_out)              # 格式合法率
      human_score = human_eval(awq_out, prompt)     # 人工评分（抽样 50 条）

  三个指标都达标（bleu > 0.95、json_valid > 95%、human_score 持平）才考虑上线。详见 模型量化基础 与 权重量化与混合精度。

陷阱 2：预处理与训练时特征不一致（tokenizer 不对、padding 不一致）

训练时用 fast tokenizer + left padding，推理时用 slow tokenizer + right padding，输出质量突变。

• 症状：模型推理输出质量明显差于训练时——重复、不连贯、答非所问。检查代码发现 tokenizer 与训练时"看起来一样"，但 padding 方向、special token、max_length 都不一样。

• 根因：训练与推理的"预处理一致"是个多层概念——tokenizer 版本一致（fast vs slow 行为不同）、padding 方向一致（left vs right 影响生成）、special token 一致（BOS/EOS 加不加）、max_length 一致、tokenizer 配置一致（add_special_tokens=True/False）。任何一层不一致，输入到模型的 token 序列就不同。

• 后果：模型表现像"变笨了"，团队排查一周才发现是 tokenizer 配置不一致——这种问题极难定位，因为它"看起来一切正常"。

• 修复：训练与推理共用同一份预处理代码（一个函数、一个配置文件）。上线前用同样的 prompt 在训练框架与推理引擎各跑一次，对比 token id 序列是否完全一致：

  # 训练框架
  train_tokens = tokenizer.encode(prompt, return_tensors="pt")
  # 推理引擎（vLLM 内部也用 tokenizer）
  vllm_tokens = tokenizer.encode(prompt, return_tensors="pt")
  assert torch.equal(train_tokens, vllm_tokens), "Token 序列不一致！"

  详见 部署设计原则 的"预处理/后处理与模型同服务"。

陷阱 3：INT8 权重 + FP16 激活算反更慢

量化用 INT8 但激活用 FP16，反量化开销大于访存节省，性能不升反降。

• 症状：上了 INT8 weight-only 量化，期待 1.5–2× 加速，结果吞吐基本没变甚至略降——nvidia-smi 看 GPU 利用率反而降了。

• 根因：weight-only 量化的逻辑是"权重访存减半、激活保持原精度"。但 INT8 权重要在每个 step 反量化回 FP16/FP32 才能做 matmul——这个反量化是额外的算子开销。在小 batch（≤ 4）或小模型（≤ 3B）时，反量化开销 > 访存节省，性能反而退化。

• 后果：团队白做量化工作，性能没收益，精度还损失了——双重打击。

• 修复：weight-only 量化只在大模型 + 中等 batch 才有正收益：

  模型规模	batch	weight-only INT8 收益
  ≤ 3B	任意	负收益（反量化主导）
  7B+	1–4	微正（10–20%）
  7B+	8–64	正收益（30–60%）
  7B+	128+	大正收益（接近 2×）

  小模型小 batch 场景，要么不上量化，要么上 weight+activation 全量化（虽然精度损失大）。详见 权重量化与混合精度 与 Roofline 模型与算力分析。

二、调度与并发层陷阱

调度层是性能差异最大的环节——同一模型同一硬件，调度好坏差 10–30×。下面三个陷阱是新手最容易踩的。

陷阱 4：单 batch 测延迟就当成品级延迟

单请求跑 vLLM 测出 TPOT 20ms，就向业务承诺"单卡延迟 20ms"。

• 症状：单请求测试时 TPOT 20ms 漂亮，承诺业务"200ms 内出 10 个 token"。上线后业务一上 32 并发，TPOT 飞到 50ms+，p99 飞到 200ms+——SLA 大幅违约。

• 根因：单请求测试是引擎的最优情况——KV cache 不挤、调度不堵、GPU 算力闲置。生产环境的真实情况是：32 个并发同时来，KV pool 不够要 swap、调度队列要排队、GPU 算力被分摊。单请求延迟反映"引擎能力上限"，不是"生产负载下限"。

• 后果：业务对延迟有错误预期，SLO 设错，上线后用户体验崩。最坏情况是 SRE 一直追"为什么生产比测试慢"，没意识到是测试方法错了。

• 修复：永远同时报单请求延迟 + N 并发延迟，最好画"并发数 vs 延迟"曲线：

  并发    p50   p99
  1       22    25      ← 引擎能力上限
  4       24    30
  16      28    50      ← 推荐生产上限
  32      35    180     ← 拐点开始退化
  64      50    1200    ← 严重退化

  生产 SLO 应该按"拐点之前"的延迟设。详见 推理基准测试实践 与 批处理与请求调度。

陷阱 5：KV cache 容量估算错（对话历史超长爆显存）

部署时按"prompt 500 + output 256"算 KV cache，上线后用户聊到 20 轮历史爆显存。

• 症状：单轮对话测试一切正常。上线后用户多轮对话（每轮加历史），到第 10 轮左右开始 OOM、KV pool 爆、swapped 飙升。

• 根因：LLM 多轮对话的 prompt 长度累积增长——每轮把前面的对话历史加进 prompt，10 轮后 prompt 轻松到 4000+。部署时按"平均 prompt 500"算 KV cache，实际生产 prompt 长尾可能到 8000+。KV cache 显存 = max_model_len × max_num_seqs × 单 token 显存——任何一个变量被低估都爆。

• 后果：上线初期一切正常，用户多轮使用一段时间后开始崩——这种"延迟故障"最难定位，因为初期数据正常，问题随使用时间累积。

• 修复：按业务长尾 prompt 长度算 KV cache，留 50% 余量：

  # 业务 prompt 长度统计
  prompt_lens = [len(tokenizer.encode(p)) for p in business_prompts]
  print("p50:", np.percentile(prompt_lens, 50))
  print("p99:", np.percentile(prompt_lens, 99))
  print("max:", max(prompt_lens))
  
  # KV cache 预算 = p99 × max_num_seqs × 单 token 显存 × 1.5 (余量)

  详见 部署设计原则 的"显存预算先算清"与 调参与性能调优 的"max_model_len 调参"。

陷阱 6：用 GPU 利用率当唯一指标（memory-bound 时 100% 但慢）

nvidia-smi 看 GPU 利用率 100%，以为"算力喂满了"，继续加 batch 没收益。

• 症状：GPU 利用率持续 100%，团队认为"算力到顶了"，去加 GPU。加了 GPU 吞吐没涨——因为瓶颈在显存带宽不在算力。

• 根因：GPU 利用率不区分 compute-bound 与 memory-bound——两者都让利用率显示 100%。memory-bound 时算力其实闲置（等数据从显存读到 SRAM），但 nvidia-smi 看利用率是 100%。只用 GPU 利用率当指标，会得出"算力饱和"的错误结论。

• 后果：花大钱加 GPU 不解决问题——瓶颈在显存带宽，加 GPU 不增加带宽。或者团队调错方向（加 batch），让 memory-bound 更严重。

• 修复：同时看 GPU 利用率 + 显存利用率：

  GPU 利用率	显存利用率	瓶颈层	应对
  > 90%	< 50%	compute-bound	加 GPU、上量化（减 FLOPs）
  < 50%	> 90%	memory-bound	上 weight-only 量化（减访存）
  > 90%	> 90%	都满	加 GPU 也要加带宽
  < 50%	< 50%	调度差	调 max_num_seqs、开 continuous batching

  详见 调参与性能调优 的"Step 1: nvidia-smi 看宏观"与 Roofline 模型与算力分析。

陷阱 7：在线推理开大 batch（吞吐上去了，p99 也炸了）

为了"成本省"把 max_num_seqs 从 16 调到 64，吞吐涨 3×，但 p99 飞涨 5–10×。

• 症状：吞吐数字漂亮（QPS 翻倍），但用户报告"偶尔卡顿"。监控看 p50 没变，但 p99 从 200ms 飞到 1200ms——少数请求被严重拖慢。
• 根因：大 batch 让 GPU 算力喂满（吞吐涨），但调度队列变长（每个请求等的时间变长，p99 涨）。吞吐与 p99 的 trade-off 是非线性的——p99 涨得比吞吐快得多。这是 批处理与请求调度 的核心权衡。
• 后果：业务对 p99 敏感（聊天、补全），大 batch 让"少数用户体验崩"——这些少数用户会投诉、流失。整体 QPS 涨 30% 但 5% 用户跑掉，得不偿失。
• 修复：max_num_seqs 设在"并发-p99 曲线拐点之前"，详见 调参与性能调优 的"max_num_seqs 调参"。在线服务宁可吞吐少一点也要保 p99——这是 部署设计原则 的"延迟优先 vs 吞吐优先先选一个"的典型应用。

陷阱 8：投机解码在大 batch 用（反向收益）

为了"再加速"在所有场景开 EAGLE，大 batch 离线场景性能反而退化 30%。

• 症状：开了 EAGLE 投机解码，单请求延迟确实砍半（小 batch 受益）。但 32 并发压测时，吞吐反而比不开 EAGLE 退化 30%。
• 根因：投机解码的收益严重依赖 batch 大小。小 batch 时大模型算力闲置，小模型猜对了等于白嫖；大 batch 时大模型已被算力喂满，draft 模型加进来徒增显存与计算。32 并发是盈亏平衡点，64+ 是反向收益。
• 后果：团队调试一周找不到原因——以为是 EAGLE 配置问题，去调 num_speculative_tokens，越调越差。实际是应用场景不匹配。
• 修复：投机解码只在小 batch 场景开（在线聊天、代码补全，batch ≤ 16）。大 batch 场景（离线批、高并发在线）关掉。如果业务同时有"小 batch 在线 + 大 batch 离线"流量，用路由分流——详见 作品集项目 的"多模型路由"项目。详见 投机解码与 Medusa/EAGLE 与 部署设计原则 的"投机解码看 batch 大小"。

三、监控与运维层陷阱

监控层的陷阱最隐蔽——出问题时"看着正常"，直到用户投诉才发现。

陷阱 9：没监控 GPU 温度（热限频后性能掉 30%）

只监控 QPS 与延迟，没监控 GPU 温度。夏天机房温度高，GPU 限频后性能掉 30%，团队排查一周。

• 症状：QPS 与错误率都正常，但 p99 延迟突然从 200ms 涨到 280ms。看日志一切正常，看 vLLM 配置没动，看模型版本没变。直到有人去机房才发现 GPU 风扇坏了、温度 90°C。

• 根因：GPU 在温度超阈值（通常 85°C）会自动降频保护——SM clock 与 memory clock 都降，性能掉 20–40%。这是硬件自我保护，不会报错，但性能悄悄退化。

• 后果：排查时间长（"日志一切正常"是最误导的信号），影响线上体感。最坏情况是机房环境本来就有问题（制冷不够），GPU 一直在限频，性能从未达标过。

• 修复：监控 GPU 温度，设 80°C 告警、85°C 紧急告警：

  # 监控命令
  nvidia-smi --query-gpu=temperature.gpu,clocks.sm,clocks.mem,power.draw --format=csv -l 10
  
  # Prometheus exporter 暴露指标
  # 指标名: nvidia_gpu_temperature_celsius, nvidia_gpu_clocks_sm_mhz

  温度超 85°C 自动告警，超 90°C 自动降负载（降 max_num_seqs）或迁移实例。详见 调参与性能调优 的"性能调优 checklist"与 部署设计原则 的"监控不只是 QPS"。

陷阱 10：模型导出 ONNX 后没 verify（数值误差悄悄漂移）

PyTorch 模型导出 ONNX 给 ONNX Runtime 部署，跑出来结果不对，但跑了一周才有人发现。

• 症状：ONNX Runtime 部署上线，跑评测集发现准确率掉了 1–3 分。最初以为是 ONNX Runtime 实现差异，调了一周才发现是导出时的数值漂移。

• 根因：PyTorch → ONNX 导出涉及：算子映射（部分 PyTorch 算子 ONNX 没有等价）、精度转换（fp32 → fp16 时部分算子溢出）、动态 shape 处理（某些动态维度导出时被固定化）。每个环节都可能引入数值漂移——单算子漂移小，累加起来显著。

• 后果：上线一段时间才有人发现"为什么 ONNX 跑出来的结果和原模型差这么多"——这段时间业务质量已悄悄掉了。回退到原模型也要时间，期间业务受损。

• 修复：ONNX 导出后必须 verify——用同一组输入跑 PyTorch 与 ONNX Runtime，对比输出：

  # PyTorch 跑
  pt_out = pt_model(input).detach().cpu().numpy()
  
  # ONNX Runtime 跑
  import onnxruntime as ort
  sess = ort.InferenceSession("model.onnx")
  onnx_out = sess.run(None, {"input": input.numpy()})[0]
  
  # 对比（容忍小数点后 3 位）
  np.testing.assert_allclose(pt_out, onnx_out, rtol=1e-3, atol=1e-3)

  漂移超阈值时定位是哪个算子引入，单算子替换或保留 PyTorch。详见 ONNX Runtime 跨平台 与 图优化原理。

陷阱 11：跨版本升级引擎没跑回归

vLLM 从 0.5.x 升到 0.6.x，性能退化 20%，没跑回归测试就上线。

• 症状：引擎升级后，benchmark 数字看着正常（甚至略升），但生产 p99 飞涨。回滚后正常，确认是升级引入的退化。

• 根因：引擎升级可能改变：默认参数（如 enable_chunked_prefill 默认从 false 改 true）、kernel 选择（新版本可能用不同 attention kernel）、量化实现（INT8 计算路径变了）。这些变化在标准 benchmark 上不显现，但在你的特定业务 prompt 分布上显现。

• 后果：升级后业务退化，团队手忙脚乱回滚。最坏情况是回滚也回不去（依赖了新版本特性），只能紧急定位问题、补丁式修复。

• 修复：引擎升级走灰度 + 完整回归测试：

  ## 引擎升级回归 checklist
  
  1. 在测试环境跑完整业务评测集
  2. 跑 [推理基准测试实践](/practice/benchmarking) 全套基准
  3. 对比新版与旧版的：吞吐、p50/p99、显存、KV 命中率
  4. 业务 prompt 抽样人工对比输出质量
  5. 灰度 5% 流量，观察 24 小时
  6. 无异常扩到 20%，再 24 小时
  7. 无异常全量

  详见 部署设计原则 的"灰度发布先 5% 流量"。

陷阱 12：CUDA 版本 / cuDNN 版本不匹配悄悄退化

torch 2.3 配 CUDA 12.1，但生产环境装了 CUDA 12.4，性能掉 15%，没人发现。

• 症状：本地测试一切正常，部署到生产环境性能下降 15%。配置完全一样、模型权重一样、参数一样，但慢。

• 根因：PyTorch / vLLM / TensorRT 等 GPU 软件对 CUDA 与 cuDNN 版本严格依赖——大版本一致但小版本不一致，可能让某些 kernel 退化（用了慢实现而不是快实现）。这种退化不报错、不警告，只是悄悄变慢。

• 后果：排查时间长——所有"看着对的"都对，性能就是差。团队怀疑模型、参数、硬件，折腾几天才发现是 CUDA 小版本不匹配。

• 修复：用 Docker 镜像锁定整个软件栈：

  FROM nvcr.io/nvidia/pytorch:24.07-py3
  # 这个镜像锁定了 torch 2.4 + CUDA 12.4 + cuDNN 9.0 的组合
  # 部署机只要 nvidia driver 版本足够，整个软件栈就一致

  或者用 conda 锁定：

  conda install pytorch=2.3.1 pytorch-cuda=12.1 cudatoolkit=12.1 cudnn=9.0 -c pytorch -c nvidia

  详见 部署设计原则 的"端到端基准而非单算子基准"——这种问题只有端到端基准能发现。

陷阱 13：多模型共享 GPU 但没设 MPS / cgroup

同一张 GPU 上跑 vLLM + embedder + reranker 三个服务，没设 MPS，互相抢占显存与算力，性能剧烈波动。

• 症状：三个服务各自单独跑性能正常，一起跑时性能剧烈波动——vLLM 的 p99 时好时坏，embedder 偶尔超时。

• 根因：默认情况下，同 GPU 上的多个 CUDA 进程互相抢占显存与算力——vLLM 占满显存时 embedder 启动 OOM、vLLM 跑 attention 时 embedder 的 kernel 被挂起。没有隔离机制，每个进程都以为自己独占 GPU。

• 后果：性能不稳定、偶发 OOM、调度不可预测。最坏情况是某个服务的内存泄露把整张 GPU 撑爆，三个服务全崩。

• 修复：用 MPS（Multi-Process Service） 或 cgroup + 显存配额：

  # 方式 1：MPS（NVIDIA 推荐）
  nvidia-cuda-mps-control -d
  # 然后三个服务都通过 MPS 跑，共享 GPU 算力但减少 context switch
  
  # 方式 2：cgroup + 每个进程的 GPU 显存配额
  # vLLM 配 gpu_memory_utilization=0.6
  # embedder 配 0.2
  # reranker 配 0.2
  # 总和 ≤ 1.0，显式留余量

  详见 GPU 体系结构与优化 与 部署设计原则 的"显存预算先算清"。

四、协议与设计层陷阱

陷阱 14：流式响应没用 SSE 而是 polling

聊天接口设计成"等模型生成完一次性返回"，前端为了"流式感"每 200ms 发一次请求轮询拿增量。

• 症状：QPS 凭空多了一个数量级——每个用户每秒 5 次轮询，32 个并发用户就是 160 QPS，服务被打挂。本质是单个生成请求被放大成 5 个 HTTP 请求。

• 根因：后端没设计流式接口，前端"模拟流式"靠 polling——每次 polling 都是一次完整 HTTP 请求，开销远大于真实流式。

• 后果：服务被打挂、QPS 暴涨、运维成本翻倍。最坏情况是用户体感比"等结果"还差——polling 间隔太长显得卡、太短服务崩。

• 修复：用 SSE（Server-Sent Events）做流式输出：

  from fastapi import FastAPI
  from sse_starlette.sse import EventSourceResponse
  
  app = FastAPI()
  
  @app.get("/chat")
  async def chat(prompt: str):
      async def event_generator():
          async for chunk in vllm_stream_client.generate(prompt):
              yield {"data": chunk.text}
          yield {"data": "[DONE]"}
      return EventSourceResponse(event_generator())

  详见 部署设计原则 的"流式优于等结果"与 作品集项目 的"流式对话 API"项目。

陷阱 15：上下文长度超模型原生支持，靠 sliding window 但精度掉

模型原生 4K 上下文，但业务需要 32K，用 sliding window 实现，长文档场景精度大幅下降。

• 症状：用 sliding window 处理 32K 长文档，模型"忘记"前文关键信息，回答质量明显下降——长文档摘要漏关键段、长对话忘记前面承诺过的事。

• 根因：sliding window 的本质是"只看最近 N 个 token"——超出窗口的内容直接丢弃。模型看起来在"读 32K 文档"，实际只看了最后 4K，前面 28K 的信息根本没进 KV cache。这不是优化，是假装支持长上下文。

• 后果：用户报告"模型变笨了"——团队以为是模型本身能力不足，去换更大的模型，结果问题没解决。实际上是上下文处理方法错了。

• 修复：要么用原生支持长上下文的模型（如 Qwen2.5-7B-Instruct 原生 32K、Yarn-7B-128K 等），要么用真正的长上下文方法：

  • chunked prefill：长 prompt 分块进入 KV cache，不丢失前文（vLLM 0.5+ 原生支持）
  • RoPE scaling：用 position interpolation 让 4K 模型扩到 32K（精度略降但远好于 sliding window）
  • RAG：长文档不要全塞给模型，用检索 + 摘要的混合方案

  详见 部署设计原则 的"端到端基准而非单算子基准"——sliding window 在单算子 benchmark 上"看起来支持 32K"，但端到端质量崩。

五、自检清单

把 15 个陷阱浓缩成一张可勾选的部署前自检清单：

## 推理部署前自检清单

### 量化与精度
- [ ] 量化前后跑了业务评测集（不只 MMLU）—— 陷阱 1
- [ ] tokenizer 与训练时完全一致（fast/slow、padding 方向）—— 陷阱 2
- [ ] weight-only INT8 用在大模型 + 中等 batch（不是小模型小 batch）—— 陷阱 3

### 调度与并发
- [ ] 单 batch 测延迟 + 多并发延迟同时报，曲线找拐点 —— 陷阱 4
- [ ] KV cache 按业务长尾 prompt 算，留 50% 余量 —— 陷阱 5
- [ ] 同时看 GPU 利用率 + 显存利用率，区分 compute/memory-bound —— 陷阱 6
- [ ] max_num_seqs 设在 p99 拐点之前，宁可吞吐少也要保 p99 —— 陷阱 7
- [ ] 投机解码只在小 batch 场景开，大 batch 关掉 —— 陷阱 8

### 监控与运维
- [ ] 监控 GPU 温度（85°C 告警、90°C 紧急）—— 陷阱 9
- [ ] ONNX 导出后 verify 数值一致 —— 陷阱 10
- [ ] 引擎升级走灰度 + 完整回归测试 —— 陷阱 11
- [ ] 用 Docker 锁定 CUDA/cuDNN 整套软件栈 —— 陷阱 12
- [ ] 多模型共享 GPU 用 MPS 或显存配额 —— 陷阱 13

### 协议与设计
- [ ] 流式输出用 SSE 不用 polling —— 陷阱 14
- [ ] 长上下文用原生支持或 chunked prefill，不用 sliding window —— 陷阱 15

这张清单怎么用

• 每次新部署前：过一遍，确认每一项都对照过
• 每次升级前：过一遍，确认升级没引入新陷阱
• 每次故障后：过一遍，看是哪个陷阱没防住
• 季度复盘：统计团队踩过哪些坑，更新清单

六、延伸阅读

• 从零部署一个推理服务 —— 部署端到端流程
• 渐进式教程：三版跑起来 —— 每版只加一项优化的对比
• 推理基准测试实践 —— 本文陷阱 4、5、6 的方法论
• 调参与性能调优 —— 本文陷阱 5、6、7、9 的工具
• 部署设计原则 —— 本文陷阱的反面原则
• 模型量化基础 —— 本文陷阱 1、3 的理论
• 权重量化与混合精度 —— 本文陷阱 3 的深入
• 批处理与请求调度 —— 本文陷阱 4、7、8 的理论
• 模型服务化与编排 —— 本文陷阱 11、13、14 的理论
• Roofline 模型与算力分析 —— 本文陷阱 6、8 的工具
• 显存层次与带宽墙 —— 本文陷阱 5、6 的理论
• GPU 体系结构与优化 —— 本文陷阱 9、13 的工具
• 算子融合与自定义核 —— 本文陷阱 10 的工具
• 图优化原理 —— 本文陷阱 10 的深入
• ONNX Runtime 跨平台 —— 本文陷阱 10 的引擎
• vLLM 与 PagedAttention —— 本文陷阱 5、7、11 的引擎
• 投机解码与 Medusa/EAGLE —— 本文陷阱 8 的深入
• 延迟、吞吐与并发 —— 本文陷阱 4、7 的理论

参考资料

• Google: Rules of ML —— 训练/服务偏差与陷阱清单的祖师爷
• vLLM: Production Best Practices —— vLLM 生产实践
• NVIDIA: Deploying LLMs in Production —— Triton 部署指南
• ONNX Runtime: Model Verification —— ONNX 数值验证方法
• NVIDIA MPS Documentation —— 多进程服务
• NVIDIA Nsight Systems —— profiling 工具
• SSE Specification —— Server-Sent Events 协议
• Continuous Batching: Orca Paper —— 连续批处理论文
• PagedAttention Paper —— KV cache 管理
• EAGLE-3: Speculative Decoding —— 投机解码 batch 依赖