ai-llm-inference

LLM 推理生产技能中心

提供选择和调优现代推理技术栈的运维指导。重点关注运行时适配、路由、输出保证、适配器加载、多模态服务，以及负载下的实测性能。

对于版本、硬件支持、基准测试、定价和发布状态等易变信息，请使用最新的一手资料。

何时使用此技能

在用户询问以下内容时使用此技能：

• 推理引擎选择或技术栈比较
• 延迟、TTFT、ITL 或吞吐量优化
• 感知缓存的路由或控制平面设计
• 按运行时和硬件制定量化策略
• 多 GPU 或多节点服务
• 服务时的结构化输出或受限解码
• 多模态或编码器-解码器服务模式
• LoRA 或多适配器服务
• 降低可自托管或 API 推理的成本
• 基准测试、性能分析或容量规划
• 多用户 llama.cpp 服务器服务，或设备端 NPU（逐张量缩放因子、静态形状）；单机 CPU／边缘设备／桌面端运行请参阅 ai-local-model-ops

范围边界

• 提示词编写 -> ai-prompt-engineering
• 评估集和质量门槛 -> ai-evals
• 微调和其他模型适配 -> ai-llm
• 单机本地运行（GGUF 量化选择、显存适配、CPU／边缘设备）-> ai-local-model-ops；CPU 和边缘设备调优请参阅其中的 edge-cpu-optimization.md
• RAG 流水线设计 -> ai-rag
• 部署自动化、监控、事件响应 -> ai-mlops
• 基础设施运维 -> ops-devops-platform
• 可观测性设计 -> qa-observability

快速参考

决策	核心问题	默认起点	何时升级
引擎	哪种运行时应负责执行 Token？	通用文本服务可从 vLLM 开始	需要更强的 KV 复用、多模态拆分或 NVIDIA 专用内核时
路由器	应如何分配请求？	先使用简单的副本池	存在多个副本、前缀粘滞、多 LoRA 或混合工作负载时
输出控制	响应是否必须遵循某种架构？	使用原生结构化输出	JSON 有效性或语法约束属于 SLA 的一部分时
多模态	是否存在独立的编码器路径？	先保持共置	编码器饱和度与解码饱和度不同时
适配器	多个 LoRA 或租户是否会共用基础模型？	使用原生多 LoRA 支持	冷加载延迟或适配器频繁切换影响 p95 时
量化	在此运行时中，哪种精度安全可靠？	使用运行时原生 FP8 或仅权重量化方案	硬件支持或模型质量尚不确定时
解耦部署	是否应拆分预填充／编码器／解码？	仅在建立共置基线后考虑	已证实存在排队干扰或资源不对称时

收集信息清单（必需）

提出变更建议前，请收集或推断以下信息：

• 模型系列、规模、上下文长度、分词器、模态和适配器用法
• 请求约定：流式传输、工具调用、推理模式、架构或语法约束
• 提示词和输出长度分布、并发量、QPS 和突发特征
• 提示词复用模式：前缀复用、会话复用、检索复用、LoRA 复用
• 当前引擎、版本、路由器、自动扩缩容器和缓存设置
• 硬件和拓扑：GPU 型号、显存、互连、节点数、CPU 和 RAM
• SLO：TTFT、ITL、端到端延迟、可用性和错误预算
• 验收标准：质量下限、JSON 有效性、长上下文准确率、回滚时限

工作流

1. 在建议更改之前，收集工作负载形态、运行时契约、硬件和 SLO。
2. 如果推理调优不是主要问题，则将提示词策略、RAG 设计或平台运维交由相邻技能处理。
3. 根据决策流程选择服务栈、路由策略、量化路径和输出控制策略。
4. 测试基线，每次只更改一个因素，并根据验收标准比较吞吐量、延迟和质量。
5. 在给出最终建议之前，通过导航来源核实易变的引擎、硬件和版本信息。

决策流程

Need to improve inference:
    |
    |- Is the workload text-only?
    |   |- No -> evaluate multimodal runtime support and encoder separation
    |   `- Yes -> continue
    |
    |- Is schema validity or constrained decoding part of the SLA?
    |   |- Yes -> prefer runtimes with native structured outputs
    |   `- No -> continue
    |
    |- Are there multiple replicas, tenants, or adapters?
    |   |- Yes -> design routing and placement explicitly
    |   `- No -> simple replica pool may be enough
    |
    |- Is there high prefix or session reuse?
    |   |- Yes -> prefer KV-aware routing and native prefix reuse
    |   `- No -> standard load balancing is acceptable
    |
    |- Are long prompts or mixed prompt lengths hurting p95?
    |   |- Yes -> test admission control first, then prefill or encoder disaggregation
    |   `- No -> keep colocated
    |
    |- Is this a MoE model (config.json lists routed experts)?
    |   |- Yes -> size memory from TOTAL params (every expert must be resident)
    |   |         and per-token compute from ACTIVE params; then assess EP degree,
    |   |         EPLB support, and all-to-all topology
    |   |         see references/moe-expert-parallelism.md
    |   `- No -> continue
    |
    `- Does the model fit latency and cost targets at current precision?
        |- Yes -> keep the simpler stack
        `- No -> walk the lever ladder in order, cheapest and least lossy first:
            1. roofline diagnosis: memory-bandwidth-bound or compute-bound?
               (the answer decides which of the rungs below can help at all)
            2. batching / admission control      (lossless)
            3. KV-cache quantization             (lossy -> eval gate)
            4. speculative decoding              (lossless only with rejection-sampling
                                                    verification; gate Medusa-style)
            5. weight quantization               (lossy -> eval gate)
            6. pruning / distillation            (lossy -> eval gate, retrain cost)
            Each lossy rung gets its own eval gate and rollback window.
            Change one rung at a time; stacking them hides the regression.

技术栈指南

vLLM

• 是 OpenAI 兼容文本服务、结构化输出、LoRA 服务和广泛量化支持的良好默认选择。
• 非常适合希望用一个运行时同时处理文本推理和生产级路由模式的团队。
• 官方文档目前为结构化输出、分离式预填充、分离式编码器服务、LoRA 和量化分别提供了独立页面。应将这些功能分别考虑，不要假设一个开关就能解决所有性能问题。
• 重要注意事项：分离式预填充被文档标记为实验性功能，本身不会提升吞吐量；只有在测得实际排队或资源争用后才使用。

SGLang

• 非常适合聊天、Agent、重复前缀、多模态服务和适配器密集型工作负载。
• 当前文档重点介绍 RadixAttention、HiCache、PD 和 EPD 分离、Model Gateway、DP Router、推理模型的结构化输出以及 LoRA 服务。
• 如果主要瓶颈是提示词复用、多模态编码器压力或适配器频繁切换，而不仅仅是原始内核速度，则优先选择 SGLang。

TensorRT-LLM

• 非常适合仅使用 NVIDIA 的部署场景，尤其是在显式精度控制、KV 缓存复用和低延迟 GPU 执行比可移植性更重要时。
• 当前文档提供了精度专项指南、KV 缓存复用、分离式服务和 trtllm-serve 的相关内容。
• 精度建议应限定在特定运行时范围内：TensorRT-LLM 文档介绍的 INT8 和低比特路径，比笼统的仅基于硬件的规则所暗示的更多。

路由器和控制平面

• 当部署规模超过单台机器或单个副本时，应将令牌生成与请求分配分开。
• 有关缓存感知路由、粘性放置、多 LoRA 请求调度和控制平面选择，请参阅 routing-and-control-planes.md。
• 以 vLLM 为核心的集群：从 vLLM Router 或 vLLM Production Stack 入手。
• Kubernetes 和缓存感知横向扩展：评估 llm-d。
• 以 SGLang 为核心的集群：采用 Model Gateway 或 DP Router 模式。
• 多云或本地数据中心环境：考虑 Dynamo（开源）；请查阅其代码库，了解当前的平台和硬件支持情况。

量化规则

• 在你实际部署的运行时中选择量化方式，不要参照通用硬件表。
• 使用 vLLM 时，优先采用运行时原生方案。当前文档列出了 FP8、INT4 W4A16、AWQ、GPTQ 和 INT8 W8A8；vLLM 文档明确指出，INT8 W8A8 不支持 Blackwell（计算能力 >= 10.0）——FP8 是文档推荐的 Blackwell 替代方案。
• 使用 TensorRT-LLM 时，从该技术栈文档列出的精度模式中选择：FP8、INT8 SmoothQuant、仅权重量化 INT4 或 INT8、GPTQ 或 AWQ，以及适用于受支持 Blackwell 流程的 NVFP4。
• 使用 SGLang 时，在决定采用 FP4、FP8、AWQ、GPTQ 或量化 KV 缓存之前，请先查阅当前文档，确认模型特定的量化器支持情况。
• 对于 CPU 或边缘部署，使用 llama.cpp 和 GGUF，并明确调整量化级别、线程数和 n_gpu_layers（参见 ai-local-model-ops edge-cpu-optimization.md）。
• 设备端 NPU 不属于 CPU/边缘部署：大多数 NPU 运行时需要 INT8/INT4、逐张量缩放和静态形状，而非分组缩放格式——参见 references/quantization-patterns.md 中的 NPU 行。
• 每次更改量化方式后，都要在推出前重新验证延迟、长上下文和结构化输出。

专家判断：量化何时会实际损害质量

• 不同格式的质量风险并不相同。仅权重量化格式（AWQ、GPTQ、INT4 W4A16）对通用聊天/指令评测的任务准确率影响通常很小， rarely 超过一两个百分点，但在以下方面的退化会更明显：长上下文检索（类似大海捞针的任务）、多步算术与代码，以及低资源语言——应针对这些情况进行测试，而不仅仅是看通用评测的平均分。
• W8A8 和其他激活量化方案存在仅权重量化方案没有的离群值风险：少数隐藏状态通道就可能占据大部分误差预算（参见 architecture-and-attention-serving.md §6 中的 SmoothQuant 校准）。如果校准集与生产流量不匹配，W8A8 可能在基准测试中表现良好，却在生产环境的长尾输入上失效——请使用能代表生产流量的样本进行校准，而非通用语料。
• KV 缓存量化（FP8/INT8 KV）对质量的影响通常比权重量化更小，因为它压缩的是中间激活值，而非模型参数——但它与推测解码和长上下文 RoPE 缩放的交互因运行时而异；应验证组合效果，而不是分别验证各个部分。
• 在通用质量指标出现变化之前，结构化输出和工具调用的有效性往往最先因激进量化而退化——应将符合 schema 的比率视为领先指标，而非事后才关注的指标。
• 在一次推出中叠加多项量化更改（权重格式 + KV 数据类型 + 推测解码），几乎不可能定位回归原因。一次只改一个因素，进行测量，然后再叠加其他改动。
• 如果质量仅在某一小类任务（例如代码、非英语或长文档）上退化，而非普遍退化，通常应采用混合精度或逐层方案，而非全面回退到全精度——请检查运行时是否支持让特定层或 LM 头保持更高精度。

专家判断：批处理与延迟

• 连续批处理几乎可以不付出额外代价地提高吞吐量，直到 GPU 的解码从受内存带宽限制转为受计算能力限制（参见 architecture-and-attention-serving.md §3 中的屋顶线模型）。在越过这个临界点之前，增加并发几乎不会改变单个 token 的延迟；越过之后，增加并发会直接推高 TTFT 和 token 间延迟，因为请求开始排队等待计算资源，而不只是等待内存带宽。
• 实际判断依据：随着负载增加，如果 p50 延迟保持平稳，而 p95/p99 延迟上升，说明批调度器接纳的并发序列数量超出了目标延迟 SLO 所支持的计算预算——应限制 max_num_seqs / 并发请求上限，而不是先调优内核。
• 不要在没有明确延迟预算的情况下，通过提高批处理或并发上限来追求吞吐量——吞吐量最优点和延迟最优点位于同一条曲线的不同位置，“最佳”批大小取决于 SLO，而不是硬件利用率最大化。
• 将长短不一的提示词流量混在同一个队列中，是导致 p99 崩溃的最常见原因。这种情况看起来像批处理故障，实际上是调度或准入控制存在缺口——在认定引擎配置错误之前，应按提示词长度分桶，或添加分块预填充。
• 当利益相关方在没有并发上限的情况下要求“降低延迟并提高吞吐量”时，应予以反驳：越过受计算能力限制的临界点后，这两个目标会相互权衡，决定取舍界限的应是 SLO，而不是引擎。

专家判断：容量规划启发式

• 不要仅根据参数总数规划 GPU。应综合以下三个数值：目标精度下的权重内存、目标最大上下文长度 × 最大并发下的 KV 缓存内存，以及为激活值和框架开销预留的余量（约占总量的 10-20%，请根据运行时的实际占用进行验证）——在实际并发和长上下文场景中，通常最先耗尽的是 KV 缓存，而不是权重。
• 应将“所需 GPU 数量”视为排队问题，而不是峰值吞吐量的除法问题：使用 Little 定律和预期突发行为（参见 queueing-theory-applied.md）来规划尾部负载，而不是平均负载；否则，集群虽然能满足平均负载下的 SLO，却会在每次突发时失效。
• 正确规划容量的共置基线，胜过凭猜测规划的解耦拓扑——先从简单部署中获取容量数据，再判断拆分各阶段是否确实能释放余量。
• 应为冷启动和适配器加载事件预留明确的容量余量（自动扩缩容延迟、LoRA 冷加载、MoE 权重加载）——忽略这些事件的稳态利用率目标，会导致实际 p99 行为下容量不足。

运维规则

应做事项

• 在真实负载下测量 TTFT、ITL、端到端延迟、排队延迟、每秒 token 数和符合架构定义的比率。
• 在 API 边界限制队列深度和并发数。
• 一旦前缀复用或适配器本地性变得重要，就应明确路由逻辑。
• 将多模态编码器饱和与解码饱和分开处理。
• 记录请求 ID、模型 ID、精度、缓存命中数据和过载原因。

应避免事项

• 避免在没有工作负载配置文件的情况下，对“最佳”引擎作出普遍性断言。
• 避免使用过时的基准测试比率来证明架构合理。
• 未证实共置会产生干扰之前，避免解耦部署。
• 未制定回滚计划并准备评估集之前，避免切换精度。
• 当前缀或适配器本地性决定了大部分成本时，避免使用通用轮询策略。

容量晋级门槛

在稳定负载和突发负载下，对真实的提示词长度、输出长度、前缀复用、适配器和请求到达分布进行基准测试。报告 p50、p95、p99、队列拒绝率、重试次数和可持续良好吞吐量。只有在保持任务质量门槛、满足每项已声明的 SLO 和回归预算，并改善主要优化目标时，才能推进服务变更。若非主要优化目标的百分位出现有界回归，且该回归事先声明，同时目标 SLO、良好吞吐量、质量、拒绝率、重试次数和恢复限制仍然满足，则可以接受。在测试中纳入冷启动、过载准入、工作进程丢失、OOM 恢复和排空行为。将原始每秒令牌数视为辅助证据。

已知陷阱

• 使用合成提示词进行基准测试，但这些提示词与生产环境中的前缀复用、输出长度、架构有效性要求或并发突发情况不符。
• 在同机部署基线上尚未收紧队列限制、准入控制和放置策略之前，就引入预填充或编码器解耦。
• 只优化每秒令牌数，却导致 TTFT、结构化输出有效性或长上下文质量下降。
• 更换引擎或分词器栈，却未验证其对停止条件、函数/工具契约和架构约束解码的兼容性。
• 将量化视为纯粹的硬件选择，而不是具有运行时特定能力及质量和功能方面注意事项的方案。

常见反模式

• 追逐醒目的基准测试差异，仿佛这些差异可以直接迁移到不同的工作负载形态。
• 在前缀密集或多 LoRA 工作负载中使用轮询路由，而这类工作负载的延迟和成本主要取决于局部性。
• 在没有准入控制策略的情况下，将多种提示词长度类别混入同一队列，随后却将 p95 崩溃归咎于运行时。
• 在没有架构有效性测试套件、长上下文检查和明确回滚窗口的情况下，部署新的精度或内核路径。

准确性规范（必需）

• 除非有当前的一手来源且测试条件可比，否则应将基准测试比率视为仅适用于特定工作负载。
• 推荐硬件或精度变更时，应说明运行时假设。
• 明确标注实验性或 Beta 功能。
• 若官方文档和次要博客均有相关信息，优先采用官方文档和发行说明。

导航

核心参考资料

• 服务架构 - 引擎选择和服务模式
• 路由与控制平面 - 放置、粘性、缓存感知路由
• 解耦推理 - 何时拆分预填充、编码器或解码
• 量化模式 - 运行时范围内的精度选择、NVFP4 与 MXFP4
• 剪枝与稀疏性 - 非结构化/N:M/结构化剪枝（SparseGPT、Wanda、Minitron）、2:4 硬件现状、激活稀疏性、剪枝与蒸馏及小模型训练的取舍、运行时支持表
• KV 缓存优化 - 分页、复用、缓存数据类型和复用模式
• 架构与注意力服务 - 注意力变体（MHA/MQA/GQA/MLA 的 KV 占用）的服务时限制→应对方案、SSM/混合架构服务、屋顶线/算术强度、长上下文（StreamingLLM/滑动窗口/环形）、服务时 RoPE 缩放陷阱、SmoothQuant 离群值、无草稿的推测解码、FlashAttention 解码与预填充
• MoE 与专家并行 - 并行前先考虑精度、EP 度数、全对全通信量闭式公式、EPLB、路由健康指标（MaxVio、负载 CV、路由熵）、全对全拓扑
• 推测解码指南 - EAGLE、MTP、草稿模型、Medusa 算法系列和部署检查清单
• 并行模式 - TP、PP、DP、EP 的权衡
• GPU 优化检查清单 - 硬件适配和生产环境调优
• GPU 节点与集群调优 - NUMA 亲和性、THP、MPS 与 MIG、CUDA/驱动兼容性和 PTX-JIT、感知 NVLink 域的 Kubernetes 分配、QoS 和抖动的决策标准
• 性能分析与容量规划 - 基准测试设计和容量估算
• 流式模式 - SSE、WebSocket 和客户端流式传输
• 成本优化模式 - 路由、缓存、批处理和 FinOps
• 批处理与调度 - 调优连续批处理、分块预填充和调度策略时加载
• 多模型路由 - 设计级联路由、跨模型缓存感知放置时加载
• 基础设施调优 - 调优主机或 GPU 设置时加载；NUMA、THP、MPS/MIG、驱动和互连设置的命令级检查清单
• 优化策略 - 组合多种优化手段时加载；用于组合量化、批处理和缓存优化手段的跨领域决策框架
• LLM 服务的弹性与高可用 - 设计故障转移、多区域或降级模式服务时加载：模型服务探测、预热、感知 KV 的自动扩缩容信号、以 Token 为单位的过载控制、KV/版本协调；通用高可用内容归入 qa-resilience，发布流程归入 ai-mlops

应用型基础

仅针对已诊断的容量或故障问题加载应用型基础，不要用于常规模型设置。平均队列等待时间无法证明 p99 TTFT。

• 数学优化 — 在确实需要进行副本／池分配，且有明确的实测容量、成本目标、内存和延迟约束时加载。返回变量、目标、约束、可行性以及求解器／证书的局限。实测延迟约束需要通过负载测试验证；连续 LP 证书无法证明整数部署或生产 SLO。单一可行方案的简单容量规划无需加载。

• 应用型排队论 - 连续批处理、KV 缓存大小调整、准入控制、解耦、多租户隔离和 token 预算反压 — 以排队论基础原理（Little 定律、M/M/c、Erlang-C、Kingman、P-K）为依据

• 应用型可靠性理论 - 级联模型的 SLO 预算分配、对冲请求、提供商故障切换、级联故障预防、KV 缓存损坏回滚和 spec-decode 回滚语义 — 以可靠性理论基础原理（MTBF/MTTR、错误预算、FTA、冗余计算）为依据

模板

• vLLM 配置
• TensorRT-LLM 配置
• DeepSpeed 推理
• LLM API 服务
• 高吞吐量设置
• 解耦式服务
• GGUF 格式
• AWQ 量化
• GPTQ 量化
• 批处理配置
• 前缀缓存
• 延迟与吞吐量测试
• 推理性能审查清单

脚本

脚本	用途
scripts/latency_benchmark.py	向兼容 OpenAI 的 /v1/chat/completions 端点发起 N 个并发请求，并报告 p50/p95/p99 延迟和吞吐量。仅使用标准库（urllib + threading）。

数据

• data/sources.json - 当前主要来源和基础论文

相关技能

• ai-llm
• ai-rag
• ai-mlops
• qa-observability
• ops-devops-platform
• huggingface-skills：插件（外部）— 使用 inspect-ai 和 lighteval 评估 HF 模型

经验反馈循环

如果以往的决策或陷阱与当前情况相关，请查阅 learnings.consolidated.md（如果存在）；仅在需要了解历史记录或它是唯一可用选项时，才使用 learnings.md。否则跳过这两个文件。

应用后，如果你遇到了值得记住的模式、值得避免的错误，或令你意外的领域事实，请通过 agents-skills-feedback-loop/scripts/append_learning.py 向 learnings.md 追加一条带日期的项目符号。不要修改 SKILL.md 本身。