LPU：超低延迟推理

可视化演示

展示LPU通过SRAM片上存储消除访存延迟、编译器全图静态调度消除运行时开销，实现亚毫秒级推理。切换模式对比LPU与GPU方案。

延迟基础：先等第一个词，再等每下一个词

专线快递的“快”到底体现在哪？不是信送出去那一下变快了，而是“第一句话说出来”变快了。用户发问后，AI 并不是把整段回答写好再一次性给你，而是一个词一个词地“蹦”出来。你感受到的速度由两段组成：从按回车到第一个词出现的等待，以及之后每两个词之间的间隔。前者像快递的“揽收装车”时间，后者像“每封信的路途”时间。

在 LLM 推理里，第一个词前的等待叫首 token 延迟（TTFT，Time To First Token），主要花在读取并处理全部 prompt 上；之后每多生成一个词花的时间叫每 token 延迟（token interval）。回答一共有 N 个词，那么总时间就是首词延迟加上剩下的 N-1 个词的间隔：

普通快递（GPU）每个词的间隔可能高达十几毫秒，整段 32 个词要几百毫秒；LPU 把 T_token 压到亚毫秒，就像专线快递把“每封信的路途时间”缩到极限——用户几乎感觉不到“打字”的过程，而是像有人直接把话说完。这也是为什么“亚毫秒级目标”对交互式 AI 意义如此重大。

架构设计：免掉每一步的现场请示

专线快递和普通快递最大的区别，是普通快递在每个中转站都要停下“现场决策”：这封信该上哪辆车？先卸哪件？调度员现场拍板，每一站都在烧时间。专线快递没有中转站，路线出发前就已写死，快递员只负责闷头赶路。

GPU 正是那个“现场决策”的系统。它的底层有硬件调度器（warp scheduler），每执行一小段算子就要动态地把计算任务分派给线程束：谁先算、谁等内存、谁让路，全在运行时决定。这些动态调度和分支处理，就是每次推理都要缴纳的“调度税”。LPU 则反向设计：计算单元按顺序流水推进，每个单元职责固定，控制逻辑极简，运行时几乎没有需要拍板的决策：

LPU 的架构就像一条装配流水线：每个工人只负责自己工位上的固定动作，传送带按固定节拍推进，没有人在每个工位前停下问“下一个零件该装哪”。专线快递员不用在每个路口停下来问路，自然就跑得快。

存储优化：食材就在手边的档口厨房

为什么很多餐馆上菜慢？因为配菜在仓库，厨师每做一道菜都要跑到仓库取食材。专线快递的背包之所以重要，是因为“回仓库取东西”是最容易被忽略的隐形时间黑洞。LPU 的做法，是把整个菜单的食材都摆在自己的档口厨房里。

GPU 推理时，模型权重存在片外 HBM（高带宽内存）里。每生成一个 token，都要把全部权重从 HBM 读一遍：单次访存延迟约 100 纳秒，带宽虽高但“路程远”。LPU 则将权重常驻在芯片上的 SRAM 中——容量虽小（几十到几百 MB），但访问延迟只有约 2 纳秒，聚合带宽可达数十 TB/s。对能装进片上容量的模型来说，“回仓库”这一步被完全省掉：

把权重放在片上 SRAM，就像把食材全部备在手边——厨师伸手就能拿到，不需要跑仓库；而 GPU 的 HBM 更像中央大冷库，带宽再高，来回一趟的时间成本依然无法抹平。“背包容量决定专线能跑多远”，这也是为什么 LPU 最适合那些能整体装进片上存储的模型。

编译调度：演出前就发好的总谱

一场交响乐演出，几十个乐手各吹各的，为什么能做到分秒不差？因为总谱在演出前就写好、分发好了：每个乐手第几小节进、什么力度、什么时候让位给主旋律，全部事先排练定死。演出时指挥只需要给个起始拍子，没人现场翻谱问“下一个该吹什么”。LPU 的编译器就是这本总谱。

推理和训练不同：训练时数据形状、梯度计算高度动态；而推理时网络结构、每层张量形状、算子顺序全部在编译期已知。LPU 的编译器对整个计算图做“全图静态调度”：哪个算子用哪个计算单元、数据放在哪块 SRAM、什么时候搬运、搬运到哪个端口，在运行之前全部排好。于是运行时没有分支判断、没有动态等待，计算单元的空闲时间被压到极致：

GPU 的运行时调度像即兴爵士：乐手们现场听、现场配，灵活但总有人要等；LPU 的编译器全图调度像交响乐总谱：每个人什么时候做什么早已写死，演出（推理）开启后只管按谱执行。这种“事前编排、事后零决策”的结构，正是亚毫秒延迟的基石。

批处理策略：既承诺速度又凑整车

专线快递承诺“件件都快”，但生意多了，快递员也不可能同时送一百件。他聪明的做法是：没人排队就立刻单飞；一旦排队，就把几个顺路的件凑成一车同时送，但前提是每一件都还在承诺的送达时间内。绝不为了凑车而让任何一件超时。

芯片同理：一个请求虽然快，但芯片资源富余时闲着也是浪费。批处理（batching）把多个请求合在一起推理，能显著提升吞吐；但批越大，单个请求等待 batch 凑齐的时间越长，延迟越高。LPU 因为权重重读成本极低（都在片上 SRAM），可以采用连续批处理（continuous batching），动态调整批大小，在吞吐与延迟之间取平衡。这个平衡有一个硬底线——服务承诺 SLO：

LPU 就像那个聪明的专线快递员：人少时单飞抢速度，人多时动态拼车保吞吐，但一切以“SLO 不超时”为底线。批处理不是 LPU 的敌人，而是它既“承诺快”又“接更多单”的平衡术。

性能对比：专线与干线谁更划算

专线快递在市区寄一封急件，确实快得惊人；但如果你要发一整车十吨货物到三千公里外，专线的小背包显然装不下，这时干线物流（GPU）的规模和成本优势就出来了。选择哪种，取决于你的货（负载）长什么样。

把两者放在同一模型上对比：小 batch、单请求、实时交互时，LPU 的端到端延迟能做到 GPU 的几十分之一（亚毫秒级 vs 数十毫秒级）；但当 batch 拉到很大、以吞吐为目标的离线场景，GPU 依靠峰值 FLOPS 与超大 HBM 带宽，单位时间处理的 token 数反而更高。LPU 的 SRAM 容量有限，模型超出后也要回退到片外存储，优势随之收窄。适合 LPU 的典型场景：实时对话、agent 多轮链式调用、交互式代码补全、同声传译；适合 GPU 的典型场景：离线批量推理、大模型训练、把吞吐当第一指标的管道任务。用加速比可以量化这个差距：

专线不是万能的，LPU 也不是“GPU 杀手”。它是一把为“低延迟实时交互”打磨的专用快刀：在它擅长的赛道里，延迟优势是数量级的；但换一个赛道（超大模型、超大 batch 的吞吐竞赛），干线的价值同样不可替代。“先看清负载，再选择线路”是每个部署者最该记住的一句话。

AI 应用场景

Python 演示

class Engine:    """模拟一颗推理芯片的单token延迟构成."""     def __init__(self, name, peak_flops, sram_bytes, sram_bw, dram_bw, sched_per_kernel):        self.name = name        self.peak_flops = peak_flops          # 每秒浮点运算数        self.sram_bytes = sram_bytes          # 片上存储容量        self.sram_bw = sram_bw                # 片上带宽 B/s        self.dram_bw = dram_bw                # 片外带宽 B/s        self.sched_per_kernel = sched_per_kernel  # 每算子调度开销     def token_latency(self, model_bytes, flops_per_token, kernel_count):        # 模型装得进片上存储就用片上带宽, 否则回退到片外        if model_bytes <= self.sram_bytes:            effective_bw = self.sram_bw        else:            effective_bw = self.dram_bw        load_time = model_bytes / effective_bw          # 搬权重的时间        compute_time = flops_per_token / self.peak_flops  # 纯计算时间        sched_time = self.sched_per_kernel * kernel_count  # 调度税        return load_time + compute_time + sched_time  def main():    gpu = Engine("GPU", peak_flops=1.5e15, sram_bytes=40e6,                 sram_bw=8e12, dram_bw=2e12, sched_per_kernel=5e-6)    lpu = Engine("LPU", peak_flops=5e14, sram_bytes=230e6,                 sram_bw=80e12, dram_bw=5e12, sched_per_kernel=0.0)     models = [("small_200MB", 200e6), ("large_2GB", 2e9)]    flops_per_token = 1.2e9    kernel_count = 4    tokens = 32     print("model          engine   ms/token   ms/32token   speedup")    for model_name, model_bytes in models:        gpu_lat = gpu.token_latency(model_bytes, flops_per_token, kernel_count)        lpu_lat = lpu.token_latency(model_bytes, flops_per_token, kernel_count)        for eng_name, lat in (("GPU", gpu_lat), ("LPU", lpu_lat)):            ratio = ("%.1fx" % (gpu_lat / lpu_lat)) if eng_name == "LPU" else "-"            print("%-12s %-6s %9.3f %12.3f %8s" % (                model_name, eng_name, lat * 1e3, lat * tokens * 1e3, ratio))  if __name__ == "__main__":    main()

1. class Engine:把芯片抽象成“带宽、容量、调度税”三个核心参数的延迟模型
2. if model_bytes <= self.sram_bytes:模型装得进片上 SRAM 吗？决定走“档口取菜”还是“回仓库取菜”
3. load_time = model_bytes / effective_bw权重读取时间 = 要搬的数据量 ÷ 有效带宽
4. sched_time = self.sched_per_kernel * kernel_count为每个算子缴纳的“调度税”；LPU 是 0
5. gpu = Engine(...)GPU 参数：大算力 + 小片上容量（40MB）+ 每算子 5 微秒调度税
6. lpu = Engine(...)LPU 参数：230MB 片上 SRAM + 80TB/s 带宽 + 零调度税
7. gpu_lat / lpu_lat加速比：小模型约 25 倍，大模型因超出片上容量缩水到约 2.5 倍

常见误区

面试题