关终端、杀进程,都停不住它
批量调 Kimi Code 之所以几分钟就烧穿限额,根因不在模型贵:脚本没有熔断(连续失败到阈值就自动停的机制),失败调用照样计费,开跑前没算额度账,并发又把烧钱速度翻了几倍。
10 月 7 日中午 12 点半,我派了个看起来简单的活:把 798 个技能文件批量过一遍,提取里面的工作流。Kimi Code 是我日常用的 AI 编程命令行工具,额度按 300 分钟窗口加周额度双闸门算。任务 12:27 起跑,几分钟后,我眼睁睁看着额度往下刷。
我的第一反应是自己停。关掉终端,进程还在跑;打开任务管理器杀进程,杀掉又自动重启,再杀再起,跟病毒一样。没辙,重新打开 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 档会员,这个窗口一满,下午什么都干不了。
更窝火的是后面查出来的事:当天上午,它已经悄悄烧完过一个同样的窗口,我毫无察觉;中午我只是让 AI 检查了一下状态,它就自己续跑上了。一松手就跑,停都停不住。
杀掉 5 个,2 秒后又起 5 个
军师先拉进程列表:5 个无头 kimi.exe 在跑,启动时间 12:33:08 到 12:33:37,间隔不到 30 秒。命令行全是同一个形态:
kimi.exe -m kimi-code/kimi-for-coding-highspeed -p "你是工作流提取器……源文件全文约 46890 字符……"
每条进程都拖着一个几万字符的源文件全文,用 highspeed 档位模型做工作流提取。5 路并发,目标目录下共 798 个技能文件。
军师把 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 Code CLI、解析返回的 JSON、写进 MySQL。先杀父进程 14832,再清残余子进程,世界才清净。
批量任务杀进程的顺序铁律:先杀父,再杀子。所谓"跟病毒一样",不是灵异事件,是一个 while 循环。
真正的窟窿,上午就烧通过一次
进程停了,账还没算完。脚本有灌库记录,我把 asset_workflow 表拉出来,完整时间线全了:
| 批次 | 结果 | 件数 | 时间窗 |
|---|---|---|---|
| 凌晨 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 分钟内。这就是我"没注意"的时候被烧掉的那个窗口。
失败原因抽三条看,清一色:
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 里删掉这个模型定义,CLI 层面它不再存在;两份团队章程和任务卡模板同步删除 highspeed 档位,批量任务口径改成"先改脚本方案,不派 LLM";extract_workflow.py 的模型改回 k3-256k;变更落台账,config_lint 机器闸退出码 0。批量提取这个需求没死,但脚本先长出熔断和预算,否则不重启。
投诉也走了官方反馈渠道,核心四点:额度消耗不透明、上一代模型倍率反而更高、进程停不掉、反馈流程扯皮。官方不情不愿地重置了额度。当晚 18:32 实测:
周额度: 已用 6/100(6%),剩 94 ← 烧穿前是 71/100
300分钟窗口: 已用 30/100(30%),重置 22:01 ← 烧穿时是 87/100 并打满
额度回来了,教训留下了:平台的账我算不了,自己侧的成本闸门必须自己建。
四条纪律,你的批量任务直接用
这四条成本闸门纪律,是我用两个窗口的额度换的,熔断是其中最值钱的一条,你批量调 LLM 之前可以直接搬走。
- 开跑前算额度账。总件数乘单件 token 估算乘模型倍率,对比当前窗口余量;装不下就分批,写进脚本参数,不靠自觉。
- 熔断写进循环。连续失败 10 次就退出并报警,失败计数清零的条件是一次成功。这一条值 745 次调用的钱。
- 杀批量任务先杀父。找到 ParentProcessId 再动手,只杀子进程会被无限续命。关终端、任务管理器,都拦不住一个有父进程循环的批量脚本。
- 额度监控命令化。别等平台账单,用官方 usages API 写个一条命令直查的脚本,会话开场自检必跑。
对企业读者换算一笔账:把 LLM 调用接进任何批量流水线,数据清洗、标注、灌库都一样,无熔断就意味着失败流量按全价计费还自动加速。我这个样本是 745 次失败调用、13 分钟烧穿一个窗口;换成公司按量付费的 API,13 分钟就是一笔直接蒸发的预算,而加一道熔断判断只要几行代码。
FAQ
Q:怎么给现有批量脚本加熔断?
A:在循环里放一个连续失败计数器,到阈值就退出并报警,一次成功就清零,我的阈值定 10 次。关键在"连续"两个字:偶发失败不该误杀,连续失败一定是系统性问题,继续跑只会按全价烧额度。
Q:无头进程杀不掉,怎么定位父进程?
A:Windows 上用 PowerShell 的 Get-CimInstance Win32_Process,按进程名和命令行关键词过滤,顺着 ParentProcessId 往上摸,找到循环拉起子进程的那个父进程,先杀父再清残余。只杀子进程,几秒钟它就给你续上一批。
Q:官方不公开额度折算,额度账怎么算?
A:算个保守上限就够做决策:输出侧按标称速率乘并发乘时间估,输入侧按 prompt 字符数估,算出来对比当前窗口余量,装不下就分批。折算不透明恰恰说明,预算这道闸门只能建在自己脚本里。
Q:highspeed 比 K3 贵 3 倍,这个数据哪来的?
A:官方套餐页口径,我口述引用;公开英文文档能核实的只有 k3 的 1M 上下文版本约 2 倍于 k3-256k,highspeed 的具体倍率查不到。这也是我投诉"额度消耗不透明"的原因之一。
我是野生码农,AI实战派。17年全栈工程师,一人AI公司实践者。打造个人IP内容体系、软件全链路产品产线,拥有百套企业AI方案、200多个岗位Agent;自研知识库、AI数字员工系统,公开实战复盘。
本文所有内容均为本人 AI 实战的过程和结果,经 AI 整理后发布,无任何瞎编虚构内容。
这篇来自《数字员工养成记》系列。
关注我,看真的。
野生码农AI实战 · 全网同名
