如何在本地运行 Kimi K2.5

像 Kimi K2.5 这种万亿参数规模的模型，通常需要庞大的多 GPU 集群和相匹配的基础设施预算，费用常常超过 $40/小时。不过，使用合适的优化工具，您就能以更低的成本运行这款最前沿的模型。

在本教程中，我将演示如何在 RunPod 上使用单块 NVIDIA H200 GPU 在本地运行 Kimi K2.5。通过借助 llama.cpp 实现高效推理，并将其连接到 Kimi CLI，您可以绕过复杂的企业级基础设施，立即开始构建高层次的软件。

什么是 Kimi K2.5？

Kimi K2.5 是一款开源的最前沿大语言模型，专为高级推理、编程与高质量文本生成而设计。它由 Moonshot AI 开发，参数规模达万亿级，面向高级推理、高质量代码生成，以及通用写作等任务。

在实际使用中，它在许多工作流上的体验可与 Claude Opus 4.5 比肩，尤其是在编程、结构化推理和长文生成方面。

Kimi K2.5 的一大优势在于它完全开源。这意味着任何人都可以下载权重并自行运行模型，而无需依赖付费 API 或封闭平台。当然，代价在于规模带来的资源需求。

Kimi K2.5 系统要求与 GPU 硬件先决条件

本节将说明在本地运行 Kimi K2.5 所需的硬件、内存与 GPU 先决条件，包括单块 H200 GPU 的预期性能。

磁盘空间

运行 1-bit 量化至少需要 300GB
建议预留额外空间用于缓存和日志

内存（RAM + VRAM）

经验法则： RAM + VRAM ≈ 量化后模型大小
建议统一内存 240GB+，以达到每秒 7+ token
低于该水平时，模型仍可通过磁盘卸载运行，但性能可能降至每秒 2 token 以下

GPU 要求

1.8-bit（UD-TQ1_0）可在单块 NVIDIA H200 GPU 上运行。
在 144GB VRAM 和约 188GB 系统内存下，预期每秒约 7 token
完整模型（约 630GB）通常需要 4× NVIDIA H200 GPU

GPU 驱动与 CUDA

安装了最新驱动的 NVIDIA GPU
推荐使用 CUDA Toolkit 12.x
在继续前请确保 nvidia-smi 可正常运行

在 RunPod 上为 Kimi K2.5 设置 GPU 环境

现在我们将在 RunPod 上创建一个 GPU pod，并为运行 Kimi K2.5 做好准备。

首先在 RunPod 中创建一个新 pod，并选择NVIDIA H200 GPU。容器镜像请选择最新的 PyTorch 模板，其中已包含我们所需的大部分 CUDA 与深度学习依赖。选择模板后，点击Edit 以调整默认 pod 设置。

按如下方式更新存储配置：

将持久卷磁盘设置为500GB
将容器磁盘大小设置为50GB

接下来，暴露一个额外端口：

在Expose HTTP Ports 下添加8080 端口

我们暴露 8080 端口，这样在服务器启动后，无论本地还是远程，都可以直接通过浏览器访问 llama.cpp 服务器与 Web UI。

保存这些设置后，部署该 pod。即便只使用单块 GPU，运行 Kimi K2.5 这样的模型也并不便宜，但与传统云服务商相比，RunPod 的成本更具优势。

当 pod 准备就绪后，启动 Jupyter Lab 界面。在 Jupyter Lab 中打开一个终端会话。

在 Jupyter 中使用终端非常方便，因为您可以即时打开多个终端会话，而无需管理多个独立的 SSH 连接。

首先，运行以下命令以确认 GPU 驱动与 CUDA 是否正确安装：

nvidia-smi技术支持

若一切正常，您应能看到 H200 GPU，且大约有144GB 可用显存（VRAM）。

接下来，安装从源码构建 llama.cpp 所需的 Linux 软件包：

sudo apt-get update
sudo apt-get install -y build-essential cmake curl git libcurl4-openssl-dev技术支持

为 Kimi K2.5 安装支持 CUDA 的 llama.cpp

我们将从源码构建 llama.cpp，因为它快速、轻量，并且能在 H200 GPU 上获得最佳性能。

llama.cpp 是一个开源的 C/C++ 推理引擎，用于运行大语言模型。它内置名为 llama-server 的 HTTP 服务器，提供 REST 端点与 Web UI，便于您直接在浏览器中与模型交互。

它还支持自定义 CUDA 内核以及 CPU+GPU 混合推理，有助于在模型无法完全装入显存时提升表现。

首先，克隆官方的 llama.cpp 仓库：

git clone https://github.com/ggml-org/llama.cpp技术支持

接着，启用 CUDA 支持进行构建配置。我们显式指定 CUDA 架构 90，这是 NVIDIA H200 GPU 所需：

cmake /workspace/llama.cpp -B /workspace/llama.cpp/build \
  -DGGML_CUDA=ON \
  -DBUILD_SHARED_LIBS=OFF \
  -DCMAKE_CUDA_ARCHITECTURES=90技术支持

现在编译 llama-server 可执行文件。稍后我们将用它来运行 Kimi K2.5，并暴露一个 HTTP 端点与 Web UI：

cmake --build /workspace/llama.cpp/build -j --clean-first --target llama-server技术支持

构建完成后，将二进制文件复制到便于访问的位置：

cp /workspace/llama.cpp/build/bin/llama-server /workspace/llama.cpp/llama-server技术支持

最后，验证二进制文件是否存在且构建成功：

ls -la /workspace/llama.cpp | sed -n '1,60p'技术支持

使用 Xet 从 Hugging Face 下载 Kimi K2.5 GGUF 模型

我们将使用Kimi K2.5 GGUF 模型，并借助Xet 从 Hugging Face 下载，以显著加速大型模型文件的传输。

首先，安装 Hugging Face 与 Xet 的传输工具：

pip install -U "huggingface_hub[hf_xet]" hf-xet hf_transfer技术支持

启用高速传输后端：

export HF_HUB_ENABLE_HF_TRANSFER=1技术支持

接下来，从 Hugging Face 下载 1.8-bit 量化模型（UD-TQ1_0），并保存在本地。

我们选择该量化版本，是因为它在模型质量与硬件可行性之间取得了最佳平衡，使 Kimi K2.5 能在单块 H200 GPU 上运行，同时将部分权重卸载到系统内存，并维持可用的推理速度。

hf download unsloth/Kimi-K2.5-GGUF \
  --local-dir /workspace/models/Kimi-K2.5-GGUF \
  --include "UD-TQ1_0/*"技术支持

即使未使用 Hugging Face 访问令牌登录，在 RunPod 上的下载速度也应达到800 MB/秒或更高。

在我们的测试中，整个下载耗时约 6 分钟。实际耗时可能因网络带宽与磁盘性能而异。

使用 llama.cpp 服务器在本地运行 Kimi K2.5

现在模型已下载完毕，且 llama.cpp 已启用 CUDA 支持，我们可以使用 llama.cpp 的 HTTP 服务器在本地启动 Kimi K2.5。

运行以下命令启动 llama-server：

/workspace/llama.cpp/llama-server \
  --model "/workspace/models/Kimi-K2.5-GGUF/UD-TQ1_0/Kimi-K2.5-UD-TQ1_0-00001-of-00005.gguf" \
  --alias "Kimi-K2.5" \
  --host 0.0.0.0 \
  --port 8080 \
  --threads 32 \
  --threads-batch 32 \
  --ctx-size 20000\
  --temp 0.8 \
  --top-p 0.95 \
  --min_p 0.01 \
  --fit on \
--prio 3 \
  --jinja \
  --flash-attn auto \
  --batch-size 1024\
  --ubatch-size 256技术支持

各参数说明：

--model：要加载的 GGUF 模型文件路径
--alias：在服务器与 UI 中用于标识模型的友好名称
--host：服务器绑定的网络接口（0.0.0.0 允许外部访问）
--port：用于暴露 llama.cpp 服务器与 Web UI 的 HTTP 端口
--threads：用于推理与预处理的 CPU 线程数
--threads-batch：用于批处理提示的 CPU 线程数
--ctx-size：最大上下文窗口的 token 数
--temp：控制生成输出的随机性
--top-p：核采样阈值
--min_p：过滤掉极低概率的 token
--fit：在 VRAM 与系统内存之间自动平衡模型权重
--prio：为推理工作负载设置更高的进程优先级
--jinja：启用基于 Jinja 的提示模板
--flash-attn：在 GPU 支持时启用Flash Attention 功能
--batch-size：每个 GPU 批次处理的 token 数
--ubatch-size：微批大小，用于平衡内存占用与吞吐

启动时，您会看到模型大约向 GPU 内存加载 136GB，剩余权重卸载至系统内存。

注意：如果 llama.cpp 服务器未检测到 GPU 而在 CPU 上启动，请重启 pod。若问题仍旧存在，请删除现有构建，并在启用 CUDA 支持的情况下重新构建 llama.cpp。

加载完成后，服务器会打印访问 URL。请在浏览器中打开该 Web UI：

注意：如果运行 nvidia-smi 时出现错误，多半是进程因内存压力而崩溃。请重启 pod。所有模型文件都保存在持久磁盘上。

通过 Web UI 访问本地 Kimi K2.5 的 API 端点

llama.cpp 服务器运行后，您可以通过暴露在 8080 端口上的 Web UI 进行访问。

打开方式：前往RunPod 仪表盘，选择正在运行的 pod，点击8080 端口旁边显示的链接。这样即可在浏览器中直接打开 llama.cpp Web UI。

该 Web UI 提供了简洁的聊天式界面，类似 ChatGPT，但完全运行在您的 RunPod 实例上。该 URL 是公开可访问的，必要时您可以将链接分享给团队或协作者。

先给 Kimi K2.5 模型发送一个简单提示，确认一切正常。在我们的测试中，模型响应速度约为每秒 6 到 7 个 token，这与在单块 H200 GPU 上以部分 RAM 卸载运行 1.8-bit 量化的预期一致。该基线表现稳健，也表明模型正确使用了 GPU。

注意：llama.cpp Web UI 不会清晰地区分推理过程与最终输出，因此可能因模板问题将两者混在一起显示。

安装并设置 Kimi CLI 以在本地进行 Kimi K2.5 推理

Kimi CLI 是 Moonshot AI 开发的终端式编程与推理代理。它旨在协助完成编码任务、Shell 工作流与项目级变更，且可直接在您的工作目录中运行。不同于简单的聊天界面，Kimi CLI 能在实际开发工作流中发挥作用。

对于本地推理，Kimi CLI 的关键优势在于支持与 OpenAI 兼容的 API。这使我们能够将其直接指向本地运行的 llama-server，从而在完全不依赖任何托管或付费 API 服务的情况下，在自有硬件上运行 Kimi K2.5。

先运行官方安装脚本：

curl -LsSf https://code.kimi.com/install.sh | bash技术支持

接着，将二进制路径加入 PATH，确保可以在终端中使用kimi 命令：

export PATH="/root/.local/bin:$PATH"技术支持

确认安装成功：

kimi --version技术支持

您应看到类似 kimi, version 1.5 的输出。

创建 Kimi CLI 使用的配置目录：

mkdir -p ~/.kimi技术支持

现在，创建配置文件。这会让 Kimi CLI 将您的本地 llama.cpp 服务器视为运行在 http://127.0.0.1:8080/v1 的 OpenAI 兼容提供方。同时注册一个与您启动 llama-server 时设置的别名相匹配的本地模型条目。

cat << 'EOF' > ~/.kimi/config.toml
[providers.local_llama]
type = "openai_legacy"
base_url = "http://127.0.0.1:8080/v1"
api_key = "sk-no-key-required"

[models.kimi_k25_local]
provider = "local_llama"
model = "Kimi-K2.5"
max_context_size = 20000
EOF技术支持

确保 model 的取值与启动 llama-server 时的 --alias 完全一致。api_key 字段只是占位符，本地推理无需该字段。

使用 Kimi K2.5 与 Kimi CLI 构建交互式贪吃蛇游戏

本节我们将把 Kimi CLI 连接到本地 Kimi K2.5 服务器，通过 vibe coding 一次性生成一个可完整游玩的贪吃蛇游戏。

首先，创建一个新的项目目录并进入：

mkdir -p /workspace/snake-game
cd /workspace/snake-game技术支持

然后，启动 Kimi CLI：

kimi技术支持

Kimi CLI 启动后，输入 /model 并选择我们之前配置的本地 Kimi K2.5 模型。您应能看到Kimi-K2.5 被列为可用模型。

现在，提示 Kimi 生成游戏。使用如下简洁直接的指令：

"Create a simple Snake game as a single self-contained file named index.html."技术支持

Kimi 会先给出计划并请求您的批准。请阅读并同意。

批准后，Kimi 将生成完整的 index.html 文件，包含HTML、CSS 与 JavaScript，一应俱全。

生成完成后，将文件下载或复制到本地，在浏览器中打开。游戏会立即启动。

按下空格键开始游戏
使用方向键控制蛇的移动

最终结果是一个功能完整的贪吃蛇游戏，动作流畅、视觉清爽，具备经典玩法特性。

游戏会记录您的最高分，撞墙即结束，再按空格键即可重新开始。

就单次提示而言，这个结果相当精致，很好地展示了在 Kimi CLI 与本地推理环境配合下，Kimi K2.5 的生成能力。

结语

坦率讲，要在一次性提示中构建一个完整可用的游戏，比预期更让人挫折。

虽然 Kimi K2.5 的能力毋庸置疑，但该模型在决定何时停止对任务迭代方面常有困难。实际使用中，它往往会“过度工作”。

例如，要求使用 Pygame 构建贪吃蛇时，它可能会切回 HTML 实现；而要求 HTML 时，它又可能转而使用 Python 实现。

这种来回切换意味着您往往需要多次干预，才能让模型与您的意图保持一致。

这种行为很大程度上源自于1.8-bit 量化。尽管 1-bit 和亚 2-bit 模式让超大模型能在受限硬件上运行，但也带来了权衡。

模型仍能生成连贯的回答，但在任务终止、长程推理、结构化规划与函数调用方面会更吃力。而这些恰恰是代理式工作流与多步编码任务最看重的能力。

更现实地说，Kimi K2.5 在更高精度（如 4-bit 或更高）时才会真正发光。在该水平上，规划能力明显改善，模型行为也更可预期。

但缺点也显而易见：更高精度需要显著更多的 RAM 与 VRAM，这使其超出了很多本地环境的承受范围。从低精度下的体积与性能比来看，GLM 4.7 等模型当前对许多用户提供了更顺滑的体验。

话虽如此，如果不受硬件限制、以更高精度运行 Kimi K2.5，或通过托管 API 使用它，这个模型确实令人印象深刻。其推理深度、代码生成质量与长上下文处理能力足以在许多工作流中替代专有模型。

事实上，通过Kimi AI API 使用时，它的表现足以支撑将整套 vibe-coding 工作流切换到它上面。

若您想继续深入学习本文涉及的概念，推荐以下资源：

作者

Abid Ali Awan

LinkedIn Twitter

作为一名持证的数据科学家，我热衷于利用前沿技术打造创新的机器学习应用。凭借在语音识别、数据分析与报告、MLOps、对话式人工智能以及自然语言处理方面的扎实背景，我不断打磨构建智能系统的能力，力求带来切实影响。除技术专长外，我也擅长沟通，能够将复杂概念提炼为清晰、简明的表述。因此，我成为数据科学领域备受关注的博主，与不断壮大的数据专业人士社区分享洞见与实践经验。目前，我专注于内容创作与编辑，借助大语言模型打造有力且吸引人的内容，帮助企业与个人更好地发挥数据价值。

主题

大语言模型人工智能

主题

技术