Kimi K3 又慢又贵？我用它重构了整个项目，有些真相你必须知道
上周，我用 Kimi K3 为墨问的 CatReader 增加了一个全新的发现页。产品左侧依旧是 Feeds 树，从 Feed 点进去一切照旧——音图文智能翻译、AskCat 阅读小猫，一应俱全。右侧主页则新增了卡片瀑布流形式的发现页，按 e 键可快速返回。
左侧的「发现」标签是基于用户阅读行为的信息流，「推荐」则是用户明确推荐的文章，全部按更新时间倒排。有图的文章出图卡，无图则显示文字卡——译文、摘要、悬停操作和卡片视觉细节，全部交给 K3 完成。
前端功能几乎一次过，不愧「前端王者」的称号。
但周五晚上 9 点左右，它突然慢了下来，原因未知。我最后把收尾工作交给了 GLM 5.2。
很多人用 Kimi 做 Vibe Coding 会直接使用 Kimi Code 终端工具，但其实 Kimi Code 自带了一个本地 Web 服务，启动后可以在 GUI 里完成编程工作，功能更丰富，尤其是多会话管理。K3 确实有种逼近 SOTA 的味道——惊艳，穿云裂帛。
即便如此，仍有用户抱怨 K3 又慢又贵。
我完全理解。但问题在于，普通用户很容易把刚发布的模型能力当成稳定运行后的能力，还会把模型能力、推理服务、产品入口和计费方式混为一谈。
《晚点》最近那篇对 K3 的报道恰好把这些问题讲清楚了，对照我这几天的实操，很多看似矛盾的体验就能说清了。
一、K3 刚发布时为什么慢？先看模型本身
K3 是一个总参数量 2.8 万亿、每次推理激活约 1040 亿参数的开放权重模型，支持原生多模态和百万 Token 上下文。
它一度登顶 Frontend Code Arena，是不折不扣的「前端王者」。原因在于：
- 预训练阶段扩大了代码与渲染图像配对的数据；
- 后训练加入了网页开发任务；
- 在**「写代码→看截图→继续修改」的视觉闭环**中训练。
这些投入最终都体现在了前端能力上。
但这种规模的模型，权重可以快速交付，推理系统却需要持续打磨——包括缓存命中率、模型切分、显存调度、并发队列。业内把这整套系统称为 serving stack。
《晚点》里的赵晨阳认为，新模型刚发布时暂时「又贵又慢」，更多反映的是架构有多新、推理栈有多难适配，而不是说这个架构天生就慢。
二、用户口中的「慢」，至少包含三个不同指标
| 指标 | 含义 |
|---|---|
| 首 Token 延迟 | 发出任务后多久看到第一个字 |
| 解码速度 | 开始输出后每秒吐出多少 Token |
| 排队时间 | 服务端同时涌入的请求数 |
我那天晚上 9 点遇到的 K3 变慢，就是首 Token 延迟——更像是服务负载或队列带来的超载问题。
另外，K3 混合使用了 KDA 与 MLA 架构，好处是长上下文下更快、更省，显存成本降低，但也带来了复杂度：
- KDA 维护的循环状态像一块不断擦写的白板；
- 每处理一个 Token 都会更新；
- 需要做更细粒度的前缀管理、状态复制和缓存复用。
这些工程优化会持续改变后续的速度和成本。
所以，K3 刚上线时的「慢」，更像一辆新赛车第一次进入真实赛道——发动机能力已经在那里，但维修站、轮胎策略和进站调度仍在逐轮优化。
而我没有觉得慢，是因为 K3 是 7 月下旬发布的，我真正开始使用已经是 8 月上旬了，速度优化已经度过了最困难的时期。
三、K3 为什么让人觉得贵？得换一把尺子量
K3 官方 API 价格为：
- 缓存命中输入：0.3 美元 / 百万 Token
- 未命中输入：3 美元 / 百万 Token
- 输出：15 美元 / 百万 Token
和极致低价的模型（比如 DeepSeek）摆在一起，确实贵。再加上 K3 经常处理长上下文和多步任务，Token 跑得飞快，用户很容易形成「这东西烧钱」的判断。
但 Agent 的成本，应该看另一把尺子：完成一个任务到底花了多少钱。
能力弱一点的模型会走弯路、反复读文件、修改失败后重来——单价低，总成本未必低。
我自己用 Kimi Code Web 连续折腾 CatReader 三四天：做了发现页、AskCat 优化、大量细节调整。7 天 Code 用量仅 45.45%。以我使用多个模型的经验，在编程场景里持续做真实项目，K3 的消耗显然是可控的。
四、最大的误区：别把 Kimi App 和 Kimi Code 混着用
很多人直接在 Kimi App 里做 Coding 项目，然后用黑色 Kimi 的消耗来判断 Kimi Code 是否耐用——这属于工具误用。
按照 Kimi 的官方说明：
- Kimi 会员共享月度总额度；
- Kimi Code 另外有 5 小时和周频控；
- 用量页能同时看到黑色的 Kimi、蓝色的 Code，以及 5 小时和 7 天进度。
它们属于同一个会员体系，却有不同的产品入口、任务编排和限制窗口：
| 产品 | 适用场景 |
|---|---|
| Kimi App | 日常问答、写作、研究、文件处理、通用云端 Agent 任务 |
| Kimi Code | 本地软件工程：读写项目文件、搜索代码、执行命令、跑测试、长任务会话恢复 |
写个小工具两个入口都能做，但 Kimi Code 肯定更省 Token。要在真实代码仓库里连续作业、看运行结果、定位 bug，应该直接使用 Kimi Code / Web。
五、Kimi Code Web：比终端更好用的 GUI 方案
Kimi Code Web 是同一套 Coding Agent 的另一个形式。用户自己启动，或让 Kimi Code 启动这个本地 Web 服务：
- 默认绑定
127.0.0.1； - 端口通常是
58627； - 浏览器打开即可。
看到的是 GUI，背后仍然是同一个可读文件、调工具、执行命令、保存会话的 Coding Agent。如果在终端会话中，输入 /web 就能把当前会话接到浏览器上。
工作流可以这样：
- 把需求、截图和修改意见交给 K3；
- 让它读取现有项目，完成一轮修改；
- 启动本地页面预览；
- 根据布局、交互和报错继续迭代。
不喜欢终端工具的，可以试试 Kimi Code Web——我觉得更好用。
六、总结：K3 的真实面目
就我自己的使用体感，K3 是一个功力深厚的新人高手——内力绵长，外家硬功也不在话下。它能在真实项目里交付高完成度的前端和长程编码任务，同时还有开放权重带来的生态优化空间，是非常值得期待的国产模型。
但也正因为新：
- 它会排队；
- 会在服务高峰变慢；
- 会让不命中缓存的长任务显得昂贵；
- 不适合拿来做简单的算术题。
还有最大的槽点：Kimi 新用户只能预约，不能购买。我就想问一句：啥时候 Coding Plan 可以开放订阅呢？估计也要到 GLM 5.2 的阶段吧。
今天我在用 K3 重构 CatReader 的阅读助手 AskCat，估计很快上线。
我一点也不怀念 Claude 了。