Kimi-K2-Thinking¶

1.简介¶

Kimi-K2-Thinking 是 Moonshot AI 开发的大规模混合专家（MoE）模型。它采用混合思考架构，在复杂推理和问题求解任务中表现出色。

本文档将展示模型的主要验证步骤，包括支持的特性、环境准备、安装、在线服务部署、功能验证、精度评估、性能评估、性能调优及常见问题解答。

建议使用最新的候选发布版本或正式版本。

2.支持的特性¶

请参阅支持的特性矩阵获取模型支持的特性列表。

请参阅特性指南获取特性的配置方法。

3.前提条件¶

3.1 模型权重¶

Kimi-K2-Thinking（bfloat16）：需要 1 个 Atlas 800 A3（64G × 16）节点。下载模型权重。

建议将模型权重下载到共享目录，例如 /mnt/sfs_turbo/.cache/。

下载模型权重后，请在原始模型的 "quantization_config.config_groups.group_0.targets" 中将 ["Linear"] 的值从 ["MoE"] 修改为 config.json 以验证量化模型。

{
  "quantization_config": {
    "config_groups": {
      "group_0": {
        "targets": [
          "MoE"
        ]
      }
    }
  }
}

您的模型文件结构如下所示：

.
|-- chat_template.jinja
|-- config.json
|-- configuration_deepseek.py
|-- configuration.json
|-- generation_config.json
|-- model-00001-of-000062.safetensors
|-- ...
|-- model-00062-of-000062.safetensors
|-- model.safetensors.index.json
|-- modeling_deepseek.py
|-- tiktoken.model
|-- tokenization_kimi.py
|-- tokenizer_config.json

4.安装¶

4.1 Docker 镜像安装¶

您可以使用官方 Docker 镜像直接运行 Kimi-K2-Thinking。

根据您的机器类型选择镜像，并在节点上启动 Docker 镜像，请参考使用 Docker 安装。

   # Update the vllm-ascend image according to your environment.
   export IMAGE=quay.io/ascend/vllm-ascend:v0.22.1rc1-a3

# Run the container using the defined variables
# Note: If you are running bridge network with docker, please expose available ports for multiple nodes communication in advance
docker run --rm \
--name $NAME \
--net=host \
--shm-size=1g \
--device /dev/davinci0 \
--device /dev/davinci1 \
--device /dev/davinci2 \
--device /dev/davinci3 \
--device /dev/davinci4 \
--device /dev/davinci5 \
--device /dev/davinci6 \
--device /dev/davinci7 \
--device /dev/davinci8 \
--device /dev/davinci9 \
--device /dev/davinci10 \
--device /dev/davinci11 \
--device /dev/davinci12 \
--device /dev/davinci13 \
--device /dev/davinci14 \
--device /dev/davinci15 \
--device /dev/davinci_manager \
--device /dev/devmm_svm \
--device /dev/hisi_hdc \
-v /usr/local/dcmi:/usr/local/dcmi \
-v /usr/local/Ascend/driver/tools/hccn_tool:/usr/local/Ascend/driver/tools/hccn_tool \
-v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi \
-v /usr/local/Ascend/driver/lib64/:/usr/local/Ascend/driver/lib64/ \
-v /usr/local/Ascend/driver/version.info:/usr/local/Ascend/driver/version.info \
-v /etc/ascend_install.info:/etc/ascend_install.info \
-v /mnt/sfs_turbo/.cache:/home/cache \
-it $IMAGE bash

参数说明：

IMAGE：指定 vllm-ascend 镜像。-a3 后缀选择 Atlas A3 镜像。
NAME：指定容器名称。
--net=host：使用主机网络，vLLM 服务端口直接暴露在主机上。
--shm-size=1g：配置容器共享内存。
--device /dev/davinci[0-15]：向容器暴露 16 个 Ascend NPU 设备。
--device /dev/davinci_manager、--device /dev/devmm_svm 和 --device /dev/hisi_hdc：暴露所需的 Ascend 运行时设备文件。
-v /usr/local/dcmi:/usr/local/dcmi：挂载 DCMI 工具用于设备管理。
-v /usr/local/bin/npu-smi:/usr/local/bin/npu-smi：挂载 NPU 监控命令。
-v /usr/local/Ascend/driver/*：挂载 Ascend 驱动库和版本文件。
-v /etc/ascend_install.info:/etc/ascend_install.info：挂载 Ascend 安装元数据。
-v /mnt/sfs_turbo/.cache:/home/cache：挂载共享模型缓存目录。如果模型权重存储在其他位置，请更新此路径。

容器启动后，在主机上运行以下命令验证容器状态：

docker ps --filter name=vllm-ascend --format "table {{.Names}}\t{{.Status}}"

预期状态：

容器名称为 vllm-ascend。
状态为 Up ...。
容器不会立即退出。

在容器中运行以下命令验证 Ascend 设备是否可见：

npu-smi info

预期状态：

命令成功退出。
输出列出预期的 NPU 设备。
设备健康状态正常。

4.2 源码安装¶

如果不想使用 Docker 镜像，也可以从源码构建：

# Install vLLM.
git clone --depth 1 --branch v0.22.1 https://github.com/vllm-project/vllm
cd vllm
VLLM_TARGET_DEVICE=empty pip install -e .
cd ..

# Install vLLM Ascend.
git clone --depth 1 --branch v0.22.1rc1 https://github.com/vllm-project/vllm-ascend.git
cd vllm-ascend
pip install -e .

验证源码安装，请运行：

python -c "import vllm; import vllm_ascend; print('vllm and vllm_ascend import ok')"

预期状态：

命令成功退出。
打印 vllm and vllm_ascend import ok。

如果要部署多节点环境，请在每个节点上设置相同的软件环境。

5.在线服务部署¶

5.1 单节点在线部署¶

单节点部署在同一节点内完成 Prefill 和 Decode，适用于中等并发需求的在线推理场景。

对于 Atlas 800 A3（64G*16）节点，tensor-parallel-size 至少应为 16。

运行以下脚本启动 vLLM 服务器：

export HCCL_BUFFSIZE=1024
export TASK_QUEUE_ENABLE=1
export OMP_PROC_BIND=false
export HCCL_OP_EXPANSION_MODE=AIV
export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True
export SERVER_PORT=8000

vllm serve moonshotai/Kimi-K2-Thinking \
  --tensor-parallel-size 16 \
  --port $SERVER_PORT \
  --max-model-len 8192 \
  --max-num-batched-tokens 8192 \
  --max-num-seqs 12 \
  --gpu-memory-utilization 0.9 \
  --trust-remote-code \
  --enable-expert-parallel \
  --no-enable-prefix-caching

参数和环境变量说明：

HCCL_BUFFSIZE=1024：配置 HCCL 缓冲区大小。
TASK_QUEUE_ENABLE=1：启用任务队列调度。
OMP_PROC_BIND=false：避免过于严格的 OpenMP CPU 绑定。
HCCL_OP_EXPANSION_MODE=AIV：启用 AIV 通信路径。
PYTORCH_NPU_ALLOC_CONF=expandable_segments:True：减少 NPU 内存碎片。
SERVER_PORT：设置服务端口。生成的脚本将 DEFAULT_PORT 映射到 8000。
--tensor-parallel-size 16：在 A3 节点上使用 16 路张量并行。
--max-model-len 8192：设置最大模型上下文长度。
--max-num-batched-tokens 8192：设置最大批处理 token 数量。
--max-num-seqs 12：设置最大并发序列数。
--gpu-memory-utilization 0.9：控制 vLLM 使用的内存比例。
--trust-remote-code：允许加载模型特定的远程代码。
--enable-expert-parallel：为MoE层启用专家并行。
--no-enable-prefix-caching：禁用前缀缓存以获得稳定基线。

服务验证：

服务启动后，您应看到类似如下的日志：

INFO:     Started server process [...]
INFO:     Waiting for application startup.
INFO:     Application startup complete.

预期状态：

服务器进程启动成功。
无与HCCL或NPU初始化相关的错误日志。
容器不会立即退出。

6 功能验证¶

服务启动后，可通过发送提示词来调用模型：

curl http://localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{
  "model": "moonshotai/Kimi-K2-Thinking",
  "messages": [
    {"role": "user", "content": "Who are you?"}
  ],
  "temperature": 1.0
}'

预期结果：

HTTP状态码为200。
choices[0].message.content包含生成的助手回复。

7 精度评估¶

使用AISBench¶

详细信息请参考使用AISBench。

使用lm-eval¶

您可以使用lm-eval通过OpenAI兼容API评估模型精度。

关于lm_eval的安装，请参考使用lm_eval。

运行lm_eval执行精度评估：

lm_eval \
  --model local-completions \
  --model_args model=moonshotai/Kimi-K2-Thinking,base_url=http://127.0.0.1:8000/v1/completions,tokenized_requests=False,trust_remote_code=True \
  --tasks gsm8k \
  --output_path ./

参考配置：gsm8k（5-shot）、--apply_chat_template、--fewshot_as_multiturn、贪心解码（temperature=0.0、top_p=1.0）、最大输出token数2048、批大小1。

以下为基于gsm8k的Kimi-K2-Thinking在单个Atlas 800 A3节点（64G × 16）上评估的参考vllm-ascend:v0.20.2rc1结果。

任务	版本	过滤器	n-shot	指标	值	标准误差
`gsm8k`	3	`flexible-extract`	5	`exact_match`	0.8992	0.0083
`gsm8k`	3	`strict-match`	5	`exact_match`	0.8453	0.0100

8 性能评估¶

更多详情请参考vllm基准测试。

测试命令示例：

vllm bench serve \
  --backend openai-chat \
  --model moonshotai/Kimi-K2-Thinking \
  --endpoint /v1/chat/completions \
  --dataset-name random \
  --random-input-len 1024 \
  --random-output-len 1024 \
  --num-prompts 10 \
  --request-rate 1

基准测试完成后，您将获得性能结果，包括请求吞吐量、输出token吞吐量、TTFT、TPOT和ITL。

以下参考结果基于vllm-ascend:v0.20.2rc1在单个Atlas 800 A3节点（64G × 16）上获得，使用OpenAI聊天服务、随机输入/输出长度、10个提示词和--request-rate 1：

随机输入长度	随机输出长度	成功	持续时间（秒）	请求吞吐量（请求/秒）	输出吞吐量（token/秒）	总吞吐量（token/秒）	平均TTFT（毫秒）	平均TPOT（毫秒）	平均ITL（毫秒）
512	512	10 / 10	111.00	0.09	46.12	94.38	507.60	200.47	200.08
1024	1024	10 / 10	221.52	0.05	46.23	93.48	566.39	208.20	208.00
2048	2048	10 / 10	479.72	0.02	42.69	85.78	722.32	230.26	230.15

对于并发扫描，保持输入和输出长度固定，并改变--max-concurrency：

MODEL_NAME=moonshotai/Kimi-K2-Thinking
INPUT_LEN=1024
OUTPUT_LEN=1024

for CONCURRENCY in 1 2 4 8 16 32; do
  NUM_PROMPTS=$((CONCURRENCY * 10))
  vllm bench serve \
    --backend openai-chat \
    --model "$MODEL_NAME" \
    --endpoint /v1/chat/completions \
    --dataset-name random \
    --random-input-len "$INPUT_LEN" \
    --random-output-len "$OUTPUT_LEN" \
    --num-prompts "$NUM_PROMPTS" \
    --request-rate inf \
    --max-concurrency "$CONCURRENCY"
done

1024个输入token和1024个输出token的参考结果如下：

最大并发数	提示词	成功	持续时间（秒）	请求吞吐量（请求/秒）	输出吞吐量（token/秒）	总吞吐量（token/秒）	平均TTFT（毫秒）	P99 TTFT（毫秒）	平均TPOT（毫秒）
1	10	10 / 10	595.07	0.02	17.21	34.80	473.71	712.49	57.71
2	20	20 / 20	623.88	0.03	32.83	66.35	708.16	996.59	60.29
4	40	40 / 40	725.38	0.06	56.47	114.13	956.11	1137.55	69.97
8	80	80 / 80	907.44	0.09	90.28	182.43	1361.85	1900.15	87.37
16	160	160 / 160	3093.07	0.05	52.97	107.04	76766.84	251245.22	222.07

注意： 在并发级别为16时，平均TTFT显著增加（76.7秒），表明存在严重的排队延迟。对于生产部署，建议根据延迟需求限制并发，或在NPU内存允许的情况下增加--max-num-seqs和--max-num-batched-tokens。

9 性能调优¶

9.1 推荐配置¶

注意： 以下配置在特定测试环境中验证，仅供参考。最佳配置取决于最大输入/输出长度、前缀缓存命中率、精度要求和部署机器比例等因素。建议参考第9.2节根据实际情况进行调优。

表1：场景概览¶

场景	部署模式	NPU总数	权重版本	关键考量
长上下文	单节点	16 (A3)	bfloat16	保持`--max-model-len`接近实际最大输入和输出长度；内存压力高时优先减少`--max-num-seqs`。
低延迟	单节点	16 (A3)	bfloat16	减少`--max-num-seqs`和`--max-num-batched-tokens`以降低排队延迟。
高吞吐	单节点	16 (A3)	bfloat16	逐步增加`--max-num-seqs`，并使用接近实际工作负载的请求速率进行基准测试。

表2：详细建议¶

长上下文： 使用tp16，保持--max-model-len接近实际最大输入和输出长度，内存压力高时优先减少--max-num-seqs。
低延迟： 减少--max-num-seqs和--max-num-batched-tokens以降低排队延迟。
高吞吐： 逐步增加--max-num-seqs，并使用接近实际工作负载的请求速率进行基准测试。对于长上下文吞吐测试，评估--decode-context-parallel-size作为可选调优参数。
对于参考并发扫描中的1024输入token和1024输出token，--max-concurrency 8具有最佳输出吞吐。更高的并发会显著增加TTFT，因此在生产环境中使用前请验证尾延迟。

注意：

--max-model-len和--max-num-seqs需要根据实际使用场景设置。

如果服务在高并发下运行，在增加请求速率前请验证NPU健康和HCCL状态。

9.2 调优指南¶

9.2.1 通用调优参考¶

通用调优方法请参考公共性能调优文档。

详细特性描述请参考特性指南。

10 常见问题¶

For common environment, installation, and general parameter issues, please refer to the Public FAQ; this chapter only covers model-specific issues.

问：使用{"error":"Model not found"}请求时，API返回404或model: "Kimi-K2-Thinking"？

答：服务器默认使用完整路径moonshotai/Kimi-K2-Thinking注册模型。当请求使用短名称Kimi-K2-Thinking且未覆盖--served-model-name时，服务器无法解析模型ID。请在请求中使用"model": "moonshotai/Kimi-K2-Thinking"，或使用--served-model-name Kimi-K2-Thinking启动服务器以启用短名称。