Kimi K3部署指南：2.8T MoE、API、自托管与GPU集群规划|赋创

先给结论：Kimi K3现在可以推进到什么部署阶段

Kimi K3 已经同时具备 API 业务验证和开放权重自托管验证的基本条件。当前企业更需要区分的不是“能不能部署”，而是业务处于 API 验证、自托管 PoC，还是生产集群规划阶段。

API：官方已提供 kimi-k3，支持 1M tokens 上下文、视觉理解、工具调用与可调推理强度，适合先建立真实业务任务基线。
开放权重：Kimi K3 完整权重已经发布，Hugging Face 官方仓库当前显示约 1.56 TB，并采用 Kimi K3 License，可进入模型文件、框架、硬件和集群的自托管可行性验证。
推理框架：Moonshot AI 官方仓库当前推荐 vLLM、SGLang 和 TokenSpeed。三套路径均已有 K3 配方，但其中部分仍明确标注为预发布或最终验证进行中，生产使用需要锁定版本并复测。
服务器规划：2.8T 总参数和 104B 激活参数不能直接换算成统一 GPU 卡数。权重格式、目标 GPU、并行拓扑、上下文、并发和服务目标共同决定最终配置。

因此，一套更实用的企业路径是：先用真实任务确认模型与业务是否匹配，再用目标环境验证资源边界，最后确定 API、自托管或混合路线。

截至2026年8月5日，哪些部署信息已经明确

项目	当前公开状态	对企业部署的意义
API	`kimi-k3` 已在 Kimi API 开放平台提供	可直接建立任务效果、上下文、Token 与成本基线
完整权重	Moonshot AI 已发布官方权重；Hugging Face 仓库当前约 1.56 TB	可进入自托管下载、校验、加载与框架验证
模型规模	2.8T 总参数 / 104B 激活参数	需要同时考虑完整权重容量与稀疏计算路径
原生精度路径	MXFP4 权重 / MXFP8 激活，采用量化感知训练	硬件、内核、框架和模型格式需要共同适配
上下文	1,048,576 tokens	长上下文验证要同时测 Prefill、缓存、并发和尾延迟
推理框架	官方推荐 vLLM、SGLang、TokenSpeed	已有公开部署配方，但生产前仍需按当前版本复测
思考模式	K3 始终进行推理；`reasoning_effort` 支持 low / high / max，默认 max	推理强度会影响输出 Token、时延与 API 成本，应纳入业务测试
国内API价格	缓存命中输入 ¥2 / MTok；普通输入 ¥20 / MTok；输出 ¥100 / MTok	可用于当前 PoC 成本测算；正式预算应按调用时价格复核

Kimi K3有哪些与部署相关的核心规格

项目	官方信息	部署含义
模型类型	开放权重、原生多模态 Agentic 模型	可通过官方 API 使用，也可基于开放权重验证自托管
架构	MoE；KDA + Gated MLA；Attention Residuals；Stable LatentMoE	推理同时涉及专家路由、混合注意力状态和跨设备通信
总参数	2.8T	影响权重存储、分片、模型分发和加载规模
激活参数	104B	可辅助理解每个 token 的稀疏计算规模，但不等于显存占用或实际 FLOPs
专家配置	896 个路由专家；每 token 选择 16 个；另有 2 个共享专家	专家并行需要评估 GPU 间及跨节点数据交换
模型层数	93 层，其中 1 层 Dense Layer	影响模型分片、并行布局和运行时状态
注意力层组成	69 层 KDA + 24 层 Gated MLA	运行时除 MLA KV 外，还需要考虑 KDA recurrent state
权重与激活	MXFP4 权重 / MXFP8 激活；量化感知训练	不能简单等同于通用 INT4；需验证目标 GPU、算子与框架的原生支持路径
最大上下文	1,048,576 tokens	模型上限不等于生产并发下的常用值，需要按真实上下文分布测试
视觉编码器	MoonViT-V2，约 401M 参数	图像预处理与视觉编码会增加额外计算和显存需求
多模态	官方模型摘要将 Modality 列为 Text、Image；K3 API Quickstart 同时提供视频输入示例	API 与自托管框架的媒体输入能力要分别核验，不能只依据基础模型标签推断
官方权重仓库	Hugging Face 当前显示约 1.56 TB，模型权重分为 96 个 safetensors 分片	需要规划模型下载、校验、缓存、分发、加载与版本切换

2.8T总参数与104B激活参数，部署时分别代表什么

Kimi K3 是 MoE 模型。对于每个 token，路由器只选择部分专家参与计算，因此官方同时给出了 2.8T 总参数和 104B 激活参数。

这两个数字解决的是不同问题：

容量规划：完整权重 + 运行时 + 通信缓冲 + 缓存/状态 + 安全余量

计算规划：激活路径 + token 数量 + 注意力/路由开销 + 算子效率 + 通信效率

104B 激活参数是理解稀疏专家计算量的重要输入，但不能直接把 Kimi K3 当作“104B 稠密模型”来估算服务器。不同 token 可能路由到不同专家，完整专家权重仍需在服务体系中保持可访问。

如果只做静态理论计算，2.8T 参数按每参数 4 bit 理想打包约为 1.4 TB；Hugging Face 官方仓库当前实际显示约 1.56 TB。两者的差异来自实际模型文件还包含量化尺度、非 4 bit 张量、元数据等内容。因此工程规划应以实际仓库、加载日志和目标框架为准，而不是用“参数量 × 位宽”得到最终显存结论。

API、自托管PoC与生产集群怎么选

路线	适用阶段	优先获取的数据	基础设施重点
Kimi K3 API	业务效果、任务边界和调用规模尚在验证	任务完成质量、输入/输出 Token、推理强度、上下文、时延、工具调用与单任务成本	应用服务、访问控制、日志、网络和数据治理
开放权重自托管 PoC	已有本地化或环境控制需求，需要验证目标硬件	模型加载、功能正确性、显存、TTFT、TPOT/ITL、吞吐、并发与稳定性	GPU、CPU、内存、NVMe、节点互连、RDMA、推理框架
生产集群	业务负载和服务目标已经相对清晰	P95/P99 时延、错误率、扩展效率、可用性、故障恢复与单位任务成本	多节点 GPU、服务调度、网络、监控、灰度、回滚和冗余

三条路线不是固定的先后关系。数据边界明确的项目可以较早进入自托管验证；业务仍在探索的项目则可先通过 API 获得真实负载数据，再决定是否建设本地集群。

Kimi K3 API当前有哪些部署相关细节值得提前验证

官方快速开始当前使用模型名 kimi-k3，OpenAI 兼容接口示例的 base_url 为 https://api.moonshot.cn/v1。企业在 API PoC 阶段可以同步记录以下信息：

推理强度：K3 始终进行推理，通过顶层 reasoning_effort 设置 low、high、max，默认 max。不同档位应分别统计质量、时延和 Token 消耗。
Preserved Thinking：多轮对话和工具调用需要把 API 返回的完整 assistant message 原样加入后续 messages，包括 reasoning_content 与 tool_calls。
输出长度：当前 K3 Quickstart 标注 max_completion_tokens 默认 131072、最大可设为 1048576；同时，输入与输出总长度仍受模型 1M 上下文窗口限制。
上下文缓存：普通请求自动尝试前缀缓存，无需单独创建 cache ID。当前文档说明前一个请求的 prompt 大于 256 tokens 时，后续保持相同长前缀的请求才有机会命中缓存。
视觉输入：当前 K3 Quickstart 说明公网图片 URL 不能直接作为视觉输入，应使用 base64 或 ms://<file-id>；视频示例也通过文件上传后引用。
工具调用：每个 tool_call 都应返回匹配的 tool_call_id。业务侧可增加 schema 校验、超时、幂等和重复调用检测。

Kimi K3 API当前价格如何进入PoC成本模型

截至 2026 年 8 月 5 日，Kimi API 开放平台公开的 K3 价格如下，其中 MTok 表示 100 万 tokens：

缓存命中输入：¥2 / MTok；
普通输入：¥20 / MTok；
输出：¥100 / MTok。

因此，API 侧更适合按“真实任务”计算成本，而不是只按请求次数估算：

单任务API成本 ≈ 缓存命中输入Token成本 + 普通输入Token成本 + 输出Token成本

Agent 场景还要把多轮推理、工具调用、失败重试和子任务产生的 Token 一并计入。价格属于时效性信息，正式预算应以项目核算时的官方价格页为准。

vLLM、SGLang与TokenSpeed当前支持到了哪一步

Moonshot AI 官方 Kimi K3 仓库当前明确推荐 vLLM、SGLang 和 TokenSpeed。这里的“推荐”代表官方提供了对应部署入口，不等于所有硬件、所有功能和所有负载都已经完成生产级验证。

框架	截至8月5日的公开状态	企业验证重点
vLLM	K3 专用 Recipe 仍标注 Pre-release，并列出 vLLM 0.27.0+、K3 专用容器、NVIDIA 与 AMD 路径	驱动/CUDA或ROCm版本、模型加载、TP/EP/P/D、all-to-all、工具调用解析、长上下文与稳定性
SGLang	已公开 K3 部署矩阵、KDA/MLA 内存模型和多类硬件配方；页面仍标注 Final Verification In Progress	KDA state 与 MLA KV 比例、目标拓扑、上下文、并发、图像输入、吞吐、精度和故障恢复
TokenSpeed	提供 K3 的 NVIDIA、AMD 执行路径，并可直接解析官方 `moonshotai/Kimi-K3` checkpoint	内核依赖、注意力后端、MoE后端、KV精度、解析器、多模态处理与目标GPU适配

Hugging Face 当前模型页也已经提供 vLLM 和 SGLang 的基础启动入口。生产项目仍建议按照各框架的 K3 专用 Recipe/Cookbook 固定容器、驱动和框架版本，因为专用文档包含模型特有的低精度、并行和缓存配置。

另一个需要保留的工程边界是：vLLM 当前 K3 Recipe 明确提示，工具调用有可能出现解析器未预期的格式，因此建议进行 schema validation 并在必要时重试。这类提示更适合在 PoC 阶段纳入稳定性测试，而不是等到生产 Agent 流程再处理。

官方公开配方提供了哪些GPU参考路径

下面列的是框架维护方当前公开的 K3 Recipe/Cookbook 示例，不是赋创给出的统一最低配置，也不代表企业项目的固定采购卡数。同一模型在不同框架、GPU显存容量、低精度算子、并行方式、上下文和并发下，资源边界会不同。

来源	公开参考路径	当前文档提示
vLLM / NVIDIA	至少 8×GB300	K3 Recipe 使用 CUDA 13 专用镜像，并提示主机侧 r580+ NVIDIA 驱动；该 Recipe 仍标注 Pre-release
vLLM / AMD	至少 8×MI355X / MI350X	使用 K3 的 ROCm 容器路径；仍需按当前镜像和 AITER 配置核验
SGLang / B300	1×8 GPU	公开部署矩阵中的参考拓扑
SGLang / GB300	2×4 GPU	公开部署矩阵中的参考拓扑
SGLang / B200	2×8 GPU	不同运行模式会采用不同 TP/DCP/EP/PP 组合
SGLang / GB200	4×4 GPU	公开部署矩阵中的参考拓扑
SGLang / H200	常见公开单元为 2×8 GPU；High-Throughput 配方可扩至 4×8	需结合 TP/EP 和跨节点网络验证
SGLang / H100	4×8 GPU	公开配方采用多节点 TP/EP 路线
SGLang / MI350X、MI355X	1×8 GPU	ROCm/AITER 路线
TokenSpeed / NVIDIA	公开示例为 8×B300	示例采用 TP8，并给出专家并行路径
TokenSpeed / AMD	公开示例为 8×gfx950 平台 GPU	示例给出 TP8/EP8 与 AMD 专用后端配置

SGLang 当前页面还明确说明，其部署单元仍需在最终权重和当前代码上重新测量吞吐与准确性。企业在采购前更适合把这些公开拓扑作为“可验证起点”，再根据自己的服务目标形成最终配置。

Kimi K3运行时显存应该怎么拆

完整权重推理的显存规划可以拆成以下部分：

集群可用显存 = 权重驻留 + 框架工作区 + 通信缓冲 + 图执行空间 + 缓存/状态 + 安全余量

权重驻留：模型分片后的专家、稠密层、视觉编码器和相关参数；
框架工作区：算子执行、临时张量、内存管理和运行时所需空间；
通信缓冲：张量并行、专家并行以及跨节点通信使用的显存；
图执行空间：CUDA Graph 或其他执行优化可能预留的空间；
缓存与状态：MLA KV、KDA recurrent state、推理历史以及多模态中间结果；
安全余量：为内存碎片、请求波动和软件版本差异保留的空间。

这也是为什么 1.56 TB 权重仓库只能作为容量规划的起点。真实运行资源要以目标框架加载后的显存分布和实际业务请求为准。

KDA状态池与MLA KV池为什么需要单独看

Kimi K3 使用 69 层 KDA 与 24 层 Gated MLA。以 SGLang 当前 K3 Cookbook 为例，其静态内存模型会在 KDA state pool 与分页 MLA KV pool 之间进行分配，并通过 --mamba-full-memory-ratio 调整比例。

KDA state pool 直接关系到同时可以接纳的请求数量；
MLA KV pool 主要关系到可保存的 token 容量；
平均请求长度、KV 精度、KDA state 精度、缓存策略和推测解码都会改变两类内存的占用；
SGLang 当前文档指出，DCP 可以分片 TP 复制的 MLA KV，但 KDA state pool 的容量边界仍需单独处理。

因此，Kimi K3 的长上下文和并发规划不适合直接套用传统 Transformer 的单一 KV Cache 估算。PoC 时应读取目标框架实际报告的可用 token 数、请求接纳上限和显存峰值。

1M上下文应该怎么进入服务器规划

1,048,576 tokens 是模型支持的最大上下文窗口，不代表企业日常请求都应按照 1M 运行。对于代码库分析、长文档、Agent 历史和多模态任务，上下文增长通常会同时增加 Prefill 计算、缓存/状态占用和端到端时延。

更有参考价值的做法，是先统计业务请求的：

典型输入长度；
P95 输入长度；
最大输入长度；
典型与 P95 输出长度；
不同上下文区间对应的并发；
是否存在大量重复前缀、代码仓库或固定知识库上下文。

API 路线可以利用当前自动前缀缓存机制观察缓存命中率；自托管路线则要分别测量短上下文、高并发与长上下文、低并发场景。最终容量规划应覆盖真实流量结构，而不仅是一次能够成功运行的 1M 请求。

AI服务器与GPU集群还需要规划哪些资源

GPU与节点内互连

GPU 选型需要同时确认可用显存、显存带宽、低精度计算路径、模型算子支持以及设备间互连。Kimi K3 使用 MXFP4 权重与 MXFP8 激活；目标 GPU 支持某种低精度数据类型，只能说明具备硬件基础，真正能否高效执行还取决于框架和内核实现。

节点内还要确认 PCIe、NVLink/NVSwitch 或 AMD 对应互连拓扑与目标 TP、EP、PP 等并行策略是否匹配。

CPU与系统内存

CPU 和系统内存需要承担模型加载、分词、图像/视频预处理、请求调度、网络通信管理、服务网关，以及 RAG 检索、文档解析、代码沙箱和 Agent 工具等工作。

如果使用 CPU offload、分层缓存或主机侧数据预处理，系统内存容量和主机带宽还会进入推理关键路径。CPU 核数和内存容量应结合框架加载方式、预处理并发和完整应用链路测试。

NVMe、模型分发与版本空间

官方仓库当前约 1.56 TB。除当前模型文件外，实际环境还要为下载缓存、容器镜像、编译/框架缓存、日志、临时文件以及必要的灰度或回滚版本留出空间。

多节点集群还应确定共享存储、节点本地 NVMe 或模型仓库分发策略，并实际测试首次下载、分片校验、并行加载、节点扩容和版本切换时间。

多节点网络

MoE 专家分布到不同设备后可能产生高频 all-to-all 通信。跨节点部署需要同时核验：

RDMA 能力及实际启用状态；
InfiniBand 或 RoCE 网络的实际设计与有效带宽；
交换机、网卡、线缆、固件和驱动版本；
NUMA、PCIe 与 GPU/NIC 亲和性；
NCCL/RCCL、UCX 等通信组件与推理框架版本；
目标 TP/EP/PP/DCP 拓扑下的扩展效率与尾延迟。

软件版本与可运维性

生产环境应固定模型 commit、容器镜像、驱动、推理框架、通信库、推理/工具调用解析器和缓存策略，并建立监控、日志、限流、灰度、回滚与故障恢复流程。

K3 的 preserved thinking 还意味着应用层需要正确保存和回传多轮 assistant message。模型服务已经启动，并不代表 Agent 协议链路已经完成生产验证。

Coding与Agent场景为什么还要单独规划执行环境

Kimi K3 面向长程 Coding 和 Agentic Knowledge Work 等场景。生产系统通常可以拆成两个资源面：

模型推理面：GPU、推理框架、模型服务、缓存、调度和网络；
Agent执行面：CPU、系统内存、NVMe、代码仓库、容器/沙箱、依赖缓存、数据库、搜索/RAG、浏览器或工具服务、权限控制与日志。

当多个 Agent 同时检索代码、运行测试、启动容器、解析文件或调用外部工具时，CPU 进程、内存、文件 I/O 和工具并发会显著增加。服务器和集群规划应覆盖完整工作流，而不是只统计模型显存。

API与自托管成本应该怎么放到同一张表里

两条路线的成本结构不同，直接比较“API 每百万 Token 价格”和“GPU 采购价格”并不能回答企业真正的成本问题。

成本维度	API	自托管
模型推理	缓存命中输入、普通输入、输出 Token	GPU 服务器或租赁资源、利用率
容量	RPM、TPM、并发与平台配额	GPU、CPU、内存、网络、存储与冗余
工程	应用接入、日志、工具链和数据治理	模型部署、框架适配、集群运维、升级与监控
可靠性	平台 SLA、应用侧超时和重试	高可用、故障恢复、备件、灰度与回滚

更适合决策的指标是“每个有效完成任务的综合成本”。同一批任务同时记录完成质量、总耗时、人工接管次数、Token 消耗、API 费用或本地资源成本，才能得到可比较的数据。

企业PoC可以怎么推进

PoC 更适合作为一个验证流程，而不是固定为“一周”“几天”或某个统一周期。任务复杂度、数据准备、硬件到位情况和现有软件环境不同，所需时间会有明显差异。

阶段	重点动作	形成的结果
阶段1：任务与验收基线	选择真实的 Coding、长文档、视觉理解、知识检索或多工具 Agent 任务；定义正确性、完成率、时延和人工接管等指标	统一任务集与验收口径
阶段2：API业务验证	测试不同 reasoning_effort、上下文长度、工具调用与缓存命中情况，记录质量、Token、时延和费用	业务效果与真实负载基线
阶段3：自托管技术验证	在目标框架和硬件上验证加载、功能、显存、TTFT、TPOT/ITL、吞吐、并发、长上下文和稳定性	目标环境的资源边界与框架适配结果
阶段4：生产路线与容量规划	结合数据边界、负载、成本和服务目标决定 API、自托管或混合路线，并完成扩容、监控、回滚和容灾设计	可执行的生产架构与容量方案

如果项目需要快速起步，可以先从几十个具有代表性的真实任务构成最小样本，再随着业务类型扩展任务集；这里的“几十个”只是便于启动的示例，并不是统一验收标准。

生产上线前建议保留哪些验证指标

指标	说明	主要影响因素
模型加载时间	从启动到可以稳定接收请求	存储、网络、分片、框架和并行加载
TTFT	请求到首个输出 token 的时间	Prefill、排队、上下文长度和调度
TPOT / ITL	连续输出 token 之间的时间	Decode、Batch、算子与通信
系统吞吐	单位时间处理的 token 或完成请求	GPU、并行策略、Batch 与请求分布
并发容量	在目标时延下可稳定承载的请求数量	显存、KDA state、MLA KV、调度和上下文
P95/P99尾延迟	高分位请求的端到端时延	排队、跨节点通信、长请求和异常流量
功能正确性	文本、视觉、推理、工具调用与结构化输出是否符合预期	模型、框架、解析器、应用协议和提示词
稳定性与错误率	持续运行中的错误、超时、OOM和资源漂移	内存碎片、异常请求、软件版本和队列
故障恢复	节点、进程或服务异常后的恢复能力	编排、路由、健康检查、冗余和模型重载

任何性能数字都应同时记录模型 commit、框架/容器版本、驱动、GPU 拓扑、请求长度分布、输出长度、并发模型与测试持续时间。脱离条件的单一 TPS 或 tokens/s 数字不适合作为采购依据。

Kimi K3 License需要关注哪些使用边界

Kimi K3 的代码仓库和模型权重采用 Kimi K3 License。许可证赋予使用、复制、修改、发布、分发、再许可、销售、运行、部署和微调等权利，同时包含以下与企业使用直接相关的条件：

如果被许可方或其关联方经营许可证定义的 Model as a Service 业务，并且合计收入在任意连续 12 个月内超过 2000 万美元，在将该软件或其衍生作品用于商业目的前，需要与 Moonshot AI 签订单独协议；
如果使用该软件或其衍生作品的商业产品/服务月活超过 1 亿，或月收入超过 2000 万美元，需要在该产品或服务界面显著展示“Kimi K3”；
许可证第 2、3 条的上述要求不适用于其定义的内部使用，以及通过 Moonshot AI 官方产品或认证推理合作伙伴访问模型的情形。

以上仅用于帮助部署团队识别需要核对的许可条件，不替代许可证原文。实际项目在确定交付方式和对外服务模式时，应以当时最新的 Kimi K3 License 为准。

进入服务器与集群规划前，建议先确认这10项信息

使用官方 API、完整官方权重，还是其他有明确来源的衍生版本？
目标是研发验证、内部生产，还是向外部用户提供服务？
数据是否需要本地处理，日志、审计和数据驻留有哪些要求？
典型、P95 与最大输入上下文分别是多少，输出长度如何分布？
平均并发、峰值并发、日请求量和队列策略是什么？
TTFT、TPOT/ITL、P95/P99 延迟、吞吐和可用性目标是什么？
是否需要图像/视频输入、结构化输出、工具调用和长程 Agent？
现有 GPU、CPU、内存、NVMe、节点内互连和跨节点网络条件如何？
目标推理框架、容器、驱动和通信库是否已有已验证版本组合？
是否需要多版本共存、灰度、快速回滚，以及对 Kimi K3 License 哪些条款进行项目级确认？

赋创可以围绕Kimi K3部署提供哪些支持

赋创可根据模型版本、权重格式、目标任务、上下文分布、并发与时延目标，以及客户现有机房和网络条件，协助完成 API PoC、自托管模型与推理框架适配验证、AI 服务器与 GPU 集群规划、网络与存储设计、Agent 运行环境配置，以及后续私有化部署与交付验收。

对于 Kimi K3 这类超大规模 MoE 模型，方案会以官方模型资料、当前框架支持状态和目标环境实测为依据，再确定服务器数量、GPU 拓扑、网络和扩展路径，避免仅依据总参数或单一公开配方直接换算生产配置。

FAQ｜Kimi K3企业部署常见问题

Kimi K3可以按104B模型估算部署资源吗？

不建议。104B 是激活参数规模，可辅助理解每个 token 经过稀疏专家路径时的计算规模，但完整 2.8T 参数权重仍需保持可访问。自托管容量还要考虑约 1.56 TB 官方仓库、运行时工作区、通信缓冲、KDA 状态、MLA KV 缓存和安全余量。

Kimi K3自托管至少需要多少张GPU？

没有脱离 GPU 型号、框架版本、并行方式、上下文、并发和服务目标的统一最低卡数。当前 vLLM 和 SGLang 已公开多种 GPU 参考路径，但它们是对应框架和软件版本下的部署配方。企业采购前应在目标环境中验证资源与性能边界。

Kimi K3支持1M上下文，是否需要所有请求都按1M规划？

不需要。1,048,576 tokens 是最大上下文窗口。真实规划应先获得典型、P95 和最大上下文及并发分布，再分别测量 Prefill、KDA state、MLA KV、TTFT 与吞吐。

Kimi K3应该选择vLLM、SGLang还是TokenSpeed？

三者均在 Moonshot AI 官方推荐列表中。当前 vLLM 专用 K3 配方仍标注 Pre-release，SGLang K3 页面也提示最终服务验证仍在进行。框架选择应结合目标 GPU、所需功能、可维护版本与同条件实测结果。

Kimi K3 API当前如何计费？

截至 2026 年 8 月 5 日，Kimi API 开放平台公开价格为：缓存命中输入 ¥2 / MTok、普通输入 ¥20 / MTok、输出 ¥100 / MTok。价格具有时效性，正式成本核算以项目实施时官方价格为准。

Kimi K3的思考模式可以关闭吗？

当前官方文档说明 K3 始终进行推理，不支持通过 thinking 参数关闭。可以通过顶层 reasoning_effort 设置 low、high 或 max，默认 max。多轮对话和工具调用应原样回传完整 assistant message。

Kimi K3开放权重后可以直接用于商业项目吗？

Kimi K3 License 提供较广泛的使用、部署、微调和衍生作品权利，同时对达到特定规模的 Model as a Service 业务和大型商业产品设置附加条件，并规定内部使用等例外。项目上线前应按实际业务模式核对最新许可证原文。

企业应该先用API还是直接做自托管？

业务效果、上下文和调用量尚未形成真实数据时，可以先用 API 建立任务基线；有明确的数据边界、环境控制或长期自托管要求时，可进入开放权重 PoC。两条路线最终都应使用同一批真实任务比较质量、时延、稳定性与单任务成本。

方案咨询

需要把方案落到实际配置？

联系赋创获取算力、软件栈和交付路径建议。

咨询方案浏览指南