LPU vs GPU：两种AI计算哲学的对决

可视化演示

双模式对比LPU与GPU：架构对比（LPU确定性数据流vs GPU多SM并行调度）和性能对比（延迟/吞吐/batch/编程/能效五维度评分）。

架构设计哲学

老板要开一家能天天量产同款 AI 大菜的中央厨房，两位设计师各交一份图纸。A 图纸是开放式大排档：一百名厨师每人一小灶，谁拿到单谁煮，追求“同一时间出锅的菜最多”。B 图纸是寿司传送带：只有五六个站点，每个站点只做切鱼、捏米、摆盘中的一个动作，追求“每道菜的节奏完全可控”。前者是 GPU，后者是 LPU。

GPU 的架构哲学从显卡时代就定型了：用海量简单小核心（上千个 CUDA core）堆出高吞吐，靠运行时调度器把任务塞给空闲核心。LPU 则信奉另一套信条——算数很便宜，搬数据才是瓶颈，于是把芯片设计成一条数据流流水线，并采用哈佛架构（指令存储与数据存储分开）避免取指令和数据搬运抢同一条路，让每个时钟周期都有确定的数据到达乘加单元。

两者都受“内存墙”约束：芯片算得再快，喂不饱数据就是空转。GPU 的策略是堆并行度——同时运行上千个线程，让总线始终有人排队取数，从而逼近峰值带宽；LPU 的策略是堆确定性——用大容量片上 SRAM 与静态流编排，让每个周期该搬哪个数据都是编译期定好的，小并行度也能吃饱带宽。于是带宽利用率 η 成了度量“喂食效率”的标尺。

大排档要热闹，靠人海把档口占满；传送带要稳，靠每个站点精确的喂料时刻表。同样是“喂饱做菜单元”这件事，两种思路从这里开始分道扬镳。

调度执行机制

后厨最乱的时刻是高峰期。大排档没有固定流程：菜一进后门，谁空谁接，厨师还会临时换锅（上下文切换），订单一多，门前排起长队。寿司传送带恰好相反：开店前师傅就把皮带速度和站点顺序排成时刻表，运行时没有任何人需要“现场决定”下一步——一切都在编译期（开店前）定完了。

GPU 的调度是动态的：warp scheduler（线程束调度器）在每个周期挑选就绪的线程束上执行单元，并且靠线程超量分配——创建比物理核心多几倍的线程——让一组线程等数据时立刻切换另一组上来，把“等待访存”变成“切换线程”，从而榨干吞吐。代价是：单个请求的命运取决于当时负载，延迟天然有方差。

LPU 的调度是静态的：编译器把计算图翻译成逐周期的硬件动作，数据在流水线站点之间按固定节拍前进，运行时不设仲裁器、不排队。利特尔定律告诉我们，系统里滞留的请求越少，单个请求等待越短——LPU 牺牲灵活性，换来的正是“滞留请求趋近于零”的确定性。

大排档的队伍长短全看运气，传送带的队伍永远不会超过站点总数。动态调度换来的是“什么都能炒”的自由，静态编译换来的是“每秒都一样稳”的承诺——看你愿意为哪一种买单。

延迟吞吐对比

客人真正在意的是“我点的这盘菜多久上”，也就是单请求延迟。大排档高峰期一小时能出 1000 盘（吞吐高），但单盘可能要等 15 分钟，而且忽快忽慢；传送带一小时只有 400 盘（吞吐低），但第一盘 30 秒必到，误差不超过一秒。

衡量大模型服务体验的第一个指标是首 token 延迟（TTFT，Time To First Token）：用户发出问题到看见第一个字的间隔。它由三段组成：排队时间、调度开销、计算时间。GPU 在高并发下把资源优先喂给大批次请求，单个请求排在后面，T_排队 迅速膨胀；LPU 的静态流水线让每个请求以固定节拍穿过五个站点，三段时间都近乎常数。

于是出现有趣的倒挂：论聚合吞吐（tokens/秒），GPU 在大 batch 下遥遥领先；论单请求延迟（毫秒/请求），LPU 在实时交互下完胜。批次越大 GPU 越划算，但交互场景凑不起大 batch——用户等不了别人一起生成，这正是 LPU 的用武之地。

宴会拼产出，堂食拼稳定。点单模式决定该选哪家厨房，而不是单纯看谁“快”——吞吐与延迟，从来是两个维度的指标。

编程开发体验

想在大排档掌勺，厨师得学几百道菜并懂得协作：什么时候抢单、什么时候让锅、怎么拼桌（共享显存），这是 CUDA 的心智模型。想给传送带排行程，你只需要画一张“有哪些站、按什么顺序、盘子怎么走”的路线图，细节时刻表交给师傅（编译器）去排。

GPU 编程用 CUDA/C++，开发者要管理 grid-block-thread 三级层次、同步与共享内存，还要主动做线程超量分配来隐藏访存延迟。这套模型对“并发控制”的要求极高，新手写出的 kernel 常常利用率惨淡——线程多了打架、少了饿肚子。LPU 编程更接近数据流：把模型画成算子图，由静态编译器映射到流水线站点并排出逐周期计划。开发者不用管线程、锁和调度，心智负担从“并发”转移到“数据流拓扑”。

代价是：任何结构改动都要重新编译，不可能像 GPU 那样在运行时灵动应变。超量比 R 这个指标能形象说明差异：GPU 鼓励你写 4 到 32 倍于核心数的线程来藏延迟，而在 LPU 的编程模型里，这个概念根本不存在。

大排档培养的是全能应变厨师，传送带要的是会画路线图的规划师。两套开发体验没有绝对好坏，只看你的团队更擅长“管理并发”还是“设计拓扑”。

能效资源利用

深夜没有客人时，大排档的厨师仍开着灯候场，调度器和一堆线程上下文也在偷偷耗电；传送带则只有盘子经过的站点在动作，没菜时皮带停转，能源一分不多花。这个画面，就是两者能效差异的缩影。

GPU 的功耗大头有四块：海量线程上下文、动态调度器、高带宽 HBM 显存的持续供电、以及负载不足时的执行单元空转。服务类负载往往长期处于中低利用率，此时大量核心闲着吃电，有效能效骤降。LPU 以 SRAM 为主要数据介质，数据供给路径短且确定，没有“为了隐藏延迟而空转”的浪费，单位功耗产出的 token 数在低并发场景显著占优。

数据中心账本上，能效 E 直接决定单 token 成本。GPU 在满载大 batch 时能效并不差，但真实推理服务的负载曲线像潮汐，波谷期的空转才是成本黑洞——这正是 LPU 撕开的口子。

煤气费账单很诚实：大排档高峰时摊薄成本划算，深夜只剩几个客人简直是烧钱；传送带无论流量宽窄，都能保持低成本运转。能效这笔账，要按负载曲线来算，而不是按峰值功率算。

应用场景选择

聪明的老板不会只开一种厨房：外卖平台高峰（高并发批量订单）交给大排档，高端堂食（实时交互）交给传送带，两种都做最赚钱。硬件选型也是同样的道理。

模型训练必须喂海量数据、做海量矩阵运算，而且不在乎单个 step 的延迟——这是 GPU 的天然主场；离线批量推理（摘要、分类、向量化）同样吞吐优先，GPU 性价比最高。反过来，实时对话、Agent 多轮工具调用、流式输出对首 token 延迟和稳定性极其敏感，用户等不了“凑一个大 batch 再一起算”，LPU 的确定性流水线正好命中这个需求。

现实中更常见的是混合部署：路由网关按延迟预算把交互流量导给 LPU 实例，把后台批量任务导给 GPU 实例。做决策时别只看采购价，要算总成本——延迟损失系数 β 越大（比如金融交易助手、医生问诊系统），越值得为低延迟硬件付费。

选厨房看客源结构，不看哪家厨师名气大。没有万能硬件，只有匹配场景的部署组合——训练、离线、实时，各回各家。

生态演进趋势

大排档的菜谱满街都是，任何厨师跟着学都能上手（CUDA 十几年沉淀的库、框架、教材）；传送带是祖传秘方，部件专用，学的人少但目标精准。技术生态的扩散就像一条 S 曲线：先慢热，再爆发，后饱和。

GPU 的护城河不只是硬件，更是 CUDA 生态——PyTorch、TensorFlow、vLLM、Triton 全部优先拥抱它，换硬件的迁移成本极高。LPU 的软件栈年轻但目标明确：专攻 LLM 推理的计算图编译与运行时，不做通用计算。更广的视野里，TPU、NPU 和各种专用加速器都在蚕食通用 GPU 的领地，AI 芯片进入“专用化浪潮”。

但竞争之外，融合已经开始：GPU 厂商不断优化推理侧的确定性调度与批处理策略，LPU 类芯片则逐步开放更多算子与可编程性。未来的 AI 芯片格局大概率不是“谁取代谁”，而是分工细化后的生态共存——就像餐厅最终都会同时拥有大排档和传送带。

新菜谱的流行也逃不过 S 曲线：第一家店门口排队（起步慢），被美食博主一推（爆发），最后满大街都是（饱和）。硬件胜负有时不在芯片本身，而在生态扩散的那条曲线走得有多陡。

AI 应用场景

Python 演示

import randomimport statistics def simulate_gpu(jobs, workers, arrival_interval):    """GPU 风格: 动态调度, 服务时间随机波动, 有空闲 worker 才派单"""    random.seed(42)    queue = []    busy_until = [0] * workers    origin = []    finish_time = []    t = 0    next_arrival = 0    done = 0    while done < jobs:        if next_arrival == t:            queue.append(t)            next_arrival += arrival_interval        for w in range(workers):            if busy_until[w] <= t and queue:                arrive = queue.pop(0)                service = random.randint(2, 8)                busy_until[w] = t + service                origin.append(arrive)                finish_time.append(t + service)                done += 1        t += 1    return [f - a for a, f in zip(origin, finish_time)] def simulate_lpu(jobs, stages, arrival_interval):    """LPU 风格: 静态流水线, 每周期整体前移一步, 无排队无抖动"""    pipeline = [None] * stages    origin = []    finish_time = []    t = 0    next_arrival = 0    done = 0    while done < jobs:        if next_arrival == t:            pipeline[0] = t            next_arrival += arrival_interval        if pipeline[-1] is not None:            origin.append(pipeline[-1])            finish_time.append(t)            pipeline[-1] = None            done += 1        for s in range(stages - 1, 0, -1):            pipeline[s] = pipeline[s - 1]        pipeline[0] = None        t += 1    return [f - a for a, f in zip(origin, finish_time)] def report(name, delays):    avg = statistics.mean(delays)    p99 = sorted(delays)[int(len(delays) * 0.99) - 1]    jitter = statistics.pstdev(delays)    print(f"{name}: 平均={avg:.1f}周期 p99={p99:.1f}周期 抖动={jitter:.1f}") if __name__ == "__main__":    gpu_delays = simulate_gpu(jobs=100, workers=4, arrival_interval=3)    lpu_delays = simulate_lpu(jobs=100, stages=5, arrival_interval=3)    report("GPU 动态调度", gpu_delays)    report("LPU 静态流水线", lpu_delays)

1. random.seed(42)固定随机种子，让对比实验可复现。
2. queue.append(t)请求先进入等待队列，模拟 GPU 的排队效应。
3. if busy_until[w] <= t and queue:有空闲 worker 才派单，对应动态调度。
4. service = random.randint(2, 8)服务时间随机波动，是 GPU 延迟抖动的根源。
5. pipeline = [None] * stages流水线固定 5 个站点，像传送带的五个工位。
6. if pipeline[-1] is not None:最末端有 token 就出货，每周期最多出一件。
7. pipeline[s] = pipeline[s - 1]所有站点整体前移一步，静态编排的铁律。
8. statistics.pstdev(delays)延迟标准差，运行后会发现 LPU 恒为 0 而 GPU 明显非零。

常见误区

面试题