野生码农
12:30 派了个简单任务,5 分钟后额度没了
事情发生在今天中午。12:30 左右,我派了一个看起来很简单的任务:把一批技能文件批量过一遍,提取里面的工作流。然后我发现 Kimi Code 的额度在刷刷往下掉。
我的第一反应是自己停:
- 关掉 Kimi Code 终端——没用,进程还在跑;
- 打开任务管理器杀进程——杀掉,又自动重启,再杀再起,跟病毒一样;
- 没办法,重新打开 Kimi Code,让军师(AI 助手)自己去停——这才停住。
停住的时候查额度(官方 usages API 直查工具):
300分钟窗口: 已用 87/100(87%),重置 10-07 17:01
周额度: 已用 71/100(71%);时间已过 16% vs 额度已用 71%,超前 55 个百分点
注意这个读数的时间含义:窗口 12:01 重置,任务 12:27 起跑,起跑约 4 分钟就冲到 87%,5 分钟整打满 100%(本人口径;87/100 为 12:34 实测读数,打满发生在停手前后)。我用的是 699 档会员(本人口径),这个窗口一满,下午什么都干不了。更窝火的是:早上它已经悄悄烧完过一个 5 小时窗口,我没注意;中午我只是让 AI 检查一下状态,它就续跑起来了——停都停不掉,一松手就自己跑。
军师接手:杀掉一批,又起来一批
军师先拉进程列表:5 个无头 kimi.exe 在跑,启动时间 12:33:08 到 12:33:37,间隔不到 30 秒【实测:ps -W + PowerShell Win32_Process】。命令行全是同一个形态:
kimi.exe -m kimi-code/kimi-for-coding-highspeed -p "你是工作流提取器……源文件全文约 46890 字符……"
每条都拖着一个几万字符的源文件全文,用 highspeed 档位模型做"技能文件工作流提取"。5 路并发,目标目录 D:\code\系统安全\skills\ 下共 798 个技能文件【实测:ls | wc -l】。
军师把 5 个 kimi.exe 杀完,2 秒后一看:又起来 5 个(12:33:45 到 12:33:50)——和我在任务管理器里遇到的是同一个现象。原因很快查明:有父进程在循环拉起子进程,只杀子进程等于挠痒。用 PowerShell 顺着 ParentProcessId 摸上去:
Get-CimInstance Win32_Process -Filter "Name='kimi.exe'" |
Where-Object { $_.CommandLine -like '*highspeed*' }
# → ParentPid 14832, python.exe
# → D:\code\thinking\.venv\Scripts\python.exe extract_workflow.py --batch --workers 5
正主是 extract_workflow.py,一个灌库脚本:读技能文件→拼 prompt→调 kimi CLI→解析 JSON→写 MySQL。先杀父进程 14832,再清残余子进程,世界才清净。
批量任务杀进程的顺序铁律:先杀父,再杀子。这就是它"跟病毒一样"的全部机理——不是什么灵异事件,是一个 while 循环。
查库才发现:上午已经空转过一轮
脚本有灌库记录,把 asset_workflow 表拉出来看,完整时间线是这样的【实测:MySQL 直查】:
| 批次 | 结果 | 件数 | 时间窗 |
|---|---|---|---|
| 凌晨 pilot | ok | 3 | 00:12~00:17 |
| 上午 batch1 | ok | 57 | 10:18 起 |
| 上午 batch1 | unstructured | 2 | 10:28 |
| 上午 batch1 | failed | 745 | 10:32~10:45 |
| 中午 batch2(被杀) | ok / unstructured / failed | 105 / 5 / 13 | 12:27~12:34 |
上午 batch1 对 804 条资产发起调用,745 条失败,集中在 13 分钟内——这就是我"没注意"时被烧掉的那个 5 小时窗口。失败原因抽三条看,清一色:
G0 FAIL: kimi 退出码 1
退出码 1 说明 CLI 调用直接被拒(额度/限流类),秒返回。而脚本的逻辑是:失败→记库→取下一条继续。失败调用返回得越快,循环空转得越快,请求打得越密——越失败越烧钱,标准的无熔断空转。
中午 batch2 的起跑也印证了"检查状态就续跑":批次时间戳 12:26:57,正是我让 AI 看状态的前后。上午烧穿一个窗口,中午 5 分钟再把新窗口烧穿,我看到的就是这最后一幕。
事后翻文档:上一代模型反而更贵
投诉之前我翻了官方文档,发现一个更让人上火的事实:我用的 K2.7 Code Highspeed 是上一代模型,额度消耗倍率却比最新的 K3 还高(官方套餐页口径:约 3 倍,本人口述;官方英文文档可核实的只有 k3 1M 上下文 ≈ 2 倍 k3-256k,highspeed 的具体倍率在公开文档页查不到)。直觉上"上一代、弱一些的模型应该便宜",这里正好反过来。
再算一笔账:highspeed 标称输出上限 260 tokens/s,5 分钟 × 5 路并发,输出侧满打满算约 39 万 tokens。就算把每条约 4.7 万字符的输入 prompt 全算上,额度单位和 token 之间的折算官方从未公开——"5 小时额度"到底是多少 token,用户无从而知。不透明本身,就是这类事故的第二层根因:你没法在开跑前把任务折算成预算。
根因不是模型贵,是批量任务没有成本闸门
定价倍率是平台的事,我管不了;我能管的是自己这边的三个叠加漏洞:
- 无熔断:连续 745 次失败,脚本不停。哪怕加一句"连续失败 10 次即退出",上午那轮最多烧 10 条的额度;
- 无预算:798 件 × 单件数万字符 prompt × 高倍率模型,开跑前没人算过总量和窗口限额的关系;
- 并发放大:5 路 workers 把烧穿速度 ×5,发现异常时已经来不及。
教训一句话:批量调 LLM,失败不是免费的——失败调用照样走 API、照样计额度,而且失败得越快,下一轮请求来得越快。
处置:模型档位全机下线
我拍板:K2.7 Code Highspeed 的所有设置全部取消。执行清单:
| 位置 | 动作 |
|---|---|
~/.kimi-code/config.toml |
删除 kimi-for-coding-highspeed 模型定义,CLI 层面此模型不再存在 |
| thinking / yiren 两份团队章程 + 任务卡模板 | 删除 highspeed 档位;批量任务口径改为"先改脚本方案,不派 LLM" |
extract_workflow.py |
MODEL 改回 kimi-code/k3-256k |
| 变更台账 + config_lint 机器闸 | 落账一条,lint 退出码 0【实测】 |
批量提取这个需求本身没死,但重启的前提是脚本先长出熔断和预算,否则不批。
结局:投诉之后,额度重置了
我走了官方反馈渠道投诉,核心四点:额度消耗不透明、上一代模型倍率反而更高、进程停不掉、反馈流程扯皮。官方最终不情不愿地重置了额度。当晚实测确认【18:32 kimi_quota_check.py 直查】:
周额度: 已用 6/100(6%),剩 94 ← 烧穿前是 71/100
300分钟窗口: 已用 30/100(30%),重置 22:01 ← 烧穿时是 87/100 并打满
额度回来了,教训留下了:平台的账我算不了,自己侧的成本闸门必须自己建。
可抄走的四条纪律
- 开跑前算额度账:总件数 × 单件 token 估算 × 模型倍率,对比当前窗口余量;装不下就分批,写进脚本参数,不靠自觉;
- 熔断写进循环:
连续失败 ≥10 次 → 退出并报警,失败计数清零条件=一次成功;这一条值 745 次调用的钱; - 杀批量任务先杀父:找到 ParentProcessId 再动手,只杀子进程会被无限续命——关终端、任务管理器都拦不住一个有父进程循环的批量脚本;
- 额度监控命令化:别等平台账单,用官方 usages API 写个一条命令直查的脚本,会话开场自检必跑。
素材点
- 798 个技能文件、5 路并发、起跑 4 分钟 87% / 5 分钟打满:批量 LLM 任务成本失控的完整实证样本;
- "关终端停不掉、任务管理器杀了自动重启、跟病毒一样"的用户亲历,机理=父进程 while 循环;
- "失败反而提速"的无熔断空转机制,配
退出码 1灌库记录(745 条); - 上一代模型(K2.7 Highspeed)计费倍率高于最新 K3 的定价反直觉点,附 260 tokens/s × 5 分钟 × 5 路的账;
- 投诉后官方重置额度,实测读数前后对照(71/100 → 6/100);
- 模型档位从章程/模板/CLI 配置三层下线的治理动作。