尧图网站建设 
Kimi-K2.5 部署实战指南基于 vLLM / SGLang / KTransformers 的推理与 LoRA 微调完整部署方案【免费下载链接】Kimi-K2.5Kimi K2.5 是一款开源的原生多模态智能体模型它在 Kimi-K2-Base 的基础上通过对约 15 万亿混合视觉和文本 tokens 进行持续预训练构建而成。该模型将视觉与语言理解、高级智能体能力、即时模式与思考模式以及对话式与智能体范式无缝融合。项目地址: https://ai.gitcode.com/MoonshotAI/Kimi-K2.5本篇技术指南以 docs/deploy_guidance.md 为骨架系统讲解开源原生多模态智能体模型 Kimi-K2.5 在 vLLM、SGLang、KTransformers 三大推理引擎上的部署命令与核心参数并结合本仓库的模型配置、聊天模板与处理器源码解释--tool-call-parser kimi_k2、--reasoning-parser kimi_k2等关键参数为何必需。读完本文你将掌握 Kimi-K2.5 单机多卡TP8服务化部署、CPUGPU 异构推理以及基于 LLaMA-Factory 的 LoRA SFT 微调与上线验证的完整实操路径。一、部署前须知模型构成与版本前提Kimi-K2.5 是一个原生多模态智能体模型在 Kimi-K2-Base 基础上通过约 15 万亿混合视觉与文本 token 的持续预训练构建将视觉语言理解、高级智能体能力、思考模式Thinking/即时模式Instant以及对话式与智能体范式融为一体。官方推荐在 vLLM、SGLang、KTransformers 三个推理引擎上运行且要求transformers最低版本为4.57.1。1.1 仓库文件构成部署时需要一并加载从仓库根目录可以看到一个可部署的完整模型目录包含以下关键文件文件作用config.json模型总配置架构为KimiK25ForConditionalGeneration内含text_config语言主干与vision_config视觉编码器modeling_kimi_k25.py模型实现KimiK25ForConditionalGeneration前向计算configuration_kimi_k25.pyKimiK25Config配置类组合文本与视觉子配置kimi_k25_processor.pyKimiK25Processor统一封装图像处理器与分词器kimi_k25_vision_processing.py视觉/视频预处理采样、分块、token 计算tokenization_kimi.pyTikTokenTokenizer分词器实现chat_template.jinja聊天模板思考模式、工具调用、媒体占位符渲染model-00001-of-000064.safetensors 等64 个分片的模型权重原生 INT4 量化因此在 vLLM / SGLang 的启动命令中都会看到--trust-remote-code其作用正是允许推理引擎加载仓库根目录下的自定义代码configuration_kimi_k25.py、tokenization_kimi.py 等这是 Kimi-K2.5 能正确启动的前提。1.2 模型架构要点影响显存与并行策略从 config.json 可确认模型的关键结构参数语言主干MoE 架构61 层、隐藏维度 7168、384 个路由专家每 token 激活 8 个 1 个共享专家注意力采用 MLAMulti-head Latent Attentionq_lora_rank1536、kv_lora_rank512max_position_embeddings262144即 256K 上下文长上下文通过 YaRN 位置插值rope_scaling.factor64实现视觉编码器MoonViTpatch_size14、27 层、隐藏维度 1152、vt_num_attention_heads16约 400M 参数多模态投影器为patchmergersd2_tpool时间池化合并merge_kernel_size[2,2]量化原生 INT4compressed-tensorsgroup_size32、4 bit 分组量化同时从量化忽略列表中可见self_attn、shared_experts、lm_head、vision_tower、mm_projector等模块保持更高精度这是 KTransformers 场景下 AMXINT4 等方案能够生效的基础。此外preprocessor_config.json 中的media_proc_cfg还定义了视觉媒体的处理预算单图 patch 上限in_patch_limit16384、单边 patch 上限patch_limit_on_one_side512、视频采样帧率sample_fps2.0、时间合并核temporal_merge_kernel_size4。这些配置决定了图片/视频输入会被压缩为多少视觉 token直接影响多模态推理时的 KV Cache 占用。1.3 关于版本时效的重要提示部署指南开头特别强调两点部署前务必知悉指南中的命令只是 Kimi-K2.5 部署命令的示例不一定是最优配置。推理引擎仍在频繁更新若追求更好的推理性能请持续跟进各推理引擎官方主页的最新指引kimi_k2推理解析器reasoning parser及相关特性已合并进 vLLM / SGLang 主线将在下一个正式版本中发布当前阶段请使用 nightly 构建的 Docker 镜像或 nightly wheel来获得这些能力。二、通用关键参数--tool-call-parser kimi_k2与--reasoning-parser kimi_k2在 vLLM 与 SGLang 的命令中有两个反复出现的参数它们是 Kimi-K2.5 正确工作的关键。结合仓库源码可以清楚地看到它们为什么必需。2.1 为什么需要--tool-call-parser kimi_k2Kimi-K2.5 的工具调用以一组专用特殊 token 表达。打开 chat_template.jinja 中的render_toolcalls宏可以看到模型输出工具调用的格式为|tool_calls_section_begin||tool_call_begin|{tool_call_id}|tool_call_argument_begin|{arguments}|tool_call_end||tool_calls_section_end|这些 token|tool_calls_section_begin|、|tool_call_begin|、|tool_call_argument_begin|、|tool_call_end|的 token id 依次是 163595163599已登记在 tokenizer_config.json 的added_tokens_decoder中。服务端必须通过--tool-call-parser kimi_k2注册对应的解析器才能把这些结构化的特殊 token 流还原成 OpenAI 兼容的tool_calls消息含id与函数arguments从而在 API 层向调用方暴露可用的工具调用能力。因此部署指南明确写道该参数是启用工具调用tool calling的必需项。2.2 为什么需要--reasoning-parser kimi_k2Kimi-K2.5默认开启思考模式thinking mode。从 chat_template.jinja 的生成提示部分可以看到|im_assistant|assistant|im_middle| {%- if thinking is defined and thinking is false -%} think/think {%- else -%} think {%- endif -%}即只要未显式传入thinkingFalse生成时就会输出think起始标签思考过程与最终回答分别包裹在think.../think中。分词器中think与/think的 token id 分别为 163606 与 163607见 tokenizer_config.json。此外tokenization_kimi.py 中的apply_chat_template方法也显式接收thinking: bool True参数并透传给模板。由于推理引擎默认不会区分思考内容与回答内容若不传入--reasoning-parser kimi_k2think标签及其内部的长篇思考文本会被当作普通输出直接返回污染最终回答。传入该参数后服务端会正确剥离并分别处理 reasoning 内容与最终回答——这正是部署指南强调Kimi-K2.5 默认启用思考模式务必传入该参数以正确处理推理内容的原因。2.3 思考/即时模式的切换部署后调用方如何控制部署完成后调用方可通过两种方式关闭思考模式官方 API 风格在请求体extra_body中传{thinking: {type: disabled}}vLLM / SGLang 部署风格在extra_body中传{chat_template_kwargs: {thinking: False}}。两种方式最终都会落入上述 chat template 的分支逻辑产出think/think空标签以开启即时模式。官方还建议思考模式推荐temperature1.0即时模式推荐temperature0.6top_p推荐0.95。三、vLLM 部署H200 单机 TP8 示例3.1 安装 nightly vLLMKimi-K2.5 当前可通过 nightly vLLM wheel 获取支持uv pip install -U vllm \ --torch-backendauto \ --extra-index-url https://wheels.vllm.ai/nightly说明--torch-backendauto让安装工具自动选择与当前环境匹配的 torch 后端--extra-index-url指向 vLLM 官方 nightly wheel 仓库。由于kimi_k2解析器等特性尚未进入正式发布版请务必使用 nightly 通道。3.2 启动服务以 H200 单节点、张量并行 8 卡TP8为例vllm serve $MODEL_PATH -tp 8 --mm-encoder-tp-mode data --trust-remote-code --tool-call-parser kimi_k2 --reasoning-parser kimi_k2各参数的作用如下参数说明$MODEL_PATH模型目录路径即包含 config.json 与 64 个 safetensors 分片的仓库目录-tp 8Tensor Parallel 张量并行度 8将模型权重与计算分布到 8 张 GPU--mm-encoder-tp-mode data多模态编码器MoonViT采用 data 并行模式视觉编码器在每个 rank 上各持一份仅对视觉输入做数据切分避免视觉部分因规模较小而在 TP 下产生额外通信开销--trust-remote-code信任并加载仓库自带的自定义代码配置类、分词器、处理器--tool-call-parser kimi_k2必需启用工具调用解析对应|tool_call_begin|等特殊 token 流--reasoning-parser kimi_k2必需Kimi-K2.5 默认开启思考模式传入该参数才能正确剥离think.../think中的推理内容四、SGLang 部署H200 单机 TP8 示例4.1 安装SGLang 侧使用最新 main 分支安装pip install sglang githttps://github.com/sgl-project/sglang.git#subdirectorypython pip install nvidia-cudnn-cu129.16.0.29其中nvidia-cudnn-cu129.16.0.29是 Kimi-K2.5 视觉部分MoonViT 注意力在 SGLang 上运行所需的 cudnn 版本依赖需与主包一起安装。4.2 启动服务sglang serve --model-path $MODEL_PATH --tp 8 --trust-remote-code --tool-call-parser kimi_k2 --reasoning-parser kimi_k2关键参数说明参数说明--model-path模型目录路径--tp 8张量并行度 8--trust-remote-code加载仓库自定义代码--tool-call-parser kimi_k2启用工具调用时必需--reasoning-parser kimi_k2正确处理推理内容必需从源码角度看SGLang 与 vLLM 两条路径共用同一套模型文件与 chat template因此两个 parser 参数的意义与 chat_template.jinja 中的思考/工具 token 结构完全一致区别仅在于各自的 serving 框架实现。五、KTransformers 部署CPUGPU 异构KTransformers 提供两条部署路径一是基于 KTransformersSGLang 的异构推理二是基于 KTransformersLLaMA-Factory 的 LoRA 微调。前者解决显存不足场景下的服务化推理后者解决单机消费级显卡上的高效微调。5.1 KTransformers SGLang 推理部署启动 CPUGPU 异构推理python -m sglang.launch_server \ --model path/to/Kimi-K2.5/ \ --kt-amx-weight-path path/to/Kimi-K2.5/ \ --kt-cpuinfer 64 \ --kt-threadpool-count 2 \ --kt-num-gpu-experts 180 \ --kt-amx-method AMXINT4 \ --trust-remote-code \ --mem-fraction-static 0.98 \ --chunked-prefill-size 16384 \ --max-running-requests 48 \ --max-total-tokens 50000 \ --tensor-parallel-size 8 \ --enable-p2p-check \ --disable-shared-experts-fusion参数含义速查参数说明--model模型目录路径--kt-amx-weight-pathAMX 量化权重的加载路径通常与模型路径一致--kt-cpuinfer 64CPU 推理使用 64 个线程参与计算--kt-threadpool-count 2线程池数量CPU 推理调度组数--kt-num-gpu-experts 180将 180 个 MoE 专家放到 GPU 上执行其余专家由 CPU 计算实现专家在 GPU/CPU 间的异构分布--kt-amx-method AMXINT4使用 AMX 指令集 INT4 量化方式执行 CPU 侧专家计算与模型原生 INT4 权重见 config.json 的quantization_config匹配--mem-fraction-static 0.98GPU 显存静态占用比例设为 0.98最大化显存利用率--chunked-prefill-size 16384chunked prefill 的 chunk 大小token 数控制预填充阶段的显存峰值--max-running-requests 48最大并发运行请求数 48--max-total-tokens 50000系统所有请求合计的最大 token 预算--tensor-parallel-size 8GPU 侧张量并行度 8--enable-p2p-check启动时检查 GPU 间 P2P 通信能力--disable-shared-experts-fusion关闭共享专家融合优化与 KTransformers 的 CPU 异构调度策略配合性能参考来自官方部署文档在 8× NVIDIA L20 2× Intel 6454S 的硬件组合上48 路并发下测得640.12 tokens/s Prefill、24.51 tokens/s Decode。该数据是特定硬件与配置下的实测结果实际吞吐会随机器配置与负载变化请以自身环境复测为准。5.2 KTransformers LLaMA-Factory 微调部署KTransformers 还支持与 LLaMA-Factory 配合在 CPUGPU 异构环境下执行 LoRA SFT低秩微调大幅降低消费级显卡上的微调门槛# LoRA SFT 训练 USE_KT1 llamafactory-cli train examples/train_lora/kimik2_lora_sft_kt.yaml # LoRA SFT 后与模型对话 llamafactory-cli chat examples/inference/kimik2_lora_sft_kt.yaml # LoRA SFT 后以 API 形式提供服务 llamafactory-cli api examples/inference/kimik2_lora_sft_kt.yaml三个命令的职责清晰train读取examples/train_lora/kimik2_lora_sft_kt.yaml训练配置启动 LoRA SFTchat加载微调产物进行交互验证api将微调后的模型以 OpenAI 兼容接口对外服务。设置环境变量USE_KT1可让 LLaMA-Factory 启用 KTransformers 后端。性能参考来自官方部署文档在 2× NVIDIA 4090 Intel 8488C1.97T 内存 200G swap的配置下端到端 LoRA SFT 吞吐为44.55 token/s。该数据为特定硬件的实测值仅供选型参考。5.3 两条 KTransformers 路径的适用场景KTransformersSGLang面向显存不足以整卡加载全部 1T 参数原生 INT4 量化后仍需较大显存的服务化场景通过把部分 MoE 专家卸载到 CPU 并利用 AMX INT4 加速在 8×L20 级别的中端显卡集群上即可支撑 48 路并发服务KTransformersLLaMA-Factory面向微调场景LoRA 只需训练低秩适配器配合异构执行可显著降低峰值显存使 2×4090 级别的桌面级配置即可完成 Kimi-K2.5 的 SFT。六、部署后的验证与调用要点服务起来之后可以从以下几个维度验证部署是否正确6.1 思考模式/即时模式验证调用时检查响应中的reasoning_content字段。思考模式下该字段应包含完整推理文本而content为最终回答即时模式则通常不产生推理内容。若服务端未传--reasoning-parser kimi_k2think.../think标签会原样出现在content中——这是最常见的部署配置错误可据此快速定位。6.2 工具调用验证工具调用依赖三层配合请求侧传入tools声明仓库通过 tool_declaration_ts.py 将 JSON Schema 工具声明编码为模型使用的 TypeScript 风格工具描述对应 chat template 中的tools_ts_str分支→ chat template 渲染|im_system|tool_declare|im_middle|...工具声明段 → 服务端--tool-call-parser kimi_k2将模型的|tool_call_begin|特殊 token 输出解析为结构化tool_calls。三个环节任一缺失都会导致工具调用失败排查时可依次确认。6.3 多模态输入验证Kimi-K2.5 支持图像与视频输入。图像通过image_url传入视频通过video_url传入kimi_k25_processor.py 中的preprocess_medias会把视频按 kimi_k25_vision_processing.py 的逻辑切分为多个视频 chunk时间池化合并temporal_merge_kernel_size4并通过update_raw_text将|kimi_k25_video_placeholder|替换为实际的 chunk 提示。需要特别注意的是视频对话目前是实验性功能仅官方 API 支持基于 vLLM / SGLang 的第三方部署暂时只保证图像输入。此外聊天模板中媒体 token 以|media_begin|image|media_content|...|media_end|形式渲染chat_template.jinja对应 token id 163602163605部署时无需额外处理但需保证 processor 与 tokenizer 版本匹配。6.4 生成参数参考generation_config.json 预置max_length262144与 256K 上下文一致与eos_token_id163586|im_end|。实际调用时建议按官方推荐设置temperature1.0思考模式/0.6即时模式、top_p0.95并根据任务规模调整max_tokens。七、常见问题与排查建议现象可能原因处理建议输出中出现think标签原文未传--reasoning-parser kimi_k2按本文第二节为服务端加上推理解析器工具调用返回空或格式错误未传--tool-call-parser kimi_k2或工具声明格式与模板不匹配确认服务端参数并使用 tool_declaration_ts.py 生成工具描述模型加载报找不到自定义类未加--trust-remote-code或transformers版本低于 4.57.1添加该参数并升级transformers多模态请求报错图片/视频预处理参数与 preprocessor_config.json 不匹配保持仓库自带的 processor 配置视频输入注意实验性限制视觉部分显存溢出--mm-encoder-tp-mode未设置或 chunk 过大vLLM 侧使用--mm-encoder-tp-mode data可调整in_patch_limit相关处理配置八、总结Kimi-K2.5 的部署覆盖了三条主线vLLM / SGLang 适合拥有充足 GPU 显存的标准化服务化部署通过--tool-call-parser kimi_k2与--reasoning-parser kimi_k2获得完整的工具调用与思考模式支持KTransformersSGLang 通过 CPUGPU 异构与 AMX INT4 在有限显存下实现高并发推理KTransformersLLaMA-Factory 则在消费级显卡上完成 LoRA SFT 微调与上线。由于kimi_k2解析器与相关特性目前仍处于 nightly 通道部署时请始终以各推理引擎官方主页的最新版本指引为准并注意transformers 4.57.1的版本前提。模型使用协议见 LICENSE第三方组件声明见 THIRD_PARTY_NOTICES.md更完整的模型能力介绍可查阅 README.md。【免费下载链接】Kimi-K2.5Kimi K2.5 是一款开源的原生多模态智能体模型它在 Kimi-K2-Base 的基础上通过对约 15 万亿混合视觉和文本 tokens 进行持续预训练构建而成。该模型将视觉与语言理解、高级智能体能力、即时模式与思考模式以及对话式与智能体范式无缝融合。项目地址: https://ai.gitcode.com/MoonshotAI/Kimi-K2.5创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kimi-K2.5 部署实战指南：基于 vLLM / SGLang / KTransformers 的推理与 LoRA 微调完整部署方案
Kimi-K2.5 部署实战指南基于 vLLM / SGLang / KTransformers 的推理与 LoRA 微调完整部署方案【免费下载链接】Kimi-K2.5Kimi K2.5 是一款开源的原生多模态智能体模型它在 Kimi-K2-Base 的基础上通过对约 15 万亿混合视觉和文本 tokens 进行持续预训练构建而成。该模型将视觉与语言理解、高级智能体能力、即时模式与思考模式以及对话式与智能体范式无缝融合。项目地址: https://ai.gitcode.com/MoonshotAI/Kimi-K2.5本篇技术指南以 docs/deploy_guidance.md 为骨架系统讲解开源原生多模态智能体模型 Kimi-K2.5 在 vLLM、SGLang、KTransformers 三大推理引擎上的部署命令与核心参数并结合本仓库的模型配置、聊天模板与处理器源码解释--tool-call-parser kimi_k2、--reasoning-parser kimi_k2等关键参数为何必需。读完本文你将掌握 Kimi-K2.5 单机多卡TP8服务化部署、CPUGPU 异构推理以及基于 LLaMA-Factory 的 LoRA SFT 微调与上线验证的完整实操路径。一、部署前须知模型构成与版本前提Kimi-K2.5 是一个原生多模态智能体模型在 Kimi-K2-Base 基础上通过约 15 万亿混合视觉与文本 token 的持续预训练构建将视觉语言理解、高级智能体能力、思考模式Thinking/即时模式Instant以及对话式与智能体范式融为一体。官方推荐在 vLLM、SGLang、KTransformers 三个推理引擎上运行且要求transformers最低版本为4.57.1。1.1 仓库文件构成部署时需要一并加载从仓库根目录可以看到一个可部署的完整模型目录包含以下关键文件文件作用config.json模型总配置架构为KimiK25ForConditionalGeneration内含text_config语言主干与vision_config视觉编码器modeling_kimi_k25.py模型实现KimiK25ForConditionalGeneration前向计算configuration_kimi_k25.pyKimiK25Config配置类组合文本与视觉子配置kimi_k25_processor.pyKimiK25Processor统一封装图像处理器与分词器kimi_k25_vision_processing.py视觉/视频预处理采样、分块、token 计算tokenization_kimi.pyTikTokenTokenizer分词器实现chat_template.jinja聊天模板思考模式、工具调用、媒体占位符渲染model-00001-of-000064.safetensors 等64 个分片的模型权重原生 INT4 量化因此在 vLLM / SGLang 的启动命令中都会看到--trust-remote-code其作用正是允许推理引擎加载仓库根目录下的自定义代码configuration_kimi_k25.py、tokenization_kimi.py 等这是 Kimi-K2.5 能正确启动的前提。1.2 模型架构要点影响显存与并行策略从 config.json 可确认模型的关键结构参数语言主干MoE 架构61 层、隐藏维度 7168、384 个路由专家每 token 激活 8 个 1 个共享专家注意力采用 MLAMulti-head Latent Attentionq_lora_rank1536、kv_lora_rank512max_position_embeddings262144即 256K 上下文长上下文通过 YaRN 位置插值rope_scaling.factor64实现视觉编码器MoonViTpatch_size14、27 层、隐藏维度 1152、vt_num_attention_heads16约 400M 参数多模态投影器为patchmergersd2_tpool时间池化合并merge_kernel_size[2,2]量化原生 INT4compressed-tensorsgroup_size32、4 bit 分组量化同时从量化忽略列表中可见self_attn、shared_experts、lm_head、vision_tower、mm_projector等模块保持更高精度这是 KTransformers 场景下 AMXINT4 等方案能够生效的基础。此外preprocessor_config.json 中的media_proc_cfg还定义了视觉媒体的处理预算单图 patch 上限in_patch_limit16384、单边 patch 上限patch_limit_on_one_side512、视频采样帧率sample_fps2.0、时间合并核temporal_merge_kernel_size4。这些配置决定了图片/视频输入会被压缩为多少视觉 token直接影响多模态推理时的 KV Cache 占用。1.3 关于版本时效的重要提示部署指南开头特别强调两点部署前务必知悉指南中的命令只是 Kimi-K2.5 部署命令的示例不一定是最优配置。推理引擎仍在频繁更新若追求更好的推理性能请持续跟进各推理引擎官方主页的最新指引kimi_k2推理解析器reasoning parser及相关特性已合并进 vLLM / SGLang 主线将在下一个正式版本中发布当前阶段请使用 nightly 构建的 Docker 镜像或 nightly wheel来获得这些能力。二、通用关键参数--tool-call-parser kimi_k2与--reasoning-parser kimi_k2在 vLLM 与 SGLang 的命令中有两个反复出现的参数它们是 Kimi-K2.5 正确工作的关键。结合仓库源码可以清楚地看到它们为什么必需。2.1 为什么需要--tool-call-parser kimi_k2Kimi-K2.5 的工具调用以一组专用特殊 token 表达。打开 chat_template.jinja 中的render_toolcalls宏可以看到模型输出工具调用的格式为|tool_calls_section_begin||tool_call_begin|{tool_call_id}|tool_call_argument_begin|{arguments}|tool_call_end||tool_calls_section_end|这些 token|tool_calls_section_begin|、|tool_call_begin|、|tool_call_argument_begin|、|tool_call_end|的 token id 依次是 163595163599已登记在 tokenizer_config.json 的added_tokens_decoder中。服务端必须通过--tool-call-parser kimi_k2注册对应的解析器才能把这些结构化的特殊 token 流还原成 OpenAI 兼容的tool_calls消息含id与函数arguments从而在 API 层向调用方暴露可用的工具调用能力。因此部署指南明确写道该参数是启用工具调用tool calling的必需项。2.2 为什么需要--reasoning-parser kimi_k2Kimi-K2.5默认开启思考模式thinking mode。从 chat_template.jinja 的生成提示部分可以看到|im_assistant|assistant|im_middle| {%- if thinking is defined and thinking is false -%} think/think {%- else -%} think {%- endif -%}即只要未显式传入thinkingFalse生成时就会输出think起始标签思考过程与最终回答分别包裹在think.../think中。分词器中think与/think的 token id 分别为 163606 与 163607见 tokenizer_config.json。此外tokenization_kimi.py 中的apply_chat_template方法也显式接收thinking: bool True参数并透传给模板。由于推理引擎默认不会区分思考内容与回答内容若不传入--reasoning-parser kimi_k2think标签及其内部的长篇思考文本会被当作普通输出直接返回污染最终回答。传入该参数后服务端会正确剥离并分别处理 reasoning 内容与最终回答——这正是部署指南强调Kimi-K2.5 默认启用思考模式务必传入该参数以正确处理推理内容的原因。2.3 思考/即时模式的切换部署后调用方如何控制部署完成后调用方可通过两种方式关闭思考模式官方 API 风格在请求体extra_body中传{thinking: {type: disabled}}vLLM / SGLang 部署风格在extra_body中传{chat_template_kwargs: {thinking: False}}。两种方式最终都会落入上述 chat template 的分支逻辑产出think/think空标签以开启即时模式。官方还建议思考模式推荐temperature1.0即时模式推荐temperature0.6top_p推荐0.95。三、vLLM 部署H200 单机 TP8 示例3.1 安装 nightly vLLMKimi-K2.5 当前可通过 nightly vLLM wheel 获取支持uv pip install -U vllm \ --torch-backendauto \ --extra-index-url https://wheels.vllm.ai/nightly说明--torch-backendauto让安装工具自动选择与当前环境匹配的 torch 后端--extra-index-url指向 vLLM 官方 nightly wheel 仓库。由于kimi_k2解析器等特性尚未进入正式发布版请务必使用 nightly 通道。3.2 启动服务以 H200 单节点、张量并行 8 卡TP8为例vllm serve $MODEL_PATH -tp 8 --mm-encoder-tp-mode data --trust-remote-code --tool-call-parser kimi_k2 --reasoning-parser kimi_k2各参数的作用如下参数说明$MODEL_PATH模型目录路径即包含 config.json 与 64 个 safetensors 分片的仓库目录-tp 8Tensor Parallel 张量并行度 8将模型权重与计算分布到 8 张 GPU--mm-encoder-tp-mode data多模态编码器MoonViT采用 data 并行模式视觉编码器在每个 rank 上各持一份仅对视觉输入做数据切分避免视觉部分因规模较小而在 TP 下产生额外通信开销--trust-remote-code信任并加载仓库自带的自定义代码配置类、分词器、处理器--tool-call-parser kimi_k2必需启用工具调用解析对应|tool_call_begin|等特殊 token 流--reasoning-parser kimi_k2必需Kimi-K2.5 默认开启思考模式传入该参数才能正确剥离think.../think中的推理内容四、SGLang 部署H200 单机 TP8 示例4.1 安装SGLang 侧使用最新 main 分支安装pip install sglang githttps://github.com/sgl-project/sglang.git#subdirectorypython pip install nvidia-cudnn-cu129.16.0.29其中nvidia-cudnn-cu129.16.0.29是 Kimi-K2.5 视觉部分MoonViT 注意力在 SGLang 上运行所需的 cudnn 版本依赖需与主包一起安装。4.2 启动服务sglang serve --model-path $MODEL_PATH --tp 8 --trust-remote-code --tool-call-parser kimi_k2 --reasoning-parser kimi_k2关键参数说明参数说明--model-path模型目录路径--tp 8张量并行度 8--trust-remote-code加载仓库自定义代码--tool-call-parser kimi_k2启用工具调用时必需--reasoning-parser kimi_k2正确处理推理内容必需从源码角度看SGLang 与 vLLM 两条路径共用同一套模型文件与 chat template因此两个 parser 参数的意义与 chat_template.jinja 中的思考/工具 token 结构完全一致区别仅在于各自的 serving 框架实现。五、KTransformers 部署CPUGPU 异构KTransformers 提供两条部署路径一是基于 KTransformersSGLang 的异构推理二是基于 KTransformersLLaMA-Factory 的 LoRA 微调。前者解决显存不足场景下的服务化推理后者解决单机消费级显卡上的高效微调。5.1 KTransformers SGLang 推理部署启动 CPUGPU 异构推理python -m sglang.launch_server \ --model path/to/Kimi-K2.5/ \ --kt-amx-weight-path path/to/Kimi-K2.5/ \ --kt-cpuinfer 64 \ --kt-threadpool-count 2 \ --kt-num-gpu-experts 180 \ --kt-amx-method AMXINT4 \ --trust-remote-code \ --mem-fraction-static 0.98 \ --chunked-prefill-size 16384 \ --max-running-requests 48 \ --max-total-tokens 50000 \ --tensor-parallel-size 8 \ --enable-p2p-check \ --disable-shared-experts-fusion参数含义速查参数说明--model模型目录路径--kt-amx-weight-pathAMX 量化权重的加载路径通常与模型路径一致--kt-cpuinfer 64CPU 推理使用 64 个线程参与计算--kt-threadpool-count 2线程池数量CPU 推理调度组数--kt-num-gpu-experts 180将 180 个 MoE 专家放到 GPU 上执行其余专家由 CPU 计算实现专家在 GPU/CPU 间的异构分布--kt-amx-method AMXINT4使用 AMX 指令集 INT4 量化方式执行 CPU 侧专家计算与模型原生 INT4 权重见 config.json 的quantization_config匹配--mem-fraction-static 0.98GPU 显存静态占用比例设为 0.98最大化显存利用率--chunked-prefill-size 16384chunked prefill 的 chunk 大小token 数控制预填充阶段的显存峰值--max-running-requests 48最大并发运行请求数 48--max-total-tokens 50000系统所有请求合计的最大 token 预算--tensor-parallel-size 8GPU 侧张量并行度 8--enable-p2p-check启动时检查 GPU 间 P2P 通信能力--disable-shared-experts-fusion关闭共享专家融合优化与 KTransformers 的 CPU 异构调度策略配合性能参考来自官方部署文档在 8× NVIDIA L20 2× Intel 6454S 的硬件组合上48 路并发下测得640.12 tokens/s Prefill、24.51 tokens/s Decode。该数据是特定硬件与配置下的实测结果实际吞吐会随机器配置与负载变化请以自身环境复测为准。5.2 KTransformers LLaMA-Factory 微调部署KTransformers 还支持与 LLaMA-Factory 配合在 CPUGPU 异构环境下执行 LoRA SFT低秩微调大幅降低消费级显卡上的微调门槛# LoRA SFT 训练 USE_KT1 llamafactory-cli train examples/train_lora/kimik2_lora_sft_kt.yaml # LoRA SFT 后与模型对话 llamafactory-cli chat examples/inference/kimik2_lora_sft_kt.yaml # LoRA SFT 后以 API 形式提供服务 llamafactory-cli api examples/inference/kimik2_lora_sft_kt.yaml三个命令的职责清晰train读取examples/train_lora/kimik2_lora_sft_kt.yaml训练配置启动 LoRA SFTchat加载微调产物进行交互验证api将微调后的模型以 OpenAI 兼容接口对外服务。设置环境变量USE_KT1可让 LLaMA-Factory 启用 KTransformers 后端。性能参考来自官方部署文档在 2× NVIDIA 4090 Intel 8488C1.97T 内存 200G swap的配置下端到端 LoRA SFT 吞吐为44.55 token/s。该数据为特定硬件的实测值仅供选型参考。5.3 两条 KTransformers 路径的适用场景KTransformersSGLang面向显存不足以整卡加载全部 1T 参数原生 INT4 量化后仍需较大显存的服务化场景通过把部分 MoE 专家卸载到 CPU 并利用 AMX INT4 加速在 8×L20 级别的中端显卡集群上即可支撑 48 路并发服务KTransformersLLaMA-Factory面向微调场景LoRA 只需训练低秩适配器配合异构执行可显著降低峰值显存使 2×4090 级别的桌面级配置即可完成 Kimi-K2.5 的 SFT。六、部署后的验证与调用要点服务起来之后可以从以下几个维度验证部署是否正确6.1 思考模式/即时模式验证调用时检查响应中的reasoning_content字段。思考模式下该字段应包含完整推理文本而content为最终回答即时模式则通常不产生推理内容。若服务端未传--reasoning-parser kimi_k2think.../think标签会原样出现在content中——这是最常见的部署配置错误可据此快速定位。6.2 工具调用验证工具调用依赖三层配合请求侧传入tools声明仓库通过 tool_declaration_ts.py 将 JSON Schema 工具声明编码为模型使用的 TypeScript 风格工具描述对应 chat template 中的tools_ts_str分支→ chat template 渲染|im_system|tool_declare|im_middle|...工具声明段 → 服务端--tool-call-parser kimi_k2将模型的|tool_call_begin|特殊 token 输出解析为结构化tool_calls。三个环节任一缺失都会导致工具调用失败排查时可依次确认。6.3 多模态输入验证Kimi-K2.5 支持图像与视频输入。图像通过image_url传入视频通过video_url传入kimi_k25_processor.py 中的preprocess_medias会把视频按 kimi_k25_vision_processing.py 的逻辑切分为多个视频 chunk时间池化合并temporal_merge_kernel_size4并通过update_raw_text将|kimi_k25_video_placeholder|替换为实际的 chunk 提示。需要特别注意的是视频对话目前是实验性功能仅官方 API 支持基于 vLLM / SGLang 的第三方部署暂时只保证图像输入。此外聊天模板中媒体 token 以|media_begin|image|media_content|...|media_end|形式渲染chat_template.jinja对应 token id 163602163605部署时无需额外处理但需保证 processor 与 tokenizer 版本匹配。6.4 生成参数参考generation_config.json 预置max_length262144与 256K 上下文一致与eos_token_id163586|im_end|。实际调用时建议按官方推荐设置temperature1.0思考模式/0.6即时模式、top_p0.95并根据任务规模调整max_tokens。七、常见问题与排查建议现象可能原因处理建议输出中出现think标签原文未传--reasoning-parser kimi_k2按本文第二节为服务端加上推理解析器工具调用返回空或格式错误未传--tool-call-parser kimi_k2或工具声明格式与模板不匹配确认服务端参数并使用 tool_declaration_ts.py 生成工具描述模型加载报找不到自定义类未加--trust-remote-code或transformers版本低于 4.57.1添加该参数并升级transformers多模态请求报错图片/视频预处理参数与 preprocessor_config.json 不匹配保持仓库自带的 processor 配置视频输入注意实验性限制视觉部分显存溢出--mm-encoder-tp-mode未设置或 chunk 过大vLLM 侧使用--mm-encoder-tp-mode data可调整in_patch_limit相关处理配置八、总结Kimi-K2.5 的部署覆盖了三条主线vLLM / SGLang 适合拥有充足 GPU 显存的标准化服务化部署通过--tool-call-parser kimi_k2与--reasoning-parser kimi_k2获得完整的工具调用与思考模式支持KTransformersSGLang 通过 CPUGPU 异构与 AMX INT4 在有限显存下实现高并发推理KTransformersLLaMA-Factory 则在消费级显卡上完成 LoRA SFT 微调与上线。由于kimi_k2解析器与相关特性目前仍处于 nightly 通道部署时请始终以各推理引擎官方主页的最新版本指引为准并注意transformers 4.57.1的版本前提。模型使用协议见 LICENSE第三方组件声明见 THIRD_PARTY_NOTICES.md更完整的模型能力介绍可查阅 README.md。【免费下载链接】Kimi-K2.5Kimi K2.5 是一款开源的原生多模态智能体模型它在 Kimi-K2-Base 的基础上通过对约 15 万亿混合视觉和文本 tokens 进行持续预训练构建而成。该模型将视觉与语言理解、高级智能体能力、即时模式与思考模式以及对话式与智能体范式无缝融合。项目地址: https://ai.gitcode.com/MoonshotAI/Kimi-K2.5创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考