跳到主要内容

让它在自己的电脑上跑得动 — 两招把七秒压到零点六秒

这一章讲什么: 这本书为什么挑了一个这么小的模型; 训一个底座到底贵到什么程度(贵到你不可能自己训); 以及两招提速 —— 一招把重复的计算存下来复用,一招把一堆小动作合并起来。 最后分清一对天天被混为一谈的概念:快,到底指的是哪一种快。

它在全书链条里的位置: 第四环,也是「阶段一」的最后一环。 读完这一章,你手上就有一个能在自己机器上跑的模型和一个够快的生成函数 —— 第 05 章开始造尺子,那是这本书真正的开场。

需要的基础: 第 03 章那个循环 —— 每写一个新词,前面所有的计算都被重做了一遍。

顶层全景:同一段生成,四种跑法​

整章的主走查只有一件事:在同一台机器(作者的 Mac Mini M4,只用它的中央处理器)上, 生成同样 100 个小块,四种跑法各要多久。

  跑法                     速度            耗时       比朴素快多少
  ────────────────────────────────────────────────────────────────
  ① 朴素(第 03 章那个循环) 5 个/秒        7.94 秒        —
  ② 只开编译                6 个/秒        6.78 秒       1.2 倍
  ③ 只开 KV 缓存           29 个/秒        1.40 秒       5.7 倍
  ④ 两个都开             ★ 68 个/秒     ★ 0.60 秒      13 倍

  图说:注意 ② 和 ③ 的差距 —— 单独上编译几乎白搭,
  而单独存一下中间结果就快了五倍多。为什么,第 3、4 节讲。

1. 选型:6 亿个参数,一个 1433 MiB 的文件​

这本书从头到尾只用一个模型:Qwen3 0.6B。

名字里的 0.6B 就是「约 6 亿个可调的数」的意思1。 下载下来的权重文件有 1433 MiB,大约 1.4 GB2 —— 对照一下:一部手机拍几分钟 4K 视频就是这个量级,而普通笔记本的内存通常是 8 到 16 GB。 所以这本书的每一段代码,你自己的电脑真的跑得动。

挑它的第二个理由更要紧:同一家公司为这个尺寸出了两个版本。

版本身份
base 版只做过预训练,没调教过 —— 这是本书要改进的对象(为什么用它,第 02 章第 4 节讲过)
官方推理版同一家做好的推理模型 —— 这是本书的参照系,一根天花板

书说得很明白:官方推理版是拿来当评测参照用的3。 有了它,每一次改进都能问一句「离官方那个还差多少」,而不是只报一个孤零零的数字。

还有一件事必须说清,否则会误会这本书的做法: 作者没有用任何现成的大模型工具库。 他自己用 PyTorch 把 Qwen3 重写了一遍,但和官方发布的权重完全兼容4。 所以你下载的是官方的权重,跑的是他自己写的那套代码。

至于模型内部长什么样,书直接说了:可以当黑盒。 理由是这本书不修改模型本身,只在它上面加东西5。

2. 你为什么不可能自己训一个底座​

这一节只有一个用途:让「我们只训改进,不训底座」这个决定有分量。

书给的不是估算,是有出处的真实数字6:

项数
第一梯队的公司训一个新底座的算力开销低的 100 万到 1000 万美元,高的 5000 万美元以上
DeepSeek V3(R1 那个推理系统的底座)2048 张 Nvidia H800 显卡,跑约 11 周,估算约 550 万美元
同上,总算力1480 万 GPU 小时
同上,耗电约 620 兆瓦时 ≈ 一个美国普通家庭用 55 年的电

那个「55 年的电」是书自己给的参照物,不是我们加的 —— 它把一个抽象的兆瓦时 换算成了一个人能想象的长度。

书还顺带下了一句判断:DeepSeek V3 是少数几个把算力开销完全公开的模型之一6。 这句话本身就是信息: 你在别处看到的训练成本,大多是外部推算的,不是厂商公布的。

作者用了一个比方解释「为什么用小模型学」: 想搞懂汽车怎么工作, 不该一上来就造法拉利,先造一辆小车;他甚至认为小车更好懂, 因为那些复杂的精细改良被拿掉了7。(比方到此为止,下面一律用正式说法: 小模型的机制更容易看清,因为遮蔽视线的工程打磨更少。)

一条硬边界书也划了: 第 2 到 5 章用中央处理器就能在合理时间内跑完; 第 5 到 8 章会受益于显卡8。

一处利益相关,作者主动披露了,我们照实转述: 他在 2.3 节推荐了一个云计算平台,并且当场说明:他 2023 年参与创建了这家公司, 但现在已经没有任何财务利益,不是赞助,自己付费使用9。 这处披露只影响这一节的读法(挑云平台的建议),不影响全书任何技术结论。

3. 为什么它越写越慢:把算过的东西存下来​

先看现象,现象在第 03 章已经出现过了。

第 03 章那个循环里有一句要命的话:「把加长后的整句重新丢进去」。 于是每写一个新词,前面所有词的计算都被从头做了一遍 —— 而除了新来的那一个词,其余的输入和上一轮一模一样10。

  第 1 轮:算 [Explain][ plain][ large][ language][ models][.]                 6 块
  第 2 轮:算 [Explain][ plain][ large][ language][ models][.][ Large]        7 块 ← 前 6 块白算了
  第 3 轮:算 [Explain][ plain][ large][ language][ models][.][ Large][ lang] 8 块 ← 前 7 块白算了
  ……

  图说:每一轮的重复部分都在变长,所以**越写到后面,浪费得越多**。

改法很朴素:把算过的中间结果存起来,下一轮直接取。

存的是什么?模型内部有一层叫注意力的机制 —— 它让每个位置去看前面所有位置、 按相关程度把信息混进来。这一层在处理每个位置时会先算出两组中间结果, 这一行分别叫 key(键)和 value(值)。

关键在于:某个词的这两组结果,只跟这个词和它前面的内容有关, 和后面还没写出来的词完全无关。 所以它们一旦算出来,就再也不会变,存下来复用是安全的。

这套做法的名字叫 KV 缓存(KV 就是 key 和 value 的首字母;缓存的意思就是 「把算过的结果存在手边,下次直接取,不再重算」)。

用起来只差一处11:

  第 1 轮:把整串输入交给模型,顺手把每个位置的 key / value 存进缓存
  第 2 轮起:只把**新来的那一个**小块交给模型,前面的内容从缓存里取

省下了多少?书就地给了一把尺子12:

生成 n 个小块的总工作量书对记号的解释
不缓存约 O(n²)总工作量大致随输出长度的平方涨
缓存后约 O(n)总工作量大致和输出长度成正比

平方和正比的差别,在长回答上是致命的。 而推理模型最典型的样子恰恰就是回答长 —— 所以这一招对这本书不是可选项。

走查第 ③ 步:同一段 100 个小块的生成,从 5 个/秒变成 29 个/秒, 耗时从 7.94 秒降到 1.40 秒13 —— 快了 5.7 倍,而模型一个数都没改。

书自己划了边界:KV 缓存内部怎么实现,超出本书范围, 作者给了自己一篇免费文章的地址12。

为什么装机章要花力气讲速度?书自己回答了: 后面的评测和推理流程动辄要生成很多小块、很多候选答案, 这里省下的一点会成倍放大14。这句话是第 04 章和后面每一章之间的桥。

4. 第二招:编译 —— 而且第一次跑反而更慢​

这一招管的是另一件事:不是少算,而是把算的过程整理得更利落。

书的说法是:torch.compile 会分析模型内部的计算流程,把一组一组的操作合并成更优的写法, 减少中间那些零碎的开销;在反复调用同一段模型代码时(生成正是这种情况)效果尤其明显15。

但它有一个反直觉的特点,书特意提醒了:第一次跑反而更慢 —— 因为要先花时间做这件「整理」的工作。所以书的做法是跑好几遍,把第一遍当热身丢掉16。

这个现象在数据上看得很清楚:

  开了编译 + KV 缓存之后,连跑三次:
     第 1 次:8.07 秒   ← 这一次在编译,不算数
     第 2 次:0.60 秒
     第 3 次:0.60 秒   ← 稳定下来了

走查第 ②、④ 步:

跑法速度耗时
② 只开编译(不开缓存)6 个/秒6.78 秒
④ 编译 + KV 缓存68 个/秒0.60 秒

② 和 ④ 放在一起看,能读出一件事:单独上编译只从 5 提到 6,几乎白搭; 可一旦配上缓存,就从 29 提到 68,又翻了一倍多17。 因为编译省的是「每一步的固定开销」,而缓存把每一步的活儿变小之后, 那些固定开销才成了大头。

书还诚实地解释了一件容易被误读的事:换到显卡上,差距并没有拉开更大18。 他给了三条原因:

原因说明
这份实现没有针对显卡打磨专门为显卡改写的版本会预先分配到最大长度(4 万块)的缓存空间,省掉反复拼接;但吃更多内存。作者选了「按需增长」这条更省内存的路,理由是内存才是大多数读者的瓶颈
模型太小模型越大,缓存和显卡内存布局带来的好处越明显
全部实验都是一次只跑一条一次处理多条的那一套放在附录里 —— 就是下一节的内容

5. 「快」到底指哪一种快​

这一节回答一个几乎所有人都会踩的坑:两种「快」是互相冲突的。

先认一个从这里起会一直用的词:你丢给模型的那一段文字,这一行就叫提示词(英文 prompt)。

书在附录里把两种「快」分得很干净19。第一种问的是一条提示词多快能拿到答案 —— 就是你盯着屏幕等的那段时间,这个量就叫延迟。

第二种问的是固定时间里能处理多少条提示词 —— 比如一晚上能跑完多少道题, 这个量就叫吞吐。两者可以背道而驰:让每一条都更快,不等于一小时能处理更多条。

前面四节讲的两招,管的都是延迟。 而要提吞吐,靠的是另一招: 把好多条提示词凑起来,一次性交给模型一起算。 一次交给它的那一组,行话就叫批。

而这种「凑成一批一起算」的做法,名字叫批处理。

书对批处理的态度非常克制,这段值得原样记住19:

批处理不是在所有设备上都更快。 小模型在中央处理器上、或者在没打磨好的显卡上, 收益可能很小甚至没有 —— 因为要额外引进补齐长度之类的麻烦和开销。 批处理该被理解成一种冲着吞吐去的改进,不是万能加速。

书给的实测把这句话坐实了20:

跑法一次几条内存在 H100 上在 DGX Spark 上
逐条评测 500 道题1 条1.8 GB90 分钟174 分钟
成批评测 500 道题64 条23.39 GB16 分钟108 分钟

读这张表要看三个数一起动:

  内存:1.8 GB → 23.39 GB   涨了 13 倍
     │
     ├─ 在 H100 上:90 → 16 分钟   快 5.6 倍   ← 划算
     └─ 在 DGX Spark 上:174 → 108 分钟   只快 1.6 倍   ← 不太划算

  图说:同一个改动,在两台机器上的回报差了三倍多。
  **这就是「批处理不是万能加速」的具体样子。**

这也解释了后面所有耗时数字为什么那么大。 从第 05 章起,书报出来的 「跑完 500 道题要 10.1 分钟 / 862.6 分钟」全部是逐条跑的成绩 —— 正文的实现自始至终一次只处理一条,一次处理多条的版本在附录和补充脚本里。

作者的判断与证据​

说法性质
4 种跑法的速度与耗时(5 / 6 / 29 / 68)书里印出来的实测,在作者的 Mac Mini M4 上跑的
DeepSeek V3 的 2048 张卡 / 11 周 / 550 万美元 / 620 兆瓦时有出处的公开数字,书说它来自技术报告
「第一梯队的公司 100 万到 5000 万美元」作者给的行业区间,没有列出处 —— 当量级看,别当引用
KV 缓存把 O(n²) 压到 O(n)书自己给的粗略口径(原文用词是「in rough terms」)
编译第一次更慢有证据:书跑了三次并把三次都印了出来
显卡上差距没拉开的三条原因作者的分析,不是对照实验 —— 他没有做一个专为显卡改写的版本来对比
「内存才是大多数读者的瓶颈」作者的设计取舍与判断,这句话解释了他为什么不预先分配缓存
批处理不是万能加速有证据:表 E.1 里同一个改动在两台机器上回报差三倍多
小模型更好懂作者的观点,原话是「我甚至会说」——他自己标了这是个人看法

判断(我们的,不是书里的): 这一章看起来是装机章,但它其实是全书最重要的一次把话说在前头。 它把「一次只跑一条」这个前提摆在了明处 —— 后面每一张成绩表里那些吓人的耗时 (最贵的一行 862.6 分钟),有相当一部分是这个前提造成的,不是方法本身有多贵。 读者若跳过这一章,很容易把「让它答十遍再投票要跑十四个小时」当成这个方法的固有代价。 如果错,会错在: 我们没有自己跑一遍带批处理的版本去量那一栏。 书只在附录里给了评测脚本的对照(90 → 16 分钟),没有给「答十遍再投票」那一行成批跑时的数字; 所以「有相当一部分」这个说法的强度,我们没有独立证据。

边界与局限​

  1. 模型内部结构一个字没讲。 除了第 3 节为了讲清缓存而提到的注意力, 模型里其余那几样零件书明说当黑盒,只把代码放在附录 C。 想补这一层的,见我们书架上的那一章21。
  2. KV 缓存的内部机制,书也不讲。 它只讲「存什么、什么时候取」, 实现细节指向作者自己的一篇文章。
  3. 所有速度数字都是一台机器上的一次测量。 换硬件、换 PyTorch 版本,数都会变。 别把 68 个/秒当成这个模型的规格。
  4. 正文全程一次只跑一条。 多卡、成批训练都不在正文里。
  5. 云平台那一段带利益相关(见第 2 节的披露块),我们建议把它当背景,不当推荐。

可带走的​

  1. 挑模型先问「装得下吗」。 一个 6 亿参数的模型,权重文件约 1.4 GB,普通笔记本能跑。 这本书之所以能从头做到尾,一半功劳在选型。

  2. 有一个「官方做好的同尺寸推理版」当参照系,比任何绝对分数都有用。 这是可以直接抄走的实验设计。

  3. 你不可能自己训底座。 2048 张卡跑 11 周、约 550 万美元、620 兆瓦时(一个美国家庭 55 年的电)。 认清这一点,才会把力气花在「在现成模型上加东西」。

  4. 它越写越慢,是因为每一轮都把前面重算了一遍。 这不是必然的。

  5. KV 缓存 = 把每个位置算过的两组中间结果存下来复用。 工作量从「随长度平方涨」压回「成正比」,实测快 5.7 倍。 对回答很长的推理模型,这一招不是可选项。

  6. 编译第一次反而更慢。 测速度一定要跑好几遍,把第一遍当热身丢掉 —— 不这么做,你会得出「编译更慢」的错误结论。

  7. 两招要一起上。 单独编译只从 5 提到 6;配上缓存才从 29 提到 68。

  8. 分清两种快:延迟(一条多快出答案)和吞吐(固定时间处理多少条)。 批处理提的是后者,而且内存涨 13 倍、回报在不同机器上差三倍多。

  9. 换更大的模型,先算内存账: 按每个参数约 2 字节估, 4B 约 8 GB、32B 约 64 GB —— 而且这只是权重的下界, 实际还要加上运行时的中间结果和缓存,加载时的峰值还会更高22。

  10. 想让它记住你上一句问了什么,得自己把前几轮的话拼进这一次的提示词里。 模型本身没有记性,所谓「多轮对话」就是每次都把整段历史重新发一遍。

  11. 而历史不能无限长:模型一次最多能读多少块是有上限的,这个上限叫上下文窗口。 超了就得裁掉一部分 —— 书的做法是从最老的内容开始丢; 更聪明的办法(比如把旧内容先总结一遍)存在,但书没实现23。

原文地图​

主题原书章原文位置
训一个底座有多贵2.3 Understanding hardware needs and recommendationstext/08-ch02-03-2-3-understanding-hardware-needs-and-recommendat.txt:7(搜「50 million dollars」) · :13(搜「2,048 Nvidia H800 GPUs」) · :19(搜「620 MWh」)
造甲壳虫而不是法拉利同上text/08-ch02-03-2-3-understanding-hardware-needs-and-recommendat.txt:37(搜「Volkswagen Beetle」)
硬件边界:哪几章需要显卡同上text/08-ch02-03-2-3-understanding-hardware-needs-and-recommendat.txt:43(搜「will benefit from using a GPU」) · :91(搜「Chapters 2-5 can be executed in a reasonable time on a CPU」)
利益相关披露同上text/08-ch02-03-2-3-understanding-hardware-needs-and-recommendat.txt:144(搜「no longer have any financial interest」)
选型:0.6B 的含义2.5 Loading pre-trained modelstext/10-ch02-05-2-5-loading-pre-trained-models.txt:26(搜「0.6 billion weight parameters」)
base 版与官方推理版同上text/10-ch02-05-2-5-loading-pre-trained-models.txt:41(搜「official reasoning variant」)
自己重写、与官方权重兼容同上text/10-ch02-05-2-5-loading-pre-trained-models.txt:61(搜「custom reimplementation of Qwen3」)
权重文件 1433 MiB同上text/10-ch02-05-2-5-loading-pre-trained-models.txt:209(搜「1433 MiB」)
架构可以当黑盒同上text/10-ch02-05-2-5-loading-pre-trained-models.txt:298(搜「treat the architecture as a black box」)
为什么装机章要讲速度2.8 Faster inference via KV cachingtext/13-ch02-08-2-8-faster-inference-via-kv-caching.txt:19(搜「small speedups here compound quickly」)
重复计算的浪费同上text/13-ch02-08-2-8-faster-inference-via-kv-caching.txt:51(搜「remain identical in subsequent iterations」)
O(n²) 与 O(n)同上text/13-ch02-08-2-8-faster-inference-via-kv-caching.txt:57(搜「grows roughly with the square of the output length」)
内部机制超出本书范围同上text/13-ch02-08-2-8-faster-inference-via-kv-caching.txt:63(搜「outside the scope of this book」)
第一轮喂全序列,之后只喂一块同上text/13-ch02-08-2-8-faster-inference-via-kv-caching.txt:124(搜「given the full input token sequence」) · :130(搜「we only provide the next_token」)
开缓存后 1.40 秒同上text/13-ch02-08-2-8-faster-inference-via-kv-caching.txt:178(搜「Time: 1.40 sec」)
朴素跑法 7.94 秒2.7 Coding a minimal text generation functiontext/12-ch02-07-2-7-coding-a-minimal-text-generation-function.txt:369(搜「Time: 7.94 sec」)
编译在做什么2.9 Faster inference via PyTorch model compilationtext/14-ch02-09-2-9-faster-inference-via-pytorch-model-compilati.txt:20(搜「more optimized kernels」)
第一次跑更慢同上text/14-ch02-09-2-9-faster-inference-via-pytorch-model-compilati.txt:52(搜「first execution using the compiled model may be slower」)
只编译 6.78 秒 · 两个都开 0.60 秒同上text/14-ch02-09-2-9-faster-inference-via-pytorch-model-compilati.txt:141(搜「Time: 6.78 sec」) · :245(搜「Time: 0.60 sec」)
29 → 68 个/秒同上text/14-ch02-09-2-9-faster-inference-via-pytorch-model-compilati.txt:266(搜「29 tokens per second」)
显卡上差距为什么没拉开同上text/14-ch02-09-2-9-faster-inference-via-pytorch-model-compilati.txt:498(搜「why the GPU gains are not larger」) · :510(搜「grows on demand via torch.cat」)
延迟与吞吐的定义Appendix E. Batching and throughput-oriented executiontext/83-apx-e-appendix-e-batching-and-throughput-oriented-exec.txt:55(搜「how quickly we get the answer for one prompt」) · :58(搜「how many prompts we can process」)
批处理不是万能加速同上text/83-apx-e-appendix-e-batching-and-throughput-oriented-exec.txt:75(搜「batching is not automatically faster on every device」)
表 E.1 的两行实测同上text/83-apx-e-appendix-e-batching-and-throughput-oriented-exec.txt:730(搜「1.8 GB」) · :734(搜「174 min」) · :745(搜「23.39 GB」) · :749(搜「108 min」)
换大模型的内存估算Appendix D. Using larger LLMstext/82-apx-d-appendix-d-using-larger-llms.txt:132(搜「about 2 bytes per parameter」) · :162(搜「about 8 GB」) · :183(搜「about 64 GB」) · :192(搜「only approximate lower bounds」)
多轮对话要裁剪历史Appendix G. Building a chat interfacetext/85-apx-g-appendix-g-building-a-chat-interface.txt:556(搜「prepend) the earlier messages in the prompt」) · :658(搜「the oldest tokens are discarded first」)

Footnotes​

  1. 出处:「2.5 Loading pre-trained models」第 26 段(text/10-ch02-05-2-5-loading-pre-trained-models.txt:26,搜「0.6 billion weight parameters」)。 ↩

  2. 出处:「2.5 Loading pre-trained models」第 209 段(text/10-ch02-05-2-5-loading-pre-trained-models.txt:209,搜「1433 MiB」)。这是下载进度条打印出来的真实文件大小。同一章里分词器文件是 6 MiB(「2.4 Preparing input texts for LLMs」第 53 段,text/09-ch02-04-2-4-preparing-input-texts-for-llms.txt:53,搜「tokenizer-base.json」)。「普通笔记本内存 8 到 16 GB」是补充(不在书里,来自通用知识),用来给 1.4 GB 这个数一个参照物。 ↩

  3. 出处:「2.5 Loading pre-trained models」第 41 段(text/10-ch02-05-2-5-loading-pre-trained-models.txt:41,搜「official reasoning variant」)。原文说 Qwen3 同时提供 base 模型和一个官方推理变体,后者可以在评测时当参照。 ↩

  4. 出处:「2.5 Loading pre-trained models」第 61 段(text/10-ch02-05-2-5-loading-pre-trained-models.txt:61,搜「custom reimplementation of Qwen3」)。原文强调这份重写「完全不依赖外部的 LLM 库」,重点放在可读性和可改性上,同时和官方权重完全兼容。 ↩

  5. 出处:「2.5 Loading pre-trained models」第 298 段(text/10-ch02-05-2-5-loading-pre-trained-models.txt:298,搜「treat the architecture as a black box」)。原文同时给了出路:感兴趣的读者可以去附录 C 看 RMSNorm 这类零件的代码。 ↩

  6. 出处:「2.3 Understanding hardware needs and recommendations」第 7 段(text/08-ch02-03-2-3-understanding-hardware-needs-and-recommendat.txt:7,搜「50 million dollars」)、第 13 段(text/08-ch02-03-2-3-understanding-hardware-needs-and-recommendat.txt:13,搜「2,048 Nvidia H800 GPUs」)与第 19 段(text/08-ch02-03-2-3-understanding-hardware-needs-and-recommendat.txt:19,搜「620 MWh」)。「少数几个把算力开销完全公开的模型之一」这句判断在第 13 段的括号里。 ↩ ↩2

  7. 出处:「2.3 Understanding hardware needs and recommendations」第 37 段(text/08-ch02-03-2-3-understanding-hardware-needs-and-recommendat.txt:37,搜「Volkswagen Beetle」)。作者原话里那句「我甚至会说小车更好懂」是个人观点,他自己也这么标注了。 ↩

  8. 出处:「2.3 Understanding hardware needs and recommendations」第 43 段(text/08-ch02-03-2-3-understanding-hardware-needs-and-recommendat.txt:43,搜「will benefit from using a GPU」)与第 91 段(text/08-ch02-03-2-3-understanding-hardware-needs-and-recommendat.txt:91,搜「Chapters 2-5 can be executed in a reasonable time on a CPU」)。 ↩

  9. 出处:「2.3 Understanding hardware needs and recommendations」第 144 段(text/08-ch02-03-2-3-understanding-hardware-needs-and-recommendat.txt:144,搜「no longer have any financial interest」)。原文的完整说法是:2023 年参与创建并发布了该平台,现已无财务利益,不是赞助,自己付费使用,用它只是因为方便。 ↩

  10. 出处:「2.8 Faster inference via KV caching」第 51 段(text/13-ch02-08-2-8-faster-inference-via-kv-caching.txt:51,搜「remain identical in subsequent iterations」)。原文的说法是:除了新生成的那一个,所有小块在后续每一轮里都完全相同,所以重算是浪费。 ↩

  11. 出处:「2.8 Faster inference via KV caching」第 124 段(text/13-ch02-08-2-8-faster-inference-via-kv-caching.txt:124,搜「given the full input token sequence」)与第 130 段(text/13-ch02-08-2-8-faster-inference-via-kv-caching.txt:130,搜「we only provide the next_token」)。原文明确说缓存里存的是「注意力的 key 和 value」。 ↩

  12. 出处:「2.8 Faster inference via KV caching」第 57 段(text/13-ch02-08-2-8-faster-inference-via-kv-caching.txt:57,搜「grows roughly with the square of the output length」)。两个记号的意思是书自己就地解释的,不是我们加的。边界声明与那篇免费文章的地址在第 63 段(text/13-ch02-08-2-8-faster-inference-via-kv-caching.txt:63,搜「outside the scope of this book」)。 ↩ ↩2

  13. 出处:「2.8 Faster inference via KV caching」第 178 段(text/13-ch02-08-2-8-faster-inference-via-kv-caching.txt:178,搜「Time: 1.40 sec」);朴素跑法的 7.94 秒见「2.7 Coding a minimal text generation function」第 369 段(text/12-ch02-07-2-7-coding-a-minimal-text-generation-function.txt:369,搜「Time: 7.94 sec」)。 ↩

  14. 出处:「2.8 Faster inference via KV caching」第 19 段(text/13-ch02-08-2-8-faster-inference-via-kv-caching.txt:19,搜「small speedups here compound quickly」)。 ↩

  15. 出处:「2.9 Faster inference via PyTorch model compilation」第 20 段(text/14-ch02-09-2-9-faster-inference-via-pytorch-model-compilati.txt:20,搜「more optimized kernels」)。 ↩

  16. 出处:「2.9 Faster inference via PyTorch model compilation」第 52 段(text/14-ch02-09-2-9-faster-inference-via-pytorch-model-compilati.txt:52,搜「first execution using the compiled model may be slower」)。三次运行的耗时(8.07 / 0.60 / 0.60 秒)见同一节第 233 段起(text/14-ch02-09-2-9-faster-inference-via-pytorch-model-compilati.txt:233,搜「Time: 8.07 sec」与 :245,搜「Time: 0.60 sec」)。 ↩

  17. 出处:「2.9 Faster inference via PyTorch model compilation」第 141 段(text/14-ch02-09-2-9-faster-inference-via-pytorch-model-compilati.txt:141,搜「Time: 6.78 sec」)与第 266 段(text/14-ch02-09-2-9-faster-inference-via-pytorch-model-compilati.txt:266,搜「29 tokens per second」)。后一段书自己的措辞是「两倍多的提速」。 ↩

  18. 出处:「2.9 Faster inference via PyTorch model compilation」第 498 段(text/14-ch02-09-2-9-faster-inference-via-pytorch-model-compilati.txt:498,搜「why the GPU gains are not larger」)与第 510 段(text/14-ch02-09-2-9-faster-inference-via-pytorch-model-compilati.txt:510,搜「grows on demand via torch.cat」)。「4 万块」那个数是原文举的最大上下文长度例子。 ↩

  19. 出处:「Appendix E. Batching and throughput-oriented execution」第 55 段(text/83-apx-e-appendix-e-batching-and-throughput-oriented-exec.txt:55,搜「how quickly we get the answer for one prompt」)与第 58 段(text/83-apx-e-appendix-e-batching-and-throughput-oriented-exec.txt:58,搜「how many prompts we can process」)是两个定义;那段警告在第 75 段(text/83-apx-e-appendix-e-batching-and-throughput-oriented-exec.txt:75,搜「batching is not automatically faster on every device」)。 ↩ ↩2

  20. 出处:表 E.1,「Appendix E. Batching and throughput-oriented execution」第 730 段(text/83-apx-e-appendix-e-batching-and-throughput-oriented-exec.txt:730,搜「1.8 GB」)、第 734 段(text/83-apx-e-appendix-e-batching-and-throughput-oriented-exec.txt:734,搜「174 min」)、第 745 段(text/83-apx-e-appendix-e-batching-and-throughput-oriented-exec.txt:745,搜「23.39 GB」)与第 749 段(text/83-apx-e-appendix-e-batching-and-throughput-oriented-exec.txt:749,搜「108 min」)。表里的两台机器分别是 H100 和 DGX Spark。 ↩

  21. 补充(不在书里,依据我们的 book 书架):这本书把模型架构当黑盒,代码放在附录 C。依据: shelf=ai-book-reference/build-large-language-model#03-attention-core.md 事实=该章从零实现了注意力机制,讲清了每个位置的 key 和 value 是怎么算出来、又是怎么被用掉的 —— 也就是本章第 3 节存进缓存的那两组中间结果。 ↩

  22. 出处:「Appendix D. Using larger LLMs」第 132 段(text/82-apx-d-appendix-d-using-larger-llms.txt:132,搜「about 2 bytes per parameter」)给了估算口径;表 D.2 的几行见第 162 段(text/82-apx-d-appendix-d-using-larger-llms.txt:162,搜「about 8 GB」)与第 183 段(text/82-apx-d-appendix-d-using-larger-llms.txt:183,搜「about 64 GB」);「只是下界」的声明在第 192 段(text/82-apx-d-appendix-d-using-larger-llms.txt:192,搜「only approximate lower bounds」)。 ↩

  23. 出处:「Appendix G. Building a chat interface」第 556 段(text/85-apx-g-appendix-g-building-a-chat-interface.txt:556,搜「prepend) the earlier messages in the prompt」)与第 658 段(text/85-apx-g-appendix-g-building-a-chat-interface.txt:658,搜「the oldest tokens are discarded first」)。原文还说明了更聪明的做法(比如把旧内容先总结一遍)确实存在,但为了简单起见没有实现。 ↩