从GPT-5.6 Sol每秒750个token、提速14倍看大模型速度的数学：吞吐量、延迟与排队论

8月13日，OpenAI预览了GPT-5.6 Sol的"Ultrafast"模式：最高每秒输出750个token，约合每秒560个词，相比常规模式提速14倍，由Cerebras晶圆级芯片驱动，目前仅限受邀客户测试。新闻里"每秒750个token"和"提速14倍"这两个数字，读起来很爽，但它们是哪来的？对参赛学生来说，这背后是一整套可以原样搬进赛题的速度建模框架：吞吐量怎么定义、加速比怎么算、延迟与吞吐量如何此消彼长、排队论如何预测系统忙不忙。本文把大模型速度的数学一次讲透。

一、新闻回放：750个token/秒是什么概念

先建立直观感觉。一个token可以粗略理解为大模型的最小文字单元，中文大约一个字对应一到两个token，英文一个词约一个token多一点。750个token每秒意味着：读一篇500字左右的短文，模型大约1秒生成完；写满一屏公众号文章（约3000字），4到5秒完成。对比人类打字约每秒1到2个字，这个速度接近"阅读速度级"生成，这也是"Ultrafast"这个名字的由来。

二、"14倍"是怎么算出来的：加速比的建模口径

"提速14倍"听起来直接，但加速比的定义有很多种口径，建模时最容易翻车的就是口径不一致。最常见的口径是峰值吞吐加速比：拿Ultrafast模式的峰值输出速率除以基线模式的峰值输出速率，14倍就是这么来的。但实际使用中，感知到的提速往往不到14倍，原因有三：

第一，峰值不等于均值。峰值速率是理想状态下测的，真实场景有网络传输、前缀缓存命中率、输入输出交错等因素，实际吞吐通常打七到八折。第二，生成速度只占端到端延迟的一部分：一次对话的总延迟等于排队等待加输入处理加生成，生成快了，排队和输入处理的时间还在。第三，任务结构不同：短任务受启动开销影响大，长任务才吃得到吞吐红利，写一句话可能只快2倍，写长文才接近14倍。

建模时建议采用"端到端延迟加速比"口径：先分别测量四个环节的时间，再算总延迟的比值。这个"分环节拆解+总量比值"的做法，和国赛里"总成本分解后看增速贡献"是完全同一套逻辑。

三、吞吐量的核心公式：速率乘时间

大模型服务吞吐量建模，本质就是一道小学应用题：吞吐量等于生成速率乘有效工作时间。用符号化语言说：一个推理服务器在一段时间内生成的token总数，等于每秒生成的token数乘以该时间段内实际用于生成的秒数。看起来简单，真正要建模的是两个"折扣"：一是并发折扣——同时服务的请求多了，单请求分到的生成速率下降；二是利用率折扣——服务器不是24小时满负荷，空闲时段等于把有效时间打折。

上表是示意算例：负载上去后，单请求速率下降，但服务器更忙，总吞吐反而上升。这就是吞吐建模的第一个结论：衡量系统能力看总吞吐，衡量用户体验看单请求速率，两者不能混用。

四、排队论：系统到底忙不忙

预测"请求要等多久"，排队论是最标准的工具。把每个请求看作"顾客"，把推理服务器看作"服务台"，请求到达是随机的（平均每分钟λ个），服务时间也随机（平均每请求服务时间1/μ）。最简单的单服务台模型里，系统稳定运行的条件是到达率小于服务率，即λ小于μ。这时有两个关键公式：平均排队等待时间等于利用率除以（服务率乘一减利用率）；平均总响应时间等于一除以（服务率减到达率）。利用率越接近100%，等待时间越是指数级爆炸——这是排队论最重要的直觉：系统不要设计在满载点，要留缓冲。

看这张表：到达率从7提到9，只增加了不到三成压力，平均等待时间却从15.6秒跳到81秒，翻了5倍。这就是"满载诅咒"——系统越接近饱和，每增加一点流量，体验崩塌得越快。大模型厂商给Ultrafast模式限量邀请制开放，本质就是在控制到达率λ，保证μ的服务能力下系统不进入排队爆炸区。

五、硬件提速14倍的建模逻辑：算力、存储与带宽

Ultrafast模式为什么能快14倍？新闻点出了核心：Cerebras晶圆级芯片。普通GPU是巴掌大的一块，晶圆级芯片把整个晶圆直接做成一块大芯片，片上集成的计算单元和存储远超常规产品。模型推理的速度瓶颈通常不在计算而在内存带宽——权重要从芯片外的显存搬到计算单元，搬得越快生成越快。晶圆级芯片把权重放在片上，省掉了大量搬运时间，生成速率因此大幅提升。

建模时可以用一个简化框架：推理吞吐量与芯片内存带宽近似成正比，与模型规模成反比。同样的模型，带宽翻倍，峰值吞吐近似翻倍；同样的芯片，模型参数翻倍，吞吐近似减半。这个"带宽换速度、规模吃速度"的框架，可以拿来写"推理成本与吞吐量预测"类赛题：给定芯片规格与模型规模，预测吞吐和单位token成本。

六、速度与成本：快是要花钱的

提速14倍不是免费的午餐。从建模视角，推理成本可以分解为三块：硬件成本分摊、电力成本、服务与运维成本。晶圆级芯片算力密度高、单次推理耗电未必更高，但采购成本与定制化投入巨大，厂商必须靠"高价值场景优先"来摊薄成本——这也解释了为什么Ultrafast模式先给受邀客户，而不是全量放开。对使用者来说，速度与成本是同一枚硬币的两面：一个请求快14倍，意味着同样的预算下单位时间能处理14倍的任务量，或者同样的任务量只花十四分之一的时间。建模时通常做"单位token成本"比较：把总成本除以总生成token数，再乘上各自的使用量，就能算出快模型到底贵不贵。

七、给参赛学生的三个落点

这套素材在国赛里至少有三个落点。第一，排队论与系统容量规划：给一个AI服务的到达率、服务率数据，求最优服务台数量，对应排队论经典赛题。第二，吞吐量预测与硬件选型：用"带宽近似正比、规模近似反比"框架估算不同硬件方案的吞吐与成本，对应优化类赛题。第三，加速比口径辨析：把新闻里的"14倍"拆成端到端口径与峰值口径的差异，考的是对指标定义的理解——这种"挑指标毛病"的能力，在国赛论文里是明显的加分项。

最后记住三句话：速率是峰值、体验是端到端；吞吐看总量、延迟看单请求；系统别满载、留缓冲。下次再看到"提速N倍"的新闻，先问一句：这个N倍，是什么口径的N倍？