# 模型回复很快，视频怎么还没导出

Next Token 博客

PDF 朗读可以尽早开始，视频包装却可能仍在等渲染。顺着一次任务的实际步骤，找到值得缩短的那段等待。

发布：2026-11-10
更新：2026-10-26

开车出发前，把没来得及读的 PDF 转给 Agent，让它念出来，接着听内容。第七期记录的这次使用，没有计时数据，但有一个很清楚的结果：人已经能听文档了，不用再操心文件如何转换。

同一期里，给录屏做包装却要等十五到二十分钟。封面、片尾、转场、目录都要做，着急发布时，自己加字幕可能还快一些。两次体验放在一起，正好说明模型响应速度解释不了整个任务的耗时。

## 先看用户什么时候能开始用

DeepSeek App 在关闭搜索时响应很快，是节目中的个人感受。要判断这种提速对产品有多大帮助，还得看输出拿来做什么。

Anthropic 的[延迟文档](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-latency)把请求发出到首个 Token 返回的时间称为 TTFT。流式输出能让人提前读到开头，适合解释、问答等边读边用的内容。若任务是生成一个文件，开头几行代码出现了，用户通常还无事可做。

朗读 PDF 则有另一种安排：第一段语音准备好就开始播放，后面的内容继续处理。这是一种设计选择，节目没有说明当时的工具是否采用了这样的流水线。它值得考虑，是因为听众的使用顺序本来就是从前往后。

同样，视频导出前可以先给一段预览。预览如果足以确认字幕位置或转场样式，就能提前发现问题；只显示制作中的几行日志，对准备发视频的人帮助不大。

## 把二十分钟拆开看

用一个假设算例看得更清楚：任务共二十分钟，其中模型处理两分钟，素材传输与导出十八分钟。把模型部分缩短到十二秒，总耗时仍然是十八分十二秒。

实际排查时，需要分别记录下载、生成、渲染和上传用了多久。如果长时间停在渲染，就查输出规格、效果和执行设备；如果主要在返工，就查第一次预览为什么出现得那么晚。

包装本身也有取舍。一条临时说明功能的录屏，可能只需要裁掉空白、加上字幕。把所有动效都做齐，增加的等待未必值得。让用户选择快速版与完整包装版，往往比继续强调模型每秒输出多少 Token 更能解决眼前的问题。

## 等待时，只报告影响下一步的事

短任务马上就能结束，直接给结果即可。长任务则要让用户分辨自己该不该介入。正在导出时可以离开；源文件缺失时应当补文件；一项已经超时的外部请求，需要给出重试或取消的入口。

这类状态可以很简短，也不需要公开模型的思考过程。完成通知最好附上能直接打开的文件，避免用户回来后再问一次结果在哪。

对于 PDF 朗读，值得检查的是声音多久开始、途中会不会停、离开当前页面后还能否继续听。对于视频，检查的是预览何时可看、最终文件何时可下载。这些时间才直接关系到用户的安排。

## 相关资料

- [DeepSeek App 的响应体验及其使用条件](https://nexttoken.tv/weekly/007/transcript#quote-c527db7301f884083b47)
- [把 PDF 交给 Agent 朗读的使用记录](https://nexttoken.tv/weekly/007/transcript#quote-da26127f2aa4fa07d186)与[对交付结果的要求](https://nexttoken.tv/weekly/007/transcript#quote-708e374316ea336c23e6)
- [录屏包装的等待时间](https://nexttoken.tv/weekly/007/transcript#quote-fe2fb8bd99cb2aed0417)与[渲染环节的讨论](https://nexttoken.tv/weekly/007/transcript#quote-05e84c5cf4c2d60321bd)
- [Anthropic：Reducing latency](https://platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-latency)，查阅于 2026 年 10 月 26 日。

## 来源与相关链接

- [网页版文章](https://nexttoken.tv/blog/fast-models-and-useful-results)
- [Weekly #007 完整文字稿](https://nexttoken.tv/weekly/007/transcript)