推理工程帕累托图谱：哪些优化在成本、质量和延迟前沿占主导？
摘要
本文构建了大语言模型推理优化的成本-质量-延迟帕累托图谱，使用校准的模拟器评估不同硬件和场景下的配置和组合。
查看缓存全文
缓存时间: 2026/09/17 09:26
# 推理工程帕累托图谱：哪些优化主导了成本、质量与延迟的边界？ 来源：https://arxiv.org/html/2609.17863 Srikanta Datta Tumkur, Jay Iyer, Mehar Simhadri, Sai Pavan Kumar, Sai Kapil Kumar, Ramesh Nampelly ###### 摘要 针对大型语言模型推理的每项优化都有其对应的加速数字，但这些数字难以直接比较。量化论文报告一种收益，KV缓存压缩论文报告另一种，而推测解码、批处理和稀疏注意力各自报告的数字也不同，且几乎总是在不同的模型、GPU、提示词和质量指标上进行测试。对于预算固定、质量底线明确或延迟目标明确的实践者来说，这些数字无法简单叠加，也无法判断当多种方法叠加使用时哪种组合最优。本文构建了一个成本-质量-延迟帕累托图谱：将每项优化及所有有前景的组合置于共同坐标轴上，并在每种部署场景中指明占优配置。由于配置空间过大无法穷举测量，我们在真实硬件上测量锚点数据，并利用经过校准的分析模拟器填充其余空间。锚点数据来自Qwen2.5-7B-Instruct模型在L4、A100和H100实例上通过vLLM 0.12服务的54种配置，每种GPU对应三种任务场景共18种配置；校准后的模拟器在锚定批处理大小下复现这些配置，跨场景偏差低于1.5%。独立的质量评估分支对FP16、AWQ-4bit、FP8权重和FP8 KV缓存配置在GSM8K（200题，5-shot）上进行评分。稀疏注意力是唯一仅能通过模拟测试的方法。在校准的配置网格中，36种配置中有18种达到帕累托前沿，组合配置比单一方法更常达到前沿（15种中的9种 vs 21种中的9种）。评估质量指标会改变胜出者：AWQ-4bit在L4上可将每token延迟降至0.34倍，但严格GSM8K准确率下降5.9%，未达到95%质量底线的差距在采样误差范围内；准确率损失主要体现在答案格式而非计算上，因为灵活提取模式与FP16基线持平。FP8权重量化在所有三种GPU上保持99.4%基线准确率，延迟降至0.61-0.65倍，并出现在四种场景胜者配置中的三组。朴素FP8 KV缓存配置表现出正常吞吐量，但200题中答对数为零——这种仅追求速度的基准测试可能推荐的配置被图谱排除。在两种提示设计下，n-gram推测解码测得0.90-0.98倍延迟，对此技术栈无增益。胜者配置随约束条件和GPU类型而变化：H100主导严格延迟场景，A100则在吞吐量和每百万token成本0.106美元的低成本场景中胜出。 \\@IEEEabskeysecsize 索引词：\\@IEEEgobblelead大型语言模型推理、帕累托前沿、成本-质量-延迟、量化、推测解码、服务、基准测试、优化图谱。 ## I 引言 参见图注图1：研究概览。(1)现有文献在不可比较的场景下报告许多孤立的加速数据，导致无法对比或组合。(2)受成本、质量或延迟约束的实践者需要知道哪种优化或组合占优。(3)我们将所有方法及有前景的组合置于共同的成本-质量-延迟坐标轴上，计算帕累托前沿，并构建图谱以显示各场景下的占优工作点。每个月都会涌现使LLM推理更便宜或更快的新方法：低比特量化[7 (https://arxiv.org/html/2609.17863#bib.bib7),8 (https://arxiv.org/html/2609.17863#bib.bib8),9 (https://arxiv.org/html/2609.17863#bib.bib9)]、KV缓存压缩与驱逐[10 (https://arxiv.org/html/2609.17863#bib.bib10),11 (https://arxiv.org/html/2609.17863#bib.bib11)]、推测解码[6 (https://arxiv.org/html/2609.17863#bib.bib6)]、连续批处理与服务级别目标感知调度[3 (https://arxiv.org/html/2609.17863#bib.bib3),4 (https://arxiv.org/html/2609.17863#bib.bib4)]以及稀疏注意力[12 (https://arxiv.org/html/2609.17863#bib.bib12)]。每项方法都有论文报告显著收益，但这些数字无法比较——它们来自不同模型、GPU、提示词和质量指标，因此论文A中的"三倍加速"与论文B中的"两倍加速"既无法相加或对比，也无法保证在给定部署中复现（图2 (https://arxiv.org/html/2609.17863#S1.F2)）。 参见图注图2：在共同坐标轴上，大多数已发表工作点被支配。帕累托前沿——即没有其他配置能在质量和延迟上同时超越的配置集合——才是实践者应选择的范围。校准网格；锚点在RunPod实例上测量。这导致实际决策困难。需要固定质量下最低延迟、或固定延迟下最低成本的工程师无法通过阅读论文选择胜者，因为各方法不在同一坐标轴上且交互作用未知。同时缺乏中立平台供新方法对比，导致声称随时间推移产生分歧。核心问题是：在整个优化技术栈和不同硬件平台上，哪些配置位于成本-质量-延迟帕累托前沿？给定约束条件下应选择哪个？ 障碍在于缺乏统一地图。已有优秀的模型质量基准和原始服务吞吐量基准[1 (https://arxiv.org/html/2609.17863#bib.bib1),13 (https://arxiv.org/html/2609.17863#bib.bib13)]，近期研究开始从成本-质量前沿构建推理经济学框架[14 (https://arxiv.org/html/2609.17863#bib.bib14)]。但尚无单一图谱能将量化、KV压缩、推测解码、批处理和稀疏注意力——无论单独还是组合——共同置于部署所关心的三个轴上，并标注各场景下的占优选择。本文即构建此图谱。 我们在三种GPU（L4、A100、H100）上对Qwen2.5-7B-Instruct模型进行54种锚点配置测量（使用512 token提示、128 token输出的单一服务负载），报告质量、首token时间、每输出token时间、吞吐量和每百万token成本，并针对每种精度设置GSM8K质量评估分支。由于配置空间（方法×组合×硬件）远超直接测量能力，我们根据锚点校准分析模拟器[2 (https://arxiv.org/html/2609.17863#bib.bib2)]以填充空间，再计算严格延迟、高吞吐量和低成本约束下的帕累托前沿及占优工作点。 我们的贡献如下： 1. 1\.成本-质量-延迟帕累托图谱（图5 (https://arxiv.org/html/2609.17863#S3.F5)）：将主要推理优化及其组合置于共同坐标轴，并标注各场景下的占优配置。 2. 2\.先测量后模拟的方法论（图4 (https://arxiv.org/html/2609.17863#S3.F4)）：通过校准分析模拟器与实际运行数据，实现从锚点测量覆盖完整配置空间。 3. 3\.实践规则集：哪些优化反复出现在前沿，哪些组合占优，以及胜选如何随约束条件和GPU类型变化。 ## II 背景与相关工作 ### II\-A 优化技术栈 我们置于图谱的方法针对不同成本维度：量化[7 (https://arxiv.org/html/2609.17863#bib.bib7),8 (https://arxiv.org/html/2609.17863#bib.bib8),9 (https://arxiv.org/html/2609.17863#bib.bib9)]和KV缓存压缩或驱逐[10 (https://arxiv.org/html/2609.17863#bib.bib10),11 (https://arxiv.org/html/2609.17863#bib.bib11)]可减少内存与带宽占用；推测解码[6 (https://arxiv.org/html/2609.17863#bib.bib6)]减少解码步骤；连续批处理[3 (https://arxiv.org/html/2609.17863#bib.bib3)]与服务级别目标感知调度[4 (https://arxiv.org/html/2609.17863#bib.bib4)]提高利用率；稀疏注意力[12 (https://arxiv.org/html/2609.17863#bib.bib12)]减少注意力计算；预填充-解码分离[5 (https://arxiv.org/html/2609.17863#bib.bib5)]将两个阶段拆分。每种方法提供不同调控维度并影响不同坐标轴，只有统一的前沿框架才能使其具有可比性。 ### II\-B 基准测试与经济学 MLPerf Inference[1 (https://arxiv.org/html/2609.17863#bib.bib1)]标准化服务测量，Spec-Bench[13 (https://arxiv.org/html/2609.17863#bib.bib13)]标准化推测解码评估，但两者均未将完整优化技术栈置于联合成本-质量-延迟前沿。近期研究探讨模型选择的推理经济学与成本-质量前沿[14 (https://arxiv.org/html/2609.17863#bib.bib14)]，以及广泛的本地推理基准测试[15 (https://arxiv.org/html/2609.17863#bib.bib15)]。我们的图谱增加了优化和硬件维度，并提供显式的占优地图。 ### II\-C 大规模配置空间的模拟 配置空间具有组合爆炸特性，穷举测量不可行。Vidur[2 (https://arxiv.org/html/2609.17863#bib.bib2)]表明，经过分析的模拟器可在误差范围内估算LLM推理延迟和吞吐量，并低成本搜索数百种部署配置。我们采用先测量后模拟的策略：在真实硬件上测量锚点，校准模拟器，再用其填充前沿空间。 参见图注图3：不同优化在不同场景下处于前沿，因此各方法在不同约束下出现在帕累托前沿的频率比单一加速数字更具信息价值。这是图谱报告场景地图的原因。校准网格，已测量锚点。 ### II\-D 帕累托占优 若某配置在所有轴上至少与另一配置持平，且在至少一个轴上严格更优，则后者被“支配”。帕累托前沿是非支配配置集合；这是理性实践者应选择的唯一集合，具体选择由约束条件决定。形式上，图谱即前沿加上各约束下最优配置的标注。 ### II\-E 我们的定位 我们将可比性和占优性视为交付物：统一协议、共同坐标轴、所有优化与组合的定位、基于实测锚点校准的模拟器，以及前沿与占优地图。输出是实践者选择优化方案时使用的地图。 ## III 方法论 参见图注图4：先测量后模拟的图谱生成流程。对固定模型、负载和GPU集合运行每种优化以生成测量锚点（质量、TTFT、TPOT、吞吐量、成本）。分析模拟器针对这些锚点进行校准，然后用于填充大规模配置空间（优化×组合×硬件）。对每个模型和负载计算成本、质量和延迟的帕累托前沿，并标注各约束下的占优配置，最终形成图谱。 ### III\-A 坐标轴与指标 每个配置置于三个轴：质量（任务准确率或与全精度模型的一致性）、延迟（TTFT和TPOT，报告P50和P99值）和成本（每百万token美元成本，基于吞吐量和GPU小时价格推算）。吞吐量和GPU显存作为辅助指标记录。质量始终与速度同步报告，确保没有配置通过隐式降低答案质量获胜。 ### III\-B 配置与组合 配置指给定模型和GPU上的优化设置选择：量化比特数、KV保留率或比特数、推测草案、批处理策略、稀疏注意力预算。单一方法配置是构建模块；组合则叠加兼容方法（例如在服务级别目标感知批处理中将推测解码与量化KV缓存结合）。组合空间庞大，这正是需要模拟器的原因。 ### III\-C 先测量后模拟 我们在每种GPU上直接测量锚点配置以捕获实际内核和内存行为，然后校准分析模拟器[2 (https://arxiv.org/html/2609.17863#bib.bib2)]使其延迟和吞吐量预测在较小误差内匹配锚点。校准后的模拟器填充其余空间。算法1 (https://arxiv.org/html/2609.17863#alg1)描述构建过程。 算法1 构建帕累托图谱 输入：模型、负载、GPU、优化配置、锚点 1：在真实硬件上测量锚点配置；记录质量、延迟、成本 2：用锚点校准分析模拟器 3：模拟完整配置和组合空间 4：对每个（模型、负载）do 5： 计算（质量、延迟、成本）帕累托前沿 6： 标注严格延迟、高吞吐量、低成本下的占优配置 7：end for 8：返回前沿和占优图谱 ### III\-D 图谱解读 图谱（图5 (https://arxiv.org/html/2609.17863#S3.F5)）是一个网格，行表示部署场景（绑定约束），列表示坐标轴或负载；每个单元格标注占优配置。三个假设待验证：少数组合反复出现在前沿；胜者随绑定约束变化（低成本场景倾向激进量化，严格延迟场景倾向推测解码，高吞吐量场景倾向批处理）；GPU选择移动整个前沿。第V节 (https://arxiv.org/html/2609.17863#S5) 报告验证结果。 参见图注图5：图谱：各部署场景下的占优配置。带框单元格标记组合配置超越所有单一方法的情况。校准网格，已测量锚点。 ### III\-E 成本核算 每百万token成本取决于GPU小时价格和测量吞吐量，两者均明确说明。模拟数据点携带模拟器的校准误差范围；测量锚点则不携带。我们从不将模拟延迟伪装成测量值，且每个前沿都标注锚点位置。 ## IV 实验设置 ### IV\-A 模型、负载、硬件与指标 测量活动锚定单一模型Qwen2.5-7B-Instruct在三种GPU（RunPod L4、A100 80GB PCIe、H100 PCIe）上的单一服务负载（512 token提示、128 token输出），均由vLLM 0.12服务，质量在GSM8K上评估。表I (https://arxiv.org/html/2609.17863#S4.T1) 列出协议定义的四种负载；其中仅数学负载（GSM8K）作为质量评估分支在此测量。指标面板包括质量、TTFT、TPOT（P50和P99）、吞吐量、GPU显存和每百万token成本，所有数值均注明模型、GPU、批处理大小和负载。 表I：协议负载及每种负载侧重的成本维度；此处仅测量数学负载（GSM8K）。 ### IV\-B 优化与协议 优化方法包括量化（KIVI、TurboQuant、AWQ）、KV压缩与驱逐（PyramidKV、H2O）、推测解码（EAGLE-3）、连续批处理与服务级别目标感知调度（vLLM、Sarathi）以及稀疏注意力（NSA），每种均为可调控维度，及其兼容组合。其中活动锚定了量化（AWQ-4bit和在线FP8权重）、KV压缩（FP8 KV缓存）和推测解码（n-gram提示查找；所用服务引擎未实现草案模型推测解码，且目标模型无EAGLE头）；稀疏注意力仅通过模拟测试。锚点在真实GPU上测量；其余使用校准分析器模拟。主要设置见表II (https://arxiv.org/html/2609.17863#S4.T2)。 表II：主要设置。 ## V 结果 本节所有延迟、吞吐量和成本数据均源自54个已测量的锚点配置（2026年7月活动：RunPod L4每小时0.39美元，A100 80GB PCIe每小时1.39美元，H100 PCIe每小时2.89美元；vLLM 0.12.0，Qwen2.5-7B-Instruct，512 token提示，128 token输出）。
相似文章
# 推理工程从入门到精通
# LLM 推理优化实用指南：在硬件约束下榨干性能 本文是一份面向实践者的指南，覆盖常见的推理瓶颈——包括运行时选型（Ollama、llama.cpp、vLLM、SGLang）、硬件相关的编译选项、量化方案的选择（IQ vs Q_K vs NL），以及按任务选型模型——并给出在有限硬件条件下优化 LLM 推理的最佳实践。 --- ## 目录 1. [为什么推理是瓶颈](#为什么推理是瓶颈) 2. [运行时选型：Ollama、llama.cpp、vLLM、SGLang](#运行时选型) 3. [硬件相关的编译选项](#硬件相关的编译选项) 4. [量化方案：IQ vs Q_K vs NL](#量化方案) 5. [按任务选择模型](#按任务选择模型) 6. [端到端最佳实践](#端到端最佳实践) 7. [常见误区与排查清单](#常见误区与排查清单) --- ## 为什么推理是瓶颈 推理的成本通常由两部分构成： - **预填充阶段（prefill）**：处理输入 prompt，计算量大，受算力（FLOPs）限制，是 **compute-bound**。 - **生成阶段（decode）**：逐 token 自回归生成，每步都要读取全部权重，受内存带宽限制，是 **memory-bandwidth-bound**。 在 decode 阶段，实际算力利用率往往只有个位数百分比，性能几乎完全由 **「模型大小 / 内存带宽」** 决定。因此： > 量化带来的收益不只是"显存更省"，更重要的是"每步读的数据更少，生成更快"。 理解这一点，是理解后续所有优化手段的基础。 --- ## 运行时选型 没有万能的推理引擎，选择取决于场景：本地单用户、批量离线处理，还是高并发在线服务。 ### Ollama - **定位**：本地开发与个人使用，开箱即用。 - **优点**：安装简单、模型管理便捷、内置轻量 HTTP API、自动选择合理的量化版本。 - **缺点**：抽象层较多，难以做细粒度调优；并发能力有限。 - **适用**：开发者本机实验、原型验证、单用户交互场景。 ### llama.cpp - **定位**：CPU / 边缘设备推理的事实标准，也可用于 GPU。 - **优点**：编译选项极其丰富、内存占用低、跨平台支持好（x86、ARM、Apple Silicon）、量化格式最全。 - **缺点**：批量与并发支持不如 vLLM；高并发吞吐不是强项。 - **适用**：树莓派、MacBook、老旧 CPU 服务器、需要极致内存控制的场景。 ### vLLM - **定位**：面向生产的高吞吐在线推理服务。 - **优点**：PagedAttention、Continuous Batching、Tensor Parallelism、丰富的量化后端支持，高并发下吞吐优势显著。 - **缺点**：资源开销较大、单用户低延迟场景未必占优、需要 GPU。 - **适用**：API 服务、多租户推理平台、需要稳定吞吐的生产环境。 ### SGLang - **定位**：复杂采样工作负载与多轮对话的高吞吐引擎。 - **优点**：RadixAttention 对共享前缀缓存极高效，擅长多轮对话、工具调用、结构化输出等场景；支持混合并行与投机解码。 - **缺点**：生态相对年轻，调试资料略少于 vLLM。 - **适用**：多轮 agent、共享系统提示的高并发服务、复杂控制流的 LLM 应用。 ### 选型速查表 | 场景 | 推荐 | | --- | --- | | 个人本机 / 开发调试 | Ollama、llama.cpp | | 边缘 / CPU / 低内存设备 | llama.cpp | | 高并发在线 API | vLLM | | 多轮对话 / Agent / 共享前缀 | SGLang | | 批量离线处理 | vLLM 或 SGLang（大 batch 时均可） | --- ## 硬件相关的编译选项 "用同样的模型和同样的量化，不同机器的性能可以差几倍"——差别的来源往往就是编译选项。 ### CPU（llama.cpp） 在 `CMake` 构建时根据 CPU 指令集开启对应选项： | 构建选项 | 说明 | | --- | --- | | `-DGGML_NATIVE=ON` | 按当前编译机器的 CPU 指令集自动生成代码 | | `-DGGML_AVX=ON` / `-DGGML_AVX2=ON` / `-DGGML_AVX512=ON` | 启用对应 SSE/AVX/AVX-512 加速 | | `-DGGML_ARM_NEON=ON` | ARM NEON 加速（默认启用） | | `-DGGML_CUDA=ON` / `-DGGML_METAL=ON` / `-DGGML_VULKAN=ON` | 对应 GPU 后端 | 要点： - **在目标机器上编译**，`GGML_NATIVE=ON` 才能选出最优指令集。 - AVX-512 相比 AVX2 在大模型推理上常有明显提升，务必确认是否开启。 - 大矩阵乘法优先走 BLAS（如 OpenBLAS、MKL），可显著提升 prefill 吞吐。 ### GPU - **CUDA**：确保 `CMAKE_CUDA_ARCHITECTURES` 或 `-DCMAKE_CUDA_ARCHITECTURES=native` 与你的 GPU 匹配，避免 PTX JIT 带来的启动开销。 - **Compute capability 对齐**：`nvcc` 编译的代码若高于 GPU 的 compute capability，可能直接无法运行。 - **Tensor Core**：确认量化内核能真正利用 Tensor Core（如 AWQ、GPTQ 的 Marlin 内核、FP8 内核），而不是退化到普通 CUDA 核心。 ### Apple Silicon - Metal 后端通常比 CPU 后端快 10 倍以上。 - 统一内存架构下，量化收益不仅体现在速度，还体现在模型容量上限。 --- ## 量化方案 ### 量化格式速览 | 类型 | 代表格式 | 位宽 | 特点 | | --- | --- | --- | --- | | **整数量化** | Q8_0、Q6_K、Q5_K_M、Q4_K_M、Q4_0 | 4–8 bit | 简单高效，广泛兼容 | | **K-Quant（Q_K）** | Q4_K_M、Q5_K_M、Q6_K、Q3_K_L | 3–6 bit | 逐层/逐块混合精度，是当前主流推荐 | | **重要性量化（IQ）** | IQ2_XXS、IQ3_XXS、IQ4_XS | 2–4 bit | 基于重要性矩阵（imatrix）的方法，低比特下质量更稳 | | **NL / 非线性量化** | NF4（bitsandbytes）、非线性 K-quants | ~4 bit | 均匀分布假设被打破，对非均匀权重分布更友好 | ### IQ（Importance Quantization） - 通过 **imatrix**（重要性校准数据集）为每个权重组赋予重要性权重，量化误差大的权重保留更多信息。 - 在 **3–4 bit** 低比特场景下，质量损失通常明显小于传统 Q 格式。 - 代价：生成 imatrix 需要校准数据集；部分格式推理速度略慢。 - **推荐**：在显存/内存吃紧、必须用 2–4 bit 时优先考虑 IQ 系列。 ### Q_K（K-Quant） - llama.cpp 中的主力格式，采用**分层混合精度**策略：对敏感层用更高位宽，非敏感层用更低位宽。 - `Q4_K_M` 是当前性价比最均衡的选择，`Q5_K_M` / `Q6_K` 则提供接近 FP16 的质量。 - **推荐**：大多数场景的默认选择。Q4_K_M 用于 8–16 GB 内存的机器，Q6_K 用于追求质量且内存尚可的机器。 ### NL（非线性量化） - NF4 等格式基于权重分布近似正态的先验，将量化区间做**非线性映射**，低比特下保真度更高。 - 在 bitsandbytes 生态中支持良好，但与 llama.cpp / GGUF 生态的兼容性有限。 - **推荐**：在 HuggingFace transformers 直接微调/推理、且可用 bitsandbytes 时使用；若走 GGUF / llama.cpp / vLLM 部署链路，K-Quant 或 IQ 更实用。 ### 选型建议 | 内存预算 | 推荐方案 | | --- | --- | | 充裕 | 不量化 / FP16 / BF16，或 Q8_0 | | 中等 | Q6_K、Q5_K_M | | 紧张（12–16 GB） | Q4_K_M（首选） | | 极紧（< 12 GB，大模型） | IQ4_XS、IQ3_XXS，或 Q3_K_L | | 最紧（2–3 bit） | IQ2_XXS（需 imatrix） | > **通用原则**：量化是"用质量换速度与容量"。每换一个更激进的格式，都要用**你的真实任务**做回归测试，而不是只看通用 benchmark。 --- ## 按任务选择模型 "最好的模型"取决于任务类型。 | 任务类型 | 关注点 | 建议 | | --- | --- | --- | | **通用对话 / 助手** | 指令跟随、事实准确性、长上下文 | 通用 instruct 模型（如 Llama、Qwen、Mistral 系列），质量优先，量化可保守 | | **代码生成** | 语法正确性、长上下文代码理解 | 代码专精模型；建议 Q5_K_M 及以上，低比特对代码影响较大 | | **摘要 / 分类 / 提取** | 输出短、延迟不敏感、可能需要低延迟 | 可大胆用低比特模型甚至更小的模型，量化到 Q4 甚至 IQ3 通常可接受 | | **数学 / 推理** | 逻辑链长度、token 敏感 | 推理增强型模型；量化影响更显著，尽量 Q6_K 以上 | | **RAG / 长文档** | 上下文长度、KV cache 体积 | 考虑支持长上下文的模型 + KV cache 量化（如 k-quant 的 KV cache、Q8 KV） | | **Agent / 工具调用** | 结构化输出稳定性、多轮一致性 | 使用原生支持 tool calling 的模型；避免过度量化 | | **边缘 / 离线** | 小模型、低延迟、无网络 | 紧凑型模型（3B–8B）+ IQ/Q4 格式 | 模型规模的取舍： - **小模型（1B–3B）**：延迟最低、成本最低，适合分类、改写等"短任务"。 - **中模型（7B–14B）**：质量与速度的甜点区，绝大多数场景够用。 - **大模型（30B+）**：复杂推理与长任务才值得，对硬件要求高。 > **务实建议**：先用小模型跑通 pipeline，测量真实指标（准确率、延迟、token/s），再决定是否升级模型规模。模型翻倍带来的收益，常常不如一个更好的量化方案或正确的引擎配置。 --- ## 端到端最佳实践 ### 1. 先测量，再优化 建立可复现的基准： - 用**你的真实请求**做测试，不要只用通用 benchmark。 - 分开测量 prefill 速度与 decode 速度。 - 关注 **首 token 延迟（TTFT）** 与 **每 token 延迟（TPOT）**，二者对应不同瓶颈。 ### 2. 针对瓶颈优化 | 症状 | 可能瓶颈 | 优化方向 | | --- | --- | --- | | prefill 慢、decode 正常 | compute-bound | 更大 batch、更好硬件、Flash Attention | | decode 慢、prefill 正常 | 内存带宽受限 | **更小的量化格式**、更快的显存/GPU、投机解码 | | 内存溢出 | KV cache / 模型过大 | 量化 KV cache、更激进的模型量化、更小模型 | ### 3. 高并发场景的关键手段 - **Continuous Batching**：让请求动态进出批次，显著提升吞吐（vLLM、SGLang 内置）。 - **Paged KV Cache**：减少显存碎片，提高并发容量。 - **Prefix / Radix Caching**：共享 system prompt 与多轮对话前缀的 KV（SGLang 的 RadixAttention 尤其强）。 - **Tensor / Pipeline Parallelism**：多卡场景下的显存与算力切分。 - **Speculative Decoding**：用小模型起草、大模型验证，decode 吞吐可提升 2–3 倍。 ### 4. 减少生成量本身 很多时候最大的优化不是引擎，而是**少生成一点**： - 精简 system prompt 与 few-shot 示例。 - 使用 `max_tokens` 硬限制与合理的 `temperature`。 - 对摘要/分类任务采用结构化输出，减少冗长自由文本。 --- ## 常见误区与排查清单 ### 误区 - ❌ "量化 = 模型变笨"。Q4_K_M 通常只带来很小的质量损失，收益是显著的速度与容量提升。 - ❌ "引擎越复杂越好"。本地单用户用 vLLM 往往是浪费；反之，高并发用 Ollama 会严重限制吞吐。 - ❌ "看别人 benchmark 选型"。别人的 GPU、上下文长度、batch size 与你不同，结论可能完全相反。 - ❌ "只调模型不调编译"。同一模型在不同 CPU 指令集下可以差 2–4 倍。 ### 排查清单 - [ ] 量化格式是否真的被目标引擎支持并能加速？ - [ ] KV cache 占用是否计入内存预算？ - [ ] batch size 是否已调优？（小 batch 可能远未打满 GPU） - [ ] 上下文长度设置是否合理？（KV cache 随长度线性增长） - [ ] 是否启用了正确的 Flash Attention / Paged Attention？ - [ ] CPU 推理是否用上了 BLAS？ - [ ] GPU 架构是否与编译时设置一致？ - [ ] 是否用真实任务做过质量回归测试？ --- ## 结语 优化 LLM 推理没有银弹，但有一条清晰的路径： 1. **明确场景**——本地开发、边缘部署，还是高并发服务。 2. **选对引擎**——Ollama / llama.cpp / vLLM / SGLang 各有其位。 3. **匹配硬件**——编译选项与并行策略要与你的 CPU/GPU 对齐。 4. **合理量化**——Q_K 是默认，IQ 用于极限压缩，NL 留给特定生态。 5. **按任务选模型**——别为短任务付长模型的代价。 6. **持续测量**——用真实负载回归，而不是盲信通用 benchmark。 把这六步走通，你就能在给定的硬件约束下，获得既快又稳的推理性能。
LLM推理的有效前沿
本文解释了LLM推理中的有效前沿概念，涵盖了延迟、吞吐量和成本之间的权衡，并概述了在部署中管理或提高效率的技术。
本地LLM推理优化：完整指南
一份关于在消费级硬件上优化本地LLM推理的全面指南，涵盖llama.cpp、vLLM和LM Studio等工具，并提供关于内存层次结构、层放置和常见故障模式的实用建议。
聚类、路由、升级：面向成本感知的LLM服务的级联框架
提出了一种面向成本感知的LLM服务的两阶段级联框架，该框架将查询聚类并路由至最具成本效益的模型，然后将低质量输出升级至更强的模型。在降低推理成本的同时，保留了97-99%的准确率。
@polynoamial: https://x.com/polynoamial/status/2064210146558136827
本文认为，LLM基准测试性能越来越依赖于测试时的计算量，而当前的评估方法在控制推理预算时无法捕捉到能力的提升。它主张绘制性能与token数、成本或时间的关系图，并讨论了对安全评估的影响。