逐字稿文字預覽
几个月前我们惊掉下巴 当时发现Deep Seek 基本上重新设计了整个V4模型架构 核心就是让百万Token上下文便宜的离谱 我们花了足足两期总共50分钟的系列视频 拆解它们为打造这样一部杰作 做了什么 所以虽然我们本以为那已经是 有史以来优化最激进的长上下文模型 几周前我们却迎来了Deep Seek V4.1 Flash 这款最新模型的架构改造甚至更疯狂 V4.1Flash的参数量 几乎是V4Flash的2倍 从2840亿增长到5520亿 而且其新架构还做了多方面精简 足以把KV缓存再压缩4倍 为了让你明白这有多厉害 过去9个月里 DeepSeek已经把每个Token的KV 缓存大小压缩了54倍 实在太惊人了 所以在今天的视频里 我们就来看看 DeepSeek是如何降低前沿AI模型成本的 以及他们想出了哪些疯狂的新技术 才让这一切成为可能 总之回到视频正题 现在我觉得很明显 Deep Seek并没有追逐 基准测试中的最先进地位 而是把实际运行大元模型这件事 优化到了极致 你多少能从性能跃升中看出这一点 而事后看来 这种跃升也并不算特别疯狂 但当你进一步细看 他们创造并落地的所有创新 尤其是考虑到模型规模后的 每百万Token价格 他们无疑正在建立一种 其他实验室望尘莫及的惊人优势 而当你站在企业的角度想一想 如果一个模型质量能达到九成 成本却只要1% 你大概率会选这个方案对吧 再往高了吹点 在TerminalBench2.1上 它的成本仅为Opus 5的5% 是GPT5.6艘的5.8% 是KIMI K3的8% 同时性能还超过了这三款模型 这就是Deep Seek的优势所在 这是难度高得多的竞争赛道 因为做优化可比刷宝难多了 在这款全新的V4.1 Flash模型中 它们的核心思路 基本就是如何在做大模型的同时 大幅降低它的内存占用 这是一个优化问题 目标是降低大元模型的使用成本 更具体的说 是降低重度智能体场景的使用成本 因为如今大元模型的大部分工作负载 都需要反复读取 塞满了工具输出和代码库的海量历史记录 Deepsy基本是全新投入优化 投入优化 常上下文下 注意力开销过大的问题 虽然说他们现有的稀疏注意力方案 已经降低了注意力成本 但另一个问题开始浮现 那就是模型仍然需要存储 搬运重新加载巨量的KV缓存 下面我快速讲下 KV缓存和注意力的关系 大元模型生成一个Token时 每个注意力层都需要用到 此前所有Token的缓存键和纸 键主要用来帮它判断 哪些历史信息是相关的 职责包含它实际要调取的信息 但要是每生成一个Token 但要是每生成一个token都重新计算所有这些表征浪费会大的离谱 所以模型会把它们存下来 这些存储下来的状态就是kb缓存 token越多kb缓存就越大 层数越多kb缓存也越大 所以当上下文规模达到100万token时 瓶颈就不再只是算力速度了 kb缓存带来的延迟和成本问题会逐渐凸显 你需要一次性计算搬运的token数量 是注意力机制最初设计承载量的10到100倍 所有预天穷算力 HBM SSD 还有带宽 如今都得适配这类需求 这是因为我们大量使用智能体工具 至少也是当下的模型服务模式导致的 V4.1的优化思路从这里开始就很有意思了 因为在V4版本中 他们已经用压缩吸收注意力 CSA将多个Token压缩为更少的KV条目 之后再用吸收索引器 判断这些压缩后的内存里 哪些部分真正值得读取 因此为了应对不断增长的上下文长度 他们已经采用了大量压缩手段 但V4.1 Flash的论文指出 KV缓存还会随着模型深度的增加而变大 模型深度与模型规模高度相关 因为如果想要更大的模型 增加深度是最直接的选择之一 所以在其他条件相同的情况下 从12层增至120层 可能意味着要存储约10倍的层专属KV状态 即使你激进的压缩上下文本身 无论剩下多少KV 他们仍会沿网络深度成倍增加 这就引出一个问题 如果某一层已经生成了有用的 全局记忆表示 下一层真的需要从头构建一个 全新的表示吗 Deepsy发现 至少对某些层来说 答案是否定的 这基本上就是压缩 吸收注意力2 CSAR背后的思路 不再只沿Token纬度压缩 还开始沿层纬度压缩 他们的做法是将注意力层 分成三种不同模式 完整层模式 重索引模式 和复用模式 完整层会正常执行所有操作 它会生成全局KV 生成锁引起K 运行吸收锁引起 并选择自己的TopK记忆条目 如果需要快速回顾一下吸收注意力 吸收锁引起基本上就是KV缓存的一个低成本搜索引擎 它会给缓存的全局KV条目打分 选出最相关的TopK条目 而注意力只读取这些被选中的条目 接下来是重锁引模式 该层会使用上一层已经生成的全局KV 但它对哪些信息重要可能有不同判断 因此它会附用上一层的主KV和索引器K 但生成自己的query并重新选择TopK 最后一种是附用模式 这种模式会附用一切 包括主KV和TopK索引 甚至不需要再次运行索引器 它只对上一层已经选中的内容执行注意力 除了改造CSA2之外 V4.1 Flash还移除了V4中那种 在SWA与HCA或CSA之间 HCA或CSA之间交错的混乱混合注意力 它们的主要改动是彻底弃用HCA 于是全聚分支现在只剩纯CSAR 从而得到更简单的CSAR SWA混合架构 但即便CSAR已经减少了跨层所需存储的KV量 仍存在另一个相当巨大的低效问题 因为无论预填充阶段的注意力被压缩到什么程度 模型人必须先让所有这些输入Token通过网络 才能生成第一个Token 设想你给一个常规40层Transformer 一个常规40层Transformer 输入100万Token的提示词 全部100万个Token 仍必须从第一层一路通过到第40层 对智能体操作来说 这相当棘手 因为如今模型会不断调用工具 读取文件 获取搜索结果 浏览代码库 然后把所有这些再加回上下文理 这意味着模型会反复耗费多的离谱的算力 只是阅读 在推理场景下 大多数前沿实验室和推理服务商 已经将预填充和解码拆分到不同的 解码拆分到不同的GPU集群运行 因为这两种工作负载的需求差异极大 其中预填充属于算力密集型任务 解码则属于内存带宽密集型任务 DeepSea也采用了这一做法 但在架构层面进行了调整 推出了名为CED的方案 全称为因果编码器解码器架构 实际上CED背后的核心构想 并非DeepSea首创 这一构想的灵感来自2024年发表的一篇论文 论文题为You only catch once 简称Yoko 优酷方面发现 Yoko方面发现在常规Transformer架构中 每一层都会生成并存储专属的全局KB缓存 所以如果模型有40层 你实际上要保存40份不同版本的记忆数据 为了解决这种重复存储的问题 他们提出了名为解码器解码器架构的解决方案 模型的下半部分是自解码器 通过高效的因果自注意力机制处理输入序列 生成提示词的上下文化表示 随后Yoko基于下半部分的输出生成共享的全局KB缓存 模型上半部分则为交叉 模型上半部分则为交叉解码器 其中每一层都有独立的query 但所有层都会对同一份共享的k和v 执行注意力计算 这样一来无需每一层都存储 各自体量庞大的kv缓存 Yoko基本上只需要生成一次全局记忆 就能供所有层服用 这也是其you only cache once命名的由来 尽管Yoko将其称为解码器 解码器架构 但它的训练和使用方式 仍与常规自回规语言模型一致 这个名称听起来可能和编码器 解码器架构相似 容易让人联想到他与最终的 容易让人联想到它与最初的注意力机制存在关联 但它取这个名字仅仅是因为架构包含两种不同类型的解码器 下半部分名为自解码器 是因为它采用因果资注意力处理序列 构建共享的全局KV 上半部分名为交叉解码器 是因为每个上层都会生成独立的query 并对下半部分生成的KV执行交叉注意力计算 这种设计还有个更棒的好处 既然上半部分只需要用到下半部分生成的KV 那么在玉田充阶段 严格来说 你完全不需要让提示词 经过上半部分的计算 你只需要超长提示词 通过自解码器处理 生成共享全局记忆后 就可以停止操作 这意味着 Yoko其实首创了这一思路 预填充和解码阶段 未必要用到同等规模的模型 当输入规模 甚至达到100万tokens时 这个设计思路的优势 就十分突出了 因此Deepseek借鉴了这一构想 并对其进行适配 使其能兼容V4的现有架构 Deepseek不再把下半部分称为自解码器 而是称之为因果编码器 它没有像Yoko那样让上半部分共享同一份全局KV 而是让每个解码器层从最终编码器表示派生各自的全局KV 所以从功能上讲 Yoko在KV缓存共享方面要激进的多 而Deepseek的因果编码器 仍会在模型前半部分之后给出这一个最终表示 但它并没有把这个表示变成所有层都必须共享的同一层 所有层都必须共享的同一份KV缓存 而是让每个解码器层 都对该最终表示进行各自学习到的投影 第20层之后的每一层 都可以从该最终表示进行投影 并通过各自层专属的权重 得到不同结果 但这种做法为什么可行呢 他们的理由是 这是模型当前对该token已知信息的 一个庞大的学习性表示 因为在经过20个Transformer层之后 每个token表示都已经经历了 相当深度的上下文处理 基本上已经成为一个 丰富的公共信息源 注意力所使用的K和V 基本上就是 该信息源的不同学习试图 建会确定这条信息 要如何表示 以便后续的查询 能够与它匹配 值则决定当它被注意到时 应当返回哪一项内容 所以通常情况下 如果你想得到 第35层的KV 每个历史提示词 Token都必须先 实际留进第21层 一直到第35层 然后第35层 再把新的隐藏状态 投影成它的KV 这里DeepSeek基本上是在质疑 仅仅为了创建全局记忆库 是否真的需要所有这些非线性计算 于是直接砍掉中间的每一个串行流程 使用该隐藏状态 再交给第35层投影 借此获得KV信息 不过如果你还记得前面讲过的内容 DeepSeek其实并不是每次都为每一层生成 完全独立的庞大KV缓存 CSAR已经通过三种不同模式 让相邻层共享全局KV 所以只有真正需要创建新全局KV的解码器层 才会用自身层专属的投影 直接从最终编码器状态将其派生出来 至于每一层具体使用哪种模式 Deep Seek几乎是把这些模式硬编码进了层布局中 在编码器中 前两个仅使用SWA的层之后 剩余18层按每6层一组划分 一个完整层后面接5个复用层 而在解码器中20层按每4层一组划分 D组以一个完整层开头 后面接三个复用层 后面的各组则以一个众索引层开头 再接三个复用层 所以综合起来看 你基本上同时获得了两个层面的成本节省 首先 CD避免了仅仅为了生成解码器全局KV 就让整个预填充跑变模型上半部分 相反 它直接从最终编码器表示派生这份KV 然后借助CSAR 一旦某个解码器层生成了这份KV 接下来的几层 也不一定需要再生成 另一份副本 而这种组合 正是DeepSeq的方案激进的多 且专门针对V4.1优化的原因 除此之外 DeepSeq V4.1的情况 也要复杂的多 它在每一层中 都仍然保留着 滑动窗口注意力分支 所以每个解码器层 其实有两种不同的记忆 一种是来自编码器表示 并通过CSAR共享的全局记忆 另一种是来自 该解码器层自身 隐藏状态的局部进气记忆 所以这里有一点很需要澄清 CSAR的KV共享只适用于全局注意力分支 这并不意味着滑动窗口注意力的KV缓存 会在各层之间共享 每个层仍然保留自己的局部SWA KV缓存 因为这种局部记忆是由该层实际的隐藏状态产生的 因此即使5个CSAR曾共享同一个全局KV 它们仍然可以有5份不同的滑动窗口KV缓存 除此之外 SWA只保留最近的128个TOKENS 因此全局KV会随着整个100万Token的上下文增长 而运行时 SWA缓存实际上始终受限于那个固定窗口 但由于它仍未压缩且未每层独有 所以仍然不是零成本 尤其是要跨大量绘画持久保存这些状态时 那么如果我们不共享SWA KV缓存 这不就意味着还得把提示词送过这些解码7层吗 而麻烦的地方在于 这个128Token的窗口实际上会随着层深不断累积 第40层的SWA状态依赖第39层 第39层本身又依赖更早的局部窗口 依此类推 所以Deepseek基本上切断了这条依赖链 只把最后128个tokens重放给每个解码7层 这正是他们所说的 SWA有借重放发挥作用的地方 所以不是让100万个tokens经过全部40层 而是让100万个经过前20层 只让128个经过剩下的20层 这意味着现在完整的预填 这意味着现在完整的预填充成本 大致等于完整提示词经过一半模型 再加上128个tokens 经过其余各层 在100万tokens上下文的情况下 那128个tokens的重放 基本可以忽略不计 所以整体预填充仍接近减半 虽说只运行这128个tokens 重建出的状态严格来说是近似的 但Deepseek仍表示对质量的影响微乎其微 而且有借重放实际上还带来了 另一个相当大的好处 因为Deepseek基本意识到 基本意识到已经不值得再把SWA-KV缓存 当作长期记忆对待了 在Deepseek V4中 当它们缓存前缀已共复用时 固态硬盘上的持久化缓存 会同时存储全局KV和SWA-KV缓存 令人惊讶的是 尽管SWA只覆盖一个很小的局部窗口 那些未压缩逐层生成的SWA状态 仍几乎占了持久化KV存储的一半 除此之外 这两种缓存的生命周期完全不同 如果同一个长前缀被复用 全局KV缓存 可能在数小时或数天后 仍然有用 但SWAKV缓存 其实仅对活跃绘画的 当前局部状态有用 有效期通常只有几分钟 因此在V4.1中 Deepseek完全不再把SWAKV缓存 存入长生命周期的持久化缓存 而是将其临时存放在 小得多的主机内存池中 一旦过期或被驱逐 就直接用有界重放重建 最后128个Token 再来说Token 与此同时 与此同时全局KV可以存储在固态硬盘这类持久化存储中 这部分的持久化KV缩减幅度非常可观 CSAR搭配FP4已经能把全局KV压缩到V4时期容量的四分之一左右 而将SWAKV移出持久化存储后 缓存规模几乎直接再减一半 回看V4的设计 持久化KV的占用空间大概一半来自SWA 另一半来自全局KV V4.1首先通过CSAR和FP4把这占一半 和FP4把这占一半的全局KV 压缩到原大小的四分之一左右 这就使得全局KV本身的占用 降至每Token近890字节 在HBM存储上 直接节省了7
本次執行流程與問題處理
下達指令
預期流程
- 下載與語音辨識
- 來源選擇與品質檢查
- 文字校正與句子單元
- 筆記與發布
- 公開網頁發布
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（來源選擇報告）
耗時：1677.2 秒
關係：依序執行
結果：完成
2. 建立筆記頁面
工具：videonote-render-html（產生筆記 HTML）
處理：產生可閱讀的筆記 HTML 頁面
產出：note.html（筆記 HTML）
耗時：0.4 秒
關係：依序執行
結果：完成
3. 發布公開頁面
工具：videonote-publish（發布公開頁面）
處理：發布到公開網站與每日列表
產出：公開筆記網址、result.json（管線結果）
耗時：0.5 秒
關係：依序執行
結果：完成
手動來源字幕
- 尚未產生
自動來源字幕
Whisper 字幕
- 尚未產生
Qwen 字幕
- 尚未產生
Parakeet 字幕
- 尚未產生
MOSS 字幕
- 尚未產生
聲學時間證據（PyAnnote / WhisperX）
- 尚未產生
校正前後逐字稿
目前待解決問題與初步改善方向
- 完整校讀／語意翻譯仍待確認，保留可用逐字稿發布
ValueError('canonical_audit failed bounded JSON/schema retries')
- 自動摘要未完成
已先發布可跳轉的逐字稿版本；可稍後以現有逐字稿重新產生摘要。；note generator exit=1, timed_out=0
- Qwen3-ASR 未完成，需確認 qwen_asr_lab 環境與音訊後重試精進模式。