kimi-API踩坑记录

Kimi API 异常消费事件运维笔记

事件日期：2026-05-03 影响金额：¥929.93（已申诉成功，平台退回 ¥1000） 根因：Kimi 平台 Context Caching 计费 bug 文档创建：2026-05-06 状态：✅ 已解决，防御方案已制定

一、事件回顾

1.1 现象

• Context Caching 费用是模型推理费用的 71 倍

• 消费集中爆发于单日，非持续累积

• 账户余额由正转负（-¥15.34）

• 当月累计消费达 ¥1050.15

1.2 调用环境

• 调用方式：直接使用 requests / curl 调用原生 API

• 使用模型：kimi-k2.6

• API 端点：https://api.moonshot.cn/v1/chat/completions

• 代码中的 caching 调用：❌ 无（从未调用过任何 /v1/caching 接口）

二、根因分析

2.1 Kimi Context Caching 的两种模式

• 用户主动调用 /v1/caching 接口创建/管理 cache

• 三段式收费：创建费（¥24/M tokens）+ 存储费（按时间）+ 命中费（¥0.02/次）

• 公测期仅对 Tier3-Tier5 用户开放（累计充值 $3000+）

• 平台自动开启，无需配置

• 系统自动识别重复上下文前缀

• 命中后按输入价格的 16.9%~17.5% 计费（应是降本机制）

2.2 矛盾点

2.3 Moonshot 官方确认

三、申诉过程与成功要点

3.1 关键证据链

1. 代码证据：证明从未调用任何 caching 相关接口

2. 资格证据：累计充值未达 Tier5，无权使用显式 Context Caching

3. 比例证据：缓存费占比 98.6%，与模型推理费比例严重失衡

4. 官方文档证据：隐式缓存按官方说明应是降本机制

3.2 有效话术结构

3.3 申诉教训

• ✅ 基于事实：引用官方文档条款，而非情感诉求

• ✅ 数据说话：用比例、数字证明异常

• ✅ 态度专业：求"协助核查"而非"要求退款"，给对方台阶

• ✅ 保留证据：截图、代码、文档全部归档

四、防御方案（四层架构）

4.1 防御体系总览

4.2 第一层：平台用量限制

4.3 第二层：API Key 速率限制

4.4 第三层：监控脚本

4.5 第四层：代码层防御

五、监控脚本部署

5.1 监控原理

5.2 三级告警阈值

5.3 文件结构

5.4 部署步骤

5.5 配置文件模板

5.6 接入 Uptime Kuma（推荐）

1. Uptime Kuma 创建 Push 类型监控，超时设为 10 分钟

2. 在 kimi-monitor.sh 主逻辑结尾添加：

3. 脚本超过 10 分钟无 push，Uptime Kuma 会告警

六、应急响应流程

6.1 收到 Telegram 告警时

🟡 注意级别（5分钟下降 ¥5-20）

🟠 警告级别（5分钟下降 ¥20-50）

🔴 紧急级别（5分钟下降 > ¥50）

6.2 余额低告警

6.3 监控脚本失效告警（Uptime Kuma）

七、关键文档与链接

7.1 Kimi 官方文档

• 平台首页：https://platform.moonshot.cn/

• API 文档：https://platform.moonshot.cn/docs/

• 余额查询接口：https://platform.moonshot.cn/docs/api/balance

• 速率限制：https://platform.moonshot.cn/docs/pricing/limits

• Context Caching 介绍：https://platform.moonshot.cn/blog/posts/context-caching

• 定价说明：https://platform.moonshot.cn/docs/pricing/chat

7.2 申诉渠道

• 控制台工单：右上角"联系销售"

• 邮件：sales@moonshot.cn

• 12315 投诉（终极手段）

7.3 监控相关

• Telegram Bot API：https://core.telegram.org/bots/api

• MarkdownV2 转义规则：https://core.telegram.org/bots/api#markdownv2-style

八、经验总结

8.1 核心教训

1. 金额硬上限是终极防线：技术防御都可能失败，平台金额上限不会

2. 隐式机制最危险：用户无感知开启的功能，一旦计费 bug 就是巨坑

3. 公开账单的不对称性：用户只能看汇总，平台知道明细

4. 申诉要靠事实，不靠情感：基于官方文档条款的矛盾点最有力

5. 所有 LLM 平台的"用量限制"都要假设是软限制，除非官方明确承诺实时熔断

8.2 通用 LLM API 安全清单

8.3 防御深度（Defense in Depth）思想

九、变更记录