DeepSeek-V4.1 Flash：迄今为止最疯狂的优化 - bycloud - 英语原声/中配 p01 配音

旁白_B 首頁 每日列表 原始影片
實際影片長度：23:54.601。原文、繁中、雙語可點擊句子跳轉影片。
0:00.000–0:01.720
zh几个月前我们惊掉下巴
0:01.720–0:03.140
zh当时发现Deep Seek
0:03.140–0:05.940
zh基本上重新设计了整个V4模型架构
0:05.940–0:08.880
zh核心就是让百万Token上下文便宜的离谱
0:08.880–0:13.000
zh我们花了足足两期总共50分钟的系列视频
0:13.000–0:15.220
zh拆解它们为打造这样一部杰作
0:15.220–0:15.940
zh做了什么
0:15.940–0:18.020
zh所以虽然我们本以为那已经是
0:18.020–0:20.820
zh有史以来优化最激进的长上下文模型
0:20.820–0:24.280
zh几周前我们却迎来了Deep Seek V4.1 Flash
0:24.700–0:27.588
zh这款最新模型的架构改造甚至更疯狂
0:27.608–0:29.668
zhV4.1Flash的参数量
0:29.668–0:31.628
zh几乎是V4Flash的2倍
0:31.628–0:35.128
zh从2840亿增长到5520亿
0:35.128–0:37.728
zh而且其新架构还做了多方面精简
0:37.728–0:40.028
zh足以把KV缓存再压缩4倍
0:40.028–0:42.008
zh为了让你明白这有多厉害
0:42.008–0:43.068
zh过去9个月里
0:43.068–0:45.428
zhDeepSeek已经把每个Token的KV
0:45.428–0:47.848
zh缓存大小压缩了54倍
0:47.848–0:49.708
zh实在太惊人了
0:49.708–0:51.248
zh所以在今天的视频里
0:51.248–0:52.108
zh我们就来看看
0:52.108–0:55.028
zhDeepSeek是如何降低前沿AI模型成本的
0:55.176–0:57.596
zh以及他们想出了哪些疯狂的新技术
0:57.596–0:59.156
zh才让这一切成为可能
0:59.156–1:00.476
zh总之回到视频正题
1:00.476–1:01.996
zh现在我觉得很明显
1:01.996–1:03.396
zhDeep Seek并没有追逐
1:03.396–1:05.156
zh基准测试中的最先进地位
1:05.156–1:07.476
zh而是把实际运行大元模型这件事
1:07.476–1:08.476
zh优化到了极致
1:08.476–1:10.936
zh你多少能从性能跃升中看出这一点
1:10.936–1:11.856
zh而事后看来
1:11.856–1:13.616
zh这种跃升也并不算特别疯狂
1:13.616–1:14.856
zh但当你进一步细看
1:14.856–1:16.776
zh他们创造并落地的所有创新
1:16.776–1:18.976
zh尤其是考虑到模型规模后的
1:18.976–1:20.536
zh每百万Token价格
1:20.536–1:22.036
zh他们无疑正在建立一种
1:22.764–1:24.384
zh其他实验室望尘莫及的惊人优势
1:24.384–1:26.444
zh而当你站在企业的角度想一想
1:26.444–1:28.824
zh如果一个模型质量能达到九成
1:28.824–1:30.084
zh成本却只要1%
1:30.504–1:32.464
zh你大概率会选这个方案对吧
1:32.464–1:33.904
zh再往高了吹点
1:33.904–1:35.804
zh在TerminalBench2.1上
1:35.804–1:39.284
zh它的成本仅为Opus 5的5%
1:39.284–1:42.244
zh是GPT5.6艘的5.8%
1:42.244–1:44.444
zh是KIMI K3的8%
1:44.444–1:46.664
zh同时性能还超过了这三款模型
1:46.664–1:49.004
zh这就是Deep Seek的优势所在
1:49.004–1:50.352
zh这是难度高得多的竞争赛道
1:51.032–1:53.272
zh因为做优化可比刷宝难多了
1:53.272–1:56.052
zh在这款全新的V4.1 Flash模型中
1:56.052–1:57.252
zh它们的核心思路
1:57.252–1:59.852
zh基本就是如何在做大模型的同时
1:59.852–2:01.992
zh大幅降低它的内存占用
2:01.992–2:03.272
zh这是一个优化问题
2:03.272–2:06.332
zh目标是降低大元模型的使用成本
2:06.332–2:07.232
zh更具体的说
2:07.232–2:09.792
zh是降低重度智能体场景的使用成本
2:09.792–2:12.232
zh因为如今大元模型的大部分工作负载
2:12.232–2:13.212
zh都需要反复读取
2:13.212–2:15.752
zh塞满了工具输出和代码库的海量历史记录
2:15.752–2:17.940
zhDeepsy基本是全新投入优化
2:17.940–2:19.160
zh投入优化 常上下文下
2:19.160–2:20.720
zh注意力开销过大的问题
2:20.720–2:22.740
zh虽然说他们现有的稀疏注意力方案
2:22.740–2:24.260
zh已经降低了注意力成本
2:24.260–2:25.820
zh但另一个问题开始浮现
2:25.820–2:27.940
zh那就是模型仍然需要存储
2:27.940–2:30.820
zh搬运重新加载巨量的KV缓存
2:30.820–2:32.020
zh下面我快速讲下
2:32.020–2:33.840
zhKV缓存和注意力的关系
2:33.840–2:35.600
zh大元模型生成一个Token时
2:35.600–2:37.220
zh每个注意力层都需要用到
2:37.220–2:39.280
zh此前所有Token的缓存键和纸
2:39.280–2:40.680
zh键主要用来帮它判断
2:40.680–2:42.340
zh哪些历史信息是相关的
2:42.340–2:44.660
zh职责包含它实际要调取的信息
2:44.660–2:45.528
zh但要是每生成一个Token
2:45.528–2:49.568
zh但要是每生成一个token都重新计算所有这些表征浪费会大的离谱
2:49.568–2:51.208
zh所以模型会把它们存下来
2:51.208–2:53.848
zh这些存储下来的状态就是kb缓存
2:53.848–2:56.308
zhtoken越多kb缓存就越大
2:56.308–2:58.748
zh层数越多kb缓存也越大
2:58.748–3:01.508
zh所以当上下文规模达到100万token时
3:01.508–3:03.948
zh瓶颈就不再只是算力速度了
3:03.948–3:07.028
zhkb缓存带来的延迟和成本问题会逐渐凸显
3:07.028–3:09.468
zh你需要一次性计算搬运的token数量
3:09.468–3:12.728
zh是注意力机制最初设计承载量的10到100倍
3:13.116–3:14.276
zh所有预天穷算力
3:14.276–3:16.796
zhHBM SSD 还有带宽
3:16.796–3:18.836
zh如今都得适配这类需求
3:18.836–3:21.136
zh这是因为我们大量使用智能体工具
3:21.136–3:23.896
zh至少也是当下的模型服务模式导致的
3:23.896–3:26.656
zhV4.1的优化思路从这里开始就很有意思了
3:26.656–3:27.656
zh因为在V4版本中
3:27.656–3:29.356
zh他们已经用压缩吸收注意力
3:29.356–3:32.476
zhCSA将多个Token压缩为更少的KV条目
3:32.476–3:34.316
zh之后再用吸收索引器
3:34.316–3:36.016
zh判断这些压缩后的内存里
3:36.016–3:37.896
zh哪些部分真正值得读取
3:37.896–3:40.656
zh因此为了应对不断增长的上下文长度
3:40.704–3:42.864
zh他们已经采用了大量压缩手段
3:42.864–3:45.084
zh但V4.1 Flash的论文指出
3:45.084–3:48.584
zhKV缓存还会随着模型深度的增加而变大
3:48.584–3:51.244
zh模型深度与模型规模高度相关
3:51.244–3:53.264
zh因为如果想要更大的模型
3:53.264–3:55.244
zh增加深度是最直接的选择之一
3:55.244–3:57.604
zh所以在其他条件相同的情况下
3:57.604–3:59.824
zh从12层增至120层
3:59.824–4:03.104
zh可能意味着要存储约10倍的层专属KV状态
4:03.104–4:05.224
zh即使你激进的压缩上下文本身
4:05.224–4:06.704
zh无论剩下多少KV
4:06.704–4:08.292
zh他们仍会沿网络深度成倍增加
4:09.072–4:10.592
zh这就引出一个问题
4:10.592–4:12.992
zh如果某一层已经生成了有用的
4:12.992–4:14.112
zh全局记忆表示
4:14.112–4:16.892
zh下一层真的需要从头构建一个
4:16.892–4:18.052
zh全新的表示吗
4:18.052–4:19.112
zhDeepsy发现
4:19.112–4:20.592
zh至少对某些层来说
4:20.592–4:21.892
zh答案是否定的
4:21.892–4:23.232
zh这基本上就是压缩
4:23.232–4:24.432
zh吸收注意力2
4:24.432–4:26.272
zhCSAR背后的思路
4:26.272–4:28.052
zh不再只沿Token纬度压缩
4:28.052–4:29.712
zh还开始沿层纬度压缩
4:29.712–4:31.272
zh他们的做法是将注意力层
4:31.272–4:32.612
zh分成三种不同模式
4:32.612–4:33.812
zh完整层模式
4:33.812–4:35.112
zh重索引模式
4:35.112–4:35.880
zh和复用模式
4:36.100–4:38.020
zh完整层会正常执行所有操作
4:38.020–4:40.020
zh它会生成全局KV
4:40.020–4:41.100
zh生成锁引起K
4:41.100–4:42.480
zh运行吸收锁引起
4:42.480–4:44.660
zh并选择自己的TopK记忆条目
4:44.660–4:47.300
zh如果需要快速回顾一下吸收注意力
4:47.300–4:51.060
zh吸收锁引起基本上就是KV缓存的一个低成本搜索引擎
4:51.060–4:53.300
zh它会给缓存的全局KV条目打分
4:53.300–4:55.380
zh选出最相关的TopK条目
4:55.380–4:57.860
zh而注意力只读取这些被选中的条目
4:57.860–5:00.100
zh接下来是重锁引模式
5:00.100–5:03.000
zh该层会使用上一层已经生成的全局KV
5:03.468–5:06.048
zh但它对哪些信息重要可能有不同判断
5:06.048–5:09.488
zh因此它会附用上一层的主KV和索引器K
5:09.488–5:12.788
zh但生成自己的query并重新选择TopK
5:12.788–5:14.368
zh最后一种是附用模式
5:14.368–5:16.368
zh这种模式会附用一切
5:16.368–5:18.528
zh包括主KV和TopK索引
5:18.528–5:21.208
zh甚至不需要再次运行索引器
5:21.208–5:24.428
zh它只对上一层已经选中的内容执行注意力
5:24.428–5:26.368
zh除了改造CSA2之外
5:26.368–5:28.948
zhV4.1 Flash还移除了V4中那种
5:28.948–5:31.056
zh在SWA与HCA或CSA之间
5:31.056–5:33.556
zhHCA或CSA之间交错的混乱混合注意力
5:33.556–5:35.996
zh它们的主要改动是彻底弃用HCA
5:35.996–5:38.996
zh于是全聚分支现在只剩纯CSAR
5:38.996–5:42.696
zh从而得到更简单的CSAR SWA混合架构
5:42.696–5:46.836
zh但即便CSAR已经减少了跨层所需存储的KV量
5:46.836–5:49.476
zh仍存在另一个相当巨大的低效问题
5:49.476–5:52.916
zh因为无论预填充阶段的注意力被压缩到什么程度
5:52.916–5:55.876
zh模型人必须先让所有这些输入Token通过网络
5:55.876–5:57.096
zh才能生成第一个Token
5:57.096–5:58.644
zh设想你给一个常规40层Transformer
5:58.644–5:59.524
zh一个常规40层Transformer
5:59.524–6:01.224
zh输入100万Token的提示词
6:01.224–6:02.824
zh全部100万个Token
6:02.824–6:05.764
zh仍必须从第一层一路通过到第40层
6:05.764–6:07.024
zh对智能体操作来说
6:07.024–6:07.944
zh这相当棘手
6:07.944–6:10.104
zh因为如今模型会不断调用工具
6:10.104–6:10.864
zh读取文件
6:10.864–6:12.004
zh获取搜索结果
6:12.004–6:13.084
zh浏览代码库
6:13.084–6:15.924
zh然后把所有这些再加回上下文理
6:15.924–6:19.244
zh这意味着模型会反复耗费多的离谱的算力
6:19.244–6:20.344
zh只是阅读
6:20.344–6:21.584
zh在推理场景下
6:21.584–6:23.944
zh大多数前沿实验室和推理服务商
6:23.944–6:26.232
zh已经将预填充和解码拆分到不同的
6:26.232–6:28.152
zh解码拆分到不同的GPU集群运行
6:28.152–6:30.792
zh因为这两种工作负载的需求差异极大
6:30.792–6:33.632
zh其中预填充属于算力密集型任务
6:33.632–6:35.892
zh解码则属于内存带宽密集型任务
6:35.892–6:37.492
zhDeepSea也采用了这一做法
6:37.492–6:39.232
zh但在架构层面进行了调整
6:39.232–6:40.852
zh推出了名为CED的方案
6:40.852–6:43.352
zh全称为因果编码器解码器架构
6:43.352–6:45.532
zh实际上CED背后的核心构想
6:45.532–6:46.752
zh并非DeepSea首创
6:46.752–6:50.152
zh这一构想的灵感来自2024年发表的一篇论文
6:50.152–6:52.092
zh论文题为You only catch once
6:52.092–6:52.992
zh简称Yoko
6:52.992–6:53.820
zh优酷方面发现
6:53.820–6:55.600
zhYoko方面发现在常规Transformer架构中
6:55.600–6:58.900
zh每一层都会生成并存储专属的全局KB缓存
6:58.900–7:00.580
zh所以如果模型有40层
7:00.580–7:03.360
zh你实际上要保存40份不同版本的记忆数据
7:03.360–7:05.360
zh为了解决这种重复存储的问题
7:05.360–7:08.280
zh他们提出了名为解码器解码器架构的解决方案
7:08.280–7:10.580
zh模型的下半部分是自解码器
7:10.580–7:14.040
zh通过高效的因果自注意力机制处理输入序列
7:14.040–7:16.260
zh生成提示词的上下文化表示
7:16.260–7:20.340
zh随后Yoko基于下半部分的输出生成共享的全局KB缓存
7:20.340–7:21.408
zh模型上半部分则为交叉
7:21.408–7:22.808
zh模型上半部分则为交叉解码器
7:22.808–7:24.768
zh其中每一层都有独立的query
7:24.768–7:27.568
zh但所有层都会对同一份共享的k和v
7:27.568–7:28.448
zh执行注意力计算
7:28.448–7:30.348
zh这样一来无需每一层都存储
7:30.348–7:32.128
zh各自体量庞大的kv缓存
7:32.128–7:34.308
zhYoko基本上只需要生成一次全局记忆
7:34.308–7:35.528
zh就能供所有层服用
7:35.528–7:38.268
zh这也是其you only cache once命名的由来
7:38.268–7:40.168
zh尽管Yoko将其称为解码器
7:40.168–7:41.088
zh解码器架构
7:41.088–7:42.588
zh但它的训练和使用方式
7:42.588–7:44.768
zh仍与常规自回规语言模型一致
7:44.768–7:46.728
zh这个名称听起来可能和编码器
7:46.728–7:48.048
zh解码器架构相似
7:48.048–7:48.996
zh容易让人联想到他与最终的
7:48.996–7:51.596
zh容易让人联想到它与最初的注意力机制存在关联
7:51.596–7:55.876
zh但它取这个名字仅仅是因为架构包含两种不同类型的解码器
7:55.876–7:57.756
zh下半部分名为自解码器
7:57.756–8:00.496
zh是因为它采用因果资注意力处理序列
8:00.496–8:02.376
zh构建共享的全局KV
8:02.376–8:04.516
zh上半部分名为交叉解码器
8:04.516–8:07.096
zh是因为每个上层都会生成独立的query
8:07.096–8:10.076
zh并对下半部分生成的KV执行交叉注意力计算
8:10.076–8:12.036
zh这种设计还有个更棒的好处
8:12.596–8:15.216
zh既然上半部分只需要用到下半部分生成的KV
8:15.216–8:16.576
zh那么在玉田充阶段
8:16.584–8:17.284
zh严格来说
8:17.284–8:18.844
zh你完全不需要让提示词
8:18.844–8:20.284
zh经过上半部分的计算
8:20.284–8:21.844
zh你只需要超长提示词
8:21.844–8:23.344
zh通过自解码器处理
8:23.344–8:25.224
zh生成共享全局记忆后
8:25.224–8:26.264
zh就可以停止操作
8:26.264–8:26.864
zh这意味着
8:26.864–8:29.104
zhYoko其实首创了这一思路
8:29.104–8:30.824
zh预填充和解码阶段
8:30.824–8:33.064
zh未必要用到同等规模的模型
8:33.064–8:34.084
zh当输入规模
8:34.084–8:35.944
zh甚至达到100万tokens时
8:35.944–8:37.284
zh这个设计思路的优势
8:37.284–8:38.224
zh就十分突出了
8:38.224–8:40.484
zh因此Deepseek借鉴了这一构想
8:40.484–8:41.864
zh并对其进行适配
8:41.864–8:44.024
zh使其能兼容V4的现有架构
8:44.172–8:47.152
zhDeepseek不再把下半部分称为自解码器
8:47.152–8:49.192
zh而是称之为因果编码器
8:49.192–8:53.332
zh它没有像Yoko那样让上半部分共享同一份全局KV
8:53.332–8:59.052
zh而是让每个解码器层从最终编码器表示派生各自的全局KV
8:59.052–9:00.352
zh所以从功能上讲
9:00.352–9:03.292
zhYoko在KV缓存共享方面要激进的多
9:03.292–9:05.312
zh而Deepseek的因果编码器
9:05.312–9:08.432
zh仍会在模型前半部分之后给出这一个最终表示
9:08.432–9:11.760
zh但它并没有把这个表示变成所有层都必须共享的同一层
9:11.760–9:13.580
zh所有层都必须共享的同一份KV缓存
9:13.580–9:15.760
zh而是让每个解码器层
9:15.760–9:19.120
zh都对该最终表示进行各自学习到的投影
9:19.120–9:20.600
zh第20层之后的每一层
9:20.600–9:22.640
zh都可以从该最终表示进行投影
9:22.640–9:24.500
zh并通过各自层专属的权重
9:24.500–9:25.580
zh得到不同结果
9:25.580–9:27.480
zh但这种做法为什么可行呢
9:27.480–9:28.480
zh他们的理由是
9:28.480–9:31.880
zh这是模型当前对该token已知信息的
9:31.880–9:33.700
zh一个庞大的学习性表示
9:33.700–9:36.120
zh因为在经过20个Transformer层之后
9:36.120–9:38.060
zh每个token表示都已经经历了
9:38.060–9:39.348
zh相当深度的上下文处理
9:39.808–9:40.908
zh基本上已经成为一个
9:40.908–9:42.308
zh丰富的公共信息源
9:42.308–9:44.208
zh注意力所使用的K和V
9:44.208–9:44.968
zh基本上就是
9:44.968–9:46.848
zh该信息源的不同学习试图
9:46.848–9:48.468
zh建会确定这条信息
9:48.468–9:49.288
zh要如何表示
9:49.288–9:50.488
zh以便后续的查询
9:50.488–9:51.488
zh能够与它匹配
9:51.848–9:53.988
zh值则决定当它被注意到时
9:53.988–9:55.528
zh应当返回哪一项内容
9:55.528–9:56.548
zh所以通常情况下
9:56.548–9:57.368
zh如果你想得到
9:57.368–9:58.768
zh第35层的KV
9:58.768–9:59.968
zh每个历史提示词
9:59.968–10:00.908
zhToken都必须先
10:00.908–10:02.528
zh实际留进第21层
10:02.528–10:03.828
zh一直到第35层
10:03.828–10:05.148
zh然后第35层
10:05.148–10:06.768
zh再把新的隐藏状态
10:06.936–10:07.836
zh投影成它的KV
10:07.836–10:09.856
zh这里DeepSeek基本上是在质疑
10:09.856–10:11.916
zh仅仅为了创建全局记忆库
10:11.916–10:14.496
zh是否真的需要所有这些非线性计算
10:14.496–10:17.576
zh于是直接砍掉中间的每一个串行流程
10:17.576–10:18.996
zh使用该隐藏状态
10:18.996–10:21.016
zh再交给第35层投影
10:21.016–10:22.556
zh借此获得KV信息
10:22.556–10:25.196
zh不过如果你还记得前面讲过的内容
10:25.196–10:27.756
zhDeepSeek其实并不是每次都为每一层生成
10:27.756–10:29.856
zh完全独立的庞大KV缓存
10:29.856–10:32.756
zhCSAR已经通过三种不同模式
10:32.756–10:34.524
zh让相邻层共享全局KV
10:34.744–10:38.624
zh所以只有真正需要创建新全局KV的解码器层
10:38.624–10:40.704
zh才会用自身层专属的投影
10:40.704–10:43.684
zh直接从最终编码器状态将其派生出来
10:43.684–10:46.164
zh至于每一层具体使用哪种模式
10:46.164–10:49.724
zhDeep Seek几乎是把这些模式硬编码进了层布局中
10:49.724–10:50.784
zh在编码器中
10:50.784–10:53.384
zh前两个仅使用SWA的层之后
10:53.384–10:56.004
zh剩余18层按每6层一组划分
10:56.004–10:58.284
zh一个完整层后面接5个复用层
10:58.284–11:01.644
zh而在解码器中20层按每4层一组划分
11:02.112–11:03.712
zhD组以一个完整层开头
11:03.712–11:05.232
zh后面接三个复用层
11:05.232–11:07.912
zh后面的各组则以一个众索引层开头
11:07.912–11:09.492
zh再接三个复用层
11:09.492–11:10.672
zh所以综合起来看
11:10.672–11:14.012
zh你基本上同时获得了两个层面的成本节省
11:14.012–11:14.572
zh首先
11:14.572–11:18.332
zhCD避免了仅仅为了生成解码器全局KV
11:18.332–11:21.392
zh就让整个预填充跑变模型上半部分
11:21.392–11:21.952
zh相反
11:21.952–11:24.972
zh它直接从最终编码器表示派生这份KV
11:24.972–11:26.832
zh然后借助CSAR
11:26.832–11:29.632
zh一旦某个解码器层生成了这份KV
11:29.700–11:30.540
zh接下来的几层
11:30.540–11:32.000
zh也不一定需要再生成
11:32.000–11:32.740
zh另一份副本
11:32.740–11:33.780
zh而这种组合
11:33.780–11:35.560
zh正是DeepSeq的方案激进的多
11:35.560–11:37.820
zh且专门针对V4.1优化的原因
11:37.820–11:38.640
zh除此之外
11:38.640–11:40.100
zhDeepSeq V4.1的情况
11:40.100–11:41.040
zh也要复杂的多
11:41.040–11:42.340
zh它在每一层中
11:42.340–11:43.340
zh都仍然保留着
11:43.340–11:44.580
zh滑动窗口注意力分支
11:44.580–11:45.880
zh所以每个解码器层
11:45.880–11:47.480
zh其实有两种不同的记忆
11:47.480–11:49.700
zh一种是来自编码器表示
11:49.700–11:52.480
zh并通过CSAR共享的全局记忆
11:52.480–11:53.680
zh另一种是来自
11:53.680–11:55.060
zh该解码器层自身
11:55.060–11:57.120
zh隐藏状态的局部进气记忆
11:57.288–11:58.968
zh所以这里有一点很需要澄清
11:58.968–12:02.348
zhCSAR的KV共享只适用于全局注意力分支
12:02.348–12:05.508
zh这并不意味着滑动窗口注意力的KV缓存
12:05.508–12:06.788
zh会在各层之间共享
12:06.788–12:10.448
zh每个层仍然保留自己的局部SWA KV缓存
12:10.448–12:13.988
zh因为这种局部记忆是由该层实际的隐藏状态产生的
12:13.988–12:17.468
zh因此即使5个CSAR曾共享同一个全局KV
12:17.468–12:20.608
zh它们仍然可以有5份不同的滑动窗口KV缓存
12:20.608–12:21.588
zh除此之外
12:21.588–12:24.748
zhSWA只保留最近的128个TOKENS
12:24.876–12:28.776
zh因此全局KV会随着整个100万Token的上下文增长
12:28.776–12:29.716
zh而运行时
12:29.716–12:33.676
zhSWA缓存实际上始终受限于那个固定窗口
12:33.676–12:36.196
zh但由于它仍未压缩且未每层独有
12:36.196–12:37.756
zh所以仍然不是零成本
12:37.756–12:40.876
zh尤其是要跨大量绘画持久保存这些状态时
12:40.876–12:43.696
zh那么如果我们不共享SWA KV缓存
12:43.696–12:46.936
zh这不就意味着还得把提示词送过这些解码7层吗
12:46.936–12:48.296
zh而麻烦的地方在于
12:48.296–12:52.396
zh这个128Token的窗口实际上会随着层深不断累积
12:52.464–12:55.964
zh第40层的SWA状态依赖第39层
12:55.964–12:58.864
zh第39层本身又依赖更早的局部窗口
12:58.864–12:59.444
zh依此类推
12:59.444–13:02.624
zh所以Deepseek基本上切断了这条依赖链
13:02.624–13:07.264
zh只把最后128个tokens重放给每个解码7层
13:07.264–13:08.584
zh这正是他们所说的
13:08.584–13:11.244
zhSWA有借重放发挥作用的地方
13:11.244–13:14.744
zh所以不是让100万个tokens经过全部40层
13:14.744–13:16.884
zh而是让100万个经过前20层
13:16.884–13:19.144
zh只让128个经过剩下的20层
13:19.144–13:20.052
zh这意味着现在完整的预填
13:20.052–13:21.292
zh这意味着现在完整的预填充成本
13:21.292–13:23.972
zh大致等于完整提示词经过一半模型
13:23.972–13:25.752
zh再加上128个tokens
13:25.752–13:27.092
zh经过其余各层
13:27.092–13:29.572
zh在100万tokens上下文的情况下
13:29.572–13:31.292
zh那128个tokens的重放
13:31.292–13:32.372
zh基本可以忽略不计
13:32.372–13:34.972
zh所以整体预填充仍接近减半
13:34.972–13:37.292
zh虽说只运行这128个tokens
13:37.292–13:39.632
zh重建出的状态严格来说是近似的
13:39.632–13:42.432
zh但Deepseek仍表示对质量的影响微乎其微
13:42.432–13:44.412
zh而且有借重放实际上还带来了
13:44.412–13:45.972
zh另一个相当大的好处
13:45.972–13:47.640
zh因为Deepseek基本意识到
13:47.640–13:49.920
zh基本意识到已经不值得再把SWA-KV缓存
13:49.920–13:51.200
zh当作长期记忆对待了
13:51.200–13:52.420
zh在Deepseek V4中
13:52.420–13:54.600
zh当它们缓存前缀已共复用时
13:54.600–13:56.320
zh固态硬盘上的持久化缓存
13:56.320–13:59.900
zh会同时存储全局KV和SWA-KV缓存
13:59.900–14:00.980
zh令人惊讶的是
14:00.980–14:04.440
zh尽管SWA只覆盖一个很小的局部窗口
14:04.440–14:07.520
zh那些未压缩逐层生成的SWA状态
14:07.520–14:10.380
zh仍几乎占了持久化KV存储的一半
14:10.380–14:11.120
zh除此之外
14:11.120–14:13.200
zh这两种缓存的生命周期完全不同
14:13.200–14:15.228
zh如果同一个长前缀被复用
14:15.588–14:16.848
zh全局KV缓存
14:16.848–14:18.668
zh可能在数小时或数天后
14:18.668–14:19.428
zh仍然有用
14:19.428–14:21.248
zh但SWAKV缓存
14:21.248–14:22.868
zh其实仅对活跃绘画的
14:22.868–14:24.348
zh当前局部状态有用
14:24.348–14:26.028
zh有效期通常只有几分钟
14:26.028–14:27.368
zh因此在V4.1中
14:27.368–14:30.108
zhDeepseek完全不再把SWAKV缓存
14:30.108–14:32.048
zh存入长生命周期的持久化缓存
14:32.048–14:33.968
zh而是将其临时存放在
14:33.968–14:35.928
zh小得多的主机内存池中
14:35.928–14:37.468
zh一旦过期或被驱逐
14:37.468–14:39.608
zh就直接用有界重放重建
14:39.608–14:40.968
zh最后128个Token
14:40.968–14:41.828
zh再来说Token
14:41.828–14:42.728
zh与此同时
14:42.816–14:46.236
zh与此同时全局KV可以存储在固态硬盘这类持久化存储中
14:46.236–14:48.996
zh这部分的持久化KV缩减幅度非常可观
14:48.996–14:55.116
zhCSAR搭配FP4已经能把全局KV压缩到V4时期容量的四分之一左右
14:55.116–14:58.136
zh而将SWAKV移出持久化存储后
14:58.136–15:00.516
zh缓存规模几乎直接再减一半
15:00.516–15:02.056
zh回看V4的设计
15:02.056–15:05.376
zh持久化KV的占用空间大概一半来自SWA
15:05.376–15:07.336
zh另一半来自全局KV
15:07.336–15:10.404
zhV4.1首先通过CSAR和FP4把这占一半
15:10.404–15:12.284
zh和FP4把这占一半的全局KV
15:12.284–15:14.604
zh压缩到原大小的四分之一左右
15:14.604–15:17.124
zh这就使得全局KV本身的占用
15:17.124–15:19.424
zh降至每Token近890字节
15:19.424–15:21.044
zh在HBM存储上
15:21.044–15:23.204
zh直接节省了75%的空间
15:23.204–15:25.504
zh之后再把占一半的SWA KV
15:25.504–15:28.144
zh移出持久化存储固态硬盘存储空间
15:28.144–15:30.324
zh最多可节省87.5%
15:30.324–15:33.184
zh这也让这个总参数量达5520亿的模型
15:33.184–15:34.164
zh在实际运行时
15:34.164–15:36.264
zh呈现出一种很奇特的不对称性
15:36.264–15:37.992
zh因此V4.1仍然属于MOE模型
15:38.732–15:42.632
zh显然它不会为每个Token都激活全部5520亿参数
15:42.632–15:47.412
zh但借助CED与填充阶段的输入Token只需经过20层编码器
15:47.412–15:51.272
zh因此DeepSeq在这阶段仅激活约80亿个参数
15:51.272–15:53.392
zh但模型一旦开始生成内容
15:53.392–15:57.112
zh每个新Token都必须同时经过编码器和解码器
15:57.112–15:59.312
zh激活参数量随之升至160亿
15:59.312–16:02.612
zh所以即便整个模型的总规模几乎是VS Flash的两倍
16:02.612–16:04.852
zh模型中负责大部分繁重输入
16:05.579–16:06.619
zh读取工作的部分其实非常小
16:06.619–16:08.539
zh这对智能体场景非常友好
16:08.539–16:11.239
zh因为这里场景往往要读取几十万token
16:11.239–16:13.839
zh最终却只生成几千个token的内容
16:13.839–16:15.299
zh还有点不可思议的是
16:15.299–16:18.959
zh哪怕上下文从4000token提升到100万token
16:18.959–16:22.339
zh也就是上下文长度扩大到原来的256倍
16:22.339–16:24.139
zh单token解码所需算力
16:24.139–16:26.239
zh也仅从约20加全GFLOPs
16:26.239–16:27.999
zh甚至25加全GFLOPs
16:27.999–16:30.319
zh我认为这次版本更新的所有改动力
16:30.319–16:33.167
zh上述这些新增核心组件是最值得关注的
16:33.267–16:34.467
zh到了这个阶段
16:34.467–16:36.987
zh百万token上下文几乎已经不是这个模型
16:36.987–16:38.227
zh最有冲击力的特性了
16:38.227–16:41.107
zh因此Deepseek开始将注意力转向架构中
16:41.107–16:44.307
zh其他人在浪费内存带宽和算力的环节
16:44.307–16:47.307
zh接下来要讲的是Deepseek在V4.1中
16:47.307–16:50.167
zh重新实现时同样做了优化的其他组件
16:50.547–16:51.747
zh首先是MHC
16:51.747–16:54.947
zh我之前已经做过MHC的相关讲解视频
16:54.947–16:56.247
zh这里就长话短说
16:56.247–17:00.107
zhV4.1针对它的专属改动叫做单路径MHC
17:00.755–17:02.855
zh这种设计基本解决了原先棘手的依赖问题
17:02.855–17:05.635
zh该依赖会迫使GPU多次访问残差流
17:05.635–17:06.835
zh和原有实现相比
17:06.835–17:09.475
zh这种新实现能将仿存流量降低约一半
17:09.475–17:12.235
zh而且这次他们真的把Ngram落地到了模型中
17:12.235–17:14.115
zhDeepseek此前就推出过Ngram
17:14.115–17:18.415
zh它可以把需要记忆的信息和开销高昂的Transformer计算分离开来
17:18.415–17:20.255
zh我也做过Ngram的相关视频
17:20.255–17:23.515
zh但此前他们从未在自家模型中落地过这项设计
17:23.515–17:25.815
zh这种情况直到V4.1才改变
17:25.815–17:28.343
zh他们加入的Ngram总参数量达1960亿分布
17:28.343–17:30.103
zh达1960亿分布在两个模块中
17:30.103–17:31.383
zh所以从技术层面来说
17:31.383–17:33.343
zh该模型总共存储的参数量
17:33.343–17:35.883
zh约为5520亿加1960亿
17:35.883–17:37.443
zh合计7480亿
17:37.443–17:39.943
zh但这多出来的1960亿参数
17:39.943–17:41.963
zh是通过哈希Ngram查照表
17:41.963–17:43.763
zh进行悉数访问的条件记忆
17:43.763–17:46.223
zh而非每个Token都会激活的
17:46.223–17:48.403
zh另外1960亿个稠密参数
17:48.403–17:50.303
zh也就是说Ngram大幅提升了
17:50.303–17:51.403
zh模型的记忆容量
17:51.403–17:53.163
zh但它单Token所需的算力
17:53.163–17:55.423
zh仍和5520亿参数规模的
17:55.423–17:55.931
zhMOE模型相当
17:56.331–17:58.151
zh最后要介绍的是Spark
17:58.151–18:00.171
zh我也做过关于Spark的视频
18:00.171–18:01.391
zh这里简单概括
18:01.391–18:03.791
zh他们用Spark实现了更快的解码速度
18:03.791–18:07.591
zh且无需将草稿模型整合到主干网络的预训练流程中
18:07.591–18:10.871
zh但这次的架构升级并不只局限于文本领域
18:10.871–18:13.691
zhV4.1的另一项重大升级是Deep Seek
18:13.691–18:16.191
zh终于让模型实现了原生多模态
18:16.191–18:20.051
zh他们从零训练了自研视觉编码器Deep Seek VIT
18:20.051–18:23.519
zh随后采用3x3像素合并加混洗的方式压缩视觉特别
18:23.519–18:24.539
zh在混洗的方式压缩视觉特征
18:24.539–18:26.319
zh再将其输入语言模型
18:26.319–18:28.559
zh这一操作将视觉tokens的数量
18:28.559–18:30.079
zh压缩至原来的九分之一
18:30.079–18:31.459
zh同时仍支持分辨率
18:31.459–18:34.579
zh约为1344×1344的图像
18:34.579–18:36.999
zh为了帮你理清我刚才讲到的所有内容
18:36.999–18:38.199
zh我们来完整梳理一下
18:38.199–18:39.799
zh他们搭建的整套模型架构
18:39.799–18:41.639
zh我们从最底层开始讲起
18:41.639–18:43.919
zh模型有文本和图像两类输入
18:43.919–18:44.779
zh二者输入模型后
18:44.779–18:46.499
zh会被合并为一个嵌入项量
18:46.499–18:47.919
zh随后它会经过两个
18:47.919–18:49.339
zh纯滑动窗口注意力层
18:49.339–18:51.107
zh这两层会读取Ngram提供的记忆之后
18:51.627–18:55.187
zh之后会进入配比为1-5的CESAR
18:55.187–18:56.547
zh全量层与复用层
18:56.547–18:57.887
zh该结构会重复三次
18:57.887–19:00.227
zh这样加起来一共是18层
19:00.227–19:03.347
zh算下来英国编码器组件的总层数为20层
19:03.347–19:04.707
zh这里的数字2指的是
19:04.707–19:06.167
zh大约每两个TOKENS
19:06.167–19:08.427
zh会被压缩成一个主KV条目
19:08.427–19:11.467
zh且每个CESAR层都配套有滑动窗口注意力
19:11.467–19:12.587
zh至于MOE部分
19:12.587–19:14.187
zh他们仍在使用DeepseekMOE
19:14.187–19:16.447
zh到这一步为止的所有输出
19:16.447–19:18.695
zh就是供后续层使用的编码器引状态
19:19.155–19:21.215
zh而SWA有介重放机制
19:21.215–19:23.055
zh会直接基于该引状态运行
19:23.055–19:25.695
zh无需从解码器层依次获取数据
19:25.695–19:28.695
zh因此预填充阶段只需要运行英国编码器组件
19:28.695–19:31.675
zh而解码器运行时则需要两个组件同时启动
19:31.675–19:33.555
zh对应的激活参数量为81
19:33.555–19:35.375
zh解码器阶段则为160亿
19:35.375–19:37.235
zh接下来讲解码器的具体层结构
19:37.235–19:39.095
zh第一层是CSAR全量层
19:39.095–19:41.035
zh之后是三层CSAR副用层
19:41.035–19:44.235
zh接着是配比为1比3的重索引与副用结构
19:44.235–19:45.815
zh该结构重复4次
19:46.283–19:49.183
zh这里的数字已表示主KV不会进行Token维度的压缩
19:49.183–19:50.603
zh我个人的理解是
19:50.603–19:54.483
zh这大概率是为了保留完整的Token级分辨率
19:54.483–19:59.363
zh毕竟解码器已经在跨层大规模复用编码器生成的全局KV了
19:59.363–20:02.263
zh但即便采用了CSAR附用重索引层
20:02.263–20:05.443
zh仍然需要重新扫描整个百万级Token的上下文
20:05.443–20:07.963
zh因此DeepSeek加入了分层吸收索引器
20:07.963–20:10.603
zh避免这类搜索再次产生过高的算力开销
20:10.603–20:12.423
zh首个完整层会扫描全部内容
20:12.423–20:13.871
zh构建一个最多包含约1.6万
20:13.871–20:15.691
zh最多包含约1.6万个位置的候选池
20:15.691–20:18.851
zh后续的重锁隐层仅在该候选池内检索
20:18.851–20:20.911
zh筛选出各自排名前512的位置
20:20.911–20:24.731
zh这些层加起来共有20层处理结果会被输入Spark
20:24.731–20:26.751
zh模型架构部分的内容就到这里
20:26.751–20:29.331
zh训练方面也有几处很有意思的改动
20:29.331–20:32.851
zh首先 DeepSeek 没有先训练常规的稠密注意力模型
20:32.851–20:35.291
zh再再之后将其转换为稀疏架构
20:35.291–20:38.631
zhV4.1从0开始直接采用稀疏注意力训练
20:38.631–20:40.811
zh初始上下文长度为6.4万
20:41.459–20:42.859
zh完全没有做稠密注意力预热
20:42.859–20:45.539
zh等训练量达到约34万亿tokens时
20:45.539–20:48.119
zh他们会直接将上下文长度扩展到100万
20:48.119–20:52.359
zh最终在总计45万亿tokens的多莫态数据上完成预训练
20:52.359–20:56.979
zh因此CSAR CED和稀疏检索行为都不是后续才新增的
20:56.979–20:59.599
zh模型实际上是从头学习这些机制的
20:59.599–21:02.199
zh而如果一家实验室能够不依赖稠密注意力
21:02.199–21:04.379
zh从零成功训练出稀疏注意力
21:04.379–21:07.679
zh这通常就意味着这套注意力机制稳定可靠
21:07.679–21:09.047
zh且具备很高的潜力
21:09.347–21:12.027
zh后训练部分的思路转变相当有意思
21:12.027–21:13.787
zh因为Deep Seek明确表示
21:13.787–21:16.607
zh他们这次基本没有推出新的后训练算法
21:16.607–21:18.567
zh他们表示几乎所有提升
21:18.567–21:21.187
zh都来自扩大模型的训练数据规模
21:21.187–21:22.807
zh也就是靠数据扩容
21:22.807–21:25.147
zh而非涉及新的强化学习目标
21:25.147–21:26.927
zh我完全明白这是为什么
21:26.927–21:28.687
zhDeep Seek已拥有最强
21:28.687–21:30.847
zh且最稳定的后训练方案之一
21:30.847–21:31.707
zh批词不变性
21:31.707–21:34.487
zh让强化学习流程的可预测性大幅提升
21:34.487–21:36.635
zh此外还有多教师在线策略蒸流
21:37.195–21:38.415
zh他们现在将其称为
21:38.415–21:40.055
zh大规模同策略蒸流
21:40.055–21:42.095
zhV4.1会向不同领域的
21:42.095–21:44.735
zh40多个各有专攻的教师模型学习
21:44.735–21:46.695
zh这也说明DeepSeek目前认为
21:46.695–21:48.995
zh投入更多时间和资金优化数据
21:48.995–21:51.275
zh比继续研发新的后训练算法
21:51.275–21:52.095
zh更有价值
21:52.095–21:53.695
zh尤其是本篇论文中
21:53.695–21:54.755
zh他们十分重视
21:54.755–21:55.875
zh强化学习数据的
21:55.875–21:57.675
zh自动化合成与环境构建
21:57.675–21:58.435
zh说到底
21:58.435–21:59.815
zh我认为就是垃圾进
21:59.815–22:00.655
zh垃圾出
22:00.655–22:01.675
zh但这也意味着
22:01.675–22:02.815
zh当前的后训练范式
22:02.815–22:03.595
zh在一段时间内
22:04.223–22:05.223
zh可能会少很多有意思的新进展
22:05.223–22:06.243
zh不过客观来说
22:06.243–22:08.123
zhMOPT也是最近才推出的
22:08.123–22:09.943
zh所以这套范式问世的时间
22:09.943–22:11.123
zh本来也不算长
22:11.123–22:12.423
zh不过他们还做了一项
22:12.423–22:14.883
zh我认为之前没有明确提到过的小调整
22:14.883–22:16.443
zh那就是模型合并
22:16.443–22:18.623
zh我也做过一期关于模型合并的视频
22:18.623–22:20.303
zh在强化学习过程中
22:20.303–22:22.663
zh他们会合并来自不同脚手架
22:22.663–22:25.263
zh不同配置的独立训练运行的检查点
22:25.263–22:27.683
zh整合不同优化路径的提升效果
22:27.683–22:29.643
zh在用合并后的模型初始化
22:29.643–22:31.063
zh下一次强化学习运行
22:31.811–22:34.671
zh也就是说模型合并是用来持续汇总各次成功
22:34.671–22:37.671
zh强化学习运行带来的提升等到流程最后
22:37.671–22:41.871
zh他们会在不同领域和训练阶段开展大规模同策略蒸馏
22:41.871–22:45.731
zh将所有专家教师模型的能力整合到同一个模型中
22:45.731–22:48.391
zh另一方面推理力度也有一项升级
22:48.391–22:53.171
zh它不再像V4那样只设置Think High和Think Max模式
22:53.171–22:54.731
zh而是通过强化学习
22:54.731–22:58.651
zh让推理力度成为一个从1到100的数值
22:58.651–22:59.399
zh力度越低
22:59.819–23:00.919
zhToken惩罚越强
23:00.919–23:01.599
zh力度越高
23:01.599–23:04.159
zh就会逐步允许模型使用更多算力
23:04.159–23:04.839
zh因此
23:04.839–23:07.299
zh模型不是训练几个彼此孤立的推理模式
23:07.299–23:09.619
zh而是学会一条平滑的成本质量曲线
23:09.619–23:12.039
zh面向用户的Low High和Max 3档
23:12.039–23:13.879
zh基本上就是同一尺度上
23:13.879–23:16.479
zh力度值为50,75和100的设置
23:16.479–23:17.039
zh好啦
23:17.039–23:19.339
zhV4.1 Flash在技术报告中提出的
23:19.339–23:21.099
zh大部分重要进展就介绍到这里
23:21.099–23:22.999
zh这份51页的技术报告里
23:22.999–23:24.279
zh还有许多技术细节
23:24.279–23:26.419
zh但其中有些内容实在太深奥
23:26.987–23:28.827
zh或者需要更多背景知识才能解释清楚
23:28.827–23:32.087
zh比如DSEC缩放多莫态混合专家均衡
23:32.087–23:33.507
zh以及其他基础设施改进
23:33.507–23:35.007
zh所以如果你们想了解更多
23:35.007–23:36.227
zh一定要去看看他们的论文
23:36.227–23:37.207
zh谢谢大家观看
23:37.207–23:39.267
zh特别感谢Spamatch Chris Ledoux
23:39.267–23:39.987
enDegan
23:39.987–23:41.827
enRoberts Zaviasa
23:41.827–23:42.447
enPoof
23:42.447–23:43.167
enInu
23:43.167–23:44.727
enDX Research Group
23:44.727–23:45.487
enAlex
23:45.487–23:46.847
enLeo Halawani
23:46.847–23:48.807
zh以及其他许多通过Patreon
23:48.807–23:50.967
zh或YouTube支持我的人
23:50.967–23:53.327
zh还没关注我的话到推特上关注我
23:53.327–23:54.447
zh我们下期再见
0:00.000–0:01.720
几个月前我们惊掉下巴
0:01.720–0:03.140
当时发现Deep Seek
0:03.140–0:05.940
基本上重新设计了整个V4模型架构
0:05.940–0:08.880
核心就是让百万Token上下文便宜的离谱
0:08.880–0:13.000
我们花了足足两期总共50分钟的系列视频
0:13.000–0:15.220
拆解它们为打造这样一部杰作
0:15.220–0:15.940
做了什么
0:15.940–0:18.020
所以虽然我们本以为那已经是
0:18.020–0:20.820
有史以来优化最激进的长上下文模型
0:20.820–0:24.280
几周前我们却迎来了Deep Seek V4.1 Flash
0:24.700–0:27.588
这款最新模型的架构改造甚至更疯狂
0:27.608–0:29.668
V4.1Flash的参数量
0:29.668–0:31.628
几乎是V4Flash的2倍
0:31.628–0:35.128
从2840亿增长到5520亿
0:35.128–0:37.728
而且其新架构还做了多方面精简
0:37.728–0:40.028
足以把KV缓存再压缩4倍
0:40.028–0:42.008
为了让你明白这有多厉害
0:42.008–0:43.068
过去9个月里
0:43.068–0:45.428
DeepSeek已经把每个Token的KV
0:45.428–0:47.848
缓存大小压缩了54倍
0:47.848–0:49.708
实在太惊人了
0:49.708–0:51.248
所以在今天的视频里
0:51.248–0:52.108
我们就来看看
0:52.108–0:55.028
DeepSeek是如何降低前沿AI模型成本的
0:55.176–0:57.596
以及他们想出了哪些疯狂的新技术
0:57.596–0:59.156
才让这一切成为可能
0:59.156–1:00.476
总之回到视频正题
1:00.476–1:01.996
现在我觉得很明显
1:01.996–1:03.396
Deep Seek并没有追逐
1:03.396–1:05.156
基准测试中的最先进地位
1:05.156–1:07.476
而是把实际运行大元模型这件事
1:07.476–1:08.476
优化到了极致
1:08.476–1:10.936
你多少能从性能跃升中看出这一点
1:10.936–1:11.856
而事后看来
1:11.856–1:13.616
这种跃升也并不算特别疯狂
1:13.616–1:14.856
但当你进一步细看
1:14.856–1:16.776
他们创造并落地的所有创新
1:16.776–1:18.976
尤其是考虑到模型规模后的
1:18.976–1:20.536
每百万Token价格
1:20.536–1:22.036
他们无疑正在建立一种
1:22.764–1:24.384
其他实验室望尘莫及的惊人优势
1:24.384–1:26.444
而当你站在企业的角度想一想
1:26.444–1:28.824
如果一个模型质量能达到九成
1:28.824–1:30.084
成本却只要1%
1:30.504–1:32.464
你大概率会选这个方案对吧
1:32.464–1:33.904
再往高了吹点
1:33.904–1:35.804
在TerminalBench2.1上
1:35.804–1:39.284
它的成本仅为Opus 5的5%
1:39.284–1:42.244
是GPT5.6艘的5.8%
1:42.244–1:44.444
是KIMI K3的8%
1:44.444–1:46.664
同时性能还超过了这三款模型
1:46.664–1:49.004
这就是Deep Seek的优势所在
1:49.004–1:50.352
这是难度高得多的竞争赛道
1:51.032–1:53.272
因为做优化可比刷宝难多了
1:53.272–1:56.052
在这款全新的V4.1 Flash模型中
1:56.052–1:57.252
它们的核心思路
1:57.252–1:59.852
基本就是如何在做大模型的同时
1:59.852–2:01.992
大幅降低它的内存占用
2:01.992–2:03.272
这是一个优化问题
2:03.272–2:06.332
目标是降低大元模型的使用成本
2:06.332–2:07.232
更具体的说
2:07.232–2:09.792
是降低重度智能体场景的使用成本
2:09.792–2:12.232
因为如今大元模型的大部分工作负载
2:12.232–2:13.212
都需要反复读取
2:13.212–2:15.752
塞满了工具输出和代码库的海量历史记录
2:15.752–2:17.940
Deepsy基本是全新投入优化
2:17.940–2:19.160
投入优化 常上下文下
2:19.160–2:20.720
注意力开销过大的问题
2:20.720–2:22.740
虽然说他们现有的稀疏注意力方案
2:22.740–2:24.260
已经降低了注意力成本
2:24.260–2:25.820
但另一个问题开始浮现
2:25.820–2:27.940
那就是模型仍然需要存储
2:27.940–2:30.820
搬运重新加载巨量的KV缓存
2:30.820–2:32.020
下面我快速讲下
2:32.020–2:33.840
KV缓存和注意力的关系
2:33.840–2:35.600
大元模型生成一个Token时
2:35.600–2:37.220
每个注意力层都需要用到
2:37.220–2:39.280
此前所有Token的缓存键和纸
2:39.280–2:40.680
键主要用来帮它判断
2:40.680–2:42.340
哪些历史信息是相关的
2:42.340–2:44.660
职责包含它实际要调取的信息
2:44.660–2:45.528
但要是每生成一个Token
2:45.528–2:49.568
但要是每生成一个token都重新计算所有这些表征浪费会大的离谱
2:49.568–2:51.208
所以模型会把它们存下来
2:51.208–2:53.848
这些存储下来的状态就是kb缓存
2:53.848–2:56.308
token越多kb缓存就越大
2:56.308–2:58.748
层数越多kb缓存也越大
2:58.748–3:01.508
所以当上下文规模达到100万token时
3:01.508–3:03.948
瓶颈就不再只是算力速度了
3:03.948–3:07.028
kb缓存带来的延迟和成本问题会逐渐凸显
3:07.028–3:09.468
你需要一次性计算搬运的token数量
3:09.468–3:12.728
是注意力机制最初设计承载量的10到100倍
3:13.116–3:14.276
所有预天穷算力
3:14.276–3:16.796
HBM SSD 还有带宽
3:16.796–3:18.836
如今都得适配这类需求
3:18.836–3:21.136
这是因为我们大量使用智能体工具
3:21.136–3:23.896
至少也是当下的模型服务模式导致的
3:23.896–3:26.656
V4.1的优化思路从这里开始就很有意思了
3:26.656–3:27.656
因为在V4版本中
3:27.656–3:29.356
他们已经用压缩吸收注意力
3:29.356–3:32.476
CSA将多个Token压缩为更少的KV条目
3:32.476–3:34.316
之后再用吸收索引器
3:34.316–3:36.016
判断这些压缩后的内存里
3:36.016–3:37.896
哪些部分真正值得读取
3:37.896–3:40.656
因此为了应对不断增长的上下文长度
3:40.704–3:42.864
他们已经采用了大量压缩手段
3:42.864–3:45.084
但V4.1 Flash的论文指出
3:45.084–3:48.584
KV缓存还会随着模型深度的增加而变大
3:48.584–3:51.244
模型深度与模型规模高度相关
3:51.244–3:53.264
因为如果想要更大的模型
3:53.264–3:55.244
增加深度是最直接的选择之一
3:55.244–3:57.604
所以在其他条件相同的情况下
3:57.604–3:59.824
从12层增至120层
3:59.824–4:03.104
可能意味着要存储约10倍的层专属KV状态
4:03.104–4:05.224
即使你激进的压缩上下文本身
4:05.224–4:06.704
无论剩下多少KV
4:06.704–4:08.292
他们仍会沿网络深度成倍增加
4:09.072–4:10.592
这就引出一个问题
4:10.592–4:12.992
如果某一层已经生成了有用的
4:12.992–4:14.112
全局记忆表示
4:14.112–4:16.892
下一层真的需要从头构建一个
4:16.892–4:18.052
全新的表示吗
4:18.052–4:19.112
Deepsy发现
4:19.112–4:20.592
至少对某些层来说
4:20.592–4:21.892
答案是否定的
4:21.892–4:23.232
这基本上就是压缩
4:23.232–4:24.432
吸收注意力2
4:24.432–4:26.272
CSAR背后的思路
4:26.272–4:28.052
不再只沿Token纬度压缩
4:28.052–4:29.712
还开始沿层纬度压缩
4:29.712–4:31.272
他们的做法是将注意力层
4:31.272–4:32.612
分成三种不同模式
4:32.612–4:33.812
完整层模式
4:33.812–4:35.112
重索引模式
4:35.112–4:35.880
和复用模式
4:36.100–4:38.020
完整层会正常执行所有操作
4:38.020–4:40.020
它会生成全局KV
4:40.020–4:41.100
生成锁引起K
4:41.100–4:42.480
运行吸收锁引起
4:42.480–4:44.660
并选择自己的TopK记忆条目
4:44.660–4:47.300
如果需要快速回顾一下吸收注意力
4:47.300–4:51.060
吸收锁引起基本上就是KV缓存的一个低成本搜索引擎
4:51.060–4:53.300
它会给缓存的全局KV条目打分
4:53.300–4:55.380
选出最相关的TopK条目
4:55.380–4:57.860
而注意力只读取这些被选中的条目
4:57.860–5:00.100
接下来是重锁引模式
5:00.100–5:03.000
该层会使用上一层已经生成的全局KV
5:03.468–5:06.048
但它对哪些信息重要可能有不同判断
5:06.048–5:09.488
因此它会附用上一层的主KV和索引器K
5:09.488–5:12.788
但生成自己的query并重新选择TopK
5:12.788–5:14.368
最后一种是附用模式
5:14.368–5:16.368
这种模式会附用一切
5:16.368–5:18.528
包括主KV和TopK索引
5:18.528–5:21.208
甚至不需要再次运行索引器
5:21.208–5:24.428
它只对上一层已经选中的内容执行注意力
5:24.428–5:26.368
除了改造CSA2之外
5:26.368–5:28.948
V4.1 Flash还移除了V4中那种
5:28.948–5:31.056
在SWA与HCA或CSA之间
5:31.056–5:33.556
HCA或CSA之间交错的混乱混合注意力
5:33.556–5:35.996
它们的主要改动是彻底弃用HCA
5:35.996–5:38.996
于是全聚分支现在只剩纯CSAR
5:38.996–5:42.696
从而得到更简单的CSAR SWA混合架构
5:42.696–5:46.836
但即便CSAR已经减少了跨层所需存储的KV量
5:46.836–5:49.476
仍存在另一个相当巨大的低效问题
5:49.476–5:52.916
因为无论预填充阶段的注意力被压缩到什么程度
5:52.916–5:55.876
模型人必须先让所有这些输入Token通过网络
5:55.876–5:57.096
才能生成第一个Token
5:57.096–5:58.644
设想你给一个常规40层Transformer
5:58.644–5:59.524
一个常规40层Transformer
5:59.524–6:01.224
输入100万Token的提示词
6:01.224–6:02.824
全部100万个Token
6:02.824–6:05.764
仍必须从第一层一路通过到第40层
6:05.764–6:07.024
对智能体操作来说
6:07.024–6:07.944
这相当棘手
6:07.944–6:10.104
因为如今模型会不断调用工具
6:10.104–6:10.864
读取文件
6:10.864–6:12.004
获取搜索结果
6:12.004–6:13.084
浏览代码库
6:13.084–6:15.924
然后把所有这些再加回上下文理
6:15.924–6:19.244
这意味着模型会反复耗费多的离谱的算力
6:19.244–6:20.344
只是阅读
6:20.344–6:21.584
在推理场景下
6:21.584–6:23.944
大多数前沿实验室和推理服务商
6:23.944–6:26.232
已经将预填充和解码拆分到不同的
6:26.232–6:28.152
解码拆分到不同的GPU集群运行
6:28.152–6:30.792
因为这两种工作负载的需求差异极大
6:30.792–6:33.632
其中预填充属于算力密集型任务
6:33.632–6:35.892
解码则属于内存带宽密集型任务
6:35.892–6:37.492
DeepSea也采用了这一做法
6:37.492–6:39.232
但在架构层面进行了调整
6:39.232–6:40.852
推出了名为CED的方案
6:40.852–6:43.352
全称为因果编码器解码器架构
6:43.352–6:45.532
实际上CED背后的核心构想
6:45.532–6:46.752
并非DeepSea首创
6:46.752–6:50.152
这一构想的灵感来自2024年发表的一篇论文
6:50.152–6:52.092
论文题为You only catch once
6:52.092–6:52.992
简称Yoko
6:52.992–6:53.820
优酷方面发现
6:53.820–6:55.600
Yoko方面发现在常规Transformer架构中
6:55.600–6:58.900
每一层都会生成并存储专属的全局KB缓存
6:58.900–7:00.580
所以如果模型有40层
7:00.580–7:03.360
你实际上要保存40份不同版本的记忆数据
7:03.360–7:05.360
为了解决这种重复存储的问题
7:05.360–7:08.280
他们提出了名为解码器解码器架构的解决方案
7:08.280–7:10.580
模型的下半部分是自解码器
7:10.580–7:14.040
通过高效的因果自注意力机制处理输入序列
7:14.040–7:16.260
生成提示词的上下文化表示
7:16.260–7:20.340
随后Yoko基于下半部分的输出生成共享的全局KB缓存
7:20.340–7:21.408
模型上半部分则为交叉
7:21.408–7:22.808
模型上半部分则为交叉解码器
7:22.808–7:24.768
其中每一层都有独立的query
7:24.768–7:27.568
但所有层都会对同一份共享的k和v
7:27.568–7:28.448
执行注意力计算
7:28.448–7:30.348
这样一来无需每一层都存储
7:30.348–7:32.128
各自体量庞大的kv缓存
7:32.128–7:34.308
Yoko基本上只需要生成一次全局记忆
7:34.308–7:35.528
就能供所有层服用
7:35.528–7:38.268
这也是其you only cache once命名的由来
7:38.268–7:40.168
尽管Yoko将其称为解码器
7:40.168–7:41.088
解码器架构
7:41.088–7:42.588
但它的训练和使用方式
7:42.588–7:44.768
仍与常规自回规语言模型一致
7:44.768–7:46.728
这个名称听起来可能和编码器
7:46.728–7:48.048
解码器架构相似
7:48.048–7:48.996
容易让人联想到他与最终的
7:48.996–7:51.596
容易让人联想到它与最初的注意力机制存在关联
7:51.596–7:55.876
但它取这个名字仅仅是因为架构包含两种不同类型的解码器
7:55.876–7:57.756
下半部分名为自解码器
7:57.756–8:00.496
是因为它采用因果资注意力处理序列
8:00.496–8:02.376
构建共享的全局KV
8:02.376–8:04.516
上半部分名为交叉解码器
8:04.516–8:07.096
是因为每个上层都会生成独立的query
8:07.096–8:10.076
并对下半部分生成的KV执行交叉注意力计算
8:10.076–8:12.036
这种设计还有个更棒的好处
8:12.596–8:15.216
既然上半部分只需要用到下半部分生成的KV
8:15.216–8:16.576
那么在玉田充阶段
8:16.584–8:17.284
严格来说
8:17.284–8:18.844
你完全不需要让提示词
8:18.844–8:20.284
经过上半部分的计算
8:20.284–8:21.844
你只需要超长提示词
8:21.844–8:23.344
通过自解码器处理
8:23.344–8:25.224
生成共享全局记忆后
8:25.224–8:26.264
就可以停止操作
8:26.264–8:26.864
这意味着
8:26.864–8:29.104
Yoko其实首创了这一思路
8:29.104–8:30.824
预填充和解码阶段
8:30.824–8:33.064
未必要用到同等规模的模型
8:33.064–8:34.084
当输入规模
8:34.084–8:35.944
甚至达到100万tokens时
8:35.944–8:37.284
这个设计思路的优势
8:37.284–8:38.224
就十分突出了
8:38.224–8:40.484
因此Deepseek借鉴了这一构想
8:40.484–8:41.864
并对其进行适配
8:41.864–8:44.024
使其能兼容V4的现有架构
8:44.172–8:47.152
Deepseek不再把下半部分称为自解码器
8:47.152–8:49.192
而是称之为因果编码器
8:49.192–8:53.332
它没有像Yoko那样让上半部分共享同一份全局KV
8:53.332–8:59.052
而是让每个解码器层从最终编码器表示派生各自的全局KV
8:59.052–9:00.352
所以从功能上讲
9:00.352–9:03.292
Yoko在KV缓存共享方面要激进的多
9:03.292–9:05.312
而Deepseek的因果编码器
9:05.312–9:08.432
仍会在模型前半部分之后给出这一个最终表示
9:08.432–9:11.760
但它并没有把这个表示变成所有层都必须共享的同一层
9:11.760–9:13.580
所有层都必须共享的同一份KV缓存
9:13.580–9:15.760
而是让每个解码器层
9:15.760–9:19.120
都对该最终表示进行各自学习到的投影
9:19.120–9:20.600
第20层之后的每一层
9:20.600–9:22.640
都可以从该最终表示进行投影
9:22.640–9:24.500
并通过各自层专属的权重
9:24.500–9:25.580
得到不同结果
9:25.580–9:27.480
但这种做法为什么可行呢
9:27.480–9:28.480
他们的理由是
9:28.480–9:31.880
这是模型当前对该token已知信息的
9:31.880–9:33.700
一个庞大的学习性表示
9:33.700–9:36.120
因为在经过20个Transformer层之后
9:36.120–9:38.060
每个token表示都已经经历了
9:38.060–9:39.348
相当深度的上下文处理
9:39.808–9:40.908
基本上已经成为一个
9:40.908–9:42.308
丰富的公共信息源
9:42.308–9:44.208
注意力所使用的K和V
9:44.208–9:44.968
基本上就是
9:44.968–9:46.848
该信息源的不同学习试图
9:46.848–9:48.468
建会确定这条信息
9:48.468–9:49.288
要如何表示
9:49.288–9:50.488
以便后续的查询
9:50.488–9:51.488
能够与它匹配
9:51.848–9:53.988
值则决定当它被注意到时
9:53.988–9:55.528
应当返回哪一项内容
9:55.528–9:56.548
所以通常情况下
9:56.548–9:57.368
如果你想得到
9:57.368–9:58.768
第35层的KV
9:58.768–9:59.968
每个历史提示词
9:59.968–10:00.908
Token都必须先
10:00.908–10:02.528
实际留进第21层
10:02.528–10:03.828
一直到第35层
10:03.828–10:05.148
然后第35层
10:05.148–10:06.768
再把新的隐藏状态
10:06.936–10:07.836
投影成它的KV
10:07.836–10:09.856
这里DeepSeek基本上是在质疑
10:09.856–10:11.916
仅仅为了创建全局记忆库
10:11.916–10:14.496
是否真的需要所有这些非线性计算
10:14.496–10:17.576
于是直接砍掉中间的每一个串行流程
10:17.576–10:18.996
使用该隐藏状态
10:18.996–10:21.016
再交给第35层投影
10:21.016–10:22.556
借此获得KV信息
10:22.556–10:25.196
不过如果你还记得前面讲过的内容
10:25.196–10:27.756
DeepSeek其实并不是每次都为每一层生成
10:27.756–10:29.856
完全独立的庞大KV缓存
10:29.856–10:32.756
CSAR已经通过三种不同模式
10:32.756–10:34.524
让相邻层共享全局KV
10:34.744–10:38.624
所以只有真正需要创建新全局KV的解码器层
10:38.624–10:40.704
才会用自身层专属的投影
10:40.704–10:43.684
直接从最终编码器状态将其派生出来
10:43.684–10:46.164
至于每一层具体使用哪种模式
10:46.164–10:49.724
Deep Seek几乎是把这些模式硬编码进了层布局中
10:49.724–10:50.784
在编码器中
10:50.784–10:53.384
前两个仅使用SWA的层之后
10:53.384–10:56.004
剩余18层按每6层一组划分
10:56.004–10:58.284
一个完整层后面接5个复用层
10:58.284–11:01.644
而在解码器中20层按每4层一组划分
11:02.112–11:03.712
D组以一个完整层开头
11:03.712–11:05.232
后面接三个复用层
11:05.232–11:07.912
后面的各组则以一个众索引层开头
11:07.912–11:09.492
再接三个复用层
11:09.492–11:10.672
所以综合起来看
11:10.672–11:14.012
你基本上同时获得了两个层面的成本节省
11:14.012–11:14.572
首先
11:14.572–11:18.332
CD避免了仅仅为了生成解码器全局KV
11:18.332–11:21.392
就让整个预填充跑变模型上半部分
11:21.392–11:21.952
相反
11:21.952–11:24.972
它直接从最终编码器表示派生这份KV
11:24.972–11:26.832
然后借助CSAR
11:26.832–11:29.632
一旦某个解码器层生成了这份KV
11:29.700–11:30.540
接下来的几层
11:30.540–11:32.000
也不一定需要再生成
11:32.000–11:32.740
另一份副本
11:32.740–11:33.780
而这种组合
11:33.780–11:35.560
正是DeepSeq的方案激进的多
11:35.560–11:37.820
且专门针对V4.1优化的原因
11:37.820–11:38.640
除此之外
11:38.640–11:40.100
DeepSeq V4.1的情况
11:40.100–11:41.040
也要复杂的多
11:41.040–11:42.340
它在每一层中
11:42.340–11:43.340
都仍然保留着
11:43.340–11:44.580
滑动窗口注意力分支
11:44.580–11:45.880
所以每个解码器层
11:45.880–11:47.480
其实有两种不同的记忆
11:47.480–11:49.700
一种是来自编码器表示
11:49.700–11:52.480
并通过CSAR共享的全局记忆
11:52.480–11:53.680
另一种是来自
11:53.680–11:55.060
该解码器层自身
11:55.060–11:57.120
隐藏状态的局部进气记忆
11:57.288–11:58.968
所以这里有一点很需要澄清
11:58.968–12:02.348
CSAR的KV共享只适用于全局注意力分支
12:02.348–12:05.508
这并不意味着滑动窗口注意力的KV缓存
12:05.508–12:06.788
会在各层之间共享
12:06.788–12:10.448
每个层仍然保留自己的局部SWA KV缓存
12:10.448–12:13.988
因为这种局部记忆是由该层实际的隐藏状态产生的
12:13.988–12:17.468
因此即使5个CSAR曾共享同一个全局KV
12:17.468–12:20.608
它们仍然可以有5份不同的滑动窗口KV缓存
12:20.608–12:21.588
除此之外
12:21.588–12:24.748
SWA只保留最近的128个TOKENS
12:24.876–12:28.776
因此全局KV会随着整个100万Token的上下文增长
12:28.776–12:29.716
而运行时
12:29.716–12:33.676
SWA缓存实际上始终受限于那个固定窗口
12:33.676–12:36.196
但由于它仍未压缩且未每层独有
12:36.196–12:37.756
所以仍然不是零成本
12:37.756–12:40.876
尤其是要跨大量绘画持久保存这些状态时
12:40.876–12:43.696
那么如果我们不共享SWA KV缓存
12:43.696–12:46.936
这不就意味着还得把提示词送过这些解码7层吗
12:46.936–12:48.296
而麻烦的地方在于
12:48.296–12:52.396
这个128Token的窗口实际上会随着层深不断累积
12:52.464–12:55.964
第40层的SWA状态依赖第39层
12:55.964–12:58.864
第39层本身又依赖更早的局部窗口
12:58.864–12:59.444
依此类推
12:59.444–13:02.624
所以Deepseek基本上切断了这条依赖链
13:02.624–13:07.264
只把最后128个tokens重放给每个解码7层
13:07.264–13:08.584
这正是他们所说的
13:08.584–13:11.244
SWA有借重放发挥作用的地方
13:11.244–13:14.744
所以不是让100万个tokens经过全部40层
13:14.744–13:16.884
而是让100万个经过前20层
13:16.884–13:19.144
只让128个经过剩下的20层
13:19.144–13:20.052
这意味着现在完整的预填
13:20.052–13:21.292
这意味着现在完整的预填充成本
13:21.292–13:23.972
大致等于完整提示词经过一半模型
13:23.972–13:25.752
再加上128个tokens
13:25.752–13:27.092
经过其余各层
13:27.092–13:29.572
在100万tokens上下文的情况下
13:29.572–13:31.292
那128个tokens的重放
13:31.292–13:32.372
基本可以忽略不计
13:32.372–13:34.972
所以整体预填充仍接近减半
13:34.972–13:37.292
虽说只运行这128个tokens
13:37.292–13:39.632
重建出的状态严格来说是近似的
13:39.632–13:42.432
但Deepseek仍表示对质量的影响微乎其微
13:42.432–13:44.412
而且有借重放实际上还带来了
13:44.412–13:45.972
另一个相当大的好处
13:45.972–13:47.640
因为Deepseek基本意识到
13:47.640–13:49.920
基本意识到已经不值得再把SWA-KV缓存
13:49.920–13:51.200
当作长期记忆对待了
13:51.200–13:52.420
在Deepseek V4中
13:52.420–13:54.600
当它们缓存前缀已共复用时
13:54.600–13:56.320
固态硬盘上的持久化缓存
13:56.320–13:59.900
会同时存储全局KV和SWA-KV缓存
13:59.900–14:00.980
令人惊讶的是
14:00.980–14:04.440
尽管SWA只覆盖一个很小的局部窗口
14:04.440–14:07.520
那些未压缩逐层生成的SWA状态
14:07.520–14:10.380
仍几乎占了持久化KV存储的一半
14:10.380–14:11.120
除此之外
14:11.120–14:13.200
这两种缓存的生命周期完全不同
14:13.200–14:15.228
如果同一个长前缀被复用
14:15.588–14:16.848
全局KV缓存
14:16.848–14:18.668
可能在数小时或数天后
14:18.668–14:19.428
仍然有用
14:19.428–14:21.248
但SWAKV缓存
14:21.248–14:22.868
其实仅对活跃绘画的
14:22.868–14:24.348
当前局部状态有用
14:24.348–14:26.028
有效期通常只有几分钟
14:26.028–14:27.368
因此在V4.1中
14:27.368–14:30.108
Deepseek完全不再把SWAKV缓存
14:30.108–14:32.048
存入长生命周期的持久化缓存
14:32.048–14:33.968
而是将其临时存放在
14:33.968–14:35.928
小得多的主机内存池中
14:35.928–14:37.468
一旦过期或被驱逐
14:37.468–14:39.608
就直接用有界重放重建
14:39.608–14:40.968
最后128个Token
14:40.968–14:41.828
再来说Token
14:41.828–14:42.728
与此同时
14:42.816–14:46.236
与此同时全局KV可以存储在固态硬盘这类持久化存储中
14:46.236–14:48.996
这部分的持久化KV缩减幅度非常可观
14:48.996–14:55.116
CSAR搭配FP4已经能把全局KV压缩到V4时期容量的四分之一左右
14:55.116–14:58.136
而将SWAKV移出持久化存储后
14:58.136–15:00.516
缓存规模几乎直接再减一半
15:00.516–15:02.056
回看V4的设计
15:02.056–15:05.376
持久化KV的占用空间大概一半来自SWA
15:05.376–15:07.336
另一半来自全局KV
15:07.336–15:10.404
V4.1首先通过CSAR和FP4把这占一半
15:10.404–15:12.284
和FP4把这占一半的全局KV
15:12.284–15:14.604
压缩到原大小的四分之一左右
15:14.604–15:17.124
这就使得全局KV本身的占用
15:17.124–15:19.424
降至每Token近890字节
15:19.424–15:21.044
在HBM存储上
15:21.044–15:23.204
直接节省了75%的空间
15:23.204–15:25.504
之后再把占一半的SWA KV
15:25.504–15:28.144
移出持久化存储固态硬盘存储空间
15:28.144–15:30.324
最多可节省87.5%
15:30.324–15:33.184
这也让这个总参数量达5520亿的模型
15:33.184–15:34.164
在实际运行时
15:34.164–15:36.264
呈现出一种很奇特的不对称性
15:36.264–15:37.992
因此V4.1仍然属于MOE模型
15:38.732–15:42.632
显然它不会为每个Token都激活全部5520亿参数
15:42.632–15:47.412
但借助CED与填充阶段的输入Token只需经过20层编码器
15:47.412–15:51.272
因此DeepSeq在这阶段仅激活约80亿个参数
15:51.272–15:53.392
但模型一旦开始生成内容
15:53.392–15:57.112
每个新Token都必须同时经过编码器和解码器
15:57.112–15:59.312
激活参数量随之升至160亿
15:59.312–16:02.612
所以即便整个模型的总规模几乎是VS Flash的两倍
16:02.612–16:04.852
模型中负责大部分繁重输入
16:05.579–16:06.619
读取工作的部分其实非常小
16:06.619–16:08.539
这对智能体场景非常友好
16:08.539–16:11.239
因为这里场景往往要读取几十万token
16:11.239–16:13.839
最终却只生成几千个token的内容
16:13.839–16:15.299
还有点不可思议的是
16:15.299–16:18.959
哪怕上下文从4000token提升到100万token
16:18.959–16:22.339
也就是上下文长度扩大到原来的256倍
16:22.339–16:24.139
单token解码所需算力
16:24.139–16:26.239
也仅从约20加全GFLOPs
16:26.239–16:27.999
甚至25加全GFLOPs
16:27.999–16:30.319
我认为这次版本更新的所有改动力
16:30.319–16:33.167
上述这些新增核心组件是最值得关注的
16:33.267–16:34.467
到了这个阶段
16:34.467–16:36.987
百万token上下文几乎已经不是这个模型
16:36.987–16:38.227
最有冲击力的特性了
16:38.227–16:41.107
因此Deepseek开始将注意力转向架构中
16:41.107–16:44.307
其他人在浪费内存带宽和算力的环节
16:44.307–16:47.307
接下来要讲的是Deepseek在V4.1中
16:47.307–16:50.167
重新实现时同样做了优化的其他组件
16:50.547–16:51.747
首先是MHC
16:51.747–16:54.947
我之前已经做过MHC的相关讲解视频
16:54.947–16:56.247
这里就长话短说
16:56.247–17:00.107
V4.1针对它的专属改动叫做单路径MHC
17:00.755–17:02.855
这种设计基本解决了原先棘手的依赖问题
17:02.855–17:05.635
该依赖会迫使GPU多次访问残差流
17:05.635–17:06.835
和原有实现相比
17:06.835–17:09.475
这种新实现能将仿存流量降低约一半
17:09.475–17:12.235
而且这次他们真的把Ngram落地到了模型中
17:12.235–17:14.115
Deepseek此前就推出过Ngram
17:14.115–17:18.415
它可以把需要记忆的信息和开销高昂的Transformer计算分离开来
17:18.415–17:20.255
我也做过Ngram的相关视频
17:20.255–17:23.515
但此前他们从未在自家模型中落地过这项设计
17:23.515–17:25.815
这种情况直到V4.1才改变
17:25.815–17:28.343
他们加入的Ngram总参数量达1960亿分布
17:28.343–17:30.103
达1960亿分布在两个模块中
17:30.103–17:31.383
所以从技术层面来说
17:31.383–17:33.343
该模型总共存储的参数量
17:33.343–17:35.883
约为5520亿加1960亿
17:35.883–17:37.443
合计7480亿
17:37.443–17:39.943
但这多出来的1960亿参数
17:39.943–17:41.963
是通过哈希Ngram查照表
17:41.963–17:43.763
进行悉数访问的条件记忆
17:43.763–17:46.223
而非每个Token都会激活的
17:46.223–17:48.403
另外1960亿个稠密参数
17:48.403–17:50.303
也就是说Ngram大幅提升了
17:50.303–17:51.403
模型的记忆容量
17:51.403–17:53.163
但它单Token所需的算力
17:53.163–17:55.423
仍和5520亿参数规模的
17:55.423–17:55.931
MOE模型相当
17:56.331–17:58.151
最后要介绍的是Spark
17:58.151–18:00.171
我也做过关于Spark的视频
18:00.171–18:01.391
这里简单概括
18:01.391–18:03.791
他们用Spark实现了更快的解码速度
18:03.791–18:07.591
且无需将草稿模型整合到主干网络的预训练流程中
18:07.591–18:10.871
但这次的架构升级并不只局限于文本领域
18:10.871–18:13.691
V4.1的另一项重大升级是Deep Seek
18:13.691–18:16.191
终于让模型实现了原生多模态
18:16.191–18:20.051
他们从零训练了自研视觉编码器Deep Seek VIT
18:20.051–18:23.519
随后采用3x3像素合并加混洗的方式压缩视觉特别
18:23.519–18:24.539
在混洗的方式压缩视觉特征
18:24.539–18:26.319
再将其输入语言模型
18:26.319–18:28.559
这一操作将视觉tokens的数量
18:28.559–18:30.079
压缩至原来的九分之一
18:30.079–18:31.459
同时仍支持分辨率
18:31.459–18:34.579
约为1344×1344的图像
18:34.579–18:36.999
为了帮你理清我刚才讲到的所有内容
18:36.999–18:38.199
我们来完整梳理一下
18:38.199–18:39.799
他们搭建的整套模型架构
18:39.799–18:41.639
我们从最底层开始讲起
18:41.639–18:43.919
模型有文本和图像两类输入
18:43.919–18:44.779
二者输入模型后
18:44.779–18:46.499
会被合并为一个嵌入项量
18:46.499–18:47.919
随后它会经过两个
18:47.919–18:49.339
纯滑动窗口注意力层
18:49.339–18:51.107
这两层会读取Ngram提供的记忆之后
18:51.627–18:55.187
之后会进入配比为1-5的CESAR
18:55.187–18:56.547
全量层与复用层
18:56.547–18:57.887
该结构会重复三次
18:57.887–19:00.227
这样加起来一共是18层
19:00.227–19:03.347
算下来英国编码器组件的总层数为20层
19:03.347–19:04.707
这里的数字2指的是
19:04.707–19:06.167
大约每两个TOKENS
19:06.167–19:08.427
会被压缩成一个主KV条目
19:08.427–19:11.467
且每个CESAR层都配套有滑动窗口注意力
19:11.467–19:12.587
至于MOE部分
19:12.587–19:14.187
他们仍在使用DeepseekMOE
19:14.187–19:16.447
到这一步为止的所有输出
19:16.447–19:18.695
就是供后续层使用的编码器引状态
19:19.155–19:21.215
而SWA有介重放机制
19:21.215–19:23.055
会直接基于该引状态运行
19:23.055–19:25.695
无需从解码器层依次获取数据
19:25.695–19:28.695
因此预填充阶段只需要运行英国编码器组件
19:28.695–19:31.675
而解码器运行时则需要两个组件同时启动
19:31.675–19:33.555
对应的激活参数量为81
19:33.555–19:35.375
解码器阶段则为160亿
19:35.375–19:37.235
接下来讲解码器的具体层结构
19:37.235–19:39.095
第一层是CSAR全量层
19:39.095–19:41.035
之后是三层CSAR副用层
19:41.035–19:44.235
接着是配比为1比3的重索引与副用结构
19:44.235–19:45.815
该结构重复4次
19:46.283–19:49.183
这里的数字已表示主KV不会进行Token维度的压缩
19:49.183–19:50.603
我个人的理解是
19:50.603–19:54.483
这大概率是为了保留完整的Token级分辨率
19:54.483–19:59.363
毕竟解码器已经在跨层大规模复用编码器生成的全局KV了
19:59.363–20:02.263
但即便采用了CSAR附用重索引层
20:02.263–20:05.443
仍然需要重新扫描整个百万级Token的上下文
20:05.443–20:07.963
因此DeepSeek加入了分层吸收索引器
20:07.963–20:10.603
避免这类搜索再次产生过高的算力开销
20:10.603–20:12.423
首个完整层会扫描全部内容
20:12.423–20:13.871
构建一个最多包含约1.6万
20:13.871–20:15.691
最多包含约1.6万个位置的候选池
20:15.691–20:18.851
后续的重锁隐层仅在该候选池内检索
20:18.851–20:20.911
筛选出各自排名前512的位置
20:20.911–20:24.731
这些层加起来共有20层处理结果会被输入Spark
20:24.731–20:26.751
模型架构部分的内容就到这里
20:26.751–20:29.331
训练方面也有几处很有意思的改动
20:29.331–20:32.851
首先 DeepSeek 没有先训练常规的稠密注意力模型
20:32.851–20:35.291
再再之后将其转换为稀疏架构
20:35.291–20:38.631
V4.1从0开始直接采用稀疏注意力训练
20:38.631–20:40.811
初始上下文长度为6.4万
20:41.459–20:42.859
完全没有做稠密注意力预热
20:42.859–20:45.539
等训练量达到约34万亿tokens时
20:45.539–20:48.119
他们会直接将上下文长度扩展到100万
20:48.119–20:52.359
最终在总计45万亿tokens的多莫态数据上完成预训练
20:52.359–20:56.979
因此CSAR CED和稀疏检索行为都不是后续才新增的
20:56.979–20:59.599
模型实际上是从头学习这些机制的
20:59.599–21:02.199
而如果一家实验室能够不依赖稠密注意力
21:02.199–21:04.379
从零成功训练出稀疏注意力
21:04.379–21:07.679
这通常就意味着这套注意力机制稳定可靠
21:07.679–21:09.047
且具备很高的潜力
21:09.347–21:12.027
后训练部分的思路转变相当有意思
21:12.027–21:13.787
因为Deep Seek明确表示
21:13.787–21:16.607
他们这次基本没有推出新的后训练算法
21:16.607–21:18.567
他们表示几乎所有提升
21:18.567–21:21.187
都来自扩大模型的训练数据规模
21:21.187–21:22.807
也就是靠数据扩容
21:22.807–21:25.147
而非涉及新的强化学习目标
21:25.147–21:26.927
我完全明白这是为什么
21:26.927–21:28.687
Deep Seek已拥有最强
21:28.687–21:30.847
且最稳定的后训练方案之一
21:30.847–21:31.707
批词不变性
21:31.707–21:34.487
让强化学习流程的可预测性大幅提升
21:34.487–21:36.635
此外还有多教师在线策略蒸流
21:37.195–21:38.415
他们现在将其称为
21:38.415–21:40.055
大规模同策略蒸流
21:40.055–21:42.095
V4.1会向不同领域的
21:42.095–21:44.735
40多个各有专攻的教师模型学习
21:44.735–21:46.695
这也说明DeepSeek目前认为
21:46.695–21:48.995
投入更多时间和资金优化数据
21:48.995–21:51.275
比继续研发新的后训练算法
21:51.275–21:52.095
更有价值
21:52.095–21:53.695
尤其是本篇论文中
21:53.695–21:54.755
他们十分重视
21:54.755–21:55.875
强化学习数据的
21:55.875–21:57.675
自动化合成与环境构建
21:57.675–21:58.435
说到底
21:58.435–21:59.815
我认为就是垃圾进
21:59.815–22:00.655
垃圾出
22:00.655–22:01.675
但这也意味着
22:01.675–22:02.815
当前的后训练范式
22:02.815–22:03.595
在一段时间内
22:04.223–22:05.223
可能会少很多有意思的新进展
22:05.223–22:06.243
不过客观来说
22:06.243–22:08.123
MOPT也是最近才推出的
22:08.123–22:09.943
所以这套范式问世的时间
22:09.943–22:11.123
本来也不算长
22:11.123–22:12.423
不过他们还做了一项
22:12.423–22:14.883
我认为之前没有明确提到过的小调整
22:14.883–22:16.443
那就是模型合并
22:16.443–22:18.623
我也做过一期关于模型合并的视频
22:18.623–22:20.303
在强化学习过程中
22:20.303–22:22.663
他们会合并来自不同脚手架
22:22.663–22:25.263
不同配置的独立训练运行的检查点
22:25.263–22:27.683
整合不同优化路径的提升效果
22:27.683–22:29.643
在用合并后的模型初始化
22:29.643–22:31.063
下一次强化学习运行
22:31.811–22:34.671
也就是说模型合并是用来持续汇总各次成功
22:34.671–22:37.671
强化学习运行带来的提升等到流程最后
22:37.671–22:41.871
他们会在不同领域和训练阶段开展大规模同策略蒸馏
22:41.871–22:45.731
将所有专家教师模型的能力整合到同一个模型中
22:45.731–22:48.391
另一方面推理力度也有一项升级
22:48.391–22:53.171
它不再像V4那样只设置Think High和Think Max模式
22:53.171–22:54.731
而是通过强化学习
22:54.731–22:58.651
让推理力度成为一个从1到100的数值
22:58.651–22:59.399
力度越低
22:59.819–23:00.919
Token惩罚越强
23:00.919–23:01.599
力度越高
23:01.599–23:04.159
就会逐步允许模型使用更多算力
23:04.159–23:04.839
因此
23:04.839–23:07.299
模型不是训练几个彼此孤立的推理模式
23:07.299–23:09.619
而是学会一条平滑的成本质量曲线
23:09.619–23:12.039
面向用户的Low High和Max 3档
23:12.039–23:13.879
基本上就是同一尺度上
23:13.879–23:16.479
力度值为50,75和100的设置
23:16.479–23:17.039
好啦
23:17.039–23:19.339
V4.1 Flash在技术报告中提出的
23:19.339–23:21.099
大部分重要进展就介绍到这里
23:21.099–23:22.999
这份51页的技术报告里
23:22.999–23:24.279
还有许多技术细节
23:24.279–23:26.419
但其中有些内容实在太深奥
23:26.987–23:28.827
或者需要更多背景知识才能解释清楚
23:28.827–23:32.087
比如DSEC缩放多莫态混合专家均衡
23:32.087–23:33.507
以及其他基础设施改进
23:33.507–23:35.007
所以如果你们想了解更多
23:35.007–23:36.227
一定要去看看他们的论文
23:36.227–23:37.207
谢谢大家观看
23:37.207–23:39.267
特别感谢Spamatch Chris Ledoux
23:39.267–23:39.987
（此句尚無繁中翻譯）
23:39.987–23:41.827
（此句尚無繁中翻譯）
23:41.827–23:42.447
（此句尚無繁中翻譯）
23:42.447–23:43.167
（此句尚無繁中翻譯）
23:43.167–23:44.727
（此句尚無繁中翻譯）
23:44.727–23:45.487
（此句尚無繁中翻譯）
23:45.487–23:46.847
（此句尚無繁中翻譯）
23:46.847–23:48.807
以及其他许多通过Patreon
23:48.807–23:50.967
或YouTube支持我的人
23:50.967–23:53.327
还没关注我的话到推特上关注我
23:53.327–23:54.447
我们下期再见
0:00.000–0:01.720
zh几个月前我们惊掉下巴
几个月前我们惊掉下巴
0:01.720–0:03.140
zh当时发现Deep Seek
当时发现Deep Seek
0:03.140–0:05.940
zh基本上重新设计了整个V4模型架构
基本上重新设计了整个V4模型架构
0:05.940–0:08.880
zh核心就是让百万Token上下文便宜的离谱
核心就是让百万Token上下文便宜的离谱
0:08.880–0:13.000
zh我们花了足足两期总共50分钟的系列视频
我们花了足足两期总共50分钟的系列视频
0:13.000–0:15.220
zh拆解它们为打造这样一部杰作
拆解它们为打造这样一部杰作
0:15.220–0:15.940
zh做了什么
做了什么
0:15.940–0:18.020
zh所以虽然我们本以为那已经是
所以虽然我们本以为那已经是
0:18.020–0:20.820
zh有史以来优化最激进的长上下文模型
有史以来优化最激进的长上下文模型
0:20.820–0:24.280
zh几周前我们却迎来了Deep Seek V4.1 Flash
几周前我们却迎来了Deep Seek V4.1 Flash
0:24.700–0:27.588
zh这款最新模型的架构改造甚至更疯狂
这款最新模型的架构改造甚至更疯狂
0:27.608–0:29.668
zhV4.1Flash的参数量
V4.1Flash的参数量
0:29.668–0:31.628
zh几乎是V4Flash的2倍
几乎是V4Flash的2倍
0:31.628–0:35.128
zh从2840亿增长到5520亿
从2840亿增长到5520亿
0:35.128–0:37.728
zh而且其新架构还做了多方面精简
而且其新架构还做了多方面精简
0:37.728–0:40.028
zh足以把KV缓存再压缩4倍
足以把KV缓存再压缩4倍
0:40.028–0:42.008
zh为了让你明白这有多厉害
为了让你明白这有多厉害
0:42.008–0:43.068
zh过去9个月里
过去9个月里
0:43.068–0:45.428
zhDeepSeek已经把每个Token的KV
DeepSeek已经把每个Token的KV
0:45.428–0:47.848
zh缓存大小压缩了54倍
缓存大小压缩了54倍
0:47.848–0:49.708
zh实在太惊人了
实在太惊人了
0:49.708–0:51.248
zh所以在今天的视频里
所以在今天的视频里
0:51.248–0:52.108
zh我们就来看看
我们就来看看
0:52.108–0:55.028
zhDeepSeek是如何降低前沿AI模型成本的
DeepSeek是如何降低前沿AI模型成本的
0:55.176–0:57.596
zh以及他们想出了哪些疯狂的新技术
以及他们想出了哪些疯狂的新技术
0:57.596–0:59.156
zh才让这一切成为可能
才让这一切成为可能
0:59.156–1:00.476
zh总之回到视频正题
总之回到视频正题
1:00.476–1:01.996
zh现在我觉得很明显
现在我觉得很明显
1:01.996–1:03.396
zhDeep Seek并没有追逐
Deep Seek并没有追逐
1:03.396–1:05.156
zh基准测试中的最先进地位
基准测试中的最先进地位
1:05.156–1:07.476
zh而是把实际运行大元模型这件事
而是把实际运行大元模型这件事
1:07.476–1:08.476
zh优化到了极致
优化到了极致
1:08.476–1:10.936
zh你多少能从性能跃升中看出这一点
你多少能从性能跃升中看出这一点
1:10.936–1:11.856
zh而事后看来
而事后看来
1:11.856–1:13.616
zh这种跃升也并不算特别疯狂
这种跃升也并不算特别疯狂
1:13.616–1:14.856
zh但当你进一步细看
但当你进一步细看
1:14.856–1:16.776
zh他们创造并落地的所有创新
他们创造并落地的所有创新
1:16.776–1:18.976
zh尤其是考虑到模型规模后的
尤其是考虑到模型规模后的
1:18.976–1:20.536
zh每百万Token价格
每百万Token价格
1:20.536–1:22.036
zh他们无疑正在建立一种
他们无疑正在建立一种
1:22.764–1:24.384
zh其他实验室望尘莫及的惊人优势
其他实验室望尘莫及的惊人优势
1:24.384–1:26.444
zh而当你站在企业的角度想一想
而当你站在企业的角度想一想
1:26.444–1:28.824
zh如果一个模型质量能达到九成
如果一个模型质量能达到九成
1:28.824–1:30.084
zh成本却只要1%
成本却只要1%
1:30.504–1:32.464
zh你大概率会选这个方案对吧
你大概率会选这个方案对吧
1:32.464–1:33.904
zh再往高了吹点
再往高了吹点
1:33.904–1:35.804
zh在TerminalBench2.1上
在TerminalBench2.1上
1:35.804–1:39.284
zh它的成本仅为Opus 5的5%
它的成本仅为Opus 5的5%
1:39.284–1:42.244
zh是GPT5.6艘的5.8%
是GPT5.6艘的5.8%
1:42.244–1:44.444
zh是KIMI K3的8%
是KIMI K3的8%
1:44.444–1:46.664
zh同时性能还超过了这三款模型
同时性能还超过了这三款模型
1:46.664–1:49.004
zh这就是Deep Seek的优势所在
这就是Deep Seek的优势所在
1:49.004–1:50.352
zh这是难度高得多的竞争赛道
这是难度高得多的竞争赛道
1:51.032–1:53.272
zh因为做优化可比刷宝难多了
因为做优化可比刷宝难多了
1:53.272–1:56.052
zh在这款全新的V4.1 Flash模型中
在这款全新的V4.1 Flash模型中
1:56.052–1:57.252
zh它们的核心思路
它们的核心思路
1:57.252–1:59.852
zh基本就是如何在做大模型的同时
基本就是如何在做大模型的同时
1:59.852–2:01.992
zh大幅降低它的内存占用
大幅降低它的内存占用
2:01.992–2:03.272
zh这是一个优化问题
这是一个优化问题
2:03.272–2:06.332
zh目标是降低大元模型的使用成本
目标是降低大元模型的使用成本
2:06.332–2:07.232
zh更具体的说
更具体的说
2:07.232–2:09.792
zh是降低重度智能体场景的使用成本
是降低重度智能体场景的使用成本
2:09.792–2:12.232
zh因为如今大元模型的大部分工作负载
因为如今大元模型的大部分工作负载
2:12.232–2:13.212
zh都需要反复读取
都需要反复读取
2:13.212–2:15.752
zh塞满了工具输出和代码库的海量历史记录
塞满了工具输出和代码库的海量历史记录
2:15.752–2:17.940
zhDeepsy基本是全新投入优化
Deepsy基本是全新投入优化
2:17.940–2:19.160
zh投入优化 常上下文下
投入优化 常上下文下
2:19.160–2:20.720
zh注意力开销过大的问题
注意力开销过大的问题
2:20.720–2:22.740
zh虽然说他们现有的稀疏注意力方案
虽然说他们现有的稀疏注意力方案
2:22.740–2:24.260
zh已经降低了注意力成本
已经降低了注意力成本
2:24.260–2:25.820
zh但另一个问题开始浮现
但另一个问题开始浮现
2:25.820–2:27.940
zh那就是模型仍然需要存储
那就是模型仍然需要存储
2:27.940–2:30.820
zh搬运重新加载巨量的KV缓存
搬运重新加载巨量的KV缓存
2:30.820–2:32.020
zh下面我快速讲下
下面我快速讲下
2:32.020–2:33.840
zhKV缓存和注意力的关系
KV缓存和注意力的关系
2:33.840–2:35.600
zh大元模型生成一个Token时
大元模型生成一个Token时
2:35.600–2:37.220
zh每个注意力层都需要用到
每个注意力层都需要用到
2:37.220–2:39.280
zh此前所有Token的缓存键和纸
此前所有Token的缓存键和纸
2:39.280–2:40.680
zh键主要用来帮它判断
键主要用来帮它判断
2:40.680–2:42.340
zh哪些历史信息是相关的
哪些历史信息是相关的
2:42.340–2:44.660
zh职责包含它实际要调取的信息
职责包含它实际要调取的信息
2:44.660–2:45.528
zh但要是每生成一个Token
但要是每生成一个Token
2:45.528–2:49.568
zh但要是每生成一个token都重新计算所有这些表征浪费会大的离谱
但要是每生成一个token都重新计算所有这些表征浪费会大的离谱
2:49.568–2:51.208
zh所以模型会把它们存下来
所以模型会把它们存下来
2:51.208–2:53.848
zh这些存储下来的状态就是kb缓存
这些存储下来的状态就是kb缓存
2:53.848–2:56.308
zhtoken越多kb缓存就越大
token越多kb缓存就越大
2:56.308–2:58.748
zh层数越多kb缓存也越大
层数越多kb缓存也越大
2:58.748–3:01.508
zh所以当上下文规模达到100万token时
所以当上下文规模达到100万token时
3:01.508–3:03.948
zh瓶颈就不再只是算力速度了
瓶颈就不再只是算力速度了
3:03.948–3:07.028
zhkb缓存带来的延迟和成本问题会逐渐凸显
kb缓存带来的延迟和成本问题会逐渐凸显
3:07.028–3:09.468
zh你需要一次性计算搬运的token数量
你需要一次性计算搬运的token数量
3:09.468–3:12.728
zh是注意力机制最初设计承载量的10到100倍
是注意力机制最初设计承载量的10到100倍
3:13.116–3:14.276
zh所有预天穷算力
所有预天穷算力
3:14.276–3:16.796
zhHBM SSD 还有带宽
HBM SSD 还有带宽
3:16.796–3:18.836
zh如今都得适配这类需求
如今都得适配这类需求
3:18.836–3:21.136
zh这是因为我们大量使用智能体工具
这是因为我们大量使用智能体工具
3:21.136–3:23.896
zh至少也是当下的模型服务模式导致的
至少也是当下的模型服务模式导致的
3:23.896–3:26.656
zhV4.1的优化思路从这里开始就很有意思了
V4.1的优化思路从这里开始就很有意思了
3:26.656–3:27.656
zh因为在V4版本中
因为在V4版本中
3:27.656–3:29.356
zh他们已经用压缩吸收注意力
他们已经用压缩吸收注意力
3:29.356–3:32.476
zhCSA将多个Token压缩为更少的KV条目
CSA将多个Token压缩为更少的KV条目
3:32.476–3:34.316
zh之后再用吸收索引器
之后再用吸收索引器
3:34.316–3:36.016
zh判断这些压缩后的内存里
判断这些压缩后的内存里
3:36.016–3:37.896
zh哪些部分真正值得读取
哪些部分真正值得读取
3:37.896–3:40.656
zh因此为了应对不断增长的上下文长度
因此为了应对不断增长的上下文长度
3:40.704–3:42.864
zh他们已经采用了大量压缩手段
他们已经采用了大量压缩手段
3:42.864–3:45.084
zh但V4.1 Flash的论文指出
但V4.1 Flash的论文指出
3:45.084–3:48.584
zhKV缓存还会随着模型深度的增加而变大
KV缓存还会随着模型深度的增加而变大
3:48.584–3:51.244
zh模型深度与模型规模高度相关
模型深度与模型规模高度相关
3:51.244–3:53.264
zh因为如果想要更大的模型
因为如果想要更大的模型
3:53.264–3:55.244
zh增加深度是最直接的选择之一
增加深度是最直接的选择之一
3:55.244–3:57.604
zh所以在其他条件相同的情况下
所以在其他条件相同的情况下
3:57.604–3:59.824
zh从12层增至120层
从12层增至120层
3:59.824–4:03.104
zh可能意味着要存储约10倍的层专属KV状态
可能意味着要存储约10倍的层专属KV状态
4:03.104–4:05.224
zh即使你激进的压缩上下文本身
即使你激进的压缩上下文本身
4:05.224–4:06.704
zh无论剩下多少KV
无论剩下多少KV
4:06.704–4:08.292
zh他们仍会沿网络深度成倍增加
他们仍会沿网络深度成倍增加
4:09.072–4:10.592
zh这就引出一个问题
这就引出一个问题
4:10.592–4:12.992
zh如果某一层已经生成了有用的
如果某一层已经生成了有用的
4:12.992–4:14.112
zh全局记忆表示
全局记忆表示
4:14.112–4:16.892
zh下一层真的需要从头构建一个
下一层真的需要从头构建一个
4:16.892–4:18.052
zh全新的表示吗
全新的表示吗
4:18.052–4:19.112
zhDeepsy发现
Deepsy发现
4:19.112–4:20.592
zh至少对某些层来说
至少对某些层来说
4:20.592–4:21.892
zh答案是否定的
答案是否定的
4:21.892–4:23.232
zh这基本上就是压缩
这基本上就是压缩
4:23.232–4:24.432
zh吸收注意力2
吸收注意力2
4:24.432–4:26.272
zhCSAR背后的思路
CSAR背后的思路
4:26.272–4:28.052
zh不再只沿Token纬度压缩
不再只沿Token纬度压缩
4:28.052–4:29.712
zh还开始沿层纬度压缩
还开始沿层纬度压缩
4:29.712–4:31.272
zh他们的做法是将注意力层
他们的做法是将注意力层
4:31.272–4:32.612
zh分成三种不同模式
分成三种不同模式
4:32.612–4:33.812
zh完整层模式
完整层模式
4:33.812–4:35.112
zh重索引模式
重索引模式
4:35.112–4:35.880
zh和复用模式
和复用模式
4:36.100–4:38.020
zh完整层会正常执行所有操作
完整层会正常执行所有操作
4:38.020–4:40.020
zh它会生成全局KV
它会生成全局KV
4:40.020–4:41.100
zh生成锁引起K
生成锁引起K
4:41.100–4:42.480
zh运行吸收锁引起
运行吸收锁引起
4:42.480–4:44.660
zh并选择自己的TopK记忆条目
并选择自己的TopK记忆条目
4:44.660–4:47.300
zh如果需要快速回顾一下吸收注意力
如果需要快速回顾一下吸收注意力
4:47.300–4:51.060
zh吸收锁引起基本上就是KV缓存的一个低成本搜索引擎
吸收锁引起基本上就是KV缓存的一个低成本搜索引擎
4:51.060–4:53.300
zh它会给缓存的全局KV条目打分
它会给缓存的全局KV条目打分
4:53.300–4:55.380
zh选出最相关的TopK条目
选出最相关的TopK条目
4:55.380–4:57.860
zh而注意力只读取这些被选中的条目
而注意力只读取这些被选中的条目
4:57.860–5:00.100
zh接下来是重锁引模式
接下来是重锁引模式
5:00.100–5:03.000
zh该层会使用上一层已经生成的全局KV
该层会使用上一层已经生成的全局KV
5:03.468–5:06.048
zh但它对哪些信息重要可能有不同判断
但它对哪些信息重要可能有不同判断
5:06.048–5:09.488
zh因此它会附用上一层的主KV和索引器K
因此它会附用上一层的主KV和索引器K
5:09.488–5:12.788
zh但生成自己的query并重新选择TopK
但生成自己的query并重新选择TopK
5:12.788–5:14.368
zh最后一种是附用模式
最后一种是附用模式
5:14.368–5:16.368
zh这种模式会附用一切
这种模式会附用一切
5:16.368–5:18.528
zh包括主KV和TopK索引
包括主KV和TopK索引
5:18.528–5:21.208
zh甚至不需要再次运行索引器
甚至不需要再次运行索引器
5:21.208–5:24.428
zh它只对上一层已经选中的内容执行注意力
它只对上一层已经选中的内容执行注意力
5:24.428–5:26.368
zh除了改造CSA2之外
除了改造CSA2之外
5:26.368–5:28.948
zhV4.1 Flash还移除了V4中那种
V4.1 Flash还移除了V4中那种
5:28.948–5:31.056
zh在SWA与HCA或CSA之间
在SWA与HCA或CSA之间
5:31.056–5:33.556
zhHCA或CSA之间交错的混乱混合注意力
HCA或CSA之间交错的混乱混合注意力
5:33.556–5:35.996
zh它们的主要改动是彻底弃用HCA
它们的主要改动是彻底弃用HCA
5:35.996–5:38.996
zh于是全聚分支现在只剩纯CSAR
于是全聚分支现在只剩纯CSAR
5:38.996–5:42.696
zh从而得到更简单的CSAR SWA混合架构
从而得到更简单的CSAR SWA混合架构
5:42.696–5:46.836
zh但即便CSAR已经减少了跨层所需存储的KV量
但即便CSAR已经减少了跨层所需存储的KV量
5:46.836–5:49.476
zh仍存在另一个相当巨大的低效问题
仍存在另一个相当巨大的低效问题
5:49.476–5:52.916
zh因为无论预填充阶段的注意力被压缩到什么程度
因为无论预填充阶段的注意力被压缩到什么程度
5:52.916–5:55.876
zh模型人必须先让所有这些输入Token通过网络
模型人必须先让所有这些输入Token通过网络
5:55.876–5:57.096
zh才能生成第一个Token
才能生成第一个Token
5:57.096–5:58.644
zh设想你给一个常规40层Transformer
设想你给一个常规40层Transformer
5:58.644–5:59.524
zh一个常规40层Transformer
一个常规40层Transformer
5:59.524–6:01.224
zh输入100万Token的提示词
输入100万Token的提示词
6:01.224–6:02.824
zh全部100万个Token
全部100万个Token
6:02.824–6:05.764
zh仍必须从第一层一路通过到第40层
仍必须从第一层一路通过到第40层
6:05.764–6:07.024
zh对智能体操作来说
对智能体操作来说
6:07.024–6:07.944
zh这相当棘手
这相当棘手
6:07.944–6:10.104
zh因为如今模型会不断调用工具
因为如今模型会不断调用工具
6:10.104–6:10.864
zh读取文件
读取文件
6:10.864–6:12.004
zh获取搜索结果
获取搜索结果
6:12.004–6:13.084
zh浏览代码库
浏览代码库
6:13.084–6:15.924
zh然后把所有这些再加回上下文理
然后把所有这些再加回上下文理
6:15.924–6:19.244
zh这意味着模型会反复耗费多的离谱的算力
这意味着模型会反复耗费多的离谱的算力
6:19.244–6:20.344
zh只是阅读
只是阅读
6:20.344–6:21.584
zh在推理场景下
在推理场景下
6:21.584–6:23.944
zh大多数前沿实验室和推理服务商
大多数前沿实验室和推理服务商
6:23.944–6:26.232
zh已经将预填充和解码拆分到不同的
已经将预填充和解码拆分到不同的
6:26.232–6:28.152
zh解码拆分到不同的GPU集群运行
解码拆分到不同的GPU集群运行
6:28.152–6:30.792
zh因为这两种工作负载的需求差异极大
因为这两种工作负载的需求差异极大
6:30.792–6:33.632
zh其中预填充属于算力密集型任务
其中预填充属于算力密集型任务
6:33.632–6:35.892
zh解码则属于内存带宽密集型任务
解码则属于内存带宽密集型任务
6:35.892–6:37.492
zhDeepSea也采用了这一做法
DeepSea也采用了这一做法
6:37.492–6:39.232
zh但在架构层面进行了调整
但在架构层面进行了调整
6:39.232–6:40.852
zh推出了名为CED的方案
推出了名为CED的方案
6:40.852–6:43.352
zh全称为因果编码器解码器架构
全称为因果编码器解码器架构
6:43.352–6:45.532
zh实际上CED背后的核心构想
实际上CED背后的核心构想
6:45.532–6:46.752
zh并非DeepSea首创
并非DeepSea首创
6:46.752–6:50.152
zh这一构想的灵感来自2024年发表的一篇论文
这一构想的灵感来自2024年发表的一篇论文
6:50.152–6:52.092
zh论文题为You only catch once
论文题为You only catch once
6:52.092–6:52.992
zh简称Yoko
简称Yoko
6:52.992–6:53.820
zh优酷方面发现
优酷方面发现
6:53.820–6:55.600
zhYoko方面发现在常规Transformer架构中
Yoko方面发现在常规Transformer架构中
6:55.600–6:58.900
zh每一层都会生成并存储专属的全局KB缓存
每一层都会生成并存储专属的全局KB缓存
6:58.900–7:00.580
zh所以如果模型有40层
所以如果模型有40层
7:00.580–7:03.360
zh你实际上要保存40份不同版本的记忆数据
你实际上要保存40份不同版本的记忆数据
7:03.360–7:05.360
zh为了解决这种重复存储的问题
为了解决这种重复存储的问题
7:05.360–7:08.280
zh他们提出了名为解码器解码器架构的解决方案
他们提出了名为解码器解码器架构的解决方案
7:08.280–7:10.580
zh模型的下半部分是自解码器
模型的下半部分是自解码器
7:10.580–7:14.040
zh通过高效的因果自注意力机制处理输入序列
通过高效的因果自注意力机制处理输入序列
7:14.040–7:16.260
zh生成提示词的上下文化表示
生成提示词的上下文化表示
7:16.260–7:20.340
zh随后Yoko基于下半部分的输出生成共享的全局KB缓存
随后Yoko基于下半部分的输出生成共享的全局KB缓存
7:20.340–7:21.408
zh模型上半部分则为交叉
模型上半部分则为交叉
7:21.408–7:22.808
zh模型上半部分则为交叉解码器
模型上半部分则为交叉解码器
7:22.808–7:24.768
zh其中每一层都有独立的query
其中每一层都有独立的query
7:24.768–7:27.568
zh但所有层都会对同一份共享的k和v
但所有层都会对同一份共享的k和v
7:27.568–7:28.448
zh执行注意力计算
执行注意力计算
7:28.448–7:30.348
zh这样一来无需每一层都存储
这样一来无需每一层都存储
7:30.348–7:32.128
zh各自体量庞大的kv缓存
各自体量庞大的kv缓存
7:32.128–7:34.308
zhYoko基本上只需要生成一次全局记忆
Yoko基本上只需要生成一次全局记忆
7:34.308–7:35.528
zh就能供所有层服用
就能供所有层服用
7:35.528–7:38.268
zh这也是其you only cache once命名的由来
这也是其you only cache once命名的由来
7:38.268–7:40.168
zh尽管Yoko将其称为解码器
尽管Yoko将其称为解码器
7:40.168–7:41.088
zh解码器架构
解码器架构
7:41.088–7:42.588
zh但它的训练和使用方式
但它的训练和使用方式
7:42.588–7:44.768
zh仍与常规自回规语言模型一致
仍与常规自回规语言模型一致
7:44.768–7:46.728
zh这个名称听起来可能和编码器
这个名称听起来可能和编码器
7:46.728–7:48.048
zh解码器架构相似
解码器架构相似
7:48.048–7:48.996
zh容易让人联想到他与最终的
容易让人联想到他与最终的
7:48.996–7:51.596
zh容易让人联想到它与最初的注意力机制存在关联
容易让人联想到它与最初的注意力机制存在关联
7:51.596–7:55.876
zh但它取这个名字仅仅是因为架构包含两种不同类型的解码器
但它取这个名字仅仅是因为架构包含两种不同类型的解码器
7:55.876–7:57.756
zh下半部分名为自解码器
下半部分名为自解码器
7:57.756–8:00.496
zh是因为它采用因果资注意力处理序列
是因为它采用因果资注意力处理序列
8:00.496–8:02.376
zh构建共享的全局KV
构建共享的全局KV
8:02.376–8:04.516
zh上半部分名为交叉解码器
上半部分名为交叉解码器
8:04.516–8:07.096
zh是因为每个上层都会生成独立的query
是因为每个上层都会生成独立的query
8:07.096–8:10.076
zh并对下半部分生成的KV执行交叉注意力计算
并对下半部分生成的KV执行交叉注意力计算
8:10.076–8:12.036
zh这种设计还有个更棒的好处
这种设计还有个更棒的好处
8:12.596–8:15.216
zh既然上半部分只需要用到下半部分生成的KV
既然上半部分只需要用到下半部分生成的KV
8:15.216–8:16.576
zh那么在玉田充阶段
那么在玉田充阶段
8:16.584–8:17.284
zh严格来说
严格来说
8:17.284–8:18.844
zh你完全不需要让提示词
你完全不需要让提示词
8:18.844–8:20.284
zh经过上半部分的计算
经过上半部分的计算
8:20.284–8:21.844
zh你只需要超长提示词
你只需要超长提示词
8:21.844–8:23.344
zh通过自解码器处理
通过自解码器处理
8:23.344–8:25.224
zh生成共享全局记忆后
生成共享全局记忆后
8:25.224–8:26.264
zh就可以停止操作
就可以停止操作
8:26.264–8:26.864
zh这意味着
这意味着
8:26.864–8:29.104
zhYoko其实首创了这一思路
Yoko其实首创了这一思路
8:29.104–8:30.824
zh预填充和解码阶段
预填充和解码阶段
8:30.824–8:33.064
zh未必要用到同等规模的模型
未必要用到同等规模的模型
8:33.064–8:34.084
zh当输入规模
当输入规模
8:34.084–8:35.944
zh甚至达到100万tokens时
甚至达到100万tokens时
8:35.944–8:37.284
zh这个设计思路的优势
这个设计思路的优势
8:37.284–8:38.224
zh就十分突出了
就十分突出了
8:38.224–8:40.484
zh因此Deepseek借鉴了这一构想
因此Deepseek借鉴了这一构想
8:40.484–8:41.864
zh并对其进行适配
并对其进行适配
8:41.864–8:44.024
zh使其能兼容V4的现有架构
使其能兼容V4的现有架构
8:44.172–8:47.152
zhDeepseek不再把下半部分称为自解码器
Deepseek不再把下半部分称为自解码器
8:47.152–8:49.192
zh而是称之为因果编码器
而是称之为因果编码器
8:49.192–8:53.332
zh它没有像Yoko那样让上半部分共享同一份全局KV
它没有像Yoko那样让上半部分共享同一份全局KV
8:53.332–8:59.052
zh而是让每个解码器层从最终编码器表示派生各自的全局KV
而是让每个解码器层从最终编码器表示派生各自的全局KV
8:59.052–9:00.352
zh所以从功能上讲
所以从功能上讲
9:00.352–9:03.292
zhYoko在KV缓存共享方面要激进的多
Yoko在KV缓存共享方面要激进的多
9:03.292–9:05.312
zh而Deepseek的因果编码器
而Deepseek的因果编码器
9:05.312–9:08.432
zh仍会在模型前半部分之后给出这一个最终表示
仍会在模型前半部分之后给出这一个最终表示
9:08.432–9:11.760
zh但它并没有把这个表示变成所有层都必须共享的同一层
但它并没有把这个表示变成所有层都必须共享的同一层
9:11.760–9:13.580
zh所有层都必须共享的同一份KV缓存
所有层都必须共享的同一份KV缓存
9:13.580–9:15.760
zh而是让每个解码器层
而是让每个解码器层
9:15.760–9:19.120
zh都对该最终表示进行各自学习到的投影
都对该最终表示进行各自学习到的投影
9:19.120–9:20.600
zh第20层之后的每一层
第20层之后的每一层
9:20.600–9:22.640
zh都可以从该最终表示进行投影
都可以从该最终表示进行投影
9:22.640–9:24.500
zh并通过各自层专属的权重
并通过各自层专属的权重
9:24.500–9:25.580
zh得到不同结果
得到不同结果
9:25.580–9:27.480
zh但这种做法为什么可行呢
但这种做法为什么可行呢
9:27.480–9:28.480
zh他们的理由是
他们的理由是
9:28.480–9:31.880
zh这是模型当前对该token已知信息的
这是模型当前对该token已知信息的
9:31.880–9:33.700
zh一个庞大的学习性表示
一个庞大的学习性表示
9:33.700–9:36.120
zh因为在经过20个Transformer层之后
因为在经过20个Transformer层之后
9:36.120–9:38.060
zh每个token表示都已经经历了
每个token表示都已经经历了
9:38.060–9:39.348
zh相当深度的上下文处理
相当深度的上下文处理
9:39.808–9:40.908
zh基本上已经成为一个
基本上已经成为一个
9:40.908–9:42.308
zh丰富的公共信息源
丰富的公共信息源
9:42.308–9:44.208
zh注意力所使用的K和V
注意力所使用的K和V
9:44.208–9:44.968
zh基本上就是
基本上就是
9:44.968–9:46.848
zh该信息源的不同学习试图
该信息源的不同学习试图
9:46.848–9:48.468
zh建会确定这条信息
建会确定这条信息
9:48.468–9:49.288
zh要如何表示
要如何表示
9:49.288–9:50.488
zh以便后续的查询
以便后续的查询
9:50.488–9:51.488
zh能够与它匹配
能够与它匹配
9:51.848–9:53.988
zh值则决定当它被注意到时
值则决定当它被注意到时
9:53.988–9:55.528
zh应当返回哪一项内容
应当返回哪一项内容
9:55.528–9:56.548
zh所以通常情况下
所以通常情况下
9:56.548–9:57.368
zh如果你想得到
如果你想得到
9:57.368–9:58.768
zh第35层的KV
第35层的KV
9:58.768–9:59.968
zh每个历史提示词
每个历史提示词
9:59.968–10:00.908
zhToken都必须先
Token都必须先
10:00.908–10:02.528
zh实际留进第21层
实际留进第21层
10:02.528–10:03.828
zh一直到第35层
一直到第35层
10:03.828–10:05.148
zh然后第35层
然后第35层
10:05.148–10:06.768
zh再把新的隐藏状态
再把新的隐藏状态
10:06.936–10:07.836
zh投影成它的KV
投影成它的KV
10:07.836–10:09.856
zh这里DeepSeek基本上是在质疑
这里DeepSeek基本上是在质疑
10:09.856–10:11.916
zh仅仅为了创建全局记忆库
仅仅为了创建全局记忆库
10:11.916–10:14.496
zh是否真的需要所有这些非线性计算
是否真的需要所有这些非线性计算
10:14.496–10:17.576
zh于是直接砍掉中间的每一个串行流程
于是直接砍掉中间的每一个串行流程
10:17.576–10:18.996
zh使用该隐藏状态
使用该隐藏状态
10:18.996–10:21.016
zh再交给第35层投影
再交给第35层投影
10:21.016–10:22.556
zh借此获得KV信息
借此获得KV信息
10:22.556–10:25.196
zh不过如果你还记得前面讲过的内容
不过如果你还记得前面讲过的内容
10:25.196–10:27.756
zhDeepSeek其实并不是每次都为每一层生成
DeepSeek其实并不是每次都为每一层生成
10:27.756–10:29.856
zh完全独立的庞大KV缓存
完全独立的庞大KV缓存
10:29.856–10:32.756
zhCSAR已经通过三种不同模式
CSAR已经通过三种不同模式
10:32.756–10:34.524
zh让相邻层共享全局KV
让相邻层共享全局KV
10:34.744–10:38.624
zh所以只有真正需要创建新全局KV的解码器层
所以只有真正需要创建新全局KV的解码器层
10:38.624–10:40.704
zh才会用自身层专属的投影
才会用自身层专属的投影
10:40.704–10:43.684
zh直接从最终编码器状态将其派生出来
直接从最终编码器状态将其派生出来
10:43.684–10:46.164
zh至于每一层具体使用哪种模式
至于每一层具体使用哪种模式
10:46.164–10:49.724
zhDeep Seek几乎是把这些模式硬编码进了层布局中
Deep Seek几乎是把这些模式硬编码进了层布局中
10:49.724–10:50.784
zh在编码器中
在编码器中
10:50.784–10:53.384
zh前两个仅使用SWA的层之后
前两个仅使用SWA的层之后
10:53.384–10:56.004
zh剩余18层按每6层一组划分
剩余18层按每6层一组划分
10:56.004–10:58.284
zh一个完整层后面接5个复用层
一个完整层后面接5个复用层
10:58.284–11:01.644
zh而在解码器中20层按每4层一组划分
而在解码器中20层按每4层一组划分
11:02.112–11:03.712
zhD组以一个完整层开头
D组以一个完整层开头
11:03.712–11:05.232
zh后面接三个复用层
后面接三个复用层
11:05.232–11:07.912
zh后面的各组则以一个众索引层开头
后面的各组则以一个众索引层开头
11:07.912–11:09.492
zh再接三个复用层
再接三个复用层
11:09.492–11:10.672
zh所以综合起来看
所以综合起来看
11:10.672–11:14.012
zh你基本上同时获得了两个层面的成本节省
你基本上同时获得了两个层面的成本节省
11:14.012–11:14.572
zh首先
首先
11:14.572–11:18.332
zhCD避免了仅仅为了生成解码器全局KV
CD避免了仅仅为了生成解码器全局KV
11:18.332–11:21.392
zh就让整个预填充跑变模型上半部分
就让整个预填充跑变模型上半部分
11:21.392–11:21.952
zh相反
相反
11:21.952–11:24.972
zh它直接从最终编码器表示派生这份KV
它直接从最终编码器表示派生这份KV
11:24.972–11:26.832
zh然后借助CSAR
然后借助CSAR
11:26.832–11:29.632
zh一旦某个解码器层生成了这份KV
一旦某个解码器层生成了这份KV
11:29.700–11:30.540
zh接下来的几层
接下来的几层
11:30.540–11:32.000
zh也不一定需要再生成
也不一定需要再生成
11:32.000–11:32.740
zh另一份副本
另一份副本
11:32.740–11:33.780
zh而这种组合
而这种组合
11:33.780–11:35.560
zh正是DeepSeq的方案激进的多
正是DeepSeq的方案激进的多
11:35.560–11:37.820
zh且专门针对V4.1优化的原因
且专门针对V4.1优化的原因
11:37.820–11:38.640
zh除此之外
除此之外
11:38.640–11:40.100
zhDeepSeq V4.1的情况
DeepSeq V4.1的情况
11:40.100–11:41.040
zh也要复杂的多
也要复杂的多
11:41.040–11:42.340
zh它在每一层中
它在每一层中
11:42.340–11:43.340
zh都仍然保留着
都仍然保留着
11:43.340–11:44.580
zh滑动窗口注意力分支
滑动窗口注意力分支
11:44.580–11:45.880
zh所以每个解码器层
所以每个解码器层
11:45.880–11:47.480
zh其实有两种不同的记忆
其实有两种不同的记忆
11:47.480–11:49.700
zh一种是来自编码器表示
一种是来自编码器表示
11:49.700–11:52.480
zh并通过CSAR共享的全局记忆
并通过CSAR共享的全局记忆
11:52.480–11:53.680
zh另一种是来自
另一种是来自
11:53.680–11:55.060
zh该解码器层自身
该解码器层自身
11:55.060–11:57.120
zh隐藏状态的局部进气记忆
隐藏状态的局部进气记忆
11:57.288–11:58.968
zh所以这里有一点很需要澄清
所以这里有一点很需要澄清
11:58.968–12:02.348
zhCSAR的KV共享只适用于全局注意力分支
CSAR的KV共享只适用于全局注意力分支
12:02.348–12:05.508
zh这并不意味着滑动窗口注意力的KV缓存
这并不意味着滑动窗口注意力的KV缓存
12:05.508–12:06.788
zh会在各层之间共享
会在各层之间共享
12:06.788–12:10.448
zh每个层仍然保留自己的局部SWA KV缓存
每个层仍然保留自己的局部SWA KV缓存
12:10.448–12:13.988
zh因为这种局部记忆是由该层实际的隐藏状态产生的
因为这种局部记忆是由该层实际的隐藏状态产生的
12:13.988–12:17.468
zh因此即使5个CSAR曾共享同一个全局KV
因此即使5个CSAR曾共享同一个全局KV
12:17.468–12:20.608
zh它们仍然可以有5份不同的滑动窗口KV缓存
它们仍然可以有5份不同的滑动窗口KV缓存
12:20.608–12:21.588
zh除此之外
除此之外
12:21.588–12:24.748
zhSWA只保留最近的128个TOKENS
SWA只保留最近的128个TOKENS
12:24.876–12:28.776
zh因此全局KV会随着整个100万Token的上下文增长
因此全局KV会随着整个100万Token的上下文增长
12:28.776–12:29.716
zh而运行时
而运行时
12:29.716–12:33.676
zhSWA缓存实际上始终受限于那个固定窗口
SWA缓存实际上始终受限于那个固定窗口
12:33.676–12:36.196
zh但由于它仍未压缩且未每层独有
但由于它仍未压缩且未每层独有
12:36.196–12:37.756
zh所以仍然不是零成本
所以仍然不是零成本
12:37.756–12:40.876
zh尤其是要跨大量绘画持久保存这些状态时
尤其是要跨大量绘画持久保存这些状态时
12:40.876–12:43.696
zh那么如果我们不共享SWA KV缓存
那么如果我们不共享SWA KV缓存
12:43.696–12:46.936
zh这不就意味着还得把提示词送过这些解码7层吗
这不就意味着还得把提示词送过这些解码7层吗
12:46.936–12:48.296
zh而麻烦的地方在于
而麻烦的地方在于
12:48.296–12:52.396
zh这个128Token的窗口实际上会随着层深不断累积
这个128Token的窗口实际上会随着层深不断累积
12:52.464–12:55.964
zh第40层的SWA状态依赖第39层
第40层的SWA状态依赖第39层
12:55.964–12:58.864
zh第39层本身又依赖更早的局部窗口
第39层本身又依赖更早的局部窗口
12:58.864–12:59.444
zh依此类推
依此类推
12:59.444–13:02.624
zh所以Deepseek基本上切断了这条依赖链
所以Deepseek基本上切断了这条依赖链
13:02.624–13:07.264
zh只把最后128个tokens重放给每个解码7层
只把最后128个tokens重放给每个解码7层
13:07.264–13:08.584
zh这正是他们所说的
这正是他们所说的
13:08.584–13:11.244
zhSWA有借重放发挥作用的地方
SWA有借重放发挥作用的地方
13:11.244–13:14.744
zh所以不是让100万个tokens经过全部40层
所以不是让100万个tokens经过全部40层
13:14.744–13:16.884
zh而是让100万个经过前20层
而是让100万个经过前20层
13:16.884–13:19.144
zh只让128个经过剩下的20层
只让128个经过剩下的20层
13:19.144–13:20.052
zh这意味着现在完整的预填
这意味着现在完整的预填
13:20.052–13:21.292
zh这意味着现在完整的预填充成本
这意味着现在完整的预填充成本
13:21.292–13:23.972
zh大致等于完整提示词经过一半模型
大致等于完整提示词经过一半模型
13:23.972–13:25.752
zh再加上128个tokens
再加上128个tokens
13:25.752–13:27.092
zh经过其余各层
经过其余各层
13:27.092–13:29.572
zh在100万tokens上下文的情况下
在100万tokens上下文的情况下
13:29.572–13:31.292
zh那128个tokens的重放
那128个tokens的重放
13:31.292–13:32.372
zh基本可以忽略不计
基本可以忽略不计
13:32.372–13:34.972
zh所以整体预填充仍接近减半
所以整体预填充仍接近减半
13:34.972–13:37.292
zh虽说只运行这128个tokens
虽说只运行这128个tokens
13:37.292–13:39.632
zh重建出的状态严格来说是近似的
重建出的状态严格来说是近似的
13:39.632–13:42.432
zh但Deepseek仍表示对质量的影响微乎其微
但Deepseek仍表示对质量的影响微乎其微
13:42.432–13:44.412
zh而且有借重放实际上还带来了
而且有借重放实际上还带来了
13:44.412–13:45.972
zh另一个相当大的好处
另一个相当大的好处
13:45.972–13:47.640
zh因为Deepseek基本意识到
因为Deepseek基本意识到
13:47.640–13:49.920
zh基本意识到已经不值得再把SWA-KV缓存
基本意识到已经不值得再把SWA-KV缓存
13:49.920–13:51.200
zh当作长期记忆对待了
当作长期记忆对待了
13:51.200–13:52.420
zh在Deepseek V4中
在Deepseek V4中
13:52.420–13:54.600
zh当它们缓存前缀已共复用时
当它们缓存前缀已共复用时
13:54.600–13:56.320
zh固态硬盘上的持久化缓存
固态硬盘上的持久化缓存
13:56.320–13:59.900
zh会同时存储全局KV和SWA-KV缓存
会同时存储全局KV和SWA-KV缓存
13:59.900–14:00.980
zh令人惊讶的是
令人惊讶的是
14:00.980–14:04.440
zh尽管SWA只覆盖一个很小的局部窗口
尽管SWA只覆盖一个很小的局部窗口
14:04.440–14:07.520
zh那些未压缩逐层生成的SWA状态
那些未压缩逐层生成的SWA状态
14:07.520–14:10.380
zh仍几乎占了持久化KV存储的一半
仍几乎占了持久化KV存储的一半
14:10.380–14:11.120
zh除此之外
除此之外
14:11.120–14:13.200
zh这两种缓存的生命周期完全不同
这两种缓存的生命周期完全不同
14:13.200–14:15.228
zh如果同一个长前缀被复用
如果同一个长前缀被复用
14:15.588–14:16.848
zh全局KV缓存
全局KV缓存
14:16.848–14:18.668
zh可能在数小时或数天后
可能在数小时或数天后
14:18.668–14:19.428
zh仍然有用
仍然有用
14:19.428–14:21.248
zh但SWAKV缓存
但SWAKV缓存
14:21.248–14:22.868
zh其实仅对活跃绘画的
其实仅对活跃绘画的
14:22.868–14:24.348
zh当前局部状态有用
当前局部状态有用
14:24.348–14:26.028
zh有效期通常只有几分钟
有效期通常只有几分钟
14:26.028–14:27.368
zh因此在V4.1中
因此在V4.1中
14:27.368–14:30.108
zhDeepseek完全不再把SWAKV缓存
Deepseek完全不再把SWAKV缓存
14:30.108–14:32.048
zh存入长生命周期的持久化缓存
存入长生命周期的持久化缓存
14:32.048–14:33.968
zh而是将其临时存放在
而是将其临时存放在
14:33.968–14:35.928
zh小得多的主机内存池中
小得多的主机内存池中
14:35.928–14:37.468
zh一旦过期或被驱逐
一旦过期或被驱逐
14:37.468–14:39.608
zh就直接用有界重放重建
就直接用有界重放重建
14:39.608–14:40.968
zh最后128个Token
最后128个Token
14:40.968–14:41.828
zh再来说Token
再来说Token
14:41.828–14:42.728
zh与此同时
与此同时
14:42.816–14:46.236
zh与此同时全局KV可以存储在固态硬盘这类持久化存储中
与此同时全局KV可以存储在固态硬盘这类持久化存储中
14:46.236–14:48.996
zh这部分的持久化KV缩减幅度非常可观
这部分的持久化KV缩减幅度非常可观
14:48.996–14:55.116
zhCSAR搭配FP4已经能把全局KV压缩到V4时期容量的四分之一左右
CSAR搭配FP4已经能把全局KV压缩到V4时期容量的四分之一左右
14:55.116–14:58.136
zh而将SWAKV移出持久化存储后
而将SWAKV移出持久化存储后
14:58.136–15:00.516
zh缓存规模几乎直接再减一半
缓存规模几乎直接再减一半
15:00.516–15:02.056
zh回看V4的设计
回看V4的设计
15:02.056–15:05.376
zh持久化KV的占用空间大概一半来自SWA
持久化KV的占用空间大概一半来自SWA
15:05.376–15:07.336
zh另一半来自全局KV
另一半来自全局KV
15:07.336–15:10.404
zhV4.1首先通过CSAR和FP4把这占一半
V4.1首先通过CSAR和FP4把这占一半
15:10.404–15:12.284
zh和FP4把这占一半的全局KV
和FP4把这占一半的全局KV
15:12.284–15:14.604
zh压缩到原大小的四分之一左右
压缩到原大小的四分之一左右
15:14.604–15:17.124
zh这就使得全局KV本身的占用
这就使得全局KV本身的占用
15:17.124–15:19.424
zh降至每Token近890字节
降至每Token近890字节
15:19.424–15:21.044
zh在HBM存储上
在HBM存储上
15:21.044–15:23.204
zh直接节省了75%的空间
直接节省了75%的空间
15:23.204–15:25.504
zh之后再把占一半的SWA KV
之后再把占一半的SWA KV
15:25.504–15:28.144
zh移出持久化存储固态硬盘存储空间
移出持久化存储固态硬盘存储空间
15:28.144–15:30.324
zh最多可节省87.5%
最多可节省87.5%
15:30.324–15:33.184
zh这也让这个总参数量达5520亿的模型
这也让这个总参数量达5520亿的模型
15:33.184–15:34.164
zh在实际运行时
在实际运行时
15:34.164–15:36.264
zh呈现出一种很奇特的不对称性
呈现出一种很奇特的不对称性
15:36.264–15:37.992
zh因此V4.1仍然属于MOE模型
因此V4.1仍然属于MOE模型
15:38.732–15:42.632
zh显然它不会为每个Token都激活全部5520亿参数
显然它不会为每个Token都激活全部5520亿参数
15:42.632–15:47.412
zh但借助CED与填充阶段的输入Token只需经过20层编码器
但借助CED与填充阶段的输入Token只需经过20层编码器
15:47.412–15:51.272
zh因此DeepSeq在这阶段仅激活约80亿个参数
因此DeepSeq在这阶段仅激活约80亿个参数
15:51.272–15:53.392
zh但模型一旦开始生成内容
但模型一旦开始生成内容
15:53.392–15:57.112
zh每个新Token都必须同时经过编码器和解码器
每个新Token都必须同时经过编码器和解码器
15:57.112–15:59.312
zh激活参数量随之升至160亿
激活参数量随之升至160亿
15:59.312–16:02.612
zh所以即便整个模型的总规模几乎是VS Flash的两倍
所以即便整个模型的总规模几乎是VS Flash的两倍
16:02.612–16:04.852
zh模型中负责大部分繁重输入
模型中负责大部分繁重输入
16:05.579–16:06.619
zh读取工作的部分其实非常小
读取工作的部分其实非常小
16:06.619–16:08.539
zh这对智能体场景非常友好
这对智能体场景非常友好
16:08.539–16:11.239
zh因为这里场景往往要读取几十万token
因为这里场景往往要读取几十万token
16:11.239–16:13.839
zh最终却只生成几千个token的内容
最终却只生成几千个token的内容
16:13.839–16:15.299
zh还有点不可思议的是
还有点不可思议的是
16:15.299–16:18.959
zh哪怕上下文从4000token提升到100万token
哪怕上下文从4000token提升到100万token
16:18.959–16:22.339
zh也就是上下文长度扩大到原来的256倍
也就是上下文长度扩大到原来的256倍
16:22.339–16:24.139
zh单token解码所需算力
单token解码所需算力
16:24.139–16:26.239
zh也仅从约20加全GFLOPs
也仅从约20加全GFLOPs
16:26.239–16:27.999
zh甚至25加全GFLOPs
甚至25加全GFLOPs
16:27.999–16:30.319
zh我认为这次版本更新的所有改动力
我认为这次版本更新的所有改动力
16:30.319–16:33.167
zh上述这些新增核心组件是最值得关注的
上述这些新增核心组件是最值得关注的
16:33.267–16:34.467
zh到了这个阶段
到了这个阶段
16:34.467–16:36.987
zh百万token上下文几乎已经不是这个模型
百万token上下文几乎已经不是这个模型
16:36.987–16:38.227
zh最有冲击力的特性了
最有冲击力的特性了
16:38.227–16:41.107
zh因此Deepseek开始将注意力转向架构中
因此Deepseek开始将注意力转向架构中
16:41.107–16:44.307
zh其他人在浪费内存带宽和算力的环节
其他人在浪费内存带宽和算力的环节
16:44.307–16:47.307
zh接下来要讲的是Deepseek在V4.1中
接下来要讲的是Deepseek在V4.1中
16:47.307–16:50.167
zh重新实现时同样做了优化的其他组件
重新实现时同样做了优化的其他组件
16:50.547–16:51.747
zh首先是MHC
首先是MHC
16:51.747–16:54.947
zh我之前已经做过MHC的相关讲解视频
我之前已经做过MHC的相关讲解视频
16:54.947–16:56.247
zh这里就长话短说
这里就长话短说
16:56.247–17:00.107
zhV4.1针对它的专属改动叫做单路径MHC
V4.1针对它的专属改动叫做单路径MHC
17:00.755–17:02.855
zh这种设计基本解决了原先棘手的依赖问题
这种设计基本解决了原先棘手的依赖问题
17:02.855–17:05.635
zh该依赖会迫使GPU多次访问残差流
该依赖会迫使GPU多次访问残差流
17:05.635–17:06.835
zh和原有实现相比
和原有实现相比
17:06.835–17:09.475
zh这种新实现能将仿存流量降低约一半
这种新实现能将仿存流量降低约一半
17:09.475–17:12.235
zh而且这次他们真的把Ngram落地到了模型中
而且这次他们真的把Ngram落地到了模型中
17:12.235–17:14.115
zhDeepseek此前就推出过Ngram
Deepseek此前就推出过Ngram
17:14.115–17:18.415
zh它可以把需要记忆的信息和开销高昂的Transformer计算分离开来
它可以把需要记忆的信息和开销高昂的Transformer计算分离开来
17:18.415–17:20.255
zh我也做过Ngram的相关视频
我也做过Ngram的相关视频
17:20.255–17:23.515
zh但此前他们从未在自家模型中落地过这项设计
但此前他们从未在自家模型中落地过这项设计
17:23.515–17:25.815
zh这种情况直到V4.1才改变
这种情况直到V4.1才改变
17:25.815–17:28.343
zh他们加入的Ngram总参数量达1960亿分布
他们加入的Ngram总参数量达1960亿分布
17:28.343–17:30.103
zh达1960亿分布在两个模块中
达1960亿分布在两个模块中
17:30.103–17:31.383
zh所以从技术层面来说
所以从技术层面来说
17:31.383–17:33.343
zh该模型总共存储的参数量
该模型总共存储的参数量
17:33.343–17:35.883
zh约为5520亿加1960亿
约为5520亿加1960亿
17:35.883–17:37.443
zh合计7480亿
合计7480亿
17:37.443–17:39.943
zh但这多出来的1960亿参数
但这多出来的1960亿参数
17:39.943–17:41.963
zh是通过哈希Ngram查照表
是通过哈希Ngram查照表
17:41.963–17:43.763
zh进行悉数访问的条件记忆
进行悉数访问的条件记忆
17:43.763–17:46.223
zh而非每个Token都会激活的
而非每个Token都会激活的
17:46.223–17:48.403
zh另外1960亿个稠密参数
另外1960亿个稠密参数
17:48.403–17:50.303
zh也就是说Ngram大幅提升了
也就是说Ngram大幅提升了
17:50.303–17:51.403
zh模型的记忆容量
模型的记忆容量
17:51.403–17:53.163
zh但它单Token所需的算力
但它单Token所需的算力
17:53.163–17:55.423
zh仍和5520亿参数规模的
仍和5520亿参数规模的
17:55.423–17:55.931
zhMOE模型相当
MOE模型相当
17:56.331–17:58.151
zh最后要介绍的是Spark
最后要介绍的是Spark
17:58.151–18:00.171
zh我也做过关于Spark的视频
我也做过关于Spark的视频
18:00.171–18:01.391
zh这里简单概括
这里简单概括
18:01.391–18:03.791
zh他们用Spark实现了更快的解码速度
他们用Spark实现了更快的解码速度
18:03.791–18:07.591
zh且无需将草稿模型整合到主干网络的预训练流程中
且无需将草稿模型整合到主干网络的预训练流程中
18:07.591–18:10.871
zh但这次的架构升级并不只局限于文本领域
但这次的架构升级并不只局限于文本领域
18:10.871–18:13.691
zhV4.1的另一项重大升级是Deep Seek
V4.1的另一项重大升级是Deep Seek
18:13.691–18:16.191
zh终于让模型实现了原生多模态
终于让模型实现了原生多模态
18:16.191–18:20.051
zh他们从零训练了自研视觉编码器Deep Seek VIT
他们从零训练了自研视觉编码器Deep Seek VIT
18:20.051–18:23.519
zh随后采用3x3像素合并加混洗的方式压缩视觉特别
随后采用3x3像素合并加混洗的方式压缩视觉特别
18:23.519–18:24.539
zh在混洗的方式压缩视觉特征
在混洗的方式压缩视觉特征
18:24.539–18:26.319
zh再将其输入语言模型
再将其输入语言模型
18:26.319–18:28.559
zh这一操作将视觉tokens的数量
这一操作将视觉tokens的数量
18:28.559–18:30.079
zh压缩至原来的九分之一
压缩至原来的九分之一
18:30.079–18:31.459
zh同时仍支持分辨率
同时仍支持分辨率
18:31.459–18:34.579
zh约为1344×1344的图像
约为1344×1344的图像
18:34.579–18:36.999
zh为了帮你理清我刚才讲到的所有内容
为了帮你理清我刚才讲到的所有内容
18:36.999–18:38.199
zh我们来完整梳理一下
我们来完整梳理一下
18:38.199–18:39.799
zh他们搭建的整套模型架构
他们搭建的整套模型架构
18:39.799–18:41.639
zh我们从最底层开始讲起
我们从最底层开始讲起
18:41.639–18:43.919
zh模型有文本和图像两类输入
模型有文本和图像两类输入
18:43.919–18:44.779
zh二者输入模型后
二者输入模型后
18:44.779–18:46.499
zh会被合并为一个嵌入项量
会被合并为一个嵌入项量
18:46.499–18:47.919
zh随后它会经过两个
随后它会经过两个
18:47.919–18:49.339
zh纯滑动窗口注意力层
纯滑动窗口注意力层
18:49.339–18:51.107
zh这两层会读取Ngram提供的记忆之后
这两层会读取Ngram提供的记忆之后
18:51.627–18:55.187
zh之后会进入配比为1-5的CESAR
之后会进入配比为1-5的CESAR
18:55.187–18:56.547
zh全量层与复用层
全量层与复用层
18:56.547–18:57.887
zh该结构会重复三次
该结构会重复三次
18:57.887–19:00.227
zh这样加起来一共是18层
这样加起来一共是18层
19:00.227–19:03.347
zh算下来英国编码器组件的总层数为20层
算下来英国编码器组件的总层数为20层
19:03.347–19:04.707
zh这里的数字2指的是
这里的数字2指的是
19:04.707–19:06.167
zh大约每两个TOKENS
大约每两个TOKENS
19:06.167–19:08.427
zh会被压缩成一个主KV条目
会被压缩成一个主KV条目
19:08.427–19:11.467
zh且每个CESAR层都配套有滑动窗口注意力
且每个CESAR层都配套有滑动窗口注意力
19:11.467–19:12.587
zh至于MOE部分
至于MOE部分
19:12.587–19:14.187
zh他们仍在使用DeepseekMOE
他们仍在使用DeepseekMOE
19:14.187–19:16.447
zh到这一步为止的所有输出
到这一步为止的所有输出
19:16.447–19:18.695
zh就是供后续层使用的编码器引状态
就是供后续层使用的编码器引状态
19:19.155–19:21.215
zh而SWA有介重放机制
而SWA有介重放机制
19:21.215–19:23.055
zh会直接基于该引状态运行
会直接基于该引状态运行
19:23.055–19:25.695
zh无需从解码器层依次获取数据
无需从解码器层依次获取数据
19:25.695–19:28.695
zh因此预填充阶段只需要运行英国编码器组件
因此预填充阶段只需要运行英国编码器组件
19:28.695–19:31.675
zh而解码器运行时则需要两个组件同时启动
而解码器运行时则需要两个组件同时启动
19:31.675–19:33.555
zh对应的激活参数量为81
对应的激活参数量为81
19:33.555–19:35.375
zh解码器阶段则为160亿
解码器阶段则为160亿
19:35.375–19:37.235
zh接下来讲解码器的具体层结构
接下来讲解码器的具体层结构
19:37.235–19:39.095
zh第一层是CSAR全量层
第一层是CSAR全量层
19:39.095–19:41.035
zh之后是三层CSAR副用层
之后是三层CSAR副用层
19:41.035–19:44.235
zh接着是配比为1比3的重索引与副用结构
接着是配比为1比3的重索引与副用结构
19:44.235–19:45.815
zh该结构重复4次
该结构重复4次
19:46.283–19:49.183
zh这里的数字已表示主KV不会进行Token维度的压缩
这里的数字已表示主KV不会进行Token维度的压缩
19:49.183–19:50.603
zh我个人的理解是
我个人的理解是
19:50.603–19:54.483
zh这大概率是为了保留完整的Token级分辨率
这大概率是为了保留完整的Token级分辨率
19:54.483–19:59.363
zh毕竟解码器已经在跨层大规模复用编码器生成的全局KV了
毕竟解码器已经在跨层大规模复用编码器生成的全局KV了
19:59.363–20:02.263
zh但即便采用了CSAR附用重索引层
但即便采用了CSAR附用重索引层
20:02.263–20:05.443
zh仍然需要重新扫描整个百万级Token的上下文
仍然需要重新扫描整个百万级Token的上下文
20:05.443–20:07.963
zh因此DeepSeek加入了分层吸收索引器
因此DeepSeek加入了分层吸收索引器
20:07.963–20:10.603
zh避免这类搜索再次产生过高的算力开销
避免这类搜索再次产生过高的算力开销
20:10.603–20:12.423
zh首个完整层会扫描全部内容
首个完整层会扫描全部内容
20:12.423–20:13.871
zh构建一个最多包含约1.6万
构建一个最多包含约1.6万
20:13.871–20:15.691
zh最多包含约1.6万个位置的候选池
最多包含约1.6万个位置的候选池
20:15.691–20:18.851
zh后续的重锁隐层仅在该候选池内检索
后续的重锁隐层仅在该候选池内检索
20:18.851–20:20.911
zh筛选出各自排名前512的位置
筛选出各自排名前512的位置
20:20.911–20:24.731
zh这些层加起来共有20层处理结果会被输入Spark
这些层加起来共有20层处理结果会被输入Spark
20:24.731–20:26.751
zh模型架构部分的内容就到这里
模型架构部分的内容就到这里
20:26.751–20:29.331
zh训练方面也有几处很有意思的改动
训练方面也有几处很有意思的改动
20:29.331–20:32.851
zh首先 DeepSeek 没有先训练常规的稠密注意力模型
首先 DeepSeek 没有先训练常规的稠密注意力模型
20:32.851–20:35.291
zh再再之后将其转换为稀疏架构
再再之后将其转换为稀疏架构
20:35.291–20:38.631
zhV4.1从0开始直接采用稀疏注意力训练
V4.1从0开始直接采用稀疏注意力训练
20:38.631–20:40.811
zh初始上下文长度为6.4万
初始上下文长度为6.4万
20:41.459–20:42.859
zh完全没有做稠密注意力预热
完全没有做稠密注意力预热
20:42.859–20:45.539
zh等训练量达到约34万亿tokens时
等训练量达到约34万亿tokens时
20:45.539–20:48.119
zh他们会直接将上下文长度扩展到100万
他们会直接将上下文长度扩展到100万
20:48.119–20:52.359
zh最终在总计45万亿tokens的多莫态数据上完成预训练
最终在总计45万亿tokens的多莫态数据上完成预训练
20:52.359–20:56.979
zh因此CSAR CED和稀疏检索行为都不是后续才新增的
因此CSAR CED和稀疏检索行为都不是后续才新增的
20:56.979–20:59.599
zh模型实际上是从头学习这些机制的
模型实际上是从头学习这些机制的
20:59.599–21:02.199
zh而如果一家实验室能够不依赖稠密注意力
而如果一家实验室能够不依赖稠密注意力
21:02.199–21:04.379
zh从零成功训练出稀疏注意力
从零成功训练出稀疏注意力
21:04.379–21:07.679
zh这通常就意味着这套注意力机制稳定可靠
这通常就意味着这套注意力机制稳定可靠
21:07.679–21:09.047
zh且具备很高的潜力
且具备很高的潜力
21:09.347–21:12.027
zh后训练部分的思路转变相当有意思
后训练部分的思路转变相当有意思
21:12.027–21:13.787
zh因为Deep Seek明确表示
因为Deep Seek明确表示
21:13.787–21:16.607
zh他们这次基本没有推出新的后训练算法
他们这次基本没有推出新的后训练算法
21:16.607–21:18.567
zh他们表示几乎所有提升
他们表示几乎所有提升
21:18.567–21:21.187
zh都来自扩大模型的训练数据规模
都来自扩大模型的训练数据规模
21:21.187–21:22.807
zh也就是靠数据扩容
也就是靠数据扩容
21:22.807–21:25.147
zh而非涉及新的强化学习目标
而非涉及新的强化学习目标
21:25.147–21:26.927
zh我完全明白这是为什么
我完全明白这是为什么
21:26.927–21:28.687
zhDeep Seek已拥有最强
Deep Seek已拥有最强
21:28.687–21:30.847
zh且最稳定的后训练方案之一
且最稳定的后训练方案之一
21:30.847–21:31.707
zh批词不变性
批词不变性
21:31.707–21:34.487
zh让强化学习流程的可预测性大幅提升
让强化学习流程的可预测性大幅提升
21:34.487–21:36.635
zh此外还有多教师在线策略蒸流
此外还有多教师在线策略蒸流
21:37.195–21:38.415
zh他们现在将其称为
他们现在将其称为
21:38.415–21:40.055
zh大规模同策略蒸流
大规模同策略蒸流
21:40.055–21:42.095
zhV4.1会向不同领域的
V4.1会向不同领域的
21:42.095–21:44.735
zh40多个各有专攻的教师模型学习
40多个各有专攻的教师模型学习
21:44.735–21:46.695
zh这也说明DeepSeek目前认为
这也说明DeepSeek目前认为
21:46.695–21:48.995
zh投入更多时间和资金优化数据
投入更多时间和资金优化数据
21:48.995–21:51.275
zh比继续研发新的后训练算法
比继续研发新的后训练算法
21:51.275–21:52.095
zh更有价值
更有价值
21:52.095–21:53.695
zh尤其是本篇论文中
尤其是本篇论文中
21:53.695–21:54.755
zh他们十分重视
他们十分重视
21:54.755–21:55.875
zh强化学习数据的
强化学习数据的
21:55.875–21:57.675
zh自动化合成与环境构建
自动化合成与环境构建
21:57.675–21:58.435
zh说到底
说到底
21:58.435–21:59.815
zh我认为就是垃圾进
我认为就是垃圾进
21:59.815–22:00.655
zh垃圾出
垃圾出
22:00.655–22:01.675
zh但这也意味着
但这也意味着
22:01.675–22:02.815
zh当前的后训练范式
当前的后训练范式
22:02.815–22:03.595
zh在一段时间内
在一段时间内
22:04.223–22:05.223
zh可能会少很多有意思的新进展
可能会少很多有意思的新进展
22:05.223–22:06.243
zh不过客观来说
不过客观来说
22:06.243–22:08.123
zhMOPT也是最近才推出的
MOPT也是最近才推出的
22:08.123–22:09.943
zh所以这套范式问世的时间
所以这套范式问世的时间
22:09.943–22:11.123
zh本来也不算长
本来也不算长
22:11.123–22:12.423
zh不过他们还做了一项
不过他们还做了一项
22:12.423–22:14.883
zh我认为之前没有明确提到过的小调整
我认为之前没有明确提到过的小调整
22:14.883–22:16.443
zh那就是模型合并
那就是模型合并
22:16.443–22:18.623
zh我也做过一期关于模型合并的视频
我也做过一期关于模型合并的视频
22:18.623–22:20.303
zh在强化学习过程中
在强化学习过程中
22:20.303–22:22.663
zh他们会合并来自不同脚手架
他们会合并来自不同脚手架
22:22.663–22:25.263
zh不同配置的独立训练运行的检查点
不同配置的独立训练运行的检查点
22:25.263–22:27.683
zh整合不同优化路径的提升效果
整合不同优化路径的提升效果
22:27.683–22:29.643
zh在用合并后的模型初始化
在用合并后的模型初始化
22:29.643–22:31.063
zh下一次强化学习运行
下一次强化学习运行
22:31.811–22:34.671
zh也就是说模型合并是用来持续汇总各次成功
也就是说模型合并是用来持续汇总各次成功
22:34.671–22:37.671
zh强化学习运行带来的提升等到流程最后
强化学习运行带来的提升等到流程最后
22:37.671–22:41.871
zh他们会在不同领域和训练阶段开展大规模同策略蒸馏
他们会在不同领域和训练阶段开展大规模同策略蒸馏
22:41.871–22:45.731
zh将所有专家教师模型的能力整合到同一个模型中
将所有专家教师模型的能力整合到同一个模型中
22:45.731–22:48.391
zh另一方面推理力度也有一项升级
另一方面推理力度也有一项升级
22:48.391–22:53.171
zh它不再像V4那样只设置Think High和Think Max模式
它不再像V4那样只设置Think High和Think Max模式
22:53.171–22:54.731
zh而是通过强化学习
而是通过强化学习
22:54.731–22:58.651
zh让推理力度成为一个从1到100的数值
让推理力度成为一个从1到100的数值
22:58.651–22:59.399
zh力度越低
力度越低
22:59.819–23:00.919
zhToken惩罚越强
Token惩罚越强
23:00.919–23:01.599
zh力度越高
力度越高
23:01.599–23:04.159
zh就会逐步允许模型使用更多算力
就会逐步允许模型使用更多算力
23:04.159–23:04.839
zh因此
因此
23:04.839–23:07.299
zh模型不是训练几个彼此孤立的推理模式
模型不是训练几个彼此孤立的推理模式
23:07.299–23:09.619
zh而是学会一条平滑的成本质量曲线
而是学会一条平滑的成本质量曲线
23:09.619–23:12.039
zh面向用户的Low High和Max 3档
面向用户的Low High和Max 3档
23:12.039–23:13.879
zh基本上就是同一尺度上
基本上就是同一尺度上
23:13.879–23:16.479
zh力度值为50,75和100的设置
力度值为50,75和100的设置
23:16.479–23:17.039
zh好啦
好啦
23:17.039–23:19.339
zhV4.1 Flash在技术报告中提出的
V4.1 Flash在技术报告中提出的
23:19.339–23:21.099
zh大部分重要进展就介绍到这里
大部分重要进展就介绍到这里
23:21.099–23:22.999
zh这份51页的技术报告里
这份51页的技术报告里
23:22.999–23:24.279
zh还有许多技术细节
还有许多技术细节
23:24.279–23:26.419
zh但其中有些内容实在太深奥
但其中有些内容实在太深奥
23:26.987–23:28.827
zh或者需要更多背景知识才能解释清楚
或者需要更多背景知识才能解释清楚
23:28.827–23:32.087
zh比如DSEC缩放多莫态混合专家均衡
比如DSEC缩放多莫态混合专家均衡
23:32.087–23:33.507
zh以及其他基础设施改进
以及其他基础设施改进
23:33.507–23:35.007
zh所以如果你们想了解更多
所以如果你们想了解更多
23:35.007–23:36.227
zh一定要去看看他们的论文
一定要去看看他们的论文
23:36.227–23:37.207
zh谢谢大家观看
谢谢大家观看
23:37.207–23:39.267
zh特别感谢Spamatch Chris Ledoux
特别感谢Spamatch Chris Ledoux
23:39.267–23:39.987
enDegan
（此句尚無繁中翻譯）
23:39.987–23:41.827
enRoberts Zaviasa
（此句尚無繁中翻譯）
23:41.827–23:42.447
enPoof
（此句尚無繁中翻譯）
23:42.447–23:43.167
enInu
（此句尚無繁中翻譯）
23:43.167–23:44.727
enDX Research Group
（此句尚無繁中翻譯）
23:44.727–23:45.487
enAlex
（此句尚無繁中翻譯）
23:45.487–23:46.847
enLeo Halawani
（此句尚無繁中翻譯）
23:46.847–23:48.807
zh以及其他许多通过Patreon
以及其他许多通过Patreon
23:48.807–23:50.967
zh或YouTube支持我的人
或YouTube支持我的人
23:50.967–23:53.327
zh还没关注我的话到推特上关注我
还没关注我的话到推特上关注我
23:53.327–23:54.447
zh我们下期再见
我们下期再见

影片筆記：DeepSeek-V4.1 Flash：迄今为止最疯狂的优化 - bycloud - 英语原声/中配 p01 配音

<!-- VIDEONOTE_PUBLICATION_WARNINGS_BEGIN -->

⚠️ 可先使用，仍有待修正項目

本筆記已完成可閱讀的逐字稿與時間跳轉；下列為待處理問題，建議播放原片確認。

  • 待修正：完整校讀／語意翻譯仍待確認，保留可用逐字稿發布（ValueError('canonical_audit failed bounded JSON/schema retries')）
  • 待修正：自動摘要未完成（已先發布可跳轉的逐字稿版本；可稍後以現有逐字稿重新產生摘要。；note generator exit=1, timed_out=0）

<!-- VIDEONOTE_PUBLICATION_WARNINGS_END -->

處理狀態

已完成語音辨識與逐字時間軸。自動摘要階段未在時間預算內完成，因此先發布可用版本；可於後續從現有逐字稿補做摘要，不需重新辨識影片。

來源

https://www.bilibili.com/video/BV1n2p765EMr/?buvid=Y7495475759B66B048429FDDC79433C6859B&from_spmid=main.push.51.6771562397565899980&is_story_h5=false&mid=NLjM5xBZitQgIUaCS7ilHQ%3D%3D&p=1&plat_id=116&share_from=ugc&share_medium=iphone&share_plat=ios&share_session_id=55EDED30-7892-473A-B7FC-BAA3FEA76029&share_source=COPY&share_tag=s_i&spmid=united.player-video-detail.0.0&timestamp=1792039438&unique_k=JJ0ze0T&up_id=335691338

完整逐字稿

几个月前我们惊掉下巴
当时发现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存储上
直接节省了75%的空间
之后再把占一半的SWA KV
移出持久化存储固态硬盘存储空间
最多可节省87.5%
这也让这个总参数量达5520亿的模型
在实际运行时
呈现出一种很奇特的不对称性
因此V4.1仍然属于MOE模型
显然它不会为每个Token都激活全部5520亿参数
但借助CED与填充阶段的输入Token只需经过20层编码器
因此DeepSeq在这阶段仅激活约80亿个参数
但模型一旦开始生成内容
每个新Token都必须同时经过编码器和解码器
激活参数量随之升至160亿
所以即便整个模型的总规模几乎是VS Flash的两倍
模型中负责大部分繁重输入
读取工作的部分其实非常小
这对智能体场景非常友好
因为这里场景往往要读取几十万token
最终却只生成几千个token的内容
还有点不可思议的是
哪怕上下文从4000token提升到100万token
也就是上下文长度扩大到原来的256倍
单token解码所需算力
也仅从约20加全GFLOPs
甚至25加全GFLOPs
我认为这次版本更新的所有改动力
上述这些新增核心组件是最值得关注的
到了这个阶段
百万token上下文几乎已经不是这个模型
最有冲击力的特性了
因此Deepseek开始将注意力转向架构中
其他人在浪费内存带宽和算力的环节
接下来要讲的是Deepseek在V4.1中
重新实现时同样做了优化的其他组件
首先是MHC
我之前已经做过MHC的相关讲解视频
这里就长话短说
V4.1针对它的专属改动叫做单路径MHC
这种设计基本解决了原先棘手的依赖问题
该依赖会迫使GPU多次访问残差流
和原有实现相比
这种新实现能将仿存流量降低约一半
而且这次他们真的把Ngram落地到了模型中
Deepseek此前就推出过Ngram
它可以把需要记忆的信息和开销高昂的Transformer计算分离开来
我也做过Ngram的相关视频
但此前他们从未在自家模型中落地过这项设计
这种情况直到V4.1才改变
他们加入的Ngram总参数量达1960亿分布
达1960亿分布在两个模块中
所以从技术层面来说
该模型总共存储的参数量
约为5520亿加1960亿
合计7480亿
但这多出来的1960亿参数
是通过哈希Ngram查照表
进行悉数访问的条件记忆
而非每个Token都会激活的
另外1960亿个稠密参数
也就是说Ngram大幅提升了
模型的记忆容量
但它单Token所需的算力
仍和5520亿参数规模的
MOE模型相当
最后要介绍的是Spark
我也做过关于Spark的视频
这里简单概括
他们用Spark实现了更快的解码速度
且无需将草稿模型整合到主干网络的预训练流程中
但这次的架构升级并不只局限于文本领域
V4.1的另一项重大升级是Deep Seek
终于让模型实现了原生多模态
他们从零训练了自研视觉编码器Deep Seek VIT
随后采用3x3像素合并加混洗的方式压缩视觉特别
在混洗的方式压缩视觉特征
再将其输入语言模型
这一操作将视觉tokens的数量
压缩至原来的九分之一
同时仍支持分辨率
约为1344×1344的图像
为了帮你理清我刚才讲到的所有内容
我们来完整梳理一下
他们搭建的整套模型架构
我们从最底层开始讲起
模型有文本和图像两类输入
二者输入模型后
会被合并为一个嵌入项量
随后它会经过两个
纯滑动窗口注意力层
这两层会读取Ngram提供的记忆之后
之后会进入配比为1-5的CESAR
全量层与复用层
该结构会重复三次
这样加起来一共是18层
算下来英国编码器组件的总层数为20层
这里的数字2指的是
大约每两个TOKENS
会被压缩成一个主KV条目
且每个CESAR层都配套有滑动窗口注意力
至于MOE部分
他们仍在使用DeepseekMOE
到这一步为止的所有输出
就是供后续层使用的编码器引状态
而SWA有介重放机制
会直接基于该引状态运行
无需从解码器层依次获取数据
因此预填充阶段只需要运行英国编码器组件
而解码器运行时则需要两个组件同时启动
对应的激活参数量为81
解码器阶段则为160亿
接下来讲解码器的具体层结构
第一层是CSAR全量层
之后是三层CSAR副用层
接着是配比为1比3的重索引与副用结构
该结构重复4次
这里的数字已表示主KV不会进行Token维度的压缩
我个人的理解是
这大概率是为了保留完整的Token级分辨率
毕竟解码器已经在跨层大规模复用编码器生成的全局KV了
但即便采用了CSAR附用重索引层
仍然需要重新扫描整个百万级Token的上下文
因此DeepSeek加入了分层吸收索引器
避免这类搜索再次产生过高的算力开销
首个完整层会扫描全部内容
构建一个最多包含约1.6万
最多包含约1.6万个位置的候选池
后续的重锁隐层仅在该候选池内检索
筛选出各自排名前512的位置
这些层加起来共有20层处理结果会被输入Spark
模型架构部分的内容就到这里
训练方面也有几处很有意思的改动
首先 DeepSeek 没有先训练常规的稠密注意力模型
再再之后将其转换为稀疏架构
V4.1从0开始直接采用稀疏注意力训练
初始上下文长度为6.4万
完全没有做稠密注意力预热
等训练量达到约34万亿tokens时
他们会直接将上下文长度扩展到100万
最终在总计45万亿tokens的多莫态数据上完成预训练
因此CSAR CED和稀疏检索行为都不是后续才新增的
模型实际上是从头学习这些机制的
而如果一家实验室能够不依赖稠密注意力
从零成功训练出稀疏注意力
这通常就意味着这套注意力机制稳定可靠
且具备很高的潜力
后训练部分的思路转变相当有意思
因为Deep Seek明确表示
他们这次基本没有推出新的后训练算法
他们表示几乎所有提升
都来自扩大模型的训练数据规模
也就是靠数据扩容
而非涉及新的强化学习目标
我完全明白这是为什么
Deep Seek已拥有最强
且最稳定的后训练方案之一
批词不变性
让强化学习流程的可预测性大幅提升
此外还有多教师在线策略蒸流
他们现在将其称为
大规模同策略蒸流
V4.1会向不同领域的
40多个各有专攻的教师模型学习
这也说明DeepSeek目前认为
投入更多时间和资金优化数据
比继续研发新的后训练算法
更有价值
尤其是本篇论文中
他们十分重视
强化学习数据的
自动化合成与环境构建
说到底
我认为就是垃圾进
垃圾出
但这也意味着
当前的后训练范式
在一段时间内
可能会少很多有意思的新进展
不过客观来说
MOPT也是最近才推出的
所以这套范式问世的时间
本来也不算长
不过他们还做了一项
我认为之前没有明确提到过的小调整
那就是模型合并
我也做过一期关于模型合并的视频
在强化学习过程中
他们会合并来自不同脚手架
不同配置的独立训练运行的检查点
整合不同优化路径的提升效果
在用合并后的模型初始化
下一次强化学习运行
也就是说模型合并是用来持续汇总各次成功
强化学习运行带来的提升等到流程最后
他们会在不同领域和训练阶段开展大规模同策略蒸馏
将所有专家教师模型的能力整合到同一个模型中
另一方面推理力度也有一项升级
它不再像V4那样只设置Think High和Think Max模式
而是通过强化学习
让推理力度成为一个从1到100的数值
力度越低
Token惩罚越强
力度越高
就会逐步允许模型使用更多算力
因此
模型不是训练几个彼此孤立的推理模式
而是学会一条平滑的成本质量曲线
面向用户的Low High和Max 3档
基本上就是同一尺度上
力度值为50,75和100的设置
好啦
V4.1 Flash在技术报告中提出的
大部分重要进展就介绍到这里
这份51页的技术报告里
还有许多技术细节
但其中有些内容实在太深奥
或者需要更多背景知识才能解释清楚
比如DSEC缩放多莫态混合专家均衡
以及其他基础设施改进
所以如果你们想了解更多
一定要去看看他们的论文
谢谢大家观看
特别感谢Spamatch Chris Ledoux
Degan
Roberts Zaviasa
Poof
Inu
DX Research Group
Alex
Leo Halawani
以及其他许多通过Patreon
或YouTube支持我的人
还没关注我的话到推特上关注我
我们下期再见

尚未產生學習筆記

請在 Telegram 指令最後加上「學習」，例如：videonote 網址 英文 雙語 學習