高级 18 分钟llama.cpp

本地部署 Kimi K2：1 万亿参数 MoE 模型在…… soi

在本地使用 llama.cpp 运行 Kimi K2，就是在个人工作站上运行一个拥有万亿参数的 MoE 模型。这一壮举依赖两个关键因素：每个 token 仅激活 32B 参数（其余参数处于休眠状态），而 llama.cpp 能通过 mmap 将未激活的权重留在 SSD 上。本指南将详细介绍硬件配置、Q2_K_S 量化、磁盘卸载以及可以期待的实际性能数据。

作者： Mohamed Meguedmi·更新于 2026-06-05·已在 Windows、macOS 和 Linux 上测试

#为何在本地部署 Kimi K2

Kimi K2 是 Moonshot AI 的旗舰模型，以开放权重（Modified MIT 许可证）发布，采用 MoE（混合专家）架构，总参数达 1 万亿，每个 token 激活约 32B 参数。在推理和代码基准测试中，其表现可与闭源前沿模型相媲美，其长上下文（宣称支持 128k tokens）使其成为大规模文档分析的有力候选者。

18 个月前，在本地运行这么大的模型还只是幻想。三项进展改变了局面：大容量 DDR5 内存的普及（花几百欧元即可获得 192–384 GB）、顺序读取速度可达 7 GB/s 的 NVMe Gen 4 SSD，以及 llama.cpp 团队在 Q2_K_S 和 IQ1_M 等极低位宽量化方面的工作。

i
非实时，但可用
说清楚一点：以每秒 2–6 个 token 的速度在本地运行时，Kimi K2 并不是交互式聊天机器人。它适合批量提交查询，让它慢慢处理长上下文，并在回答质量比响应延迟更重要时使用。

#理解 MoE：1T 总参数 / 32B 活跃参数

本地 AI 套件

只需 1 小时，即可在您的电脑上拥有专属的免费 ChatGPT — LM Studio、Ollama、Open WebUI、您的文档，无需云端。

  • 在线空间，终身可用
  • PDF + 文件
  • 30 天内退款
本地 AI 套件 →或 所有套件终身使用权 — 49 € →

MoE 架构将稠密的 FFN 模块替换为一个由多个专家组成的层（通常有 256 个以上的专家），路由器针对每个 token 从中选择 8 到 12 个专家。计算时，只处理被选中的专家的参数——这就是约 32B 个“活跃”参数的由来。但在内存方面，所有专家都必须能够被寻址访问，否则路由器就无法访问模型中 95% 的部分。

总参数
约 1 万亿（1T）。这是驻留在 RAM 或磁盘上的部分。
每个 token 的激活参数量
≈ 320亿。这决定了计算和速度。
每层的专家
数百个专家，每个 token 都会被路由到其中固定数量的专家（top-k 路由）。
共享层（注意力）
始终处于激活状态。在上下文较短时，它们占据主要的内存开销。
KV缓存
随上下文长度线性增长。在 128k 上下文下，KV 缓存即使经过量化，也可能超过 30 GB。
→
为什么MoE模型能进入密集模型1T无法容纳的区域
一个拥有 1T 参数的稠密模型在 FP16 下需要约 2 TB，即使采用 Q2 量化也需要约 250 GB。在同等质量下，一个总参数量为 1T、激活参数量为 32B 的 MoE 模型，采用激进量化后可在 200 至 250 GB 内存中运行，而且其中大部分内存主要用于读取，而非写入——因此，在 SSD 上使用 mmap 是可行的。

#需预留的内存预算

计算 1T MoE 模型的内存需求时，可将其分为三个独立部分。在花钱购买 RAM 或 SSD 之前，理解这三个部分至关重要。

模型大小（量化后）
Q2_K_S ≈ 245 GB，Q3_K_S ≈ 320 GB，Q4_K_M ≈ 480 GB，Q8_0 ≈ 1 TB。模型权重是占用空间最多、也最容易压缩的部分。
KV缓存（上下文）
FP16格式下每个token约0.25 MB，Q8格式下约0.12 MB。因此128k个token在Q8格式下占用约32 GB。可通过 --cache-type-k/-v 参数配置。
激活缓冲区
每个GPU用于中间计算的显存为几GB。虽然影响较小，但在24GB显存的GPU上不可忽视。
!
RAM ≠ 模型存储
借助 mmap，llama.cpp 可以对无法全部装入 RAM 的模型权重进行寻址：内核会按需从 SSD 调入内存页。但在推理过程中，每个不在内存中的页面都需要一次磁盘读取，因此快速的 NVMe 至关重要。RAM 决定速度，SSD 决定容量。

#硬件要求

三类机器配置都可以在本地运行 Kimi K2，但在速度方面需要作出的取舍差异很大。

配置 A — 高性能 DDR5（192–384 GB 内存）
Threadripper/Xeon W 工作站或 EPYC 平台。256 GB DDR5 ECC 内存，不强制要求 GPU。在 Q2_K_S 量化下，模型能完全放入系统内存。纯 CPU 运行的预期速度：4–8 token/秒。
B型配置 — DDR5 + 1块24 GB显卡
96–128 GB 系统内存 + RTX 4090/3090。将共享层转移到 GPU 上运行，专家保留在系统内存中。预期速度：6–12 token/秒，具体取决于显存中能容纳多少个专家。
C型配置 — 内存有限 + NVMe固态硬盘
64-96 GB 内存 + NVMe Gen 4（读取速度 7 GB/s，空闲空间 ≥ 1 TB）。从 SSD 映射权重。预期速度：1-3 个 token/秒，具体性能高度依赖实际 SSD 读取带宽。
→
SSD成为新的性能瓶颈
如果您打算依靠磁盘卸载，请检查 SSD 的随机访问延迟，而不只是营销宣传中的顺序吞吐量。三星 990 Pro 或西部数据 SN850X 能够胜任。入门级 QLC SSD 的随机读取速度会骤降至 200 MB/s——在这种场景下无法使用。

#1. 使用正确的后端编译llama.cpp

Kimi K2 需要较新的 llama.cpp 版本（2025 年 12 月之后的近期构建），该版本需支持其 MoE 架构和 IQ 量化。我们从官方仓库编译。

克隆并编译（CUDA + mmap）
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DGGML_CUDA_FA_ALL_QUANTS=ON
cmake --build build --config Release -j

在搭载 Apple Silicon 芯片的 Mac 上，将 GGML_CUDA 替换为 GGML_METAL。在使用 ROCm 的 AMD 平台上，则替换为 GGML_HIP。GGML_CUDA_FA_ALL_QUANTS 标志可为所有量化类型启用 Flash Attention——要容纳 128k 上下文且不超出显存容量，这是必不可少的。

i
预编译二进制文件
如果您希望避免编译，GitHub 发布版本提供适用于 Linux、Windows 和 macOS 的二进制文件。请根据所使用的 GGUF 重打包版本，确认该软件版本确实支持 deepseek2 或 kimi 架构。

#2. 选择 GGUF 量化方式

对于这种规模的模型，除非拥有 512 GB RAM，否则就别考虑 Q4_K_M 及更高精度的量化。极端量化——Q2_K_S、IQ2_XXS，甚至 IQ1_M——让本地运行成为可行方案，代价是可测量的质量损失，但对 MoE 模型而言通常可以接受。

Q2_K_S（~245 GB）
最佳平衡点。代码基准测试性能下降约 5%，推理性能下降约 3%。如果您有 256 GB 内存或快速 SSD，推荐使用。
IQ2_XXS (~210 GB)
通过重要性矩阵更加激进，可在192 GB RAM上运行，带少量卸载，质量略低一个等级。
IQ1_M（~155 GB）
混合 1 位量化。适用于资源极度受限的配置。质量下降明显，但模型的输出仍然连贯。
Q3_K_S（约320 GB）
接近Q4质量但需要384 GB RAM。适用于配置良好的EPYC工作站。
从Hugging Face下载Q2_K_S格式的GGUF模型
pip install -U "huggingface_hub[cli]"
huggingface-cli download \
  unsloth/Kimi-K2-Instruct-GGUF \
  --include "*Q2_K_S*" \
  --local-dir ./models/kimi-k2-q2ks

此类GGUF文件会被分割成多个文件（如split-00001-of-00007.gguf等）。如果指向第一个文件，llama.cpp会自动检测到这些分割文件。

!
哈希值与来源
从可信的仓库下载 GGUF 文件（unsloth、bartowski、mradermacher 最受关注）。核对提供的 SHA 校验和。量化不当或损坏的 GGUF 文件可能在第一次提示时生成连贯的文本，随后却出现异常——这类问题很难诊断。

#3. 使用 mmap 和 offload 启动 Kimi K2

基础命令使用 llama-server，即 llama.cpp 提供的 HTTP 服务器。它默认在 8080 端口暴露一个兼容 OpenAI 的接口。

使用CPU运行，通过mmap将部分模型权重卸载到SSD
./build/bin/llama-server \
  --model ./models/kimi-k2-q2ks/kimi-k2-Q2_K_S-00001-of-00007.gguf \
  --ctx-size 32768 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --threads 16 \
  --no-mmap=false \
  --host 0.0.0.0 --port 8080

使用配备 24 GB 显存的 GPU 时，将共享层（注意力层）的计算交给 GPU，并将 MoE 专家保留在 RAM 或 SSD 中。-ot 参数可以精确指定哪些部分放到 GPU 上，哪些放到 CPU 上。

CPU + 24 GB GPU 混合运行
./build/bin/llama-server \
  --model ./models/kimi-k2-q2ks/kimi-k2-Q2_K_S-00001-of-00007.gguf \
  --ctx-size 65536 \
  --cache-type-k q8_0 \
  --cache-type-v q8_0 \
  --n-gpu-layers 999 \
  -ot "\.ffn_.*_exps\.=CPU" \
  --threads 12 \
  --host 0.0.0.0 --port 8080

传给 -ot 的正则表达式表示：“所有专家的 FFN（前馈网络）层（MoE 模型的主体部分）都保留在 CPU/RAM 上，其余部分放到 GPU 上。”正是这一技巧让混合运行成为可行方案：利用 GPU 进行注意力计算，而不必将整个模型都加载到 GPU 上。

→
mmap 默认启用
llama.cpp 会自动使用mmap。如果物理内存不足，内核将从磁盘上的GGUF文件进行分页——因此请将GGUF文件存放在速度最快的NVMe固态硬盘上，绝不要存放在HDD上。除非有特定原因，否则请避免使用--no-mmap。

#4. 实测生成速度（token/秒）

以下是实际使用中观察到的一些吞吐量参考值。数值会随提示词（预填充阶段较慢，生成阶段更稳定）以及操作系统页缓存的状态而变化。

EPYC 9354P，384 GB DDR5，Q2_K_S，全部加载到系统内存中
预填充速度约 80 个 token/秒，生成速度约 6-8 个 token/秒。适用于批量推理的基准配置。
Threadripper 7960X，256 GB DDR5，Q2_K_S
预填充速度约 50 个 token/秒，生成速度约 4-6 个 token/秒。内存延迟（DDR5）是主要瓶颈。
Ryzen 9 7950X，128 GB DDR5 + NVMe Gen 4 SSD
预填充约 15 tok/s，生成约 1.5–3 tok/s。一旦超出可驻留在 RAM 中的范围，SSD 就会成为瓶颈。
Mac Studio M2 Ultra 192 GB
以IQ2_XXS量化时，生成速度约为每秒4到7个token。统一内存带宽（800 GB/s）对MoE模型有显著帮助。
工作站 256 GB + RTX 4090（混合型）
预填充约 60 tok/s，生成约 7-10 tok/s。GPU 处理注意力机制会将预填充时间减半。
i
Prefill 与生成
对于这种规模的 MoE 模型，预填充（读取提示词）受益于批处理并行，性能仍然不错。逐 token 生成则较慢，因为每生成一个新 token，都需要重新读取路由选中的专家。这是架构本身的特性，并非 llama.cpp 的缺陷。

#5. 128k 上下文使用场景

与 7B 至 70B 的本地模型相比，Kimi K2 的一大优势是拥有 128k token 的上下文窗口。具体来说，您可以向它输入一份完整的年度报告、一个中等规模的代码库，或约一百页 PDF，并让它在掌握全部内容的基础上生成综合摘要，而不是采用分块 RAG。

长文档摘要
一份 300 页的报告不到 12 万 tokens。Kimi K2 一次处理就能生成结构化摘要，而 RAG 则会将片段拼接起来。
代码库重构
加载 50 个 Python 文件（约 8 万个 token），要求进行一套前后一致的架构审查。对于涉及代码库多个部分的技术债务，这非常有用。
日志关联分析
粘贴 50 MB 的日志（已过滤），并要求生成事件时间线。模型能看到所有关联，而不只是滑动窗口内的关联。
长篇文档翻译
在整个书籍文本中保持术语一致性，而分块翻译会丢失上下文关联。
→
量化 KV 缓存以支持 128k 上下文
使用 --cache-type-k q8_0 --cache-type-v q8_0，128k 的 KV 缓存从约 60 GB 降至约 30 GB。实际使用中质量损失不可察觉，同时为避免内存饱和提供了必要的缓冲空间。

#故障排除

「failed to load model」或魔数错误
你的 llama.cpp 版本对于此 GGUF 文件来说太旧了。请更新到 2025 年 12 月之后的构建版本，并检查 GGUF 重新打包者声明的架构版本。
内存容量本应足够，生成速度却只有 0.2 token/秒
在尚未访问完所有内存页之前，内核会持续从 GGUF 文件按页载入数据。先用一条简短提示词进行一次“预热运行”，可预加载常用的内存页。否则，请增大 --threads 参数，以便更早达到带宽饱和。
使用长提示词时突然出现 OOM
KV 缓存急剧膨胀。请将 --ctx-size 降至 32768，或启用缓存的 Q8 量化。KV 缓存随上下文长度线性增长，而不是随模型大小线性增长。
输出内容不连贯或语言表达混乱
通常是聊天模板不正确导致的。请检查 --chat-template，或确认 GGUF 中确实包含 Moonshot 官方模板（jinja）。错误的结束 token 会导致输出反复失控。
SSD 温度高达 80°C，吞吐量骤降
高端 NVMe 固态硬盘在没有散热器时会因过热而降速。长时间运行时，请加装散热器，或切换到体积更小、能装入 RAM 的量化版本，以降低负载。

#深入了解

在本地运行 Kimi K2，为探索超大模型提供了一个实验场。以下是进一步探索的三个方向：

掌握llama.cpp的编译方法
《使用 CUDA 编译 llama.cpp》指南详细介绍了一些不太容易注意到的参数（张量卸载、MMQ、Flash Attention），这些参数会影响此类模型的性能。
理解量化技术
《选择量化方式》指南介绍了深入研究 IQ2_XXS 或 Q3_K_S 之前需要掌握的概念基础，并说明究竟哪些方面会受到影响而退化。
进一步提高压缩程度
TurboQuant 指南详细介绍了一种比 K-quants 更新的方法，可让前沿模型装入消费级硬件的内存，但需要作出不同的取舍。
这份指南对您有帮助吗？

有反馈、发现了错误，或想补充说明？请告诉我们，让这份指南对每个人都更有帮助。