架构演化 — 当规模本身成了瓶颈
这一章讲三件事: 为什么架构创新越来越像系统创新; 一次生成时那份必须被存下来的东西是什么、它为什么会吃掉显存; 以及每一种「新架构」到底把代价挪到了哪儿。
它在全书链条里的位置:第 03 章讲的是标准结构本身, 这一章讲的是「这个底座在规模继续变大之后,怎么改才划算」。 第 09、10 章会把这些改动落到真实机器上再验一遍。
顶层全景:同一张账本上的四栏
每一次架构改动,都要在这四栏上同时记账
┌───────────┬───────────┬───────────┬───────────┐
│ 能力 │ 练出来 │ 用起来 │ 工程 │
│ 有没有涨 │ 贵不贵 │ 贵不贵 │ 复杂多少 │
├───────────┼───────────┼───────────┼───────────┤
长窗口 §3§4 ↑ ↑ ↑↑ ↑
拆专家 §5–§7 ↑ → →(显存↑) ↑↑
压缓存 §8 → → ↓↓ ↑
外挂资料 §9 ↑(时效) ↓ → ↑
换主干 §10 ? ? ↓(超长时) ↑↑↑
└───────────┴───────────┴───────────┴───────────┘
图说: 这一章每一节都在填这张表里的一行。 读到任何一个新名字时,先问同一个问题:它把代价挪到哪儿去了?
1. 架构创新为什么越来越像系统创新
在早期,人们谈架构时主要关心一件事:表示能力更强了吗?
可规模一旦进入工业级,这个问题就不够用了。一个结构如果训不了、扩不到大规模、 用起来单位时间处理不了多少、和现有硬件严重不匹配,那么它即使在小实验里很漂亮,也很难成为主流1。 于是今天很多架构创新从一开始就要同时面对训练系统和使用系统的约束。
这也是为什么架构演化经常表现为「局部结构和系统策略一起改」。 把窗口拉长,既要求注意力变化,也要求存下来的中间结果怎么管、材料怎么切、考法怎么出都跟着变; 把一层拆成很多专家,远不止多加几个层,它意味着通信、负载分配和调度都要重新设计2。
从读者角度看,这能帮你避开一个常见误解:并不是所有架构名词都对应一种全新的认知原理。 很多时候,新架构之所以重要,多半在于它更合理地组织了计算、内存和外部信息流, 而未必动了「它如何理解语言」这一层3。
2. 一张账本:读每一节时都问同一个问题
这一章后面每一节,都可以放进开头那张表里对照着读。 读到任何一个新名字,先问:它把代价挪到哪儿去了?
书里给出的评价口径是四条同时看:能力有没有提升、 练出来的成本有没有失控、用起来的成本有没有下降或至少可接受、 以及这种设计是不是足够稳定、足够容易做成工程4。
这条口径解释了一个反复出现的现象:理论上更漂亮的方案,常常打不过常数因子更小的工程方案。 第 09 章 §6 会给出这条规律最干净的一个例子——那个方案在数学上根本没动注意力, 连一个新公式都没引入,只是把计算顺序调得更贴合显卡的存储层级, 论文里那些理论上更省的方案反而至今没能把它挤出主流框架的默认配置5。
3. 上下文窗口:这一次能看见多长
先把一个全书都要用的名字定下来。
上下文窗口说的是:这一次推断,它能看见的输入范围有多长。 你的问题、之前的对话、你贴进去的资料,合起来都要装进这个范围; 装不下的部分,要么被截断,要么根本进不来。这个长度按词元数算—— 今天常见的是几万到几十万,前沿的能到百万量级。
全书只用这一个名字。 你在别处会看到「长上下文」「上下文长度」这些说法, 它们指的是同一件事;为了不让你以为那是三样东西,本组拆解统一叫上下文窗口。
对用户来说,窗口更长意味着能一次读入更长的论文、代码库、合同或对话历史。 但对内部来说,这首先是一个计算问题6。
回到第 03 章 §3 那张 N × N 的关系表:标准注意力的特点是每个位置都要和其他位置发生交互。 好处是全局关系建得很牢,坏处是长度越长,计算和显存涨得越快。 短的时候这代价还能接受;窗口一旦继续拉大,它很容易变成部署里的主要压力。
所以长窗口研究要做的,是想办法让它在更大范围内保留有用信息, 同时不为所有位置之间的两两交互付出同样高昂的代价。单把窗口数字改大,远远不够7。
4. 把窗口拉长要同时做三件事
书里点出一个经常被忽略的问题:训练时见过的长度和使用时要求的长度,并不总是一致8。 一个模型即使在训练中学会了处理较长输入,也未必意味着它在更长的场景里 仍能稳定找到关键证据、保持主题一致、避免前后混淆。
很多时候,用户以为自己需要的是「更长的窗口」,真正需要的却是「更稳的长程引用能力」。 这两件事差别很大,而且要靠三件事一起做。
第一件是位置方案要能往更长处推。 第 03 章 §6 讲过位置编码的演化。 当训练时只见过几千词元,使用时却被要求处理几十万甚至 上百万时, 它对那些「从未见过的远位置」的反应往往不可靠:要么权重分布失常, 要么只关注开头和结尾、忽略中段9。
书里给了三种修法。一种直接在分数上加一个线性惩罚:两个位置离得越远,分数衰减得越多; 好处是天然能往更长处推,代价是对位置的表达比较粗糙。 另一种是把位置坐标压缩,让长输入的旋转角落回训练时见过的范围。 第三种在这基础上再加「斜率退火」和分数陡峭度的调节,是把已有模型从短窗口平滑扩到长窗口 最常用的方案之一10。
第二件是必须真的在长材料上练过。 光把位置方案改好还不够。 直接随机拼接超长材料效果一般,因为大多数长文档里真正需要长程呼应的关系并不多。 更精细的做法是构造合成的长程任务(在长文档中插入需要前后呼应的「针」)、 用书籍、长论文、代码仓库这类天然长程材料训练,或者把多份相关文档串成一个长输入11。
第三件是要有配套的考法。 有一类经典考法叫「大海捞针」: 给它一段几十万词元的文本,中间藏一句关键事实,看它能不能找出来。 书里那句判断很硬:一个能扩到百万词元却找不到中段事实的模型,顶多算「读得快」, 谈不上「读得懂」12。
5. 稀疏激活与混合专家:把「参数多」和「每步算得少」分开
窗口解决的是「看得够不够远」;这一节解决另一个同样现实的问题: 能不能在不让每一步计算都变重的前提下,拥有更大的容量。
标准做法的特点是稠密——每个词元都会经过同一套参数路径, 所有参数在每一次计算中都要参与一遍。这样结构简单, 但当参数规模继续扩大时,成本会跟着一起上涨13。
混合专家给出的思路是:把一部分层改造成「许多专家并列存在,但每次只调用少数几个」。 书里那个比方很好记:像一家大型医院,专家门诊很多,但一个病人不会同时让所有专家一起看, 而是先经过分诊,再去最相关的几个科室14。
对应到模型里,就是由一个路由模块根据当前词元的表示,决定把它送往哪几个专家网络。 于是参数总数可以增长得很大,但每个词元真正激活的参数仍是少数。 第 03 章 §10 说过它为什么拿前馈层开刀:那是「胖」的那部分,拆开收益最大。
这类设计之所以重要,关键并不在于它「参数更多」,而在于它在容量和单步计算之间 开出了一条新的折中路线15。稠密做法想增强本事,通常意味着每一步都更贵; 这条路试图把「更多本事」和「每次只算一部分」结合起来。
但代价并没有消失,它只是从纯计算问题转移成了路由、通信和调度问题。 换句话说,它重新安排了成本结构,并没有凭空省下代价16。 这正是这一章开头那张账本要提醒的事。
6. 路由、负载均衡与专家塌缩
最难的地方往往是「怎么把词元分得合理」,把专家堆起来反倒是简单的一步。
如果路由模块总是偏爱少数几个专家,就会出现明显的负载不均: 某些专家非常忙,另一些几乎闲置。这样一来,模型虽然名义上拥有很多专家, 实际上却只有少数路径在真正学习,既浪费容量,也拖垮训练效率17。
书里列了三类常见做法:在主目标之外加一个额外约束,鼓励不同专家获得更均匀的分配; 限制每个专家能接收的词元数量,超过部分重新分流或直接丢弃; 用更平滑的路由策略减少极端集中18。更激进的一种做法干脆不加额外损失, 而是在路由打分上直接给低负载的专家一个动态加分,让分配自然均衡。
直观地说,路由要既分得准,又分得散。 这两个要求本身就有张力。
路由带来的第二个问题是稳定性。因为专家路径是动态选择的, 训练时不同词元会触发不同的子网络,梯度分布也会变得更不均匀。 设计不好就容易出现专家塌缩、训练震荡、通信瓶颈放大19。
真正的难点是「这些专家是不是真的学出了不同本领」,专家数量多寡反在其次。 如果所有专家都做差不多的事,那么这套结构就只是复杂化; 只有专家之间形成明确分工,容量才真正转化成有效能力20。 这也决定了它究竟是在扩大能力,还是只是在扩大参数数字。
7. 工程账:细粒度、共享专家与两次全体通信
书里在这里给了不少可落地的细节,值得单列一节21。
细粒度专家。 早期方案通常把每层切成 8、16、64 个专家,每次激活 1 到 2 个。 后来有团队把单个专家拆得更小,同时增加专家总数,比如 256 个专家、每次激活 8 个。 直觉是:更细的分工能让每个专家学到更窄、更专的本事;代价是路由复杂度和通信开销都更高。
共享专家。 全靠动态分流有一个隐患:某些通用模式可能没有任何专家专门负责。 于是保留一个或几个「所有词元都会经过的公共专家」,让基础本事总有路径承载, 把动态分流留给更专的任务。「越稀疏越好」反而是个误区22。
通信是最疼的那一笔。 参数一多,每张卡装不下全部专家,必须分布到多张卡上。 路由完成后要把词元通过一次「全体对全体」的通信发到对应专家所在的卡上, 算完再发回来——算一遍的过程里要做两次这样的全体通信, 通信时间常常占总时间的相当大比例23。
显存账也变了形。 虽然每次只激活几个专家,但所有专家的参数都要常驻显存。 书里给了一个很具体的数:一个「370 亿激活、6710 亿总参数」的模型, 使用时仍然要吃 700 GB 量级的显存24。 「每次只算一小部分」省的是算力,不是显存——这条区分非常要紧, 第 10 章讲「同时能接多少人」时还 会回来。
8. 那份必须存下来的东西,和三条把它压小的路
这一节是全章最要紧的一节,因为它解释了一笔几乎所有人都会撞上的账。
先说清楚这份东西为什么必须存在。
第 03 章 §7 讲过,只用后半边的那种结构是一个位置一个位置往下生成的: 先生成第 1 个词元,把它接回去,再生成第 2 个,再接回去,生成第 3 个……
问题来了。生成第 N 个词元时,注意力要让这个位置去看前面 N−1 个位置。 而「看」需要前面每个位置的键和值。如果什么都不存, 那么每生成一个新词元,都要把前面所有位置的键和值从头重算一遍。
算一下就知道这有多蠢:生成第 100 个词元时要重算 99 个位置, 生成第 101 个时要把这 99 个再算一遍,只多了一个新位置。 前面那 99 份东西根本没变过——它们只依赖已经确定下来的前文。
所以做法很自然:把每一层、每个头已经算出的键和值存起来,下次直接取用。 把算过一次的东西留在手边、下次不再重算,这种做法本身有个通用的名字叫缓存。
这份被留下来的东西因此叫键值缓存——前文每个位置在每一层算出的键和值都在里面, 生成下一个词元时直接取用,不必重算;它更常见的英文简称是 KV 缓存。
书里的比方很贴切:像写侦探小说时的资料夹。前面每个角色、地点、线索的「资料卡」 已经整理好了,下一页要写新内容时,不必把前文重新读一遍, 只要把新线索的查询拿来和旧资料卡比对25。
但这份缓存不是免费的。 它要占显存,而且占用量随着已经生成的长度线性增长: 每层、每个头都要存一份,层数越多、头越多、窗口越长,它就越大。 于是长窗口场景的真实瓶颈常常不是参数本身,而是这份缓存26。 它到底怎么限制「同时能接多少人」、怎么被当成内存管起来,是第 10 章 §4 的主题; 这一节只管把「它为什么存在」讲清楚。
现在可以看压它的办法了。书里把这一类改造归成三条路27。
第一条路是缩减这份缓存本身。 既然每个头都要存一份键和值,那就让它们共享。 最激进的做法是所有头共享同一套键和值,只保留各自的查询—— 缓存大小直接除以头数,省得最狠,但表达力有损失。
温和一些的做法是把头分成若干组、组内共用一套键和值,借此把缓存按组数缩小, 这种做法叫分组查询注意力;它省了一大截、质量几乎不掉, 所以被一票主流模型直接收编28。
更新一代的做法是对键和值做低秩(用两个瘦长的小矩阵相乘去近似一个大矩阵)压缩, 再在每个头里恢复,显存压到接近最省的水平,效果却不输完整多头。
第二条路是不让每个位置都看所有其他位置,这叫稀疏注意力 (只保留一部分位置之间的连接,其余直接不算)。常见的三种组合是: 让每个位置只关注邻近的几个;让少数特殊位置充当「公告板」,所有位置都能看到它们; 再补上少量随机的远处连接保证全局连通29。 组合起来能把复杂度从平方级降下来,代价是某些需要全局精确连接的任务会有损失——稀疏不是免费的。
第三条路更激进:用数学近似把那张表本身绕开。 常见思路是把 Softmax 换成某种别的函数, 利用矩阵乘法的结合律,先算一个小矩阵再乘,从而避开那个 N × N 的中间产物30。 它最大的诱惑是复杂度真的降到了线性,最大的代价是准头下降—— 目前还没有一种这样的做法能在所有任务上完全追平标准注意力。
9. 检索增强生成:把知识挪到参数外面
架构演化并不只有「把这套结构修得更好」这一条路。
另一类思路认为:既然长窗口和大容量的难点都集中在「所有信息都被塞进参数和那张表里」, 那不如把一部分本事外移31。
先补一个词。检索说的是:拿一句话或一组关键词,去一堆资料里把最相关的几段找出来。 它是搜索引擎干了几十年的事,只是这里被接到了模型前面。
于是有了检索增强生成(回答之前先从外部资料里找回相关内容, 再把这些内容连同问题一起交给模型)。与其要求它把所有知识都记在参数里, 不如在需要时从外部知识库、文档库甚至外部程序里取回相关信息,再交给它整合。
它的英文简称是 RAG——出门在外你撞见这三个字母的次数, 可能比撞见中文全称还多,所以本组拆解两个都留。
这样做把它的任务从「记住一切」改成了「知道去哪里找、拿回来之后怎么用」32。 好处有两条:知识时效性(它不知道训练截止之后的事,但资料库可以随时更新) 和知识私有性(它不知道公司内部文档,但那些文档可以放进资料库)。 要更新知识,只要把资料库重新整理一遍,不必重训。
这条线在这一章只需要知道它「把能力重新分布到了参数、外部存储和运行时控制之间」。 它的工业链路——怎么切块、怎么召回、怎么把召回的结果再排一次序、怎么在多轮里边推边查—— 是第 12 章 §6 和 §7 的主题。
10. 换掉主干:另一类新路线
还有一类研究从序列建模的基本机制出发,试图减少标准注意力在长输入上的负担。
其中一个重要方向叫状态空间模型:用一种递推式、压缩式的状态更新来保留历史信息, 每一步只维护一个压缩状态,不必显式回看全部历史33。 听起来是不是很像第 02 章 §8 那条被打穿的老路?确实很像——区别在于它的状态更新方式 经过了重新设计,而且能像标准注意力一样并行训练。
书里给出了这条路线成立的数学骨架,叫并行-串行对偶: 同一个数学对象既能批量训练(所有位置一次过), 又能像老路那样逐词元使用(只维护一个固定大小的状态矩阵)34。 使用时不再随长度积累缓存——这正是它对超长输入的吸引力所在。
但它们受困于同一个代价:这类近似难以精确逼近 Softmax 能造出的那种尖锐关注模式, 表达能力理论上弱于标准注意力。所以今天它们主要出现在超长输入场景, 或者和标准注意力混着用,还没有在通用任务上完全取代它35。
书里对这一类新路线给了一句很克制的判断:与其急着判断谁会全面取代谁, 不如先问一个更基本的问题——它解决了哪个已知瓶颈,又为此新增了什么约束36。
这也解释了为什么很多「新架构」最终会以混合形态进入主流: 主体仍然是标准结构,但会接入外部检索;或者局部保留注意力、更长范围使用压缩状态。 真正大规模落地时,很少有团队愿意为了一点局部优势彻底放弃成熟工具链和现有部署体系; 于是新架构能否被吸收进主流,往往取决于它能不能以模块化方式嵌入现有堆栈37。
11. 怎么评价一个架构创新
最后给一条读新名字时的判断规矩。
有一个经常被忽略、但在真实系统里极其重要的视角: 一种结构也许训练时很友好,却未必使用时友好;反过来也一样38。 架构面对的从来不是单一目标,而是同时要回答「能不能训出来」和「训出来之后好不好用」。
书里拿混合专家当例子:它在参数容量和单步计算之间提供了诱人的折中, 看起来非常适合扩大能力;可一旦进入使用阶段,路由、跨卡通信、缓存管理和负载波动 都会带来新复杂度39。同样一个优点,在两本账上可能写成完全 不同的结果。
书里还给了一个「刚刚好」的正面例子:分组共享那套做法没有把缓存压到最极致 (那样省得最狠但伤表达力),而是让若干头共享一组键和值—— 缓存省了一大截、质量几乎不掉,于是被一票主流模型直接收编40。
判断(我们的,不是书里的): 判断一个新架构值不值得关注, 最省事的办法不是看它的名字或复杂度公式,而是问一句: 有没有主流框架把它设成默认? 默认配置是最诚实的投票—— 它同时通过了训练账本、使用账本和工程成熟度三关。 如果错,会错在: 生态惯性也会让一个次优方案长期占着默认位置, 尤其在切换成本很高的时候;这条判断会漏掉那些「更好但没人愿意改」的方案。
主走查:一份 12.8 万词元的合同进入模型
这条走查贯穿本章。 假设你把一份很长的采购合同整个贴进对话框, 问它「第 7 条的责任限制和去年模板有没有冲突」。凡不是书里给出的数,都当场标明是为演示编的。
① 窗口装不装得下? 这份合同切完大约 12.8 万个词元(这个数是为演示编的)。 如果窗口是 8 千,它连一半的一半都装不下;如果是 12.8 万,刚好装满, 再加你的问题就溢出了。这就是第 3 节那件事:窗口先决定了「能 不能开始」。
② 位置方案撑不撑得住? 假设这个模型训练时只见过 8 千长度的材料。 现在突然给它 12.8 万,那些「从未见过的远位置」会让它的关注变得不可靠—— 典型症状就是第 4 节说的「只看开头和结尾、忽略中段」。 所以要么它已经在长材料上补训过,要么用第 4 节那三种修法把位置压回训练见过的范围。
③ 那张关系表有多大? 12.8 万个位置两两相比,格子数是 12.8 万的平方 ≈ 164 亿。 对比一下:8 千长度时是 6400 万格。长度涨 16 倍,格子涨 256 倍。 这就是第 3 节说的平方级代价,也是第 8 节三条路要救的东西。
④ 缓存吃掉多少显存? 用第 8 节那份键值缓存算一笔账。 假设 80 层、8 个键值头、每头宽度 128、每个数占 2 字节: 一个位置一层要存的键和值 = 2(键和值各一份) × 8 × 128 = 2048 个数; 80 层就是 16.4 万个数,占 32.8 万字节 ≈ 0.31 MB。 乘以 12.8 万个位置 = 约 40 GB。 一份合同、一个人、一次对话,就吃掉了将近 40 GB 显存—— 这已经接近一张 80 GB 显卡的一半41。
⑤ 换成分组共享省几倍? 上面那个配置里键值头是 8 个。 如果原本是 64 个头各存一份,缓存就是 8 × 40 = 320 GB,单卡根本装不下。 分成 8 组、组内共享之后降到 40 GB——省了 8 倍42。 第 8 节那三条路,第一条救的就是这一笔。
⑥ 更省的做法:根本别 把整份合同塞进去。 按第 9 节那条路, 先把合同切成几百段、给每段建好可查的条目,你问「第 7 条的责任限制」时只取回最相关的 5 段 (加起来也许 3000 个词元),连同问题一起交给它。 窗口从 12.8 万降到 4 千,关系表从 164 亿格降到 1600 万格,缓存从 40 GB 降到 1.2 GB。
⑦ 但第 ⑥ 步不是白拿的。 如果这个问题真正需要通读全文才能回答 (比如「这份合同整体上对谁更有利」),取回来的 5 段就不够了。 这正是第 9 节那句话的意思:检索把任务从「记住一切」改成了「知道去哪儿找」, 而「找得准不准」就变成了新的天花板。 这条线第 12 章会展开。
作者的判断与证据
书里给了具体数字的地方:
- 那个「370 亿激活、6710 亿总参数」的模型使用时仍吃 700 GB 量级显存, 这是一笔可以自己核的账,也是「稀疏省算力不省显存」最硬的证据24;
- 一次前向要做两次全体通信,以及通信时间常常占总时间相当大比例23;
- 分组共享让缓存按组数缩小,书里明确说它「省了一大截、质量几乎不掉」40。
书里明确标成判断或未定的地方:
- 哪一条新路线会赢,书里拒绝下判断,只给了「它解决了哪个瓶颈、又新增了什么约束」 这条问法36;
- 线性近似能不能追平标准注意力,书里说「目前还没有一种能在所有任务上完全追平」35;
- 专家是不是真的学出了不同本领,书里说这种专业化「未必总是清晰可解释」20。
这一章还有一处口径值得点出:书里把「架构创新」和「系统创新」的界限主动模糊掉了。 它反复强调很多新架构并没有动「如何理解语言」这一层,只是重新组织了计算、内存和信息流3。 这是一条很有价值的判断,因为它能帮你在读新论文时快速分辨: 这是认知层面的进展,还是账本层面的挪动。
边界与局限
- 本组拆解把那个「不改数学、只改计算顺序」的方案整节挪到了第 09 章。 原因 是它要靠「显卡内部有两级存储」这件事才说得通, 而那两级存储要到第 09 章 §1 才出现;放在这里会跳级。
- 书里没有给出各种方案的横向实测对比。 哪种压缩在什么长度下省多少、 质量掉多少,书里只给定性判断。
- 状态空间那条线书里讲得很浅。 它的递推形式、选择性机制、 以及为什么能并行训练,都只给了结论。
- 检索这一节在书里是「架构演化」的一个小节,而不是一条完整链路。 真正的工业做法(切块、混合召回、再排一次序、边推边查)全在第 12 章。
可带走的
- 架构创新越来越像系统创新。 一个训不了、扩不动、用起来慢的结构,再漂亮也当不了主流。
- 读新名字时问同一个问题:它把代价挪到哪儿去了? 能力、练出来、用起来、工程复杂度,四栏同时记账。
- 上下文窗口就是这一次推断能看见的输入范围。 全书只用这一个名字。
- 拉长窗口要同时做三件事: 位置能往更长处推、真的在长材料上练过、有配套的考法;扩到百万词元却找不到中段事实的模型,顶多算「读得快」。
- 混合专家把「总参数」和「每次激活的参数」分开。 但代价没消失,只是从算力挪到了路由、通信和显存。
- 稀疏省的是算力,不省显存。 所有专家的参数都要常驻。
- 键值缓存存在的理由只有一条:前面那些位置的键和值根本没变过,重算是纯 浪费;它随长度线性增长,长窗口的真实瓶颈常常是它,不是参数。
- 压它有三条路: 让头共享(省得最实在)、只连一部分位置(有损失)、用数学近似绕开(准头代价大)。
- 检索把任务从「记住一切」改成「知道去哪儿找」。 于是天花板从记忆量变成了检索质量。
- 判断一个架构值不值得关注,看有没有主流框架把它设成默认。
原文地图
| 主题 | 原书节 | 原文位置 |
|---|---|---|
| 架构创新像系统创新 | 3.6 | text/04-ch03-3-transformer.txt:636(搜「架构问题就不再只是数学结构问题」) · text/04-ch03-3-transformer.txt:646(搜「并不是所有架构名词都对应一种全新的认知原」) |
| 四条评价口径 | 3.10.1 | text/04-ch03-3-transformer.txt:909(搜「四件事」) |
| 计算顺序重排那个例子 | 3.10.1 | text/04-ch03-3-transformer.txt:915(搜「它在数学上根本没动」) |
| 上下文长度的扩展 | 3.7 | text/04-ch03-3-transformer.txt:657(搜「这首先是一个计算问题」) · text/04-ch03-3-transformer.txt:662(搜「单把窗口数字改大远远不够」) |
| 训练长度与使用长度不一致 | 3.7 | text/04-ch03-3-transformer.txt:666(搜「训练时见过的长度和推断时要求的长度」) |
| 三种位置外推方案 | 3.7.1 | text/04-ch03-3-transformer.txt:686(搜「线性偏置注意力」) · text/04-ch03-3-transformer.txt:691(搜「RoPE 和它的缩放变种」) |
| 长材料怎么构造 | 3.7.1 | text/04-ch03-3-transformer.txt:699(搜「模型必须真的在长序列上」) · text/04-ch03-3-transformer.txt:708(搜「顶多算」) |
| 混合专家的想法 | 3.8 | text/04-ch03-3-transformer.txt:714(搜「每个输入 token 都会经过同一套参数路径」) · text/04-ch03-3-transformer.txt:721(搜「一家大型医院」) |
| 关键不在参数更多 | 3.8 | text/04-ch03-3-transformer.txt:725(搜「关键并不在于它」) · text/04-ch03-3-transformer.txt:727(搜「它只是从纯计算问题转移」) |
| 路由与负载均衡 | 3.8.1 | text/04-ch03-3-transformer.txt:745(搜「就会出现明显的负载不均」) · text/04-ch03-3-transformer.txt:748(搜「负载均衡是」) · text/04-ch03-3-transformer.txt:756(搜「这些专家是不是真的学出了不同本领」) |
| 细粒度与共享专家 | 3.8.2 | text/04-ch03-3-transformer.txt:766(搜「细粒度专家」) · text/04-ch03-3-transformer.txt:771(搜「共享专家」) |
| 通信与显存开销 | 3.8.2 | text/04-ch03-3-transformer.txt:796(搜「一次前向传播里要做两次」) · text/04-ch03-3-transformer.txt:803(搜「所以一个」) |
| 缓存与三条路 | 3.9 | text/04-ch03-3-transformer.txt:808(搜「显存里的 KV 缓存也」) · text/04-ch03-3-transformer.txt:811(搜「第一条路是缩减 KV 缓存本身」) · text/04-ch03-3-transformer.txt:818(搜「第二条路是不让每个位置都看所有其他位置」) · text/04-ch03-3-transformer.txt:823(搜「第三条路更激进」) |
| 缓存复用的比方 | 6.3.3 | text/07-ch06.txt:445(搜「把先前 token 在各层里已经算出的键和值缓存下来」) · text/07-ch06.txt:448(搜「资料夹」) |
| 缓存显存公式与算例 | 6.3.3 | text/07-ch06.txt:194(搜「其中」) · text/07-ch06.txt:478(搜「单条 8K 序列大约要」) |
| 检索把能力外移 | 3.10 | text/04-ch03-3-transformer.txt:861(搜「那不如把一部分能力外移」) · text/04-ch03-3-transformer.txt:864(搜「知道去哪里找」) |
| 状态空间与对偶 | 3.10 / 3.9 | text/04-ch03-3-transformer.txt:17(搜「状态空间模型」) · text/04-ch03-3-transformer.txt:851(搜「并行-串行对偶」) · text/04-ch03-3-transformer.txt:855(搜「性核难以精确逼近」) |
| 混合形态与生态惯性 | 3.10 | text/04-ch03-3-transformer.txt:873(搜「它解决了哪个已知瓶颈」) · text/04-ch03-3-transformer.txt:882(搜「点局部优势彻底放弃成熟工具链」) |
| 训练友好 vs 使用友好 | 3.10.1 | text/04-ch03-3-transformer.txt:887(搜「一种结构也许训练时」) · text/04-ch03-3-transformer.txt:899(搜「GQA 就是个现成的例子」) |