---
title: "Kimi K3 API 价格与缓存写入费：5 分钟还是 1 小时 TTL，moonshot-v1 返回 404 怎么办"
description: "整理 Kimi K3 API 价格（输出 ¥100/百万 token）、缓存写入费和 TTL 怎么选，并给出 kimi-k2.5、moonshot-v1 下线后返回 404 的排查步骤与文件接口检查清单。"
url: https://cdnping.org/blog/kimi-k3-api-pricing-cache-and-legacy-404
language: zh-CN
published: 2026-10-19
category: "排障指南"
tags: ["Kimi","K3","API 计费","缓存","排障"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# Kimi K3 API 价格与缓存写入费：5 分钟还是 1 小时 TTL，moonshot-v1 返回 404 怎么办

Kimi K3 API 价格按每百万 token 计：缓存命中输入 ¥2，未命中输入 ¥20，输出 ¥100，上下文 1,048,576 tokens；另外多了一项缓存写入费，5 分钟 TTL 为 ¥20，1 小时 TTL 为 ¥40。如果你的老项目最近突然返回 404，多半是用了已下线的 kimi-k2.5 或 moonshot-v1 系列，需要迁移到 K3 或其他在售模型。

以下内容截至 2026 年 10 月，依据 Kimi 开放平台的[定价页](https://platform.kimi.com/docs/pricing/chat)和[更新日志](https://platform.kimi.com/docs/changelog)。价格可能调整，下单前请再看一遍官方页面。

## K3 的价格到底怎么算？

定价页给出的 kimi-k3 价格（单位：每百万 token）：

| 项目 | 价格 |
|---|---|
| 输入，缓存命中 | ¥2.00 |
| 输入，缓存未命中 | ¥20.00 |
| 输出 | ¥100.00 |
| 缓存写入，TTL 5 分钟 | ¥20.00 |
| 缓存写入，TTL 1 小时 | ¥40.00 |

同一页还列了几个价格更低的选项，上下文都是 262,144 tokens，页面没有为它们列缓存写入费和 TTL 档位：

| 模型 | 缓存命中 | 未命中 | 输出 |
|---|---|---|---|
| kimi-k2.7-code | ¥1.30 | ¥6.50 | ¥27.00 |
| kimi-k2.7-code-highspeed | ¥2.60 | ¥13.00 | ¥54.00 |
| kimi-k2.6 | ¥1.10 | ¥6.50 | ¥27.00 |

选哪个取决于任务：需要百万级上下文或更强能力才值得上 K3，日常代码类任务可以先在便宜的型号上跑一遍，再比较结果。

## 缓存写入费是什么，TTL 怎么选？

按定价页的说明，缓存分 5 分钟和 1 小时两档，不指定时默认 5 分钟。在有效期内命中，只按缓存命中价计费；命中会自动续期，不会再收一次写入费。具体怎么在请求里指定 TTL，以官方文档为准。

选择的关键是你的请求间隔。下面是一个假设的例子，只用来演示算法：一段 10 万 token 的固定前缀，连续调用 20 次，只计这段前缀的输入费用，并假设首次请求只收写入费、不再额外按未命中计费（实际以账单为准）。

| 场景 | 5 分钟 TTL | 1 小时 TTL | 不用缓存 |
|---|---|---|---|
| 每 2 分钟调用一次 | 写入 ¥2 + 19 次命中 ¥3.8 = ¥5.8 | ¥4 + ¥3.8 = ¥7.8 | 20 × ¥2 = ¥40 |
| 每 10 分钟调用一次 | 每次都过期重写，约 20 × ¥2 = ¥40 | ¥4 + ¥3.8 = ¥7.8 | ¥40 |

结论很直接：请求密集、间隔不到 5 分钟，用 5 分钟档更省；间隔拉长到 5 分钟以上又在 1 小时之内，1 小时档更划算；前缀每次都变，缓存就没有意义，写入费反而是多出来的成本。上线后建议用一周的真实账单校准这些假设，核对方法见《[API 计费不对怎么查](/blog/relay-billing-token-mismatch)》。

## 调用返回 404，怎么判断是模型下线还是服务故障？

更新日志在 2026 年 8 月写明：kimi-k2.5 和 moonshot-v1 全系列（包括 vision-preview 和 moonshot-v1-auto）在所有国内外平台下线，之后调用返回 404，官方建议迁移到 K3。日志只写了月份，没有具体日期。

排查可以按这个顺序：

1. 先看请求里的 model 字段。是 kimi-k2.5 或 moonshot-v1-* 的，就是已下线，不是网络问题。
2. 换成 kimi-k3 或表中其他在售模型，同一个 Key 再请求一次。成功就说明是下线。
3. 仍然失败，再看是不是故障：打开 [/down/kimi](/down/kimi) 和 [/status/moonshot](/status/moonshot)，对照官方状态与 cdnping 的探测结果。
4. 状态正常但自己这里不通，再按《[ChatGPT 挂了吗？三步判断](/blog/is-chatgpt-down-or-my-network)》的思路分清是服务端还是本地网络，同样适用于 Kimi。

迁移时还要注意：K3 的价格和旧模型不同，换模型名之前先估一下月成本；输出单价是表中最高的一档。

## 文件接口变了什么，要检查什么？

同一份更新日志里，文件接口有这些变化：

- 新生成的文件 ID 统一带 `file_` 前缀。
- 表格、公式等复杂内容的解析有改进。
- 图片不再做 OCR 文字提取；要做图片理解，需用 `purpose=image` 上传。
- 同名文件上传时，服务端会自动重命名新文件。

对照检查清单：

- [ ] 代码里有没有按旧 ID 格式写正则或长度校验。
- [ ] 有没有用文件接口上传图片，再依赖 OCR 结果的流程；有的话改为 `purpose=image`。
- [ ] 有没有靠文件名唯一性去查找文件；同名会被重命名，改用返回的 ID。
- [ ] 解析结果有变化的表格和公式类文档，重跑一遍验收样例。

## 怎么不再被下线和调价打个措手不及？

模型下线和价格变动通常先出现在官方更新日志里。cdnping 的 [/changes](/changes) 会监控多家官方的更新日志和价格页，逐行记录增删并提供 RSS；整套追踪方法见《[大模型 API 价格变了怎么第一时间知道](/blog/track-llm-price-and-model-changes)》。Kimi 开放平台近期的其他改动，可以看《[Kimi 开放平台 9 月更新](/blog/kimi-platform-september-2026-updates)》。如果在考虑官方直连之外的接入方式，《[AI API 接入方式怎么选](/blog/official-api-vs-cloud-vs-gateway)》有对照。

## 参考来源

- [Kimi 开放平台：Chat 定价](https://platform.kimi.com/docs/pricing/chat)
- [Kimi 开放平台：更新日志](https://platform.kimi.com/docs/changelog)