本地LLM推理优化：完整指南

# 本地LLM推理优化：完整指南 来源：https://carteakey.dev/blog/local-inference/local-llm-optimization/ > **注意：**本文在大量AI辅助下起草，综合了来自l3ms家庭实验室工具包（https://github.com/carteakey/l3ms）以及本站一系列模型运行帖子的笔记、基准测试结果和脚本。文中记录的实验、数字和故障模式均为真实数据——综合和文笔由AI辅助完成。 ## 前言 过去一年中，我撰写了关于在消费级硬件上本地运行以下模型的帖子：gpt-oss-120b（https://carteakey.dev/blog/local-inference/optimizing-gpt-oss-120b-local-inference/）、Qwen3-Coder-Next（https://carteakey.dev/blog/local-inference/optimizing-qwen3-coder-next-local-inference/）、Gemma 4 26B（https://carteakey.dev/blog/local-inference/running-gemma-4-26b-a4b-locally/）、Qwen3.6-35B-A3B（https://carteakey.dev/blog/local-inference/running-qwen3-6-35b-a3b-locally/）以及Gemma 4 MTP（https://carteakey.dev/blog/running-gemma-4-mtp-locally/）。每篇帖子都有自己的笔记、故障模式和调优结果——但相同的经验反复出现：启用XMP、绑定到P-核心、量化KV缓存、不要相信电源配置。这是我尝试编写一份主参考文档。我不想每次在新模型帖子中重新发现标志，而是希望有一份可以链接回的文件。如果你遇到性能瓶颈、从头开始，或者想了解每个旋钮的实际作用——从这里开始。 范围有意宽泛。我们从“我到底该不该本地运行？”开始，一直深入到CUDA环境变量和特定故障模式。跳到你所卡住的地方。 --- ## 1. 太长不读：从这里开始 - **如果你想要最大控制和性能：**直接使用`llama.cpp`。本指南假定采用这条路径。 - **如果你想要桌面体验、模型浏览以及一个良好的本地OpenAI兼容端点：**LM Studio 非常合理。 - **如果你想要多用户服务、批处理和产线吞吐量：**评估`vLLM`。 - **如果你使用Apple Silicon：**比较`llama.cpp` Metal与`mlx`；统一内存改变了容量计算。 - **如果MoE模型上的TG差：**在动标志之前检查RAM速度。关闭XMP/EXPO可能损失2-3倍。 - **如果你遇到VRAM限制：**减少上下文、量化KV缓存、降低`--parallel`，然后调整层放置。 - **如果你使用MTP投机解码：**同时基准测试草稿接受率和KV缓存精度；原始TPS不够。 - **如果你运行单用户家庭实验室：**在获得稳定配置后，优先使用`--parallel 1`、显式上下文大小设置和静态放置。 ### 1.1 从哪里切入 这是一份参考，不是线性教程。从与你问题匹配的部分开始： - **MoE生成慢：**检查RAM速度（https://carteakey.dev/blog/local-inference/local-llm-optimization/#6-1-the-memory-hierarchy-the-most-important-mental-model），然后检查层放置（https://carteakey.dev/blog/local-inference/local-llm-optimization/#10-layer-placement-the-core-optimization-for-moe）和P-核心绑定（https://carteakey.dev/blog/local-inference/local-llm-optimization/#14-3-taskset-p-core-pinning-linux）。 - **模型放不下或之后在会话中崩溃：**从`--fit`（https://carteakey.dev/blog/local-inference/local-llm-optimization/#10-4-fit-on-recommended-starting-point）、上下文和KV缓存（https://carteakey.dev/blog/local-inference/local-llm-optimization/#11-context-and-kv-cache）开始，然后是已知OOM原因（https://carteakey.dev/blog/local-inference/local-llm-optimization/#known-tg-variability-root-causes）。 - **视觉在加载或第一张图片时失败：**前往视觉/多模态（https://carteakey.dev/blog/local-inference/local-llm-optimization/#19-vision-multimodal）。投影仪和图像批处理需要各自的余量。 - **MTP不比正常解码快：**检查草稿接受率和KV精度（https://carteakey.dev/blog/local-inference/local-llm-optimization/#18-2-the-kv-cache-constraint-ctk-f16-ctv-f16），而不仅仅是报告的TG。 - **你使用LM Studio或Ollama：**硬件（https://carteakey.dev/blog/local-inference/local-llm-optimization/#6-hardware）、操作系统（https://carteakey.dev/blog/local-inference/local-llm-optimization/#7-os-choice）和安全（https://carteakey.dev/blog/local-inference/local-llm-optimization/#21-security-notes）部分仍然适用。大多数llama.cpp标志不适用。 ### 1.2 安全起始配置 这些是单用户服务器的保守基线。它们是起点，不是通用最优值；模型架构仍然会改变内存计算。 工作负载 | `--fit-target` | 上下文 | KV缓存 | `--parallel` | 批处理 -- | -- | -- | -- | -- | -- 文本, 12 GB VRAM | 512 MiB | 64k | `q8_0`/`q8_0` | 1 | 1024 文本, 24 GB VRAM | 512–768 MiB | 128k | `q8_0`/`q8_0` | 1–2 | 1024 视觉, 12 GB VRAM | 2048 MiB | 64k | `q8_0`/`q8_0` | 1 | 256 MTP投机解码 | 512+ MiB | 64k | `f16`/`f16` | 1 | 1024 > **避免这些令人兴奋的故障模式：**不要在12 GB显卡上将视觉压缩到低于`--fit-target 2048`；不要在小于512 MiB余量时启用`GGML_CUDA_GRAPH_OPT=1`；不要在混合Intel CPU的线程范围中包含E-核心；不要在没有测量草稿接受率的情况下将`q8_0` KV设置复制到MTP配置中。所有这四种情况在短时间基准测试中可能看起来正常，但在真实会话中会失败。 ## 2. 优化优先级检查清单 按典型影响排序。每个项目链接到包含完整解释的章节。 # | 动作 | 影响 | 章节 -- | -- | -- | -- 1 | **在BIOS中启用XMP/EXPO** | MoE上TG提升2-3倍 | §6.1 2 | **使用MTP投机草案** | TG加速2.0x-2.6x | §18.1 3 | **使用QAT低比特模型**（如Q4 QAT） | 恢复大部分丢失的低比特质量 | §9.3 4 | **运行Linux**或调优Windows电源计划 | TPS提升约15-20% | §7 5 | **将`power-profiles-daemon`替换为`tuned-ppd`** | 消除间歇性20-30%的TG下降 | §7.4 6 | **从源码构建llama.cpp；保持更新** | 每版MoE内核改进 | §8.2 7 | **使用`--fit on`**进行VRAM最优层放置 | 重大TG提升；无需手动调优 | §10.4 8 | **在不使用MTP时使用`-ctk q8_0 -ctv q8_0`** | 释放KV VRAM用于额外GPU层 | §11.2 9 | **除非测试过，MTP下保持KV缓存为`f16`** | 在已测试的Gemma 4 MTP配置中保留草稿接受率 | §18.2 10 | **单用户家庭实验室设置`--parallel 1`** | 回收KV VRAM用于权重 | §11.3 11 | **使用`taskset -c`绑定到P-核心** | Intel混合架构上TG提升+20-30% | §14.3 12 | **启用`--flash-attn on`** | 大上下文稳定性要求 | §11.4 13 | **启用`--no-mmap`** | 消除页面错误导致的TG抖动 | §15.1 14 | **启用`--mlock`** | 防止会话中途交换降级 | §15.2 15 | **使用无头模式**（`systemctl isolate multi-user.target`） | 释放200-400 MB RAM + 合成器VRAM | §7.4 16 | **使用iGPU进行显示**（主板HDMI） | 释放500-1000 MB VRAM | §6.2 17 | **设置`LLAMA_SET_ROWS=1`** | MoE专家访问的缓存局部性 | §17.1 18 | **仅在余量充足时设置`GGML_CUDA_GRAPH_OPT=1`** | 减少CUDA分派开销 | §17.1 19 | **评估ik_llama.cpp**用于生成密集型工作负载 | 可能以牺牲PP为代价获得TG提升 | §20 ## 3. 调优前要测量什么 优化只有在你知道哪个阶段慢时才有意义。 度量 | 它告诉你什么 | 常见瓶颈 -- | -- | -- **TTFT**（首个token时间） | 多久后才开始输出 | 模型加载、提示处理、冷缓存 **PP**（提示处理） | 模型读取输入上下文的速度 | 批处理大小、GPU内核、长提示 **TG**（token生成） | 预填充后输出流的速度 | VRAM/RAM带宽、层放置、CPU绑定 **加载时VRAM** | 权重、KV缓存和mmproj是否放得下 | 上下文大小、并行槽位、量化级别 **长时间会话后VRAM** | 内存是否增长到OOM区域 | CUDA图、VMM池增长、拟合余量 **RAM带宽/交换** | 混合MoE权重是否成为瓶颈 | XMP/EXPO、通道、`--mlock`、swappiness **草稿接受率** | 投机解码是否有效 | 草案质量、KV精度、推测长度 不要基于单个短提示进行优化。短提示会隐藏KV缓存成本、长上下文VMM增长以及并行槽位分配。在你实际服务的上下文长度下进行基准测试。 ## 4. 术语表 术语 | 定义 -- | -- **GGUF** | llama.cpp使用的量化LLM权重文件格式。将权重、元数据和分词器存储在单个二进制文件中。 **量化** | 降低权重数值精度（FP16 → Q4等）以缩小模型大小并加速计算。更多比特=更高质量，更大文件。 **QAT（量化感知训练）** | 在训练/微调模型中注入量化噪声。允许在4比特内存大小下实现接近无损的8比特智能。 **MTP（多token预测）** | 原生用于MTP训练模型（如Gemma 4）的投机解码方法。使用伴随的草案模型并行生成多个候选token，基础模型在一个GPU步骤中验证它们。 **PP / 提示处理** | 预填充阶段每秒处理的token数——模型读取输入的速度。受GPU限制。 **TG / token生成** | 自回归解码期间每秒生成的token数——你看到输出流的速度。受内存带宽限制。**这是用户感受到的。** **KV缓存** | 存储所有先前上下文token的注意力Key/Value张量的缓冲区。随上下文长度线性增长。位于VRAM中。 **上下文窗口** | 单个会话中最大的总token数（输入+输出）。决定了KV缓存的大小。 **密集模型** | 标准Transformer：每个token激活所有参数。必须完全放入VRAM才能全速推理。 **MoE / 专家混合** | 架构，每个token只激活一小部分“专家”网络。允许非常大的总参数和很低的每个token计算量。放不进VRAM的专家权重可以溢出到系统RAM。 **活跃参数** | 对于MoE：每个token计算的参数子集。gpt-oss-120b：总120B中约5B活跃。Qwen3-Coder-Next：总80B中约3B活跃。TG速度跟踪活跃数量，而非总量。 **VRAM** | 视频RAM——GPU板载内存。推理中延迟最低、带宽最高的存储。 **困惑度** | 模型在测试语料库上惊讶程度的统计度量。越低越好。比较量化质量级别的标准代理指标。 **llama-bench** | llama.cpp中包含的用于合成PP和TG基准测试的CLI工具。 **llama-fit-params** | CLI工具，探测空闲VRAM并输出最优的`-ngl`和`--override-tensor`标志，无需启动服务器。 **`-ngl`/n-gpu-layers** | 要加载到GPU VRAM上的Transformer块数量。 **`-ot`/override-tensor** | 基于正则表达式的每个张量放置覆盖——将特定权重张量路由到CPU或GPU。 **XMP / EXPO** | 以额定速度运行系统RAM的BIOS配置（Intel XMP / AMD EXPO）。BIOS中的“自动”通常默认为JEDEC基准——额定速度的一个分数。 **Fit** | `--fit on`标志：启动时自动探测VRAM并计算最优放置，考虑KV缓存。 ## 5. 推理格局 ### 5.1 为什么本地运行？ - **隐私**：提示永远不会离开你的机器。 - **成本**：硬件后边际成本为零。在重度使用下很快摊销。 - **控制**：任何模型、任何量化、任何参数。无弃用、无速率限制、无价格变更。 - **离线**：无需互联网即可工作。 - **实验**：无需API合约即可切换模型、调整参数、运行评估。 ### 5.2 云端 vs 本地——诚实的权衡 托管API | 自托管云端GPU | 本地硬件 -- | -- | -- 设置 | 分钟 | 小时 | 小时–天 模型质量天花板 | 前沿 | 你的选择 | 你的选择 每token成本 | $1–15/M | $0.10–0.50/GPU-小时 | 零（边际） 隐私 | 提供商看到数据 | 你控制 | 完整 硬件投资 | 无 | 无 | $500–$3000+ 大多数严肃用户最终两者都用：云端API用于前沿任务，本地用于所有隐私敏感、实验性或常规性任务。 ### 5.3 本地推理工具 工具 | 最适合 | 备注 -- | -- | -- **llama.cpp** | 性能调优、完全标志控制、任何硬件 | 从源码构建；CLI为中心 **Ollama** | 零配置、模型管理、Docker | 内部使用llama.cpp；调优面有限 **LM Studio** | 桌面GUI、Windows/macOS、模型浏览、本地OpenAI兼容API | 良好用户体验，支持服务器/无头工作流、JIT加载、TTL和自动驱逐 **vLLM** | 多用户生产服务、连续批处理 | 专为完全VRAM服务设计；不适合消费级混合设置 **exllamav2** | 密集模型最高速度 | 仅CUDA；适合完全放入VRAM的模型 **mlx** | Apple Silicon | 仅macOS；利用统一内存；无CUDA **本指南聚焦于llama.cpp。** 大多数概念（KV缓存、量化、层放置）适用于各个工具。 ### 5.4 llama.cpp中的后端 后端 | 构建标志 | 最适合 -- | -- | -- **CUDA** | `-DGGML_CUDA=ON` | NVIDIA GPU；性能最高且经过最多测试 **Vulkan** | `-DGGML_VULKAN=ON` | AMD和Intel GPU；跨平台；也适用于NVIDIA **Metal** | (macOS自动) | Apple Silicon；统一内存 **仅CPU** | (无GPU标志) | 参考；小模型或调试 **RPC** | `-DGGML_RPC=ON` | 实验性分布式推理 > **本文档假设CUDA。** 在Vulkan或仅CPU上行为不同的地方，会标记为`[Vulkan]`或`[CPU]`。如果你使用AMD/Intel GPU，大多数标志逻辑相同，但特定于CUDA的环境变量不适用。 ## 6. 硬件 ### 6.1 内存层次结构——最重要的思维模型 Token生成速度受限于运行时如何快速将活跃权重流经内存层次结构。粗略带宽数字： ``` VRAM (GPU板载) ~600–1000 GB/s 统一内存 (Apple Silicon) ~200–400 GB/s 系统RAM ~50–200 GB/s (因速度和通道配置差异巨大) NVMe SSD ~5–7 GB/s SATA SSD / HDD ~0.5–3 GB/s ``` **密集模型**：每个token读取所有活跃权重。模型必须完全放入VRAM才能全速推理。任何溢出到系统RAM都会导致TG大幅下降。 **MoE模型**：每个token只需要专家权重的一小部分，但这些权重仍然必须被流式传输——通常来自系统RAM。TG ∝ RAM带宽。这意味着额定速度运行的RAM套件相对于JEDEC基准可以提供2-3倍的带宽，几乎线性地转化为MoE模型上的TG吞吐量。 **检查你的RAM是否以其额定速度运行：** ``` sudo dmidecode -t memory | grep -E "Speed|Configured" # "Configured Memory Speed" 必须与你的XMP/EXPO配置速度匹配。 # 如果不匹配，在BIOS中启用XMP/EXPO。 ``` 这是MoE推理中可获得的最大单一收益之一。BIOS“自动”设置通常默认使用JEDEC基准速度，无论套件的额定值如何。 ### 6.2 GPU / VRAM VRAM是主要的推理资源。更多VRAM = GPU上更多层 = 更快推理。 VRAM | 密集示例 | MoE混合示例 -- | -- | -- 8 GB | 7B–13B Q4 | 30B–70B，大量RAM卸载 12 GB | 13B–20B Q4; 7B Q8 | 70B–120B+，CPU卸载 24 GB | 34B Q4; 13B Q8 | 120B+ 适度卸载 48 GB+ | 70B Q8; 34B FP16 | 大多数MoE部分/完全在GPU上 80 GB+ | 120B+ FP16 | 无需卸载 **iGPU显示技巧（桌面NVIDIA）**：通过主板视频输出而不是GPU路由显示。这将释放GPU用于桌面合成的500-1000 MB VRAM。 ### 6.3 CPU 对于**密集模型**（全部在VRAM中）：推理期间CPU几乎空闲。核心计数影响极小。 对于**MoE混合**：CPU为每个token执行专家前向传播。专家计算是TG瓶颈。 **Intel混合架构（第12代及以上）**：P-核心和E-核心在矩阵运算上的吞吐量差异显著。E-核心会使TG下降20-30%。始终绑定到P-核心： ``` taskset -c 0-11 llama-server ... # i5-12600K：核心0-11是P-核心 ``` 线程数：将`--threads`设置为P-核心数，留1-2个给操作系统。线程数超过P-核心数是适得其反的。 ### 6.4 什么算“足够好”的吞吐量？ TG速度 | 体验 -- | -- < 5 t/s | 痛苦；几乎无法使用 5–10 t/s | 可用；接近人类阅读速度（~7 t/s） 10–20 t/s | 交互式聊天舒适 20–40 t/s | 快；编码智能体感觉流畅 40+ t/s | 对大多数任务接近即时 对于编码智能体：TG占主导。一旦上下文预热，首个token延迟就不再重要。每秒获得的每个t/s在整个会话中都会累积。 ## 7. 操作系统选择 ### 7.1 Linux