99 块实测 Kimi K3 API：账单长这样

先说结论：99 块钱按 Kimi K3 的 API 按量计费，能买到大约 99 万输出 token，或 495 万未命中缓存的输入 token。听着不少，但真拿它写一个中等复杂度的全栈项目，可能一个下午就要再看余额。

我做了八年接口平台，看到一个开源模型能在代码榜上超过 GPT-5.6 和 Claude 旗舰，还是忍不住充了 99 块。这篇文章把从充值到跑实测的完整账单摊开，供你选型前先算一笔明白账。

7 月 16 日，月之暗面放出 Kimi K3：2.8 万亿参数、100 万 token 上下文窗口、原生视觉理解，Frontend Code Arena 榜单 1679 分超过 Claude Fable 5 和 GPT-5.6 Sol。紧接着两条新闻把热度推高：7 月 27 日 K3 全链条开源（权重、技术报告、训练 Infra 全公开），当天登顶 Hugging Face 趋势榜；7 月 29 日完成 F 轮融资超 35 亿美元，投后估值涨至 350 亿美元。

对普通开发者来说，重点不是参数多大，而是「顶级能力 + 公开权重 + 比闭源旗舰便宜一半的 API 价格」第一次同时出现。所以我不只看新闻，直接充钱实测。

Kimi 开放平台对 OpenAI SDK 做了兼容。如果你接过快照生成类的 GPT 接口，迁移几乎零成本：第一步进 platform.moonshot.cn 注册并完成实名认证；第二步在控制台充值 99 元，到账余额 99.00 元，没有赠送也没有隐藏门槛；第三步新建 API Key，只在创建时完整显示一次；第四步把 baseURL 改成 Kimi 端点、换上 Kimi 的 Key。

from openai import OpenAI

client = OpenAI(
    api_key="sk-你的KimiKey",
    base_url="https://api.moonshot.cn/v1"
)

resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[{"role": "user", "content": "用 FastAPI + JWT 写带鉴权的 Todo 接口和单元测试"}]
)
print(resp.usage)  # 关注 prompt_tokens / completion_tokens / cached_tokens

跑通后重点看返回的 usage 字段，这三个数字就是后面算账的核心。从打开官网到第一次成功调用，15 分钟内搞定。

我设计了 6 个日常开发最常见的任务，每个都记录输入、输出和缓存命中：

官方定价：输入 20 元 / 百万 token（缓存未命中）、2 元 / 百万 token（缓存命中）、输出 100 元 / 百万 token。我按缓存命中 40% 保守估算，6 个任务总花费约 ¥7.99，99 块大概能跑十几轮。

参数大不等于账单小。K3 的 1M 上下文和 Agent 输出能力是把双刃剑，能做的事变多了，烧钱的口子也一起变大了。

但任务 6 这种 Agent 模式才是真烧钱口子：一个完整 CRUD 后台输出 4.5 万 token，成本 ¥4.73，一天跑 20 个类似任务就是 ¥94.6。掘金上那篇「榨干 99 块」的实测文能霸榜，是真有人一下午跑光额度。

只看 Kimi 自己的账单不够，得放到全球旗舰里比。2026 年 7 月底各家公开 API 定价如下：

同样一次「10 万输入 + 2 万输出、缓存命中 50%」的长上下文代码分析，K3 约 $2.93，Sol 约 $6.28，Opus 5 约 $5.28，Fable 5 约 $11.00。K3 成本只有 Sol 的一半不到、Fable 5 的四分之一。

但要提醒一个边界：K3 的缓存命中率和输出长度极大影响实际账单。每次都是全新长文档、没有上下文复用时，输入就要按 20 元 / 百万 token 算，成本优势会缩水。输出侧才是真正的烧钱大头，尤其是 thinking / Agent 模式。

K3 全量开源的意义，不只是「免费下载权重」。它让普通开发者第一次同时拿到三样东西：顶级能力、公开权重、比闭源旗舰便宜一半的 API 价格。

但模型选项变多，反而带来新问题——怎么接才划算？我的判断是，单一模型已经很难满足真实业务，不同模型在不同任务上的性价比差距很大：

• 日常对话、简单总结、客服问答 → 轻量或高性价比模型
• 复杂代码生成、长上下文分析、Agent 编排 → Kimi K3 或 Claude Opus 5
• 数学推理、OpenAI 生态深度集成 → GPT-5.6 Sol

大模型选型正在从「买品牌」变成「买菜」——哪种食材适合做哪道菜，比盯着一家米其林下单更重要。

最优策略不是 all in 一个，而是按任务路由、按量计费、随时可切换。对个人和小团队尤其重要，没有大厂那种固定年度预算，每一笔 API 支出都要算清楚。

我手头在用的做法，是把不同模型的调用封装成统一 API 接口，上层业务只传「任务类型」和「预算上限」，底层根据模型能力、当前价格、响应速度自动选最合适的。哪个模型涨价、限流或效果下降，只改配置，业务代码不动。

以我手头在用的 YesApi Pro 为例，它作为 API 低代码开发与接口开放平台，很适合做这种多模型路由层。你可以把 Kimi K3、GPT-5.6 Sol、Claude Opus 5 分别封装成独立接口，再在上层用一个统一 AI 调度接口根据 token 预估成本做选择，先算账再调用，让成本真正可预测。

具体分三步：

• 第一步，建一张模型成本表。 把常用模型输入输出和缓存命中价按统一单位（人民币 / 百万 token）列出来，定期更新，价格变动是大模型行业常态。
• 第二步，把模型调用做成可配置接口。 别在业务里写死 model="kimi-k3"，用配置或数据库管模型列表、价格、优先级，方便快速切换。
• 第三步，按任务类型做路由规则。 代码生成优先 K3，数学推理优先 Sol，超长文档分析优先 K3 的 1M 上下文。规则先用硬编码，跑通后再按实际成本和效果动态调整。

这套思路对中小团队尤其有价值：先接入 Kimi K3 吃开源红利，同时保留切到其他模型的能力，而不是被某一家锁定。