Kimi K3 用 API 还是自部署？开源权重与迁移决策

多数团队不会在 Kimi K3 发布当天讨论自部署。真正的问题通常出现在更晚一点：API 已经接通，用量慢慢涨起来，有人看到权重可以下载，于是问了一句——“既然每天都在用，我们还要继续按 token 付费吗？”听起来只是 API 和自部署二选一，实际上要同时回答三件事：K3 到底适不适合这项业务、用量是否稳定、团队有没有能力长期维护一个超大模型。

先别谈买卡，看看 API 账单是怎么长出来的

月之暗面公布的缓存未命中价格，是一个干净的计算起点：输入 $3、输出 $15/百万 tokens。命中缓存后，输入降到 $0.30；输出价格不变。

调用方式	输入 / 百万 tokens	输出 / 百万 tokens	我们如何处理
Kimi 官方 API——缓存未命中	$3.00	$15.00	官方价格基线
Kimi 官方 API——缓存命中	$0.30	$15.00	官方输入缓存折扣
第三方渠道记录	查看实时详情页	查看实时详情页	按来源与核对状态分层显示

最后一行很重要。一个平台可以先放出模型名称，但它的实际路由、计费单位和返回 Model ID 未必已经独立核对。Kimi K3 比价页因此把官方、渠道和未核对记录分开显示，而不是把每个宣传入口都写成确定报价。

真正容易把账单拉高的，是输出

缓存未命中时，月成本很好算：输入 tokens ÷ 100 万 × $3，再加上输出 tokens ÷ 100 万 × $15。下面不是流量预测，只是让人直观看到，同一个模型怎样从一次便宜试验变成一笔正式预算。

月负载	缓存未命中成本	输入全部命中缓存	我们会重点观察什么
1000 万输入 + 200 万输出	$60	$33	答案是否真的被业务接受
1 亿输入 + 2000 万输出	$600	$330	缓存比例和不必要的冗长输出
10 亿输入 + 2 亿输出	$6,000	$3,300	并发、重试和渠道容灾

Artificial Analysis 的评测记录显示，K3 在 Intelligence Index 测试中生成了约 1.3 亿输出 tokens，高于同类中位数。这不能直接证明 K3 在所有场景都“话多”，但足以提醒我们：只看输入单价会低估总成本。一个模型如果输出更长、重试更多、额外调用工具，纸面上的价格优势很容易被吃掉。

K3 不是分数第一，但它的位置很有意思

在本文采用的带日期外部快照里，K3 与前沿模型的距离不大，官方 token 价格却更低。这个位置，比简单喊“第一名”更值得研究。

模型	外部 Intelligence Index	官方输入 / 输出价	为什么值得放在一起比较
Kimi K3	57	$3 / $15	编码、Agent、知识工作、百万上下文
GPT-5.6 Sol	59	$5 / $30	追求通用前沿能力
Claude Fable 5	60	$10 / $50	高端长任务与成熟交互体验
GLM-5.2	51	查看当前渠道报价	成本更低的中文编码竞品
Kimi K2.7 Code	42	$0.95 / $4	更便宜的月之暗面编码主力

能力分数和价格来自不同数据源，我们没有把它们揉成一个虚构的“性价比总分”。真正有用的问题要窄得多：在你的代码库、Agent、研究或多模态任务里，K3 能不能比便宜模型少失败几次、少让人返工几次？

开放权重真正改变的，不是 API 价格

它让基础设施团队终于有真实东西可测。K3 完整权重已经通过月之暗面的 GitHub 和 Hugging Face 官方仓库发布，并采用自定义 Kimi K3 License。现在可以实际测检查点、推理框架和服务行为，不需要继续围绕“未来会开放”做预算。

但它不会自动让自部署更省钱。已发布检查点约 1.56TB，仍然需要互联完整的多卡拓扑、推理栈、存储、监控和维护人员。另一篇 Kimi K3 GPU 部署成本文章已经把卡数与当前租赁价格拆开计算；这里不再重复那些数字，因为迁移决策比“最少几张卡”更容易被忽略。

出现这三个信号，才值得认真做自部署 PoC

1. 用量已经稳定到可以测量。再便宜的理论小时价，遇到长期闲置的集群也会失去意义。
2. 除了价格，你还有别的理由。数据控制、自定义服务行为、稳定容量或深度运行时集成，能支撑单纯价差无法支撑的工程投入。
3. 这套系统有人负责。模型服务、网络、升级、监控、故障恢复，以及 Agent 的工具权限和安全边界，都必须有明确负责人。

对话状态也要单独测试。月之暗面提醒需要保留思考历史，中途切换模型可能让结果不稳定。因此迁移测试应该回放完整会话，而不是从两个端点各抽几条孤立提示词。

一条不容易后悔的迁移路径

我们不会先向 GPU 供应商询一个月的集群。更稳妥的顺序，是让每一步拿到的证据，决定是否值得花下一笔更大的钱：

1. 先通过 API 跑一组接近生产的真实任务，同时限制输出长度和工具权限。
2. 把成功任务成本与现用模型比较，算上重试、缓存命中、延迟和人工修正。
3. 如果隐私或运行时控制仍然重要，再短租几天接近厂商验证的拓扑，回放同一批任务。
4. 只有实测利用率证明集群会长期繁忙，才比较长期租赁与自购。

最后应该走哪条路？

如果 K3 对你的业务还是新模型，或者用量忽高忽低，API 能用更小的风险更快买到答案。如果 K3 已经承担稳定、高用量任务，而且数据控制或运行时所有权确实重要，那么完整权重已经让一次短期自部署 PoC 变得合理。

不要因为榜单分数、某一行最低单价，或者“权重开源”四个字直接做决定。把合格任务数量、输出长度、重试、缓存命中、工具失败、集群利用率和维护人员都算进去，答案通常会比“API 还是自部署”这句口号清楚得多。

这些事实从哪里核对

模型架构、官方定位、可用渠道、限制、API ID、价格、权重和许可证来自月之暗面 Kimi K3 官方仓库、官方 Hugging Face 仓库与 Kimi API 平台；能力分数、速度、延迟、上下文和评测渠道来自 Artificial Analysis。ComputeUnion 把官方价、渠道价和市场数据分层展示；当前渠道记录与核对状态以实时比价页为准，不在文章里写死。