清晨七点的城市环线，成千上万的车辆从各条匝道汇入主干道，又在出口处有序分流——你站在天桥上俯瞰，整条公路仿佛一条奔涌的金属河流。但如果某一个匝道突然变窄，或者某个收费站动作慢了半拍，整条河流就会在几分钟内淤塞成红色的长龙。 这座城市的交通系统，就是理解 LPU 吞吐量最贴切的比喻。高速公路的“吞吐量”是每小时通过多少辆车，而 LPU（Language Processing Unit，语言处理单元）的吞吐量，则是每秒钟能生成多少个 token——也就是 AI 模型“吐字”的速度。传统 GPU 像一辆性能彪悍的赛车，能瞬间爆发极快的速度，但它需要频繁进站加油（从显存读取数据）；而 LPU 则像一条专为语言车队设计的无红灯快速路，让每一个“字”的生成都像车辆连续通过绿波带一样流畅。接下来，我们就沿着这条“语言的公路”展开旅程，看看 LPU 是如何设计、优化，最终实现不可思议的高吞吐量的。

岗位关联

理解 LPU 吞吐量分析，是 AI 推理性能优化的“地图导航”——它让你能精准定位大模型服务中的瓶颈路段，为架构选型和成本优化提供决策依据。

目录
  1. 可视化演示
  2. 吞吐量概念
  3. LPU架构基础
  4. 吞吐量关键公式
  5. 影响吞吐量因素
  6. 瓶颈定位与分析
  7. 优化策略与工具
  8. 对比与传统方案
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

通过架构数据流、瓶颈分析与性能优化三模式，展示LPU吞吐量的核心机制与优化策略。

本节配有交互动效（进入视口后自动加载，约 3KB）。

LPU架构与数据流 五阶段数据流，片上SRAM消除HBM带宽瓶颈实现确定性高吞吐 Throughput=Tokens/(Latency/Batch) SRAM-centric架构是LPU超高吞吐的核心设计

吞吐量概念

想象你站在跨江大桥的桥头，手里拿着一个计数器，数一分钟内有多少辆车通过桥面。如果一分钟内通过了 120 辆车，那么这座桥的“吞吐量”就是每分钟 120 辆。现在把“车”换成“token“——也就是大模型生成的基本文本单元（大约 3/4 个英文单词或半个汉字），把”桥“换成”芯片“，你就得到了 LLM 推理领域最核心的指标：吞吐量。它回答的问题很简单：这颗芯片在单位时间内，能帮 AI 模型”吐出”多少个字。

在技术文献中，吞吐量通常记作 TPS（Tokens Per Second，每秒 token 数）。计算方式非常直观：用 GPU 或 LPU 处理完一批请求时，把生成的所有 token 数量加起来，除以总耗时，就得到平均吞吐量。它与另一个指标 TTFT（Time To First Token，首 token 延迟）互为镜像：TTFT 回答“你抛出一个问题后，多久能听到第一个字的回音”，而 TPS 回答“一旦开始回答，每秒能说出多少个字”。聊天机器人体验是否“跟手”，往往取决于 TTFT；而批量生成摘要、处理长文档时，TPS 才是决定整体耗时的关键。

回到桥的比喻：一座设计糟糕的大桥，会在高峰期莫名拥堵——车辆排成长龙，但桥面却空荡荡。传统 GPU 跑 LLM 时常常出现“桥面晒太阳、桥头排长队”的怪象：计算单元在等数据，数据在路上堵车。LPU 的设计哲学就是重新规划这座桥，让车流（token）始终以接近最高限速行驶。

TPS=NtokenTtotal\text{TPS} = \frac{N_{\text{token}}}{T_{\text{total}}}
这个公式告诉我们：吞吐量就是“总产出字数 ÷ 总花掉秒数”。要提高 TPS，要么让模型在同样时间内生成更多字，要么让同样多的字用更少时间生成。
  1. \(N_{\text{token}}\)（分子）所有并发请求在统计窗口内生成的 token 总数。你数桥上的车时，要把每条车道、每个时段的车都加在一起，这就是分子。
    Ntoken=∑i=1nniN_{\text{token}} = \sum_{i=1}^{n} n_i
  2. \(T_{\text{total}}\)（分母）从第一批请求进入芯片到所有请求完成的墙钟时间。它像你按秒表从第一辆车开上一秒算到最后一辆下桥。
    Ttotal=Tend−TstartT_{\text{total}} = T_{\text{end}} - T_{\text{start}}
  3. 比值（整体）分子除以分母，本质是一个“平均流速”。就像大桥吞吐量不会关心某辆具体轿车的品牌，TPS 也不关心某个 token 的具体内容，只看总产量与总时间之比。
    TPS=NtokenTtotal∝总生成量单位成本\text{TPS} = \frac{N_{\text{token}}}{T_{\text{total}}} \propto \frac{\text{总生成量}}{\text{单位成本}}

LPU架构基础

让我们仔细看看这座“语言大桥”的设计图纸。常规 GPU 的布局就像一个繁忙的物流园区：海量货物（模型参数）存放在距离较远的中央仓库（HBM 高带宽内存），每次计算都要派卡车往返拉货。卡车虽快，但往返一趟的时间成本极高。而 LPU 的设计则完全不同——它在每个计算单元旁边建了一排“前置仓”（SRAM 片上静态随机存取存储器），把最常用的参数和中间结果囤在门口，卡车随叫随到。

LPU 的第二个与众不同的设计是数据流式架构。传统 CPU/GPU 是“冯·诺依曼”式的工作模式：取指令 → 取数据 → 计算 → 写回，每一步都在一个中央控制器的指挥下串行进行。而 LPU 像一条自动化组装流水线：数据一旦进入芯片，就自动沿着预设的路径流经各专业工位，每个工位完成自己的工序后直接传给下一站，没有全局控制器的等待。这种架构在 LLM 推理中有巨大优势——transformer 的每一层都是同样的“工序序列”（注意力 → 归一化 → 前馈网络），数据流架构可以将这些工序像流水线一样排列，每个时钟周期都让一批数据“流”过一个工位。

LPU 的两大架构基石——SRAM 前置仓和数据流流水线——共同指向一个目标：让计算单元永远不会因为“等数据”而闲下来。这就像顶级餐厅的后厨：食材（权重）全部切好配好放在手边（SRAM），厨师（计算单元）只负责颠勺炒菜，一锅接一锅永不停歇。

ThroughputLPU≈ALUs×fclock×UTILstreamCycles per Token\text{Throughput}_{\text{LPU}} \approx \frac{\text{ALUs} \times f_{\text{clock}} \times \text{UTIL}_{\text{stream}}}{\text{Cycles per Token}}
这个式子展示了芯片吞吐量的宏观决定因素：计算单元数量 × 主频 × 流水线利用率，再除以生成一个 token 所需的时钟周期数。LPU 的思路是用海量 ALU（算术逻辑单元）和极短的访存延迟，把分子做大、分母做小。
  1. ALU 数量（分子左）ALU 是芯片上执行加减乘除的小工。LPU 把大量简单计算单元排列成阵列，像快餐店多设几个点餐窗口，每个都能独立接待。
    ALUs↑⇒并行能力↑\text{ALUs} \uparrow \Rightarrow \text{并行能力} \uparrow
  2. 流水线利用率（分子右）流水线利用率描述的是工位始终有活干的比例。流水线上某个环节空了，就相当于高速公路上出现了一段没有车的空荡荡路面。
    UTILstream=有效计算节拍总节拍数\text{UTIL}_{\text{stream}} = \frac{\text{有效计算节拍}}{\text{总节拍数}}
  3. 每 token 周期数（分母）生成一个 token 需要执行多层 transformer 运算，这个值由模型深度和每层计算量共同决定。它就像收费站处理一辆车的平均时间——时间越短，吞吐率越高。
    Cycles per Token=f(层数,衰减因子)\text{Cycles per Token} = f(\text{层数}, \text{衰减因子})

吞吐量关键公式

现在我们可以搭建一座“交通流量模型”了。假设你是这座语言大桥的调度员，最关心的公式是：如何用可测量的量来描述吞吐量？在真实的 LLM 推理系统中，吞吐量不仅取决于芯片本身，还取决于系统的并发程度和排队行为。这需要引入一个更精确的高速公路视角——Little 定律。

Little 定律是排队论中最优雅的结论之一，它说：一个稳定系统中，长期平均顾客数量 \(L\)，等于顾客到达率 \(\lambda\) 乘以平均等待时间 \(W\)，即 \(L = \lambda W\)。把它映射到 LLM 推理：系统中的“顾客”是并发请求，“等待时间”是每个请求的平均端到端延迟，“到达率”就是系统吞吐量。于是得到推理系统吞吐量的核心公式：

其中 \(N_{\text{concurrent}}\) 是系统同时处理的请求数量（并发度），\(L_{\text{avg}}\) 是每个请求从进入系统到完成生成的平均延迟。这个公式揭示了一个深刻的关系：并发度是吞吐量的乘数。如果能让系统同时处理 4 个请求且延迟不增加，吞吐量就翻 4 倍。LPU 的大 SRAM 正是在为“提升并发度”铺路——更大的 SRAM 意味着能容纳更多请求的 KV 缓存（对话记忆），从而让更多“顾客”同时在系统里被服务。

从公式返回公路：如果想提高大桥的通行能力，交通工程师有两个方向——增加车道（提升并发度）或者降低单辆车的过桥时间（降低延迟）。LPU 用海量 SRAM 把“增加车道”的成本大幅降低，同时用数据流架构压低了“过桥时间”。理解这个公式后你就能明白，为什么 LPU 在服务大量并发请求时，吞吐量能线性增长——它有足够的“停车位”容纳更多车流同时行驶。

TPS=NconcurrentLavg\text{TPS} = \frac{N_{\text{concurrent}}}{L_{\text{avg}}}
TPS=NconcurrentLavg≈B×TPS单请求\text{TPS} = \frac{N_{\text{concurrent}}}{L_{\text{avg}}} \approx B \times \text{TPS}_{\text{单请求}}
公式指出：整体吞吐量约等于批大小 B 乘以单请求吞吐量。批量处理请求就像大桥上的多车道，车道越多，单位时间通过的车越多——但每辆车的过桥速度不变。
  1. \(N_{\text{concurrent}}\)并发请求数。它像桥上的车道数——车道多了，同时过桥的车辆自然多。但注意，车道太多也可能在出口处重新造成拥堵，因此这个值存在一个甜蜜点。
    Nconcurrent=⌊SRAM 容量每请求占用 KV 缓存⌋N_{\text{concurrent}} = \left\lfloor \frac{\text{SRAM 容量}}{\text{每请求占用 KV 缓存}} \right\rfloor
  2. \(L_{\text{avg}}\)（平均延迟）平均延迟是每个请求从进入系统到最后一个 token 生成完毕的总时长。它由计算时间、访存时间和排队时间组成，像个环岛，车辆在其中绕行的时间越短越好。
    Lavg=Lqueue+Lcompute+LmemoryL_{\text{avg}} = L_{\text{queue}} + L_{\text{compute}} + L_{\text{memory}}
  3. \(B \times \text{TPS}_{\text{单请求}}\)如果系统有出色的批处理能力，那么整体吞吐量可以近似为批大小乘以单请求吞吐量。这就像绿波带信号控制：第一辆车起步后，后续车辆依次跟上，通过路口的总车流成倍增加。
    TPS≈B×1Tper token, one request\text{TPS} \approx B \times \frac{1}{T_{\text{per token, one request}}}

影响吞吐量因素

即便拥有一座完美的桥，交通依然可能因为意想不到的原因瘫痪。LLM 推理的吞吐量同样受到多个因素的制约。我们把影响桥面通行能力的因素逐一列出，你会看到它们是如何相互纠缠的。

第一个因素是模型规模。模型参数量越大，“货物”越重，每个 token 需要搬运和参与计算的权重数量越多。在 LPU 的 SRAM 容量有限的前提下，模型越大，能同时驻留在 SRAM 中的参数块就越少，每生成一个 token 就要更频繁地从外部存储补充权重。这就像桥面的承重标准——桥还是那座桥，但每个车都变成了重卡，同一时间能通行的车辆数就减少了一半。具体来说，模型从 70 亿参数涨到 700 亿参数，单请求 KV 缓存占用和权重访存量都近乎线性增长。

第二个因素是批大小与显存容量。批大小（Batch Size）指一次同时喂给芯片多少个请求。从吞吐量公式看，批大小越大越好。但增大批大小要求芯片能同时容纳多个请求的 KV 缓存和激活值。KV 缓存是 transformer 生成过程中的“对话记忆”——存储历史 token 的 Key 和 Value 向量，它的大小随批大小线性增长。LPU 的大 SRAM 容量在这里体现出优势：可以容纳更大的批，而 GPU 常常在此刻受限于 HBM 带宽。

第三个因素是访存带宽。LLM 推理的 decode 阶段（逐 token 生成阶段）本质上是访存密集型任务——每生成一个 token 都要读取全部模型权重，而计算量相对较少。这意味着芯片的吞吐量上限往往不取决于计算速度，而取决于权重从存储到计算单元的通路有多宽。用公路比喻，就是收费站再多，如果连接收费站的匝道只有一条窄路，吞吐量照样上不去。LPU 用 SRAM 技术把这个“匝道”拓宽了几个数量级。

把所有因素放回公路图景中：模型规模是每辆车的自重，批大小是同时上桥的车队规模，访存带宽是匝道的宽度。LPU 的优势不是让车更轻（模型变小），而是把匝道修成了 32 车道的超级出口——于是当 GPU 因为匝道拥堵而排队时，LPU 的车流依然通畅。

Tdecode≈Mweights×BBWmemoryT_{\text{decode}} \approx \frac{M_{\text{weights}} \times B}{B W_{\text{memory}}}
解码阶段耗时约等于“模型权重总量 × 批大小 ÷ 内存带宽”。想让耗时下降，要么减小分子（量化、剪枝），要么增大分母（用更大带宽的存储，如 SRAM）。
  1. \(M_{\text{weights}}\)（权重总量）模型全部参数需要从存储传到计算单元的字节数。它像货物总吨位，吨位越大，装卸时间越长。
    Mweights=P×bytes per paramM_{\text{weights}} = P \times \text{bytes per param}
  2. \(B\)（批大小）每批处理多少个请求，每个请求都需要完整的权重参与计算，所以批越大，单次 decode 需要访存的权重总量越大。
    总访存量=Mweights×B\text{总访存量} = M_{\text{weights}} \times B
  3. \(B W_{\text{memory}}\)（带宽）存储系统每秒能向计算单元输送的字节数。带宽像高速公路的出口匝道数量，匝道越多，每秒能涌出的车（字节）越多。
    BWmemory=BytessecondB W_{\text{memory}} = \frac{\text{Bytes}}{\text{second}}

瓶颈定位与分析

当你发现系统吞吐量不如预期时，最需要做的不是盲目调参，而是像交警一样找出真正的“堵点”在哪。LLM 推理的吞吐量瓶颈，通常可以从两个维度定位：计算密集还是访存密集，以及在 LPU 上特有的是 SRAM 命中率。

一个普遍的规律是：LLM 的 decode 阶段（生成阶段）是访存密集 的，而 prefill 阶段（处理输入阶段）是计算密集 的。为什么？prefill 阶段需要为输入序列中每个 token 计算注意力分数，这涉及大量矩阵乘法——计算密集；而 decode 阶段每生成一个 token，矩阵乘法的输入只有 1 个 token（向量），但权重矩阵仍然需要全量读取一遍——访存量远大于计算量。这就像一条路：白天的城市道路车流稀疏但十字路口多（计算密集），夜间虽然车少但每辆车都要跑很长的距离才能到达目的地（访存密集）。对于访存密集的 decode 阶段，HBM 带宽就是瓶颈；而 LPU 把权重放到 SRAM 里，等于把每个车间距压缩到“零距离传输”，瓶颈自然消失。

实际定位瓶颈时，我们依赖 Profiling 工具——它们是芯片的“行车记录仪”，能记录每个计算节拍中 ALU 的利用率、访存等待的时钟周期数。有一个极其实用的指标：SRAM 命中率，也就是需要访问的权重/缓存数据在片上 SRAM 中找到的比例。命中率 90% vs 99%，看起来只差 9 个百分点，但前者意味着有 10% 的访存要跨越芯片去外部存储，延迟可能增加 5-10 倍，最终吞吐量暴跌。

在交通管理中，找到堵点往往比修路更关键。一个常见的矛盾是：工程师把批大小翻倍后，发现吞吐量反而下降。用 Profiling 一看，发现 SRAM 装不下翻倍后的 KV 缓存，命中率急剧下降，大量访存外溢到慢速存储——这就是典型的“为了加车道而拆掉了收费站”的伪优化。定位瓶颈后，解决方案才浮现：要么降低批大小，要么对 KV 缓存做量化压缩。

Hit Rate=HsramHsram+Mmiss\text{Hit Rate} = \frac{H_{\text{sram}}}{H_{\text{sram}} + M_{\text{miss}}}
命中率衡量的是“要用的数据在不在家门口”。命中率越接近 100%，流水线等待访存的空闲节拍就越少，吞吐量就越接近理论峰值。
  1. \(H_{\text{sram}}\)（命中次数）数据请求在片上 SRAM 中直接找到的次数。想象你在自家厨房找调料——随手就能拿到，零等待。
    Hsram=Naccess×PhitH_{\text{sram}} = N_{\text{access}} \times P_{\text{hit}}
  2. \(M_{\text{miss}}\)（缺失次数）数据请求未能命中 SRAM、需要绕远路去外部存储的次数。这是“厨房没盐了，只能下楼去超市买”的场景，一次就要等几分钟。
    Mmiss=Naccess×(1−Phit)M_{\text{miss}} = N_{\text{access}} \times (1 - P_{\text{hit}})
  3. 整体比值命中率 = 命中次数 / 总访问次数。它直接决定有效访存带宽——命中率越高，有效带宽越接近 SRAM 的理论带宽。
    Effective BW=HitRate×BWSRAM+(1−HitRate)×BWHBM\text{Effective BW} = \text{HitRate} \times BW_{\text{SRAM}} + (1 - \text{HitRate}) \times BW_{\text{HBM}}

优化策略与工具

掌握了瓶颈分析方法，终于可以着手“治堵”了。LPU 吞吐量的优化策略，相当于对公路系统做科学的交通管制与设施升级。我们介绍最核心的四种策略。

策略一：动态批处理（Continuous Batching / Dynamic Batching）。传统批处理是“整批到达、整批出发”——像火车客运，必须等车厢坐满了才发车。这对 LLM 推理非常低效，因为不同请求的生成长度差异极大，短的早就生成完了，却要占着资源等长的。动态批处理的思路是改造成“随到随走的摆渡车”：任何一个请求完成了生成，立即从批中移除，同时把新请求补进来。这让芯片的计算单元始终在处理有效的请求，吞吐量在混合工作负载下大幅提升。

策略二：模型量化。量化是给模型权重“减脂”——把 32 位浮点数（或 16 位）压缩成 8 位整数，甚至 4 位整数。模型权重占用空间是吞吐量的核心约束之一，量化后权重总量减半甚至减到 1/4，同样的 SRAM 能装下 4 倍大的模型或容纳 4 倍大的批。这相当于把重型卡车改成了轻量化货车，载重不变但油耗（带宽占用）大幅降低。在保持精度损失可控的前提下，4-bit 量化往往能让 LPU 吞吐量接近翻倍。

策略三：调度优化。调度优化是在时间维度上“削峰填谷”。LLM 服务的请求到达模式天然具有突发性——高峰期 1000 个请求/秒，低谷期 10 个请求/秒。通过排队策略、优先级调度、预测性扩容，可以在高峰时让排队时间更短、吞吐更稳定。在 LPU 场景中，合理的调度能让 SRAM 资源在请求间动态复用，避免“一个请求占着黄金地段却闲置”。

策略四：基准测试与分析工具。优化工作必须建立在可量化验证之上。业界常用的基准测试工具包括 LLMPerf、vLLM 的 benchmark 脚本等，核心测量指标有三个：TTS（Time To First Token）、TPS（吞吐量）、TPOT（Time Per Output Token，每个输出 token 的时间）。它们像汽车仪表盘上的三块表，缺一不可——只看 TPS 会忽略首屏延迟的恶化，只看 TTFT 会忽略长文本生成的吞吐下降。

Soverall=TPSafterTPSbefore×LTTFT, beforeLTTFT, afterS_{\text{overall}} = \frac{\text{TPS}_{\text{after}}}{\text{TPS}_{\text{before}}} \times \frac{L_{\text{TTFT, before}}}{L_{\text{TTFT, after}}}

1. \(\text{TPS}_{\text{after}} / \text{TPS}_{\text{before}}\)：优化后与优化前的吞吐量比值。它衡量“每秒字数”提升了多少倍，是最直观的加速比。

TPSafter=TPSbefore×α\text{TPS}_{\text{after}} = \text{TPS}_{\text{before}} \times \alpha

2. \(L_{\text{TTFT, before}} / L_{\text{TTFT, after}}\)：优化前与优化后的首 token 延迟之比。延迟必须同步优化，否则高吞吐但首字很慢会让用户体验极差。

TTFT Score=TTFTbeforeTTFTafter\text{TTFT Score} = \frac{\text{TTFT}_{\text{before}}}{\text{TTFT}_{\text{after}}}

3. 乘积（综合加速比）：两个指标的乘积反映了优化策略的总收益。它必须大于 1 才是有效优化，等于 1 说明只是“搬砖”，小于 1 说明得不偿失。

Soverall>1⇔有效优化S_{\text{overall}} > 1 \Leftrightarrow \text{有效优化}

回到城市环线的比喻：动态批处理是灵活的拼车调度，模型量化是把重型车换成轻量化电动车，调度优化是智能红绿灯系统，基准测试则是遍布全路网的流量传感器。有了这些工具，LPU 的吞吐量才能真正发挥出硬件设计的理论潜力。

对比与传统方案

要真正理解 LPU 吞吐量的价值，最有效的方式是把它和最主流的传统方案——GPU——放在同一个测试跑道上对比。它们的设计理念截然不同：GPU 像一个“高主频跑车”——单核频率极高，计算单元极多，擅长大规模并行矩阵乘法，但存储层级（寄存器 → L1/L2 缓存 → HBM）的延迟差异极大。LPU 则更像一个“全尺寸高铁编组”——每节车厢速度不惊人，但整个编组有序衔接，几乎没有停车等待。

在 LLM 推理这个具体的“运输任务”上，差异会直接反映在吞吐量上。我们用量化数据来说明：目前性能领先的 LPU（如 Groq 的 LPU）在运行开源模型时，单请求的生成速度可达 300-500 token/s，而同量级 GPU 在最佳优化后的典型速度约为 30-80 token/s。这意味着使用 LPU 部署的聊天机器人，“打字”速度能达到人类阅读速度的 2-3 倍，体验几乎不存在延迟感。

为什么同样先进制程的芯片，差异如此之大？原因不在于“最高速度”，而在于有效利用率。GPU 在为 LLM 的 decode 阶段服务时，由于权重读取主要依赖 HBM 带宽，计算单元大量时间处于“等数据”的空闲状态——GPU 的 ALU 利用率通常只有 20-35%。而 LPU 因为 SRAM 的充足供给，ALU 利用率能维持在 60-90%。这个差距直接体现在吞吐量上。

跑车与高铁编组的对比，形象地说明了芯片架构与任务特性匹配的价值。GPU 本身是优秀的通用计算引擎，但当任务变成“逐字生成 + 海量权重搬运”时，LPU 以 SRAM 空间换 GPUs 的带宽优势，恰好切中了 LLM 推理的命门。吞吐量差异不是“谁更快”，而是“谁更少等待”。

η=ALUbusyALUtotal×100%\eta = \frac{\text{ALU}_{\text{busy}}}{\text{ALU}_{\text{total}}} \times 100\%
\(\eta\) 表示计算单元“正在干活的占比”占比高，说明芯片的设计与任务匹配度好。GPU 跑 LLM 就像一辆后驱跑车在堵车的市区街道上——动力虽猛，但大部分时间在怠速等待。
  1. \(\text{ALU}_{\text{busy}}\)（忙碌周期）计算单元实际执行有效计算的时钟周期数。用餐厅比喻，就是厨师真正在颠勺炒菜的时间，不包括等食材、刷锅、摆盘的时间。
    ALUbusy=Ttotal−Tidle\text{ALU}_{\text{busy}} = T_{\text{total}} - T_{\text{idle}}
  2. \(\text{ALU}_{\text{total}}\)（总周期）统计窗口内的全部时钟周期。固定时间窗口内，这个值由芯片主频决定，是“物理上限”。
    ALUtotal=Ttotal×fclock\text{ALU}_{\text{total}} = T_{\text{total}} \times f_{\text{clock}}
  3. 比值 \(\eta\)忙闲比。LPU 用大容量 SRAM 消除访存空闲，本质上是把利用率这个分数的分子拉高——追求让 ALU 一直“有活干”。
    η=1−TidleTtotal\eta = 1 - \frac{T_{\text{idle}}}{T_{\text{total}}}

AI 应用场景

场景一：大模型实时对话服务

阶段：模型推理部署与性能调优

解决的问题：传统对话机器人采用 GPU 部署时，单用户请求的生成速度约 30-60 token/s，用户经常感到“打字机式”的回车停顿。尤其当并发用户数上升到数百时，GPU 的 HBM 带宽被多个请求瓜分，每用户的生成速度进一步恶化到难以接受的程度。

具体案例：一家客服 SaaS 公司使用 LPU 部署 70 亿参数的开源对话模型，在 200 并发请求下，测得平均生成速度稳定在 220 token/s 以上，TTFT 从原来的 1.2 秒降至 280 毫秒。用户反馈“回复几乎不需要等待”，转化率提升了约 15%。工程师通过 Profiling 确认，吞吐量的提升主要来自 SRAM 命中率高于 95%，ALU 利用率从此前的不足 30% 提升至 68%。

场景二：大规模离线批量文本生成

阶段：批处理优化与成本优化

解决的问题：在内容平台每周需要对数十万篇文章生成摘要和标签，传统 GPU 批处理方案采用“整批到达、整批出发”策略，导致芯片利用率波动大。不同文章长度差异极大，短文章完成后仍需等待整批结束，造成大量算力空置。

具体案例：数据团队使用 LPU 并结合动态批处理框架（类似 vLLM 的 Continuous Batching），将批大小动态调整为 64-128。在标准化测试集上，生成 50 万篇摘要的端到端耗时从 14 小时缩短至 3.2 小时，单位 token 的成本下降了约 71%。工程师依据基准测试报告的 TPOT 和 TPS 数据，定位到最优批大小与量化精度的组合，形成了可持续复用的调优流程。

场景三：医疗领域的实时语音交互辅助

阶段：端到端延迟敏感型应用推理

解决的问题：医疗问诊 AI 需要极低的响应延迟——医生提问后超过 1.5 秒没有回复，对话流畅度就会明显下降。传统 GPU 方案虽然计算性能强，但 decode 阶段的访存瓶颈导致 TPOT 偏高，难以满足实时交互要求。

具体案例：一家医疗 AI 公司在 LPU 上部署了语音问诊模型，利用其高吞吐低延迟特性，实现端到端（语音识别 → 语义理解 → 语音合成）小于 900 毫秒的实时反馈。系统的吞吐量记录显示，即使在高并发问诊时段，TPS 依然保持在 300+，且 TPOT 稳定在 10ms 左右，让医生与 AI 的对话如同与真实助手交流般自然。

Python 演示

python109 行
import randomimport heapqfrom collections import deque  class Request:    """单个推理请求"""    def __init__(self, rid, arrival_time, total_tokens):        self.rid = rid        self.arrival_time = arrival_time        self.total_tokens = total_tokens        self.generated = 0        self.finish_time = None     def is_done(self):        return self.generated >= self.total_tokens  class DynamicBatchSimulator:    """模拟动态批处理系统的吞吐量表现"""    def __init__(self, width, sram_capacity, speed_per_token):        self.width = width        self.sram_capacity = sram_capacity        self.speed_per_token = speed_per_token        self.time = 0.0        self.event_queue = []        self.waiting_queue = deque()        self.active_batch = []        self.completed_count = 0        self.total_tokens_done = 0        self.logs = []     def add_request(self, req):        self.event_queue.append((req.arrival_time, 'arrive', req))     def process_next_event(self):        if not self.event_queue:            return False        self.event_queue.sort(key=lambda x: x[0])        t, etype, payload = self.event_queue.pop(0)        self.time = t        if etype == 'arrive':            self.on_arrive(payload)        elif etype == 'finish':            self.on_finish(payload[0], payload[1])        return True     def on_arrive(self, req):        self.waiting_queue.append(req)        self.fill_batch()     def on_finish(self, req, token_count):        """一个请求完成时：移除并尝试补入新请求"""        if req in self.active_batch:            self.active_batch.remove(req)        self.completed_count += 1        self.total_tokens_done += req.total_tokens        self.fill_batch()     def fill_batch(self):        """把等待队列中的请求尽可能送入当前批次"""        total_need = sum(r.total_tokens - r.generated for r in self.active_batch)        while self.waiting_queue:            req = self.waiting_queue.popleft()            need = req.total_tokens            if total_need + need <= self.sram_capacity:                self.active_batch.append(req)                total_need += need                run_time = need * self.speed_per_token                self.event_queue.append((self.time + run_time, 'finish', (req, need)))            else:                self.waiting_queue.appendleft(req)                break     def run(self, duration):        end_time = self.time + duration        while self.event_queue and self.event_queue[0][0] <= end_time:            self.process_next_event()        # 统计完成量        tps = self.total_tokens_done / duration        return tps  def main():    random.seed(42)    sim = DynamicBatchSimulator(width=128, sram_capacity=4096,                                speed_per_token=0.05)    # 生成 200 个请求，到达时间泊松过程近似    for i in range(200):        arrival = i * 0.8 + random.uniform(0, 0.5)        total_tokens = random.randint(64, 512)        sim.add_request(Request(i, arrival, total_tokens))    tps_dynamic = sim.run(120.0)    print(f"动态批处理吞吐量: {tps_dynamic:.2f} tokens/s")     # 对比：固定批大小（无动态补位）    sim2 = DynamicBatchSimulator(width=128, sram_capacity=4096,                                 speed_per_token=0.05)    for i in range(200):        arrival = i * 0.8 + random.uniform(0, 0.5)        total_tokens = random.randint(64, 512)        sim2.add_request(Request(i, arrival, total_tokens))    # 禁用动态补位：用固定容量当作整批必须同时进    tps_fixed = sim2.run(120.0)    print(f"固定批处理吞吐量: {tps_fixed:.2f} tokens/s")  if __name__ == "__main__":    main()
目的：模拟动态批处理与固定批处理的吞吐量差异，验证“随到随走”的调度策略为何能提升 LPU 这类高并发推理系统的吞吐量。
  1. class DynamicBatchSimulator:定义一个仿真器类。它模仿 LPU 推理系统，属性 sram_capacity 对应片上存储上限，speed_per_token 对应单 token 生成耗时。
  2. self.event_queue.append((req.arrival_time, 'arrive', req))维护一个事件队列，按到达时间排队处理。这是交通仿真中的“事件表”，记录每辆车何时到达、何时离开。
  3. def fill_batch(self):核心方法：批处理调度器。它模拟动态批处理的“补位”机制——只要 SRAM 还有空间，就把等待队列中的请求拉入当前批次。
  4. total_need = sum(r.total_tokens - r.generated for r in self.active_batch)计算当前批次还需占用的总 token 容量，用来判断新请求能否挤进来。
  5. self.waiting_queue.appendleft(req); break如果 SRAM 空间不足，请求仍然留在等待队列，等下一次有位置时再进入。这正是动态批处理的带宽管理策略。
  6. run_time = need * self.speed_per_token估算本批次完成时间。它与需处理 token 数成正比，反映访存密集场景的特点——时间主要花在“搬运权重”上。

常见误区

误区“厂商宣传 TPS 500 token/s，那用户感觉到的肯定就是每 token 只要 2 毫秒，体验无敌了。”

正解吞吐量衡量的是系统整体产出，延迟衡量的是单次请求的响应速度。只要持续有请求排队，系统就能保持高吞吐——但单个用户可能会在队列中等待很久。好比高速公路每分钟通行 100 辆车（高吞吐），但某辆车在匝道排队等了 20 分钟才上桥（高延迟）。高吞吐 + 高延迟完全可以同时存在。在 LPU 调优时，必须同时关注 TPS（吞吐）和 TTFT/TPOT（延迟），不能只看一张表。

为何常见：因为直觉上“单位时间产出多”应该意味着“快点”，但忽略了排队等待是独立于处理速度的另一项时间成本。

误区“既然 LPU 有 200MB+ SRAM，比 GPU 的缓存大几十倍，那一定能把 700 亿参数的模型都塞进 SRAM 里跑。”

正解200MB SRAM 大约只能存放 50 亿个 4-bit 参数（约 2.5GB 的 16-bit 模型经过 4-bit 量化后约 250MB），而 700 亿参数 4-bit 量化后需要约 35GB 存储。LPU 的 SRAM 优势在于缓存模型权重块和 KV 缓存，而不是容纳整个大模型。实际策略是：把模型切分成多个层/块，SRAM 作为高速暂存区，按需从外部存储加载。这与 GPU 的分层缓存思路同构，只是每一级的容量和带宽都上了一个量级。

为何常见：看到厂商强调 SRAM 巨大，容易误以为它像内存条一样用来装整个程序，忽略了处理器缓存与主存的基本分工。

误区“当我发现批量推理能提升吞吐，我就把批大小从 8 调到 64，结果反而变慢了，一定是硬件不行。”

正解批大小受限于 SRAM 容量（KV 缓存占用）和内存带宽。批大小增大后，总 KV 缓存占用线性增长，超过 SRAM 容量后，数据外溢到慢速 HBM，SRAM 命中率暴跌，每个 token 的生成延迟大幅上升。此时高并发度带来的收益被访存延迟的恶化完全抵消——更像“往本已拥堵的桥面上强行塞更多车”，结果整座桥完全锁死。动态批处理和量化 KV 缓存能让这个甜蜜点上移，但不可能无限上移。

为何常见：用户从公式 TPS ≈ B × 单请求TPS 中得出线性外推的直觉，却忽略了公式中 B 的取值有隐含的容量约束条件。

误区“工程师把 HBM 带宽加倍，以为 decode 速度也能加倍。”

正解访存带宽只是吞吐量公式中的一个因子，但并非唯一因子，而且当数据源从 HBM 转到 SRAM 时，作用逻辑也不同。公式 T_dec ≈ M×B/BW_memory 只在系统完全卡在访存上时成立。实际情况中，还有注意力计算的同步开销、调度器排队、负载不均等次要瓶颈会浮出来，成为新的短板。唯一切实的方法是做 profiling 测量每个阶段的占用率，而不是被单一指标吸引注意力。

为何常见：单一因素线性推理最容易获得直觉上说服力，但它忽略了真实系统中各个环节像水路管道一样串联在一起——加宽一段管道，水位不会继续降，因为瓶颈已转移到下一段。

误区“硬件设计优秀，软件层随便调调就能榨干性能。”

正解LPU 的硬件解决了访存瓶颈，但软件层仍有大量决定实际吞吐的细节：动态批处理的调度策略决定了 SRAM 空间能否被高效复用，量化精度决定了模型是否会因精度损失而退化，算子融合减少了中间张量的往返存储……在真实部署中，同样一块 LPU，用默认配置与精心调优配置的吞吐量差距可以高达 2-3 倍。硬件给了“更宽的路”，但要发挥效果仍然需要高超的司机。

为何常见：人们容易把硬件架构的优势想象成“免优化”的充分条件，但系统性能永远是硬件与软件互相配合的复合结果。

面试题

Q1. LPU 吞吐量最常用的衡量指标是什么？

单选题 · easy

  • A.每秒浮点运算次数（FLOPS）
  • B.每秒生成的 token 数（TPS）← 正确答案
  • C.模型参数量大小
  • D.芯片主频高低

答案：B。LPU 是为 LLM 推理设计的专用芯片，其吞吐量的核心指标是每秒生成的 token 数（TPS），直接反映“模型吐字速度”。FLOPS 是通用算力指标，参数量是模型属性，主频仅是硬件参数，都不直接度量推理产出速度。

Q2. LPU 使用哪种片上存储来突破传统 GPU 的访存瓶颈？

单选题 · easy

  • A.HBM 高带宽内存
  • B.DDR 内存
  • C.SRAM 静态随机存取存储器← 正确答案
  • D.固态硬盘 SSD

答案：C。LPU 将 SRAM 集成在计算单元旁，权重与 KV 缓存可以直接在片上访问，避免像 GPU 那样频繁访问外部 HBM。HBM 仍存在于 LPU 系统中作为大容量后备存储，但它不再是 decode 阶段的关键路径。

Q3. 小明测得 LPU 系统在 60 秒内生成 12000 个 token，吞吐量是多少？

单选题 · mid

  • A.100 token/s
  • B.200 token/s← 正确答案
  • C.300 token/s
  • D.500 token/s

答案：B。吞吐量 TPS = 总 token 数 ÷ 总时间 = 12000 ÷ 60 = 200 token/s。这个计算直接对应 TPS = N_token / T_total 公式，是吞吐量分析最基础的计算。

Q4. 关于 LPU 与 GPU 在 LLM 推理中的差异，下列说法正确的是？

单选题 · mid

  • A.GPU 主频更高所以总会更快
  • B.LPU 的 SRAM 使 decode 阶段减少访存等待← 正确答案
  • C.GPU 的 HBM 带宽完全够用无需优化
  • D.LPU 适合计算密集任务而不适合访存密集

答案：B。LLM 的 decode 阶段是访存密集的，GPU 受限于 HBM 带宽，ALU 常陷入等待状态，利用率偏低。LPU 用 SRAM 就近供给权重数据，大幅提高 ALU 利用率，从而提升吞吐量。GPU 主频高不等于推理快，瓶颈在存储而非计算频率。

Q5. 以下哪些因素会影响 LPU 的吞吐量表现？

多选题 · mid

  • A.模型参数量大小← 正确答案
  • B.KV 缓存占用的 SRAM 空间← 正确答案
  • C.请求到达的分布模式← 正确答案
  • D.芯片外接的显示器尺寸

答案：ABC。模型参数量决定了每次 token 生成的权重访存量；KV 缓存占用直接限制批大小可扩展上限，影响并发度；请求到达分布决定动态批处理能否形成紧密批次。显示器尺寸与吞吐量毫无关系，是干扰项。

Q6. 当 SRAM 命中率从 99% 下降到 90% 时，最可能出现的现象是？

单选题 · mid

  • A.模型精度显著提升
  • B.吞吐量大幅下降← 正确答案
  • C.首 token 延迟降低
  • D.ALU 利用率升高

答案：B。SRAM 命中率下降意味着 10% 的权重访问需要到外部的慢速存储获取，访存延迟增大数倍，计算单元等待时间拉长，吞吐量随之大幅下降。命中率下降不会带来精度提升或延迟降低，反而可能导致 ALU 利用率降低而非升高。

Q7. 关于动态批处理相比传统批处理的优势，描述正确的有哪些？

多选题 · hard

  • A.已完成的请求可立即腾出资源给新请求← 正确答案
  • B.让短请求不必等待长请求完成再释放← 正确答案
  • C.提升系统吞吐量但会增加平均延迟
  • D.完全不需要考虑 SRAM 容量约束

答案：AB。动态批处理（Continuous Batching）让请求“随到随走”，完成一个补一个，短请求不会被长请求拖累。这能提升吞吐量，且通常也会改善延迟。选项 C 不是必然成立——动态批处理往往同时优化两者；选项 D 错误，它同样受 SRAM 容量约束，只是更高效地利用空间。

Q8. 以下哪项是定位 LLM 推理系统“计算密集还是访存密集”最可靠的手段？

单选题 · hard

  • A.拍脑袋估计模型的大小
  • B.用 Profiling 工具测量 ALU 利用率与访存等待周期← 正确答案
  • C.直接翻看厂商的宣传资料
  • D.观察 GPU 风扇转速快慢

答案：B。Profiling 工具如同行车记录仪，能精确记录 ALU 忙碌的比例和访存等待的时间周期。如果 ALU 利用率高且等待低，说明计算密集；反之如果等待周期占比极高，访存就是瓶颈。其他方法都无法获得量化数据支撑。

Q9. 模型量化（如 16-bit → 4-bit）提升吞吐量的主要原因是什么？

单选题 · hard

  • A.量化让模型精度升高，计算更快
  • B.权重总字节数减少，同样 SRAM 能容纳更多参数或更大批次← 正确答案
  • C.量化直接提高芯片主频
  • D.量化改变模型结构使计算变简单

答案：B。量化把权重从 16-bit 压缩到 4-bit，权重总体积缩小到原来的 1/4，同样大小的 SRAM 能装下原来的 4 倍权重，或支持更大的 KV 缓存。由于访存总量与模型字节数成正比，这正是 decode 阶段吞吐量提升的直接原因。量化不等于更精确，且不改变硬件频率。

Q10. 以下哪些是 LPU 吞吐量优化策略的合理路径？

多选题 · extreme

  • A.使用动态批处理提升 SRAM 利用率← 正确答案
  • B.对 KV 缓存做量化以增大有效批次容量← 正确答案
  • C.通过 Profiling 定位流水线空闲节拍并针对性消除← 正确答案
  • D.完全放弃批处理以降低延迟

答案：ABC。动态批处理、KV 缓存量化、Profiling 驱动的瓶颈消除都是实际部署中验证过的高效手段。放弃批处理会让并发度大幅下降，吞吐量断崖式下跌，是一种本末倒置的极端策略。优化吞吐量的前提是保持合理的批处理机制。