你觉得 Kimi K3 又慢又贵是吧，我来告诉你为什么

上周我用 Kimi K3 为墨问的 CatReader 增加了一个全新的发现页。产品的左侧依然 Feeds 树，从 Feed 点进去还是原汁原味的操作，音图文智能翻译，还有 AskCat 阅读小猫，一应俱全。右边主页增加了卡片瀑布流形式的发现页，快捷键 e 可以快速回到发现页。

左侧的标签 发现 是基于用户阅读行为的信息流，推荐是用户明确推荐的文章，全部是按照文章更新时间的倒排。有图的文章出图卡，没有图的是文字卡，译文、摘要、悬停操作和卡片视觉细节都让 K3 一起做了。前端功能上几乎一次过，不愧前端王者的称号。

在我使用 K3 的那几天，它大部分时间都很快，并且挺抗用的。定位问题准，修 bug 也利落，前端还原度尤其让人惊讶。到了周五晚上 9 点左右，它突然慢下来，原因未知，我最后把收尾工作交给 GLM 5.2 搞定了。

注意，很多人用 Kimi 做 Vibe Coding 会直接使用 Kimi Code 这个终端工具，其实 Kimi Code 自带了一个本地 Web 服务，启动后你可以在 GUI 里就完成编程工作，非常方便，功能也更丰富，尤其是多会话管理：

K3 确实有种逼近 SOTA 的味道，惊艳，穿云裂帛的感觉，即便如此，还有用户——包括 墨问 Vibe 群里的用户——会抱怨 K3，觉得它又慢又贵，这个我完全理解。原因是普通用户很容易把刚发布的模型能力当成稳定运行后的能力，还会把模型能力、推理服务、产品入口和计费方式混为一谈。

《晚点》最近那篇对 K3 的报道，恰好把这些问题讲清楚了，再对照我这几天的实操，很多看起来互相矛盾的体验就能说清楚了。

K3 为什么刚发布的时候会慢？

先说模型本身。K3 是一个总参数量 2.8 万亿、每次推理激活约 1040 亿参数的开放权重模型，支持原生多模态和百万 Token 上下文。K3 一度登顶了 Frontend Code Arena，不折不扣的前端王者，这是因为 K3 在预训练阶段扩大了代码与渲染图像配对的数据，后训练又加入网页开发任务，同时会在“写代码—看截图—继续修改”的视觉闭环里训练，这些投入最后都体现在前端能力上。

这种规模的模型发布之后，模型权重可以很快交付，但围绕它的推理系统却需要继续打磨，包括缓存的命中率。在线服务要持续处理模型切分、显存、调度、缓存、并发和队列，业内把这一整套系统叫 serving stack。《晚点》里的赵晨阳认为，新模型刚发布时暂时“又贵又慢”，更多反映架构有多新、推理栈有多难适配，并不是说这个架构天生就慢。

用户平时说“慢”，至少包含三个指标。第一个是首 Token 延迟，也就是发出任务后多久看到第一个字；第二个是解码速度，也就是开始输出后每秒能吐出多少 Token；第三个是排队时间，服务端同时涌入多少请求会直接影响这一项。我那天晚上 9 点 K3 变慢，就是首 Token 延迟，更像是服务负载或队列带来的超载问题。

另外，K3 混合使用了 KDA 与 MLA 架构，好处是长上下文下的速度更快、更省，显存成本降低，但也带来了复杂度。KDA 维护的循环状态更像一块不断擦写的白板，每处理一个 Token 都会更新，需要做更细粒度的前缀管理、状态复制和缓存复用，这些工程优化会持续改变后续的速度和成本。

所以，K3 刚上线时的慢，更像一辆新赛车第一次进入真实赛道。发动机能力已经在那里了，但维修站、轮胎策略和进站调度仍在逐轮优化。

我为什么不觉得慢，因为 K3 是 7 月下旬发布的，我真正开始使用已经是 8 月上旬了，显然速度的优化已经度过了最困难的时期。

K3 为什么让人觉得贵

再说贵。K3 官方 API 价格是：缓存命中的输入每百万 Token 0.3 美元，未命中 3 美元，输出 15 美元。和极致低价的模型摆在一张表里，比如 DeepSeek，确实贵点，再加上 K3 经常处理长上下文和多步任务，用户看着 Token 往前跑，很容易先形成“这东西烧钱”的判断。

但是，Agent 的成本还应该看第二把尺子：完成一个任务到底花了多少钱。能力弱一点的模型会走弯路、反复读文件、修改失败后重来，单价低，最后的成本未必低。

还有个问题就是，不少用户用 Kimi App 去做 Coding 的事情，最后把 Kimi 的额度消耗没了，Coding 一点没动。这是个使用上的误区，当然了，Kimi 也没说清楚这事 😂

我自己用 Kimi Code Web 连续折腾 CatReader 三四天，做了发现页，AskCat 的优化，也做了不少细节调整，7 天 Code 用量 45.45%，就我自己使用多个模型的经验来说，在为编程设计的场景里持续做真实项目，K3 的消耗显然是可控的。

Kimi 会员总用量、5 小时 Code 用量与 7 天 Code 用量

对，Kimi App 和 Kimi Code，别再混着用了。

这个误区尤其需要强调下：很多人直接在 Kimi App 里做 Coding 项目，然后用 黑色 Kimi 的消耗判断 Kimi Code 是否耐用，这属于工具误用。

按照 Kimi 目前的官方说明，Kimi 的会员是共享月度总额度，Kimi Code 另外还有 5 小时和周频控；我自己的用量页也能同时看到黑色的 Kimi、蓝色的 Code，以及 Code 的 5 小时和 7 天进度。它们属于同一个会员体系，却有不同的产品入口、任务编排和限制窗口。

Kimi App 适合日常问答、写作、研究、文件处理，以及由云端 Agent 完成的通用任务。Kimi Code 面向本地软件工程，它知道当前工作目录，可以读写项目文件、搜索代码、执行命令、跑测试，并把长任务保存为可恢复的会话。

写个小工具，两个入口都能做，Kimi Code 肯定是省 Token 的；要在真实代码仓库里连续作业、看运行结果、定位 bug，应该直接使用 Kimi Code / Web。

前面说过，Kimi Code Web 是同一套 Coding Agent 的另一个形式，用户可以自己启动，也可以让 Kimi Code 启动这个本地 Web 服务：

默认只绑定本机的 127.0.0.1，端口通常是 58627，浏览器打开即可。你看到的是 GUI，背后仍然是同一个可以读文件、调工具、执行命令和保存会话的 Coding Agent；

如果你已经在终端会话里，也可以输入 /web 把当前会话接到浏览器上。

你可以把需求、截图和修改意见交给 K3，让它读取现有项目，完成一轮修改后启动本地页面，再根据你看到的布局、交互和报错继续迭代。

不喜欢或者不习惯终端工具的，可以用 Kimi Code Web，我觉得更好用一些。

就我自己的使用体感，K3 是一个功力深厚的新人高手，内力绵长，外家硬功也不在话下，它能在真实项目里交付高完成度的前端和长程编码任务，同时还有开放权重带来的生态优化空间，是非常值得期待的国产模型。

当然了，因为新，它会排队，会在服务高峰变慢，会让不命中缓存的长任务显得昂贵，更不适合拿来做简单的算术题。还有个最大的槽点，Kimi 新用户只能预约，不能购买，我就想问一句，啥时候 Coding Plan 可以开放订阅呢？估计也会尽力 GLM 5.2 的阶段吧。

今天我在用 K3 重构 CatReader 的阅读助手 AskCat，估计很快上线。

我一点也不怀念 Claude 了。