一个只服务一个人的语言模型，是怎么把速度做到两倍的

你有没有想过，你手机上跑的AI助手，和数据中心里那些动辄几千张显卡同时轰鸣服务几万用户的大模型，本质上其实不该是同一种东西？

大部分人不会想这个问题，因为现在的做法就是：先在GPU集群上训练一个大模型，追求各种榜单分数，然后想办法把它"压缩"塞进手机或电脑里，砍掉一些层，量化一下精度，凑合能跑就行。这是行业默认的路径，几乎没人质疑过。

但有一群人反过来想了这件事。他们说，等一下，如果我们一开始就知道这个模型最终只会在CPU上运行，只服务一个用户，一次只吐出一个字，那为什么不从这个约束出发去设计架构，而是事后削足适履？

这就是这篇论文里Daedalus-150M模型的起点。它不是又一个"更小的大模型"，而是一个从终端使用场景反推出来的架构。结果挺有意思：它用不到300亿token七分之一都不到的数据量，打赢了好几个用了三到六倍数据训练出来的同尺寸模型，解码速度还快了将近两倍。

为什么CPU上跑模型和GPU完全是两回事

先说清楚一件事：这篇论文瞄准的不是"更省参数"，而是"更省内存带宽"。这两者听起来像近义词，其实差得很远。

在GPU服务器上，一次会同时处理很多用户的请求，这叫批处理。批处理的好处是，模型的权重只要从显存读一次，就能被一堆用户的请求同时复用，读取权重的成本被摊薄了。这时候，真正的瓶颈是算力，也就是显卡一秒钟能做多少次乘法加法。

但如果只有一个用户在跟模型对话呢？没有其他请求可以拿来摊薄成本。每生成一个字，模型都得把自己全部的参数完整地从内存里读一遍。这时候瓶颈就不再是算力了，而是内存带宽，也就是硬件一秒钟能从内存里搬多少字节的数据。现在的CPU算力其实过剩，真正卡脖子的是数据搬运的速度。

打个比方，这就像一个厨师做菜。批处理模式下，厨师一次性给二十个客人炒同一道菜，切菜、开火这些准备工作只需要做一次，二十份菜均摊了这个成本，效率很高。但要是厨师一次只给一个客人做一道菜，做完立刻要换下一道完全不同的菜，那准备工作没法摊薄，每道菜都要重新经历一次完整的准备流程。这时候决定你吃饭速度的，不是厨师炒菜的手速有多快，而是他从冰箱里把食材搬到灶台上要花多长时间。如果不认清这一点，还在死磕"让厨师炒得更快"，那优化方向就从一开始就错了。

带宽*：指硬件在单位时间内能从内存搬运多少字节数据的能力，这里是决定CPU推理速度的核心瓶颈。

除此之外，还有第三个麻烦，叫KV缓存的问题。

KV缓存*：Key-Value Cache的缩写，是注意力机制里用来记住之前所有字的一种存储结构，每生成一个新字都要重新读一遍这个缓存。

在标准的Transformer架构里，每一层的注意力机制，都需要"回头看"前面所有已经生成的内容，才能决定下一个字该是什么。这意味着，你聊得越久，对话越长，模型每生成一个新字，需要读取的历史信息就越多。这个成本是随着对话长度线性增长的。在GPU上批处理的场景下，这个成本被很多用户摊薄了，还能忍。但单用户CPU场景下，这个成本会随着对话变长直接拖垮整个系统的响应速度。

这就是这篇论文要解决的核心矛盾：怎么让模型在长对话里也不至于越聊越卡。

三分之二的层不再回头看历史：一个混合架构的设计

Daedalus-150M的解法是，把整个模型的18层拆成两种角色。其中6层保留标准的全注意力机制，另外12层换成一种叫短卷积的结构。

短卷积*：一种只关注最近几个字、状态大小固定不变的计算方式，不管对话进行到第几个字，它需要"记住"的东西永远只有那么多。

这12个卷积层的状态窗口只有2个时间步宽，不管你和它聊了2句话还是2000句话，它每次要处理的历史信息量是完全一样的，是个常数，不会随对话变长而膨胀。而剩下的6个注意力层，还是老老实实地保留了回头看整个历史的能力，只是层数被压缩到了原来的四分之一。

这里有个细节特别巧妙。论文里给出了具体的字节计算：混合架构每往前多聊一个字，需要多读的缓存字节数是6144字节；而如果换成传统的、24层全部用注意力的对照模型，这个数字是12288字节，正好是两倍。原因不只是层数少了四倍这么简单，混合架构还在保留的6个注意力层里用了一种叫分组查询注意力的技术，把缓存进一步压小了三倍。

分组查询注意力*：英文缩写GQA，让多个查询头共享同一组键值头，从而减少每层需要保存的缓存数据量，是一种在保留大部分能力的同时压缩内存占用的技术。

回到之前那个厨师的比喻。如果厨师是全职翻看菜谱的类型，每做一道菜都要把之前做过的所有菜谱翻一遍以确保风味一致，那么随着他做的菜越来越多，翻菜谱的时间会越来越长，最后可能比炒菜本身还慢。而这个混合架构相当于让厨师团队里三分之二的人换了一种工作方式：他们只需要记住刚做的上一道菜和上上道菜的味道就行，完全不用翻旧菜谱，剩下三分之一的人依然保留翻菜谱的能力，负责那些真正需要"记住很久以前细节"的菜式。如果不这么分工，让所有厨师都去翻菜谱，团队整体速度就会被拖得越来越慢，聊天聊得越久这个拖累就越明显。这正是论文里反复强调的一点：混合架构的速度优势不是一个固定倍数，而是随着对话变长不断拉大的差距，这恰恰证明了问题出在"要不要回头看历史"这件事上，而不是别的什么原因。

论文里那张架构图（图1）画得很清楚：18个色块交替排列，深色的是保留注意力的层，位置分别在第4、7、9、11、13、16层，其余全是浅色的卷积层。深色块旁边标着"缓存随对话线性增长，这是要交的税"，浅色块旁边标着"状态固定为2个时间步，跟对话长度无关"。这张图其实就是整篇论文的浓缩版：用最少的"税"，换最多的能力保留。

为什么不干脆把所有注意力层都换掉？因为纯粹靠卷积没法做精确的长距离信息检索，比如你在对话很早期提到的一个具体名字或数字，纯卷积结构很难原封不动地把它捞回来。注意力机制在这件事上是独一无二的，所以论文选择保留六层，而且这六层是均匀撒在18层里的，不是堆在一起，这样不同深度的表示都能获得检索能力。

除了架构，还有几个不起眼但重要的小设计

论文里提到几个容易被忽略的选择，其实都在为"省字节"这个目标服务。

第一个是词嵌入共享，也就是让输入层的查字典表和输出层的查字典表用同一份参数，而不是各自维护一份。这个词表有49152个词，对应的矩阵占了3770万参数，接近整个模型的四分之一。共享之后相当于直接省掉了一整份的存储和读取开销。

第二个是把前馈网络的中间层宽度从常规的4倍模型宽度收窄到2.67倍。这个选择听起来很技术，但背后的逻辑很直白：前馈网络的这个中间层是模型里最"胖"、每次读取消耗字节最多的部分之一，收窄它就是把参数预算从最耗带宽的地方挪到更有效率的地方，比如层数和注意力机制上。

引用块：前馈网络*：Transformer里每层负责在两次注意力计算之间做非线性变换的子模块，通常会先把维度放大再缩小，这个放大的倍数是个可调参数。

第三点是量化格式的选择。论文选用了一种叫Q4_0的4比特量化格式，理由不是它的数值误差最小，而是它在目标硬件上对应的底层计算指令是优化得最好的。这个选择背后透露一个态度：这篇论文从头到尾优先考虑的都是"这东西真的能在普通CPU上跑得快"，而不是"这个数字在纸面上好看"。

量化*：把模型参数从32位或16位浮点数压缩成更少比特（比如4比特）表示的技术，能大幅减小模型体积和内存占用，但通常会牺牲一些精度。

这就好比你去买一双跑步鞋，有的鞋在实验室测试里各项数据都很漂亮，但穿上跑起来却不趁手，因为它的设计目标是测试台而不是真实路面。这篇论文里的每一个小选择，都在反复确认自己是不是真的适配"真实路面"，也就是那台安静地待在用户口袋里或者笔记本电脑里的CPU。

数据从哪来，怎么喂给模型

模型的训练数据是十个英文数据源混合而成的，总共有169亿个不重复token，但整个训练过程消耗了599亿token，这意味着平均每份数据被模型看了大约3.5遍。

这里有个细节挺有意思：论文给每个数据源设了一个上限，最多重复四次，这是参考了此前的研究，说重复读四遍以内对模型质量的损伤很小。但问题是，如果严格按比例分配，某些体量很小的数据源（比如一个只有大约40万token的日常对话数据集）想要达到它2%的目标占比，就得被反反复复读上千遍，这已经完全偏离了"2%占比"原本想表达的意思。所以论文用了一种叫水位填充的策略，把超出上限的部分匀给还有余量的其他数据源。

这就像分蛋糕，你说每个人应该分到蛋糕的2%，但如果某种口味的蛋糕总共只做了很小的一份，硬要让它占满2%，那就得把这一小份反复端上桌几十次，客人吃到最后早就腻了还没吃到别的口味。水位填充的做法相当于，某种口味不够就用别的口味补上，保证蛋糕总量凑够，但不会让某一种口味被迫无限重复。如果不做这个调整，模型很可能会对着那几十万token的日常对话数据反复咀嚼上千遍，学到的可能是重复带来的偏差，而不是这类内容本身该有的语言风格。

数据切分上也藏着一个容易踩的坑。论文严格按照整份文件来划分训练集和验证集，不允许把一份文档从中间切开，一半拿去训练一半拿去验证。这样做的代价是，不同数据源实际预留出来的验证集比例并不完全等于设定的2%，有个数据源因为最后一份文件恰好比较大，实际预留比例达到了9.16%。论文没有藏着掖着这个问题，而是把它明确写了出来，还专门指出如果不这样处理，用holdout的token数量而不是采样概率去加权计算验证集指标，算出来的数字会偏高9.7%，因为那些偏难的数据源恰好文件比较大。这种连细枝末节的加权方式都要交代清楚的态度，在论文里出现了不止一次。

训练过程里，一个容易被误读的"停滞"现象

论文用了一种叫WSD的学习率调度方式，全称是预热-稳定-衰减。

学习率调度*：训练过程中控制模型学习速度快慢变化的策略，这里采用的方式是先快速升温，然后长时间保持在最高点，最后线性下降到零。

有意思的是，在稳定阶段，也就是大约从第2万步到第6.8万多步这段时间里，学习率一直保持在峰值不变，这时候模型的训练损失几乎不怎么下降，看起来像是"卡住了"。论文里特别提到，这次训练过程中确实有观察者把这段平台期误判成了训练失败或者停滞，但实际上这是调度策略本身的设计，真正的质量提升绝大部分发生在后面学习率开始下降的阶段。

这让我想起跑步训练里的一个现象：有些跑者会经历一段体感"没有进步"的平台期，明明每天都在练，配速却纹丝不动，很多人会在这个阶段选择放弃，觉得练不动了。但实际上身体在这段时间做的是打基础的工作，真正看得见的突破往往发生在放弃临界点之后不久。如果论文的研究者也被这个平台期唬住了提前砍掉训练，那后面通过学习率衰减换来的大部分质量提升根本不会发生。

核心实验：混合架构真的比纯注意力架构强吗

这是整篇论文里最关键的一次对照实验。研究者训练了两个参数量几乎相等的模型：一个是刚才说的混合架构，160.49M参数；另一个是传统的、24层全部用注意力机制的对照组，161.25M参数，两者相差不到0.5%。它们用完全相同的数据和训练流程各训练了50亿token。

更值得称道的是，评判这次实验胜负的标准是在实验开始之前就写死的，不是等结果出来之后再挑一个对自己有利的指标。这个预先定好的标准是验证集上的bits-per-byte指标，同时设了一个0.5%的最低胜出门槛，如果传统架构赢过这个门槛，那么整个正式训练所用的架构就要推翻重来。

结果混合架构在这个预先约定的指标上赢了0.81%，越过了那道门槛。但在下游任务的五项测试平均分上，传统架构反而略微领先0.14分，这个差距在统计上大约只有0.24个标准差，考虑到这类测试本身的噪声在0.58个标准差左右，这个差距基本可以视为噪声，谁也没赢谁。论文对此的态度非常坦诚：五个任务里两边互有胜负，胜负模式看不出规律，这正是噪声的典型特征，而不是真实差距的信号。

引用块：bits-per-byte*：简称bpb，衡量语言模型预测能力的一种指标，按字节而不是按词元计算，好处是不同分词方式的模型之间也能公平比较。

这里说句实话，我觉得这个诚实的态度挺难得。很多论文在两个指标打架的时候，会选择性地突出对自己有利的那个，闭口不提另一个。这篇论文直接把两个指标都摆出来，说"这是打平"，不试图把它包装成一场胜利。

真正决定性的差距出现在解码速度上。研究者测试了三个不同的对话长度：空白开局、聊到512个字、聊到2048个字（也就是模型训练时设定的最长对话长度）。结果发现，两个模型的速度差距在对话刚开始时几乎可以忽略不计，只有1.20倍，但随着对话变长，差距持续拉大，到2048个字时达到了1.76倍。

这个"差距随长度增长"的模式极其重要，因为它恰恰印证了差距的根源确实是"要不要回头翻旧账"这个设计，而不是别的什么原因导致的。如果混合架构只是单纯地"更瘦"，那不管对话多长，它应该始终快一个固定的倍数，而不是越聊越占优势。

论文还专门去测了和一个完全不同团队做的、参数量135M的外部模型对比，结果同样的模式复现了：空白对话时两者速度接近，只快6%；聊到2048字时，Daedalus快了整整2.08倍，而且Daedalus本身参数量还比对方多19%。这个复现在论文里被认为是比内部对照实验更有说服力的证据，因为它没法用"这是本项目训练代码或者导出代码的巧合"来解释。

|对话长度|混合架构 (tok/s)|对照架构 (tok/s)|速度比|

|0（空白）|1111.9|922.8|1.20×|

|512|960.3|664.4|1.45×|

|**2048**|**739.3**|**420.3**|**1.76×**|

一个算出来的数字，居然比实测的还保守

论文里做了个挺有意思的动作：先用一个简单的数学公式去预测这个速度优势应该是多少，然后拿实测结果去检验这个公式对不对。

这个公式的逻辑很简单：每生成一个字，需要读取的总字节数等于模型权重的字节数，加上所有注意力层缓存字节数乘以当前对话长度。按这个公式算下来，在2048字长度时，混合架构应该比对照架构快17%。

但实测结果是76%的优势，比预测值高出四倍还不止。

论文很诚实地承认，这个纯粹靠字节数计算的模型"方向是对的，但数量级错得离谱"，而且这个偏差还会随对话变长继续扩大。他们给出的解释是，公式没考虑到两个东西：一是注意力机制在读取缓存时要做一个依赖性很强的运算步骤，这个步骤受限于运算延迟而不是单纯的数据搬运速度，尤其当要处理的数据量超过CPU高速缓存容量时会明显变慢；反观卷积结构只需要处理两个元素的固定状态，数据访问的局部性非常好。二是对照组模型本身层数更多，24层对18层，每层都有的一些固定开销也因此多付出了三分之一。

这就好比你去预测两条路线开车到目的地分别要多久，你只计算了路程长度除以限速，得出A路线应该比B路线快17%。但实际测下来快了76%，因为你没算上B路线沿途有一堆红绿灯路口需要停下来等，而且路口越多车流积压得越严重，这种"停等"造成的延误跟路程长度不是简单的线性关系，会随着红绿灯数量的增加而加速恶化。如果只按路程算账，会严重低估拥堵路线的实际损失。这也是论文特别强调的一点：单纯优化底层的注意力计算内核，能缩小差距，但没法消除它，因为混合架构根本没有保留那份需要被优化的缓存。

揭晓成绩单：这个模型到底考了多少分

论文设定的评测标准，是在五个常见任务上的平均分：HellaSwag、ARC-Easy、PIQA、OpenBookQA和WinoGrande。这五项测试涉及常识推理、科学知识、物理常识等不同方面。

在正式训练开始之前，研究者就把及格线定好了：42.2分，这是几个对照模型里表现最强的一个的分数。最终Daedalus-150M考出了47.31分，超过及格线5.11分。

这个成绩单最有意思的地方在于对照组的构成。表格里列出的对照模型，包括GPT-2 124M、Pythia-160M、OPT-125M、GPT-neo-125M，全都用了三到六倍于Daedalus的数据量进行训练，结果还是被超过了。甚至连MobileLLM-125M这个用了整整1万亿token训练出来的模型，公开发表的分数也被Daedalus超过了。要知道，Daedalus总共只用了599亿token，MobileLLM用的数据量是它的近17倍。

|模型|训练token数|五项任务平均分|

|**Daedalus-150M**|59.9B|**47.31**|

|MobileLLM-125M|1T|46.3（发表值）|

|GPT-2 124M|—|42.2|

|OPT-125M|180B|42.1|

|GPT-neo-125M|300B|41.9|

|Pythia-160M|300B|41.0|

|Peer-135M|2T|51.2|

表里最后一行Peer-135M用了2万亿token，比Daedalus多了三十多倍的数据，分数还是领先3.9分。论文对此没有回避，直接说这是"训练开始前就承认会输的部分"：这项研究本质上是在拿质量换取解码速度，在参数量固定的前提下做取舍，不是想在所有维度上都当第一。

论文还特别提醒读者，这里所有的对照模型分数，都是研究者自己重新在同一套评测工具上跑出来的，而不是直接引用各自论文里公布的数字。原因是公开发表的分数往往用的评测任务子集或计分方式略有不同，直接拿来比较容易制造出并不真实存在的优势，差距可能有0.5到1.5分之多。这种自己动手统一复现的做法，虽然麻烦，但公平性高得多。

论文没有藏着的失败：那些没成功的尝试

这篇论文一个很打动我的地方，是专门辟出篇幅讲了三件没做成的事，而不是只报喜不报忧。

第一件事是量化感知训练的失败。研究者原本计划在训练的最后5%阶段，让模型提前适应4比特量化会带来的误差，这样正式量化之后的精度损失能小很多。但这个方案一启动，训练第一步就出现了数值上的崩溃，直接被叫停。最终发布的模型是训练完之后再做量化的，量化损失达到了大约6%的困惑度，而如果量化感知训练成功了，这个数字本可能只有2.5%。研究者坦承没有查出崩溃的具体原因。

困惑度*：衡量语言模型预测下一个词准确程度的指标，数值越低说明模型预测得越准。

第二件事是关于卷积通道里存在大量"死掉"的部分。研究者发现，模型里将近47.9%的短卷积通道对最终输出完全没有贡献，这个比例在训练过程中稳定不变，从第9896步到第3万步几乎纹丝不动，相当于白白浪费了大约1360万参数，占整个模型参数量的8.5%。

既然这些通道是死的，那把它们直接砍掉、瘦身模型文件不就行了？研究者确实这么试了，但推理引擎在加载模型文件时会检查每个张量的形状是否符合预设标准，砍窄之后的文件直接被引擎拒绝加载，报错信息明确指出期望的维度和实际维度对不上。研究者甚至专门做了个对照实验：把没有砍窄、维度完全正常的文件用同样的重写工具重新生成一遍，结果是能正常加载的，这就排除了"是重写工具本身有问题"的可能性，确认问题就出在砍窄这个操作本身。

要修复这个问题，得去修改推理引擎本身的代码，但这样一来就没法用现成的、未经修改的标准推理程序来运行模型了，而这恰恰是整个项目"能在普通CPU上跑起来"这个卖点的根基。为了省下不到8MB的文件体积，去打破和标准推理软件的兼容性，这笔账怎么算都不划算，所以研究者选择放弃这个方向，把它列为留给下一代模型在设计初期就要解决的问题。

这就好比你买了一件衣服，发现内衬有一块布料完全用不上，纯属浪费材料，想着不如把这块布料剪掉省点重量。但裁缝店的标准生产线要求衣服必须符合特定的裁剪模板，剪掉那块布料就没法通过质检流程上架销售。你要么违反标准流程冒险改造，要么就接受这块布料一直存在。研究者选择了后者，还诚实地把这个"衣服里有块用不上的布料"的事实告诉了所有读者。

第三件事是词表选得偏大。这个模型用的词表有49152个词，但论文引用的经验规律显示，像这个尺寸的模型，词表大小理想值应该在24000到32000之间。之所以选了偏大的词表，是因为最早的项目计划里，这个模型要跟另一个更大的"老师"模型共享同一套分词方式，后来那个计划因为别的原因取消了，但词表这个选择却被保留了下来，没人回头去改。这多花的参数占了模型整体的23%，如果换成理想大小的词表，能省出大约1300万参数用在真正做计算的层上。

论文特意提到他们专门验证了分词器是否真的和量化后的模型文件保持一致，直接从量化文件里读取词元编号，和标准分词器逐一核对，结果完全没有偏差。研究者说得很直白：如果这里出了偏差，模型会看起来一切正常，各项指标都很健康，实际生成的却是一堆读起来通顺但毫无意义的胡话，而且整个流程里没有任何其他环节能捕捉到这种错误。

部署到真实设备上会是什么样子

论文最后聊了些落地层面的细节。整个量化后的模型文件只有95.56 MiB，加上2048字长对话所需的缓存空间大约12.6MB，一次完整的单用户会话所需内存能控制在128MB以内。这意味着这个模型完全可以常驻在手机或电脑里，跟着某个应用程序一起运行，不需要单独占用一个进程。

论文还提到一个和直觉不太一致的现象：因为CPU上单用户解码是被内存带宽卡住的，所以增加处理器核心数到一定程度后，速度就不再提升了，混合架构因为搬运的数据量本身更少，达到这个"饱和点"所需要的核心数也更少。这对于要在共享设备上运行的场景是个额外的好处。

写在后面

读完这篇论文，最触动我的其实是那种近乎较真的诚实。大部分论文写到实验对比的时候，会本能地把镜头对准自己赢的那部分，但这篇论文把"平局"清清楚楚地摆出来了，甚至专门解释了为什么下游任务的0.14分差距其实是噪声，不该被解读成任何一方赢了。这种克制在学术写作里其实不常见。

另一个让我意外的细节是那个"死通道砍不掉"的故事。研究者花了力气去验证瘦身方案确实可行、确实能省空间，最后却因为推理引擎的形状校验卡死在最后一步。这种"技术上能做，工程上做不了"的落差，比单纯说"我们尝试了剪枝但没成功"要真实得多，也更有教育意义，它提醒我们很多时候限制一个想法落地的不是理论，而是周围整套生态系统愿不愿意配合。

还有一个小地方值得琢磨：论文反复强调速度优势是"随对话长度增长的"，而不是一个固定倍数。这其实是个很好的判断方法论，判断一个改进是不是真的来自你声称的那个机制，就看它的表现是否符合那个机制该有的形状。如果速度提升是个常数倍数，那更可能只是代码写得更精简了；只有当提升幅度随着你动的那个变量变化时，才说明你真的改对了地方。这个思路其实不止适用于模型架构，任何时候想验证"我做的这个改动是不是真的解决了我以为的那个问题"，都可以问一句：如果我的解释是对的，效果应该随什么变量变化？

那个词表选大了却一直没人改的细节也挺值得咂摸。一个早已作废的计划留下的选择，就这样悄悄地在模型里躺了23%的参数份额，直到写论文复盘的时候才被翻出来重新审视。这大概是所有工程项目里都会发生的事：某个决定的原因早就不存在了，但决定本身还在。

Q&A

Q1：Daedalus-150M是什么？

A：Daedalus-150M是一个专门为CPU单用户推理设计的语言模型，参数量约1.6亿，18层里只有6层用传统注意力机制，其余12层用短卷积结构，训练数据量约599亿token，在五项常识推理任务上平均得分47.31，超过了多个用三到六倍数据训练的同尺寸模型。

Q2：混合架构比传统全注意力架构到底快多少？

A：在对话长度2048个字时，混合架构解码速度比参数量相近的全注意力对照模型快1.76倍，跟外部一个135M参数模型对比快2.08倍。速度优势会随着对话变长持续扩大，对话刚开始时差距很小，说明这个优势确实来自缓存机制的差异，而不是模型本身更精简。

Q3：这个模型有哪些没解决的问题？

A：论文坦承了三个问题：量化感知训练在训练时因数值崩溃被迫取消，导致最终4比特量化的精度损失达到6%；模型里约47.9%的卷积通道完全不起作用却因为推理引擎的形状校验无法被物理删除；词表规模49152个词偏大，理想值应在24000到32000之间，多余部分浪费了约1300万参数。