逐字稿文字預覽
Hello,大家好,我是Tommy。今天很高興跟大家分享最新的前置內容。 那上一次我們講過Deepseek V4.1 Flash,怎麼降低KP Cache的存儲開銷。 那麼這一次我們繼續看它怎麼減少脫離計算和緩存成本。 那核心呢就兩件事。第一個就是重新計算上下文的時候呢,只計算前一半的層。 那麼後面一半是直接附用已有的結果。 那第二個呢就是一部分短期緩存不再長期保存,而是在需要時重新計算。 那最终呢 计算量降低约一半 持久化缓存降到原来的1% 同时性能基本不受影响 那么这里呢 最关键的是两个问题 那第一个就是 为什么只计算一半的层就够了 第二个呢 为什么重新计算 反而比把缓存一直存下来更划算 那下面我们就直接来看它的具体设计 上一集那个编码agent 修一个仓库里的bug 跑了三个小时 上下文堆到50万token 上一集算的是它要存多少 40层只存4份KV 每个Token890字节 这一集算的是它要读多少 上一集结尾留了一句 4份里解码器那一份 还是从编码器投影来的 这意味着读入新内容时 只用跑前20层 后20层不用算 这一招叫CED 全称因果编码器解码器 这一集就讲它 它把40层分成前后两半 前20层叫编码器 负责读上下文 后20层叫解码器负责生成 解码器要用的KV 从编码器的输出投影出来 所以读入的时候 后20层可以不跑 为什么能这么干 代价是什么 就是这一集的内容 先看读入这一步为什么贵 Agent每掉一次工具 工具的返回都要接到上下文后面 模型再把新内容读一遍 也就是上一集说过的prefill 有缓存的时候 只读新增的那一段 缓存一旦没命中 整段50万都要重算 一次任务几十次工具调用 就是几十次读入 读一次 40层每一层都要算 上下文越长 这比算力越大 这还只是算力 50万token的KV还得留着 等下一轮 甚至等第二天用户回来接着聊 所以它要从显存落到硬盘上 V4的线上部署里 这份缓存要在硬盘上留72小时以上 显存装不装的下 硬盘存不存的起 机器之间搬不搬的动 三处都是压力 算力和硬盘两笔成本 问题来了 独入这一步 V4.1凭什么算力砍一半 硬盘砍到1% 先说算力 2024年有篇论文叫Yoko 意思是你只缓存一次 它把模型前后两半分开 后半层不再各自算KV 直接用前半层算好的那一份 后半层在独入阶段 就可以整个跳过 代价是后半层共用同一份KV 每一层没法有自己的一份 能存的信息就少了 CD顺着这个思路改了两处 解码器要用的全局KV 拿编码器第20层的输出 乘一个投影矩阵得到 第一处改动 投影矩阵可以逐层不同 每层能有自己的一份KV 容量比YOKO共用一份大 第二处 滑动窗口那条局部分支 不投影 每一层还是自己算 局部信息的计算深度保住了 在V4.1里 配合上一集讲的共用 真正做投影的是解码器那一个负层 其余层沿用它 独入阶段编码器20层算完 解码器要的全局KV顺手投影出来 后20层根本不用跑 算力从40层变20层 激活参数从160亿降到80亿 生成阶段才用满160亿 这里有个缺口要补 滑动窗口KV每一层自己算 可独入阶段解码器根本没跑 解码器20层的滑动窗口KV就是空的 生成第一个Token时 解码器要用到前面128个Token的窗口KV 手里却是空的 想精确补上 就得让解码器 把前面那些token重新算一遍 算多少 窗口是一层套一层的 解码器第一层的一个位置 只看它前面128个 第二层的同一个位置 看的是第一层算出的那128个 而那128个 各自又看过更前面的128个 所以第二层实际牵扯到前面256个 一层多128个 到第二层就是20乘128 2560个 也就是说 要把第20层的窗口KV算准 得从2560个Token之前开始 把解码器重新跑一遍 Agent的场景是多轮短消息 每轮新内容可能就几百个Token 为了补窗口再多跑2560个 这比开销不小 这个版本的做法叫 滑动窗口有界回放 不回退2560个 只回退末尾128个 把这128个Token的编码器输出 送进解码器跑一遍 开销是128个Token乘20层 跟50万笔可以忽略 窗口也只在这128个里面看 再往前的一律不看 因为再往前的token没经过解码器 没有东西可看 回放段里的第一个token 窗口里就只有他自己 越往后能看到的越多 到末尾正好是完整的128个 算出来的滑动窗口KV只拿来生成 不存进缓存 为什么敢 因为窗口的有效视野远比理论知晓 有篇叫PowerAttention的工作专门测过这件事 理论上第20层的视野 能到2560个token之外 实际上远处的信息 一层一层传过来 早就衰减到可以忽略 远处的东西 本来就归全局分支管 窗口只负责眼前这一段 这样补出来的KV 和完整跑一遍 不完全一样 报告说实测几乎不掉点 为了保险 后训练时 把同样的回放模拟进去 模型是在这种近似下练出来的 顺便说一句 这两集提到的前变量 稀疏注意力 后训练里的这种训练感知 都出自DeepSeek这套技术战 我做了一门DeepSeek专题的实战课 从MLA MOE ROPE这些核心机制 讲到GRPO对齐训练 再到VLLM SGLAN固鼓鼠 共计11张配项目代码 想把这两集背后的底子补齐 链接在简介和置顶评论里 算力说完 说硬盘 这一半省得更巧 先看V4是怎么存的 落到硬盘的缓存 叫持久化缓存 分两类 全局KV整段存 只要新请求的开头和缓存里的一样 就整段复用 滑动窗口KV不整段存 只在两个位置各存128个 一段提示词的末尾 一段回答的末尾 为的是重新生成和多轮接续 两类各自淘汰 最久没被用到的先删 硬盘配的够大 两类都能留72小时以上 就这样 滑动窗口KV还是占了持久化缓存将近一半 它没有压缩 每个位置128个Token 每一层各一份的8比特KV原样存 多轮对话每轮都要存一份 轮次多每轮短分数就多 问题处在访问模式 全局KV是常委复用 一天以后用户回来还会命中 滑动窗口KV只在一次绘画里 几分钟之内被用到 绘画一结束或者进到下一轮 它就再也不会被用到 把一份分钟级的东西放进保留72小时的缓存 又贵又没用 V4的报告提过干脆不存 要用再算 叫做Zero SWA Catching 可精确重算 要按层数乘128个token跑一遍完整前向 线上扛不住 这个版本改了两条 第一条 滑动窗口KV不再进硬盘 改放进一个内存池 所有机器各拿出10%的内存拼成一个池子 注意是机器的内存不是显存 池子总量比硬盘小得多 但有效期只有几分钟 过期立刻腾给新绘画 真实负载下这种高周转 够服务绝大多数正在进行的绘画 全局KV照旧流硬盘 保证72小时 第二条池子小必然有未命中 未命中指的是全局KV硬盘上还在 滑动窗口KV在池子里已经过期 编码器也是20层 精确补齐同样要2560个 现在只回放128个 补出来的窗口KV是近似的 缓存到哪里为止 回放就从哪里开始 起点不同 补出来的KV就略有不同 报告说这对回答质量几乎没有影响 还用了一个说法 把灾难性的未命中 变成了优雅又便宜的降级 正因为兜底便宜 才敢把滑动窗口KV从硬盘上拿掉 两种回放别混 解码器回放每次独入都做 补的是解码器的窗口KV 因为解码器从来不跑独入 编码器回放只在未命中识做 补的是编码器的窗口KV 因为硬盘上不再存它 两个都只回放末尾128个 都基于同一个判断 窗口的记忆很短 1%就是这么算出来的 不存滑动窗口KV 19化缓存少一半 剩下的全局KV 上一集讲过 是上一代的四分之一 二分之一乘四分之一 八分之一 把三层存储放在一起看就清楚了 显存里放正在用的全局KV 每个Token890字节 机器内存里放几分钟内会用的 滑动窗口KV 过期就扔 硬盘上放几天内可能会用的全局KV 留72小时 三层各管一个时间尺度 每一层只存它该存的 回到那个50万Token的绘画 看两个时刻 第一个时刻 工具返回一段新内容 读入直跑编码器20层 激活80亿参数 解码器要的全局KV顺手投影出来 滑动窗口回放128个 开始生成 第二个时刻 第二天用户回来接着聊 硬盘上取出来的只有全局KV400多兆 滑动窗口那份现算还是128个 两处近似 报告给的结论是性能与基线相当 读入的计算量减半 部署上还把视觉编码读入生成分成三段 各自扩缩容 读入密集的agent负载可以单独加机器 多轮短消息的agent绘画 就是报告点名要服务的场景 局限一共三条 第一条 有界回放是近似 尤其是缓存和新内容接缝的地方 报告承认还没充分验证 接下来要加压力测试 也要在真实负载里继续观察 后两条是我自己的判断 第二条 收益跟场景绑定 多轮每轮短的agent绘画收益最大 一次性为一份几十万token的长文档 省的主要是算力那一半 硬盘那一半的好处基本用不上 第三条 10%的内存池 几分钟的有效期 72小时的硬盘保留 都是按Deepseek自家的线上负载掉出来的 换一种负载分布 未命中率和回放开销都要重新测 回到开头的问题 算力砍一半 靠CED解码器的全局KV 从编码器投影 独入只跑20层 硬盘砍到1% 靠不存滑动窗口KV 为民众就回放128个补出来 再乘上上一集全局KV的1% 两件事背后是同一个判断 滑动窗口的记忆很短 短到可以现算 上一集的共用 加上这一集的回放 长上下文的存和算一起压了下来 成绩还没有掉 如果这一集让你有点收获 欢迎点赞转发 关注 评论区也聊聊 换你来做部署 滑动窗口KV 你会存硬盘保命中率 还是不存 靠回放节省硬盘 好 我们下期继续
本次執行流程與問題處理
下達指令
預期流程
- 下載與語音辨識
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
1. 下載與語音辨識
工具：videonote-transcribe-url（主辨識管線：下載、Whisper 辨識與選稿）
處理：下載音訊、以 Whisper 辨識並選出最佳逐字稿
產出：yt_dlp_meta.json（影片元資料）、audio_16k_mono.wav（16kHz 單聲道音訊）、transcript.whisper.json（Whisper 辨識結果）、transcript.json（正式逐字稿）、transcript_selection_report.json（來源選擇報告）
耗時：38.5 秒
關係：依序執行
結果：完成
2. 全文快速校讀
工具：videonote_rapid_transcript_review.py
處理：先速讀完整逐字稿，再修正高可信突兀詞句並列出待確認項目
產出：rapid_transcript_review_report.json（產出檔案）
耗時：44.2 秒
關係：依序執行
結果：完成
3. 建立句子單元
工具：videonote-build-sentence-units
處理：將逐字稿切成帶時間軸的句子單元
產出：sentence_units.json（句子單元）
耗時：0.3 秒
關係：依序執行
結果：完成
4. 句子密度平衡
工具：videonote_balance_sentence_units.py
處理：平衡句子長度與密度
產出：sentence_units.json（句子單元）
耗時：0.3 秒
關係：依序執行
結果：完成
5. 時間軸稽核
工具：videonote_timeline_audit.py
處理：檢查時間軸與音訊對齊
產出：timeline_audit_report.json（時間軸稽核）
耗時：0.3 秒
關係：依序執行
結果：完成
6. 品質檢查
工具：videonote_controlled_quality.py（檢查時間軸與品質）
處理：檢查語言、時間軸與可讀性品質
產出：controlled_quality_report.json（品質報告）、language_sanity_report.json（語言檢查）
耗時：0.4 秒
關係：依序執行
結果：完成
7. 播放時間軸回填
工具：videonote_rebase_display_timeline.py
處理：將網頁播放時間軸回填為校正字幕時間
產出：display_timeline_rebase_report.json（時間軸回填報告）
耗時：0.4 秒
關係：依序執行
結果：完成
8. 逐字稿交叉檢查
工具：videonote_cross_check_transcript.py
處理：交叉檢查逐字稿與來源字幕
產出：transcript_crosscheck_report.json（交叉檢查）
耗時：0.4 秒
關係：依序執行
結果：完成
9. 來源句整理
工具：videonote_prepare_source_entries.py
處理：整理來源句子供時間軸與頁面使用
產出：sentence_units.json（句子單元）
耗時：0.4 秒
關係：依序執行
結果：完成
10. 生成筆記摘要
工具：videonote-generate-note（生成筆記摘要）
處理：生成筆記摘要與重點
產出：note.md（筆記 Markdown）、note.html（筆記 HTML）
耗時：128.8 秒
關係：依序執行
結果：完成
11. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：0.9 秒
關係：依序執行
結果：完成
12. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：1.0 秒
關係：依序執行
結果：完成
手動來源字幕
- 尚未產生
自動來源字幕
Whisper 字幕
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
- 校正前 transcript.whisper.json 純文字 JSON
- 校正後 transcript.json 純文字 JSON
目前待解決問題與初步改善方向
- 逐字稿全文快速校讀未完成
已保留自動字幕/原始逐字稿並繼續生成筆記。；未完成的全文速讀項目可在精進模式回聽確認。；RAPID_REVIEW_STATUS=REVIEW_REQUIRED_INVALID_OUTPUT
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。