兰 亭 墨 苑

标题 *

URL 别名 *

内容 * (支持 Markdown 格式) # 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` 就能把当前会话接到浏览器上。 工作流可以这样： 1. 把需求、截图和修改意见交给 K3； 2. 让它读取现有项目，完成一轮修改； 3. 启动本地页面预览； 4. 根据布局、交互和报错继续迭代。 **不喜欢终端工具的，可以试试 Kimi Code Web——我觉得更好用。** --- ## 六、总结：K3 的真实面目 就我自己的使用体感，**K3 是一个功力深厚的新人高手**——内力绵长，外家硬功也不在话下。它能在真实项目里交付高完成度的前端和长程编码任务，同时还有**开放权重带来的生态优化空间**，是非常值得期待的国产模型。 但也正因为新： - 它会排队； - 会在服务高峰变慢； - 会让不命中缓存的长任务显得昂贵； - **不适合拿来做简单的算术题**。 还有最大的槽点：**Kimi 新用户只能预约，不能购买**。我就想问一句：啥时候 Coding Plan 可以开放订阅呢？估计也要到 GLM 5.2 的阶段吧。 今天我在用 K3 重构 CatReader 的阅读助手 AskCat，估计很快上线。 **我一点也不怀念 Claude 了。**

配图 (可多选)

标签