Kimi K3 原生视频理解实测：与 Claude 同题对决

Moonshot AI 的 Kimi K3 支持将视频文件直接通过 API 传入，而 Claude 至今没有视频输入通道——要让 Claude 看视频，得先抽帧成图片。Codex CLI 即便指向 K3 也没有视频通路。开发者 kenimoto 用两条 40-55 秒的 SSH 教学实操视频做了一次真实的对比测试，结果有些出乎意料。

测试背景：自动生成的教学视频

测试素材来自作者正在开发的 CLI 工具 handson-cast。你给它一个 JSON 步骤文件，它在 Docker 容器里真实执行每条命令，用 vhs 录制终端画面，再配上 OpenAI TTS 生成的日语旁白并烧入字幕。底层是 Python 和 ffmpeg。

两条视频分别是：密钥认证（55 秒），演示创建密钥、安装公钥、验证仅密钥登录、禁用密码认证；跳板机（47 秒），演示同一把密钥通过 ssh -J 被跳板机拒绝、但经由 ~/.ssh/config 却能成功。所有终端输出都是容器内 OpenSSH 10.0p2 真实产生的，没有摆拍。

问题在于第一版（v1）完全不可看——开篇第一秒屏幕上是作者在敲内部包装脚本 bash /lab/ssh-config.step-01.sh，观众根本不知道视频在讲什么。作者自己都承认看不下去。他拿这版 v1 分别给 K3 和 Claude 分析。

如何把视频喂给 K3

K3 API 兼容 OpenAI 格式。流程是先用 files.create 上传视频、拿到返回的文件 ID，再以 ms:// 前缀引用。公网 URL 不被接受。官方文档把视频描述为一组关键帧，分辨率越高消耗 token 越多。

一次 55 秒 1080p 视频的实测数据：输入 token 约 40,659（几乎全是视频），输出 2,500 个（其中 1,912 是推理），成本约 0.16 美元，耗时 83.5 秒。按输入每百万 token 3 美元、输出每百万 token 15 美元计价。

要假设它听不见

作者做了一版不带烧入字幕的视频，要求 K3 转写旁白的最后一句，K3 回复无法识别音频。不假装听见听不见的东西，这恰恰是评测者该有的态度。但也意味着 K3 无法感知旁白内容和字幕音画偏移，它只能看到画面和烧进画面的字幕。

画面读取方面 K3 表现不错：它按顺序准确列出了四个步骤的命令和输出，包括 600/644 权限、拒绝消息的变化、以及一条屏上注释。唯一读错的是包装脚本的文件名。

视频理解模型处理视频时，主流做法是把视频解码为按时间抽样的关键帧序列，再作为多帧图像送进视觉编码器。这种方案天然丢弃了音轨，因为音频需要独立的语音识别链路才能转成文本。K3 官方文档把视频描述为「一组关键帧」正说明了这一点：模型看到的是离散画面而非连续流。分辨率越高消耗 token 越多，是因为每帧图像会被切成固定大小的图像块并各自编码，帧数乘以每帧块数即为视觉 token 总量。实测 55 秒 1080p 视频约 4 万输入 token，可反推出其抽帧密度和每帧编码成本。这也解释了为何烧入画面的字幕能被读到，而旁白不能——字幕已成为像素的一部分，旁白仍在音轨里。

输出预算要给足

K3 总是先推理再回答。max_tokens 设 300 时推理把预算耗尽，答案返回空白；设 8,000 时完整视频审查在第一个问题中途就被截断。作者对这类长回答建议用 32,000。

OpenAI 兼容格式指 K3 的 API 接口在请求体结构、字段命名和鉴权方式上对标 OpenAI 的 Chat Completions 规范，因此原本为 OpenAI 编写的 SDK 或代码只需替换 base_url 和模型名即可迁移。files.create 是这一体系下的文件上传端点，返回的 file ID 可在后续消息中多次引用，避免重复上传大文件。ms:// 是 Moonshot 自定义的引用前缀，用于在消息内容中指向已上传的文件，替代 OpenAI 使用的 file:// 形式。公网 URL 不被接受，意味着模型端不会主动抓取外部资源，所有输入必须经过上传流程，这对含敏感内容的视频是一道额外的管控门槛。

对照实验设置

K3 和 Claude 在匹配条件下各自审查同样的两条 v1 视频：K3 直接吃文件一次；Claude 抽帧后读图。音频方面 K3 无法理解，Claude 侧关闭了转写。两者都附上了步骤 JSON，问的是同样措辞的五个问题。

有意思的是 Claude 侧以子代理方式运行，从未看过 K3 的答案，避免锚定偏差。抽帧使用 claude-video 的 /watch 工具，帧数和分辨率交给 Claude 自主决定，结果它重新抽了 4 次，开头按 0/0.5/1/2/3 秒取帧，之后每 2 秒一帧，共 34 帧。

抽帧策略是 Claude 视频分析方案的核心变量。帧率过低会漏掉短暂出现的画面变化，帧率过高则迅速耗尽上下文预算。claude-video 的 /watch 工具把这一决策交给模型自主判断，模型会根据视频时长和问题类型动态选择采样间隔。本次实验中 Claude 最终采用开头密集（0/0.5/1/2/3 秒）、之后每 2 秒一帧的混合策略，共 34 帧，这种「开头密、中段疏」的做法符合短视频钩子集中在开头的规律。子代理方式运行指 Claude 在一个独立的上下文中完成任务，主对话不携带 K3 的答案作为参考，从而消除锚定偏差——若模型先看到他人的结论，往往倾向于附和而非独立判断。

结果：发现几乎一致

两个模型的答案高度重合。0-2 秒在敲包装脚本导致主题不明、首句旁白介绍网站而非观看理由、跳板机视频里 Could not resolve hostname 这个强钩子被埋没、用冷开场直给结论、剪掉打字和步骤间等待、加大字体高亮关键输出、做竖版、在 ls -l 处插权限图、结尾放 OG 图、跳板机视频先发——这些发现双方全部命中。

差异只在少数几条：K3 额外提出顶部加进度条；Claude 额外给出了改写后的旁白句子，并指出四条 ssh-copy-id 的 INFO 日志是噪音。

这些修改建议本身都是标准的短视频常识——开头给结论、剪掉空白、字幕精简、结尾放行动号召。这次对比没有找到任何只有 K3 才能发现的问题。 作者本以为能原生读视频的模型会看到 Claude 看不到的东西，结果并没有。

真正拉开差距的是时间戳精度

最大的差异在时间定位。K3 能写出类似「第一个有意义的输出出现在 3.7 秒」「跳板机视频里 00:03.2 的错误被埋没」这样亚秒级的判断；在审查改进版时它甚至给出了区间：「30.5 到 36.1 秒之间输出出现后画面冻结」。

Claude 的时间戳基于每 2 秒一帧估算，它自己也承认区间边界可能偏差 ±1 秒。可以加密采样，但代价是更多图片要读。「画面究竟在哪一秒冻结」这种问题很难从几张静帧里答出来——这正是直接读视频的价值所在。

亚秒级判断来自模型对帧序列时间戳的内部表示。当视频被解码为带时间信息的帧序列时，每一帧都附带精确到毫秒的 PTS（显示时间戳），模型可以在推理中直接引用这些数值。抽帧方案则会丢失帧间的时间连续性：若每 2 秒取一帧，两个相邻帧之间发生的任何变化都只能被定位到一个 2 秒宽的区间，模型只能给出区间估计并自报误差。冻结帧检测尤其依赖时间连续性，因为冻结本身是「连续多帧内容完全相同」这一模式，只有逐帧比对才能确定冻结的起止时刻。单纯增加抽帧密度可以缩小误差，但 token 成本随帧数线性增长，存在收益递减的拐点。

效率与速度各有胜负

K3 侧作者只需递出文件，耗时 363 秒，消耗 84,461 输入 / 10,863 输出 token，约 0.20 美元（部分输入按缓存价计费）。Claude 侧需要决定抽帧策略（它重做了 4 次），耗时 185 秒，消耗 111,313 token、40 次工具调用。K3 更省心力，Claude 更快。由于 K3 花时间推理，每次审查要 6-8 分钟——够泡杯咖啡再回来。

视频确实变好了

按评审意见，作者给 handson-cast 加了六项改动：开篇卡片「同一把钥匙，ssh -J 却被拒绝，为什么？」；剪掉包装脚本打字和步骤等待；逐字符敲命令并加大字体；拒绝发生后全屏展示文章配图 4.5 秒；输出完成后缓慢放大终端左上角；结尾放 OG 图和 URL。

跳板机视频从 46.8 秒缩到 41.0 秒。作者用一份 10 项技术短视频清单让 K3 给改进版打分（涵盖 3 秒内钩子、每 1-3 秒画面有变化、只在结尾放短行动号召等），结果 7 项通过、2 项边缘、1 项预估通过，两个边缘项——输出后冻结片段和字幕过长——现已修好。

顺带一提，作者本想用 K3 的联网搜索 $web_search 来做清单调研，但 K3 上第二次调用（返回搜索结果那次）每次都报 400 tokenization failed；kimi-k2.6 首次搜索能过，之后却停止搜索、只在答案里写出看起来像搜索调用的文本。文档显示该功能计划于 2026-10-20 退役。作者放弃，改用 Claude 的联网搜索完成调研再把结果交给 K3。

分工方案

基于本次测试，作者的结论是：需要知道「视频里某件事发生在第几秒」时用 K3——冻帧区间、画面被截断的时刻、字幕停留时长这类答案是一个时间跨度的问题，且无需操心抽帧策略。决定「怎么改」两者皆可，改进思路没有差别。涉及音频的一律不用 K3，旁白内容和同步问题需单独准备转写稿比对。另外，视频会上传到 Moonshot AI 的服务器，内部屏幕录像需要另作处理。

作者也承认这是个小样本对比：两条视频、一组问题、没有统计意义。但它给出了可用的答案——直接读视频没有改变判断，改变的是时间戳精度和投入心力。下一步他打算在视频里故意埋入缺陷，看两个模型各自能找出多少。