想象这样一个早晨：你要赶飞机，面前有两个选择。出租车随叫随到，听着很灵活，可你永远不知道路上会不会堵车，会不会因为红绿灯、施工或前面那辆开得歪歪扭扭的电动车而迟到。高铁则不同，它按精确到秒的时刻表运行，14:03 到就是 14:03 到，你心里有底。今天的主题 Groq LPU，就是大模型推理世界里那列“高铁”——它不干别的，只跑“语言推理”这一条线，却因此能把时间控制得分毫不差。 GPU 是那个“万能出租车”，什么活都能接，但每次执行任务都可能因为“路况”（缓存未命中、动态调度冲突）而忽快忽慢。Groq 公司却认为，大模型推理是一条每天要走无数遍的固定线路，与其依赖“出租车”的运气，不如专门修一条铁路、造一列高铁。LPU（Language Processing Unit，语言处理单元）由此诞生。它用确定性时序保证每个 token 的生成时间像时刻表一样稳定，用 TSP 张量流处理器让数据像乘客一般在车厢间流动，最终在 Llama 2 70B 上跑出了单卡 700 token/s 的惊人速度。

岗位关联

理解 LPU 的确定性时序与 TSP 架构，能帮你穿透“算力大、显存多”的表层选型逻辑，看清 AI 推理硬件的性能本质——这在做模型部署方案和系统级面试时，都是极具差异化的认知优势。

目录
  1. 可视化演示
  2. LPU 概述：专修一条“语言高铁”
  3. 确定性时序：比瑞士手表还准
  4. TSP 架构：乘客在车厢间流动
  5. 性能表现：700 token/s 的震撼
  6. 编译器协同：幕后编制时刻表的总师
  7. 市场定位：高铁不是万能的
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示Groq LPU三维度：TSP架构（MXM矩阵乘/SXM交换/VXM向量/MEM存储功能单元列+230MB片上SRAM无HBM数据流驱动执行）、确定性时序（编译器预调度每时钟周期零分支预测无缓存未命中P99延迟等于平均延迟）、推理性能（单卡Llama 2 70B 700token/s对比单卡H100约100token/s需8卡才达600token/s），三模式切换理解新型推理硬件架构。

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

'+C1+'

LPU 概述：专修一条“语言高铁”

每天开车走同一条路去上班，却被红绿灯和堵车折磨得心烦意乱——Groq 的工程师们受够了这种“不确定性”。他们的解决方案不是换一辆更好的出租车，而是直接修一条专属铁路：取消路口、取消红绿灯、取消一切可能干扰速度的变量，让“语言推理”这趟列车沿着固定轨道飞奔。这就是 LPU（Language Processing Unit）诞生的初衷：它是为语言模型推理专门设计的处理器，而不是另一个通用加速器。

GPU 从诞生起就走着“出租车”路线：什么计算任务都能接，渲染图形、科学计算、深度学习训练、推理……样样都行。但“万能”也意味着“无法为任何一条路做极致优化”。Groq 的创始团队来自 Google TPU 项目，他们深知专用芯片的威力，于是把“语言推理”磨成了这趟车的唯一使命。LPU 不承担训练任务，也不管图形渲染，它只做一件事——让大模型生成 token 的速度快到令人咋舌。

为了衡量这种“专线”相比“出租车”的收益，我们定义加速比：

如果说 GPU 是一辆在城市里见缝插针的出租车，那么 LPU 就是那个“我不接散客，只跑一条线”的高铁。这种取舍让它在自己的领地上一骑绝尘，也注定了它无法像出租车一样招之即来——这正是理解 LPU 所有设计决策的起点。

加速比=TGPU,平均TLPU,恒定\displaystyle \text{加速比} = \frac{T_{\text{GPU,平均}}}{T_{\text{LPU,恒定}}}
  1. GPU 平均耗时GPU 上生成一个 token 的平均时间，受缓存、调度等“路况”影响而忽高忽低
    TGPU,平均\displaystyle T_{\text{GPU,平均}}
  2. LPU 恒定耗时LPU 上每生成一个 token 的时间，在编译期就已被“时刻表”锁定，执行时绝不改变
    TLPU,恒定\displaystyle T_{\text{LPU,恒定}}
  3. 加速比计算当 LPU 的恒定延迟低于 GPU 的平均延迟时，比值大于 1，表示专线比出租车更快
    TGPU,平均TLPU,恒定>1\displaystyle \frac{T_{\text{GPU,平均}}}{T_{\text{LPU,恒定}}} > 1

确定性时序：比瑞士手表还准

高铁敢把到站时间精确到秒，靠的不是司机车技好，而是整条线路没有红绿灯、没有逆行车辆、没有突发路况。LPU 的设计师在做同样的事：把“路况”从系统中全部删除。传统处理器运行时充满不确定性——缓存是否命中要看运气，分支预测可能猜错，内存带宽可能被抢占。LPU 则把这些变量统统拿到编译期解决，让硬件在运行时只需“看表执行”。

这种设计理念被称为确定性时序（Deterministic Timing）。在 LPU 中，每条指令的执行时刻、每个数据在 SRAM 中的地址、每次核心间的通信时机，都在编译阶段被精确安排。硬件运行时不需要做任何动态决策，因此它永远不会出现“缓存未命中的停顿”，也永远不会因为调度器的临时决定而拖延。每个 token 的生成延迟都像高铁时刻表一样精准。

如果模型要生成一整段回答，解码阶段的总耗时就是一个简单的乘法：

想象你坐出租车赶飞机，司机说“大概 40 分钟到”，结果堵在桥上 20 分钟；而坐高铁，时刻表写 14:03 到，14:03 你就站在站台上了。确定性时序带来的不仅是快，更是“可预期”——这对需要稳定响应时间的生产级 AI 服务来说，比偶尔的爆发速度珍贵得多。

Tdecode=Ntoken×Tstep\displaystyle T_{\text{decode}} = N_{\text{token}} \times T_{\text{step}}
  1. 解码总时长模型从吐出第一个 token 到最后一个 token 的总时间，就像整趟高铁从始发站到终点站的耗时
    Tdecode\displaystyle T_{\text{decode}}
  2. Token 数量回答中包含的 token 总数，相当于这趟车要停靠的站数
    Ntoken\displaystyle N_{\text{token}}
  3. 单步固定时延每生成一个 token 的耗时，在 LPU 上是一个编译期确定的常量，绝不抖动
    Tstep=常量\displaystyle T_{\text{step}} = \text{常量}

TSP 架构：乘客在车厢间流动

高铁车厢里的乘客不需要每到一个站就下车跑到行李仓库取箱子再上车——行李随人走，车厢与车厢之间畅通无阻。LPU 的 TSP（Tensor Streaming Processor，张量流处理器）正是按这个思路设计的。传统 GPU 中，数据要反复往返于“仓库”（HBM 显存）和“车间”（计算核心）之间，每次搬运都是一笔巨大的时间开销。而 TSP 让数据像乘客一样，在核心与核心之间的专用通道里连续流动，算完一层就直接推给下一层。

TSP 架构的核心是一张由大量计算核心组成的阵列，核心之间用高带宽直连网络互联。每个核心自带一块 SRAM，像乘客随身携带的行李——权重和中间激活值就放在手边，不需要去远处的大仓库取。这种“流式处理”让数据搬运次数大幅减少，也让执行节奏变得像流水线一样稳定可预测。LPU 甚至不使用 HBM 大容量显存，而是用分布式的 SRAM 加上精心设计的数据流，解决了大模型推理最头疼的带宽瓶颈。

数据穿过整个核心阵列的延迟可以用一个简单的模型描述：

如果说 GPU 的架构是“工人频繁去远处仓库搬料”，那 TSP 就是“物料在传送带上自动流到每个工位前”。这种“乘客不下车”的智慧，让 LPU 在同样的功耗下跑出了远超 GPU 的推理吞吐——因为省掉的时间，大半都省在了“来回取行李”的路上。

Tflow=N层×T单核\displaystyle T_{\text{flow}} = N_{\text{层}} \times T_{\text{单核}}
  1. 数据流总延迟一批数据从进入核心阵列到完成全部计算并输出的总时间，就像乘客从车头走到车尾
    Tflow\displaystyle T_{\text{flow}}
  2. 串行层数计算过程中数据必须依次经过的核心层数，相当于列车经过的车厢节数
    N层\displaystyle N_{\text{层}}
  3. 单核节拍每个核心处理一批数据所需的固定时间，因为这个值是确定的，整个流水线的节奏也就确定了
    T单核\displaystyle T_{\text{单核}}

性能表现：700 token/s 的震撼

一列高铁跑完一趟全程的时间是固定的，每天发多少班、运多少人，都可以精确计算。LPU 的“运力”用 token/s 来衡量——每秒生成多少个 token。Llama 2 70B 是 Meta 发布的 700 亿参数大模型，通常需要多张高端 GPU 才能流畅推理。而 Groq 仅在单张 LPU 卡上，就跑出了 700 token/s 的惊人速度。

这个数字意味着什么？每生成一个 token 只需约 1.4 毫秒。作为对比，一个成年人快速阅读的速度大约是每秒 5 到 8 个字，而一个英文 token 大约相当于不到一个单词。LPU 每秒吐出的单词量，比人眼能阅读的速度还快一个数量级。当你在聊天框里打字时，那边的模型已经在“涌”出回答了——不是挤牙膏，而是开闸放水。更关键的是，这 700 token/s 是在确定性时序下稳定输出的，不会突然卡顿一下再继续。

把“每秒 700 个 token”这个结果翻译成数学语言：

你用手机打字时，输入法偶尔会卡一下再蹦出候选词，那种“忽快忽慢”在实时对话中非常出戏。LPU 的 700 token/s 是“全程匀速 350 公里每小时”的高铁体验——每个字都稳稳当当地冒出来，既没有让人着急的停顿，也没有突然的爆发，这种稳定感本身就是性能的一部分。

R=1Tstep\displaystyle R = \frac{1}{T_{\text{step}}}
  1. 生成速率每秒能生成的 token 数，即模型的“运力”，单位是 token/s
    R\displaystyle R
  2. 单步时延LPU 上每生成一个 token 的固定时间，这里是 0.0014 秒，也就是 1.4 毫秒
    Tstep=0.0014 s\displaystyle T_{\text{step}} = 0.0014\,\text{s}
  3. 速率计算用 1 秒除以单步时延，就得到每秒生成的 token 数
    R=10.0014≈700\displaystyle R = \frac{1}{0.0014} \approx 700

编译器协同：幕后编制时刻表的总师

高铁能准点到站，真正的功臣不是车头，而是调度中心——它提前几个月把每条线路的列车运行图编排得严丝合缝。LPU 的“调度中心”就是它的编译器。拿到模型的计算图后，编译器会把每个算子的执行时间、每个权重张量的存放位置、每两个核心之间的数据通信时机，全部安排妥当，生成一张精确到时钟周期的“运行图”。

这正是 LPU 与 GPU 最深刻的区别。GPU 的软件栈（如 CUDA）允许运行时动态调度：内核按需启动，缓存按需替换，一切都在“实时决策”。LPU 的编译器走的是静态调度路线：所有内存分配、核心分配、通信规划全部在编译期完成，生成的指令序列就是一张不可变更的时刻表。硬件在运行时不需要做任何选择，只需要按部就班地执行。这也是“确定性时序”能成立的根本原因——软件把自己的自由裁量权全部收走了。

要把一次完整的推理总耗时算清楚，可以拆成两个阶段：

如果没有列车运行图，再多的高铁也会在站台上撞成一团；如果没有编译器，LPU 的硬件就只是一堆不知道该何时动作的核心。Groq 的编译器不是“辅助工具”，而是整个系统的大脑——它把灵活性让渡给确定性，用前期的精心规划换取了运行时的极致稳定。

Ttotal=Tprefill+Ndecode×Tstep\displaystyle T_{\text{total}} = T_{\text{prefill}} + N_{\text{decode}} \times T_{\text{step}}
  1. 预填充时间处理用户输入提示词的时间，相当于高铁加速离站的阶段，通常只占很小比重
    Tprefill\displaystyle T_{\text{prefill}}
  2. 解码步数需要逐字生成的 token 个数，这是列车的“长途站段”
    Ndecode\displaystyle N_{\text{decode}}
  3. 单步固定时间每个解码步的确定耗时，由编译器的时刻表提前锁定
    Tstep\displaystyle T_{\text{step}}

市场定位：高铁不是万能的

高铁再快，也没法开到你家小区楼下；LPU 也一样，它不会出现在图形渲染、通用计算或大模型训练的场景中。Groq 很清楚这一点：GPU 统治着训练和通用 AI 计算的广袤市场，而推理——尤其是大语言模型的实时推理——正是一片高速公路般开阔的蓝海。LPU 选择在这条路上做到极致。

不过，这条“专线”也面临现实挑战。其一，SRAM 容量有限，万亿参数级别的超大模型需要跨卡协同甚至配合外部存储，这不免削弱确定性优势。其二，软件生态与 CUDA 相差悬殊，开发者早已习惯了用 PyTorch 加 CUDA 一条龙部署，迁移到 LPU 意味着要接受一套全新的编译工具链。其三，Groq 作为创业公司，在芯片产能和市场声量上都难以与英伟达正面抗衡。但换个角度看，当每家公司都在为模型推理成本发愁时，LPU 用 700 token/s 单卡性能证明了“专线方案”的价值。

从成本角度，部署什么样的硬件可以用单 token 成本来衡量：

高铁没有取代出租车，LPU 也不会取代 GPU。真正理性的市场选择，是让出租车留在它擅长的城市巷道，让高铁驰骋在固定干线。Groq 的这场豪赌启示我们：在 AI 硬件的世界里，做“窄而深”的专线，有时比做“宽而普”的路线更有爆发力。

Costtoken=C硬件+C能耗R×U\displaystyle \text{Cost}_{\text{token}} = \frac{C_{\text{硬件}} + C_{\text{能耗}}}{R \times U}
  1. 硬件成本单卡采购成本摊销到运行时长，高铁的“车身折旧”
    C硬件\displaystyle C_{\text{硬件}}
  2. 能耗成本单位时间消耗的电费，高铁比一堆小轿车编队更省能源
    C能耗\displaystyle C_{\text{能耗}}
  3. 有效产出token 生成速率乘以硬件利用率，即“跑起来的运力”才是有效的
    R×U\displaystyle R \times U

AI 应用场景

场景一：流式对话机器人的极致体验

阶段：推理部署

解决的问题：传统 GPU 推理虽然平均速度尚可，但 token 生成时间忽快忽慢，用户端表现为“打字机”一顿一顿的，严重影响实时对话的沉浸感。LPU 的确定性时序让每个 token 以恒定节奏流出。

具体案例：某电商客服团队接入 Groq 云服务后，原来需要 6 秒才能完整输出的 300 字回复，现在 1.5 秒内以均匀节奏播完，用户的“等待焦虑”明显降低，人工转接率下降 12%。

场景二：推理硬件选型的 TCO 决策

阶段：硬件选型与成本评估

解决的问题：面对 GPU、LPU 等多种推理硬件，传统评估只看“峰值算力”，忽略了延迟抖动和利用率对真实吞吐的影响。LPU 的确定性执行让性能可精确预估，方便做单位 token 成本核算。

具体案例：一家 AI 写作 SaaS 公司按公式（硬件成本 + 能耗成本）/（token 速率 × 利用率）对比多种方案，发现 LPU 在长文本生成的稳态场景下单位 token 成本比旗舰 GPU 低 35%，从而决定为生成服务单独部署 LPU 集群。

场景三：编译器静态时序分析的方法论迁移

阶段：系统软件设计

解决的问题：传统编译器把运行时决策留给硬件，导致关键路径延迟不可控。LPU 的编译器示范了一种“编译期全覆盖”的思路：把每个操作的时间建模为常量，提前完成全局调度。

具体案例：一家自研 AI 芯片的创业公司借鉴 Groq 编译器方案，在自家工具链中加入静态时序标注：每个算子的执行时间在编译时确定，运行时调度器退化为纯执行器，最终让模型推理延迟方差从 18% 降到 3%。

Python 演示

python42 行
import random  class ScheduleSimulator:    """比较动态调度与确定性调度的 token 生成节奏差异. """     def __init__(self, step_ms=1.4):        self.step_ms = step_ms        self.dynamic_times = []  # 出租车模式:延迟抖动        self.fixed_times = []    # 高铁模式:恒定延迟     def run_dynamic(self, jitter_ms=1.2):        """模拟 GPU 风格的一次 token 生成,耗时在基础值上随机加塞. """        latency = self.step_ms + random.uniform(0, jitter_ms)        self.dynamic_times.append(latency)        return self.dynamic_times[-1]     def run_fixed(self):        """模拟 LPU 风格的一次 token 生成,耗时严格等于基础值. """        self.fixed_times.append(self.step_ms)        return self.fixed_times[-1]     def compare(self, trials=120):        """各跑 trials 次,输出平均耗时、抖动与总耗时. """        for _ in range(trials):            self.run_dynamic()            self.run_fixed()        dyn_avg = sum(self.dynamic_times) / trials        dyn_std = (sum((t - dyn_avg) ** 2 for t in self.dynamic_times) / trials) ** 0.5        fixed_avg = sum(self.fixed_times) / trials        print("动态调度: 平均 %.2fms, 抖动 %.3fms, 总耗时 %.1fms" %              (dyn_avg, dyn_std, sum(self.dynamic_times)))        print("确定性调度: 平均 %.2fms, 抖动 0.000ms, 总耗时 %.1fms" %              (fixed_avg, sum(self.fixed_times)))        return dyn_std, sum(self.dynamic_times), sum(self.fixed_times)  if __name__ == "__main__":    sim = ScheduleSimulator()    dyn_std, dyn_total, fix_total = sim.compare()    gap = (dyn_total - fix_total) / dyn_total * 100    print("确定性调度总耗时比动态调度减少 %.1f%%" % gap)
目的：用简单的随机模拟展示 GPU 式动态调度与 LPU 式确定性调度的核心差异——抖动和总耗时的对比。
  1. class ScheduleSimulator:定义调度模拟器，类比两家“列车运营公司”共用同一套测试标准。
  2. self.dynamic_times.append(latency)记录动态模式每次耗时，出租车式延迟会随机“加塞”变慢。
  3. self.fixed_times.append(self.step_ms)高铁模式永远准点，每次耗时都严格等于 1.4ms。
  4. dyn_std = (...)**0.5计算标准差，用来量化“时间不靠谱程度”，抖动越小越接近确定性时序。
  5. if __name__ == "__main__":程序入口，跑一次对比实验并打印总耗时差距。

常见误区

误区很多人看到 700 token/s 的新闻，第一反应是“这不就是比 GPU 更快的显卡吗？那以后所有深度学习任务都该用 LPU”。

正解LPU 是专用处理器，像高铁不能随意改道去接乘客。它只对符合静态调度模型的 LLM 推理场景有优势，训练、卷积网络、图形渲染等任务在 LPU 上既无法运行，也不会有性能优势。它的“快”建立在软硬件深度协同和场景专一之上。

为何常见：媒体传播时习惯用“性能猛兽”这类标签，模糊了“通用”与“专用”的架构差异，让人误以为 LPU 只是 GPU 的升级版。

误区“确定性时序嘛，就是编译器优化做得好，把指令排得整齐，这不算架构革命吧。”

正解确定性时序不是某个优化技巧，而是从硬件层面删除了所有运行时决策机制：没有动态调度器、没有缓存未命中补偿、没有分支预测。编译器在编译期完成所有安排后，硬件只是一个精确执行指令的“机械钟表”。换一台机器或者换一个框架，这套确定性就会失效。

为何常见：习惯用 CPU/GPU 的“运行时优化”思维去理解新架构，低估了“软硬件共同设计”的深度。

误区“LPU 用 SRAM 代替 HBM，本质不就是把缓存做大，减少内存访问吗？”

正解TSP 的精髓在于“流”：数据像传送带上的零件一样在核心间流动，每个核心顺手完成自己那段计算后直接推给下一个核心。这不仅仅是“缓存更大”，而是彻底改变了数据搬运的方式。即便 SRAM 总量不大，只要数据流编排得当，也能实现极高吞吐。

为何常见：缓存是计算机体系结构中最常被提及的概念，人容易用旧框架去套新架构，忽略“数据流”这一层本质变化。

误区“LPU 既然能跑 700 token/s，那我换个大点的模型应该也差不多吧？”

正解700 token/s 是在 Llama 2 70B 上得到的特定成绩，不同模型参数量、架构、输入长度、batch size 都会显著影响实际速率。模型越大、单 batch 推理越复杂，LPU 也需要更多核心协同，速度会相应下降。时刻表再精确，也得看列车编组有多长。

为何常见：单点指标被放大成普遍结论，这是“锚定效应”在作祟——一个醒目的数字容易盖过其他约束条件。

误区“LPU 推理这么快，以后 GPU 就该被淘汰了吧？”

正解GPU 在模型训练、通用加速、图形渲染等领域仍然不可撼动；LPU 只是在大模型推理这个垂直场景里抢到一块地盘。生态壁垒（CUDA 的开发者资产）、SRAM 容量限制、创业公司的供应链短板，都让 LPU 无法“通吃”。高铁再方便，城里短途还是得靠出租车。

为何常见：人们总喜欢“新王取代旧王”的叙事，但真实技术市场往往是“各守一摊”的分工格局。

面试题

Q1. LPU 的全称是什么？

单选题 · easy

  • A.Language Processing Unit← 正确答案
  • B.Large Parallel Unit
  • C.Logic Processing Unit
  • D.Linear Performance Unit

答案：A。LPU 是 Language Processing Unit 的缩写，意为“语言处理单元”。它专为语言模型的推理计算设计，不是通用并行处理器。

Q2. LPU 与传统 GPU 最根本的设计理念差异是什么？

单选题 · easy

  • A.显存容量更大
  • B.采用确定性时序执行← 正确答案
  • C.核心主频更高
  • D.支持更多编程语言

答案：B。确定性时序是 LPU 的灵魂：所有操作在编译期排定执行时刻，运行时不做动态决策。这与 GPU 依赖运行时调度形成鲜明对比。

Q3. 以下关于 TSP 架构的描述，正确的是哪一项？

单选题 · mid

  • A.数据频繁往返于外部内存
  • B.数据在核心间直连流动← 正确答案
  • C.完全依赖 HBM 大容量缓存
  • D.由操作系统实时调度任务

答案：B。TSP 是张量流处理器，数据像高铁乘客一样在核心阵列间流动，每个核心算完直接推给下一个，避免反复去外存取数。

Q4. 确定性时序带来的直接好处有哪些？

多选题 · mid

  • A.延迟可精确预测← 正确答案
  • B.能耗分布更平稳← 正确答案
  • C.分支预测准确率提高
  • D.编译器无需做任何优化

答案：AB。由于运行时没有动态决策，每个 token 的延迟恒定，系统能耗因此平稳。C 和 D 与确定性时序无关：LPU 干脆不做分支预测，编译器恰恰要做极大量的静态编排。

Q5. Llama 2 70B 在 Groq 单张 LPU 卡上的推理速度约为多少？

单选题 · mid

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

答案：C。Groq 公开演示的指标是单卡 700 token/s。这是 700 亿参数模型在专门推理芯片上跑出的惊人成绩，比常规 GPU 部署方案快数倍。

Q6. 若 LPU 每生成一个 token 耗时为 1.4ms，则每秒约生成多少个 token？

单选题 · mid

  • A.70 个
  • B.700 个← 正确答案
  • C.7000 个
  • D.140 个

答案：B。用 1 秒除以 0.0014 秒，得到约 714，约等于每分钟 700 个 token。速率与单步时延互为倒数，这正是确定性时序下吞吐量的简单估算。

Q7. LPU 实现确定性时序依赖以下哪些条件？

多选题 · hard

  • A.编译器静态调度全部指令← 正确答案
  • B.硬件放弃运行时决策机制← 正确答案
  • C.使用大型共享缓存吸收冲突
  • D.运行时关闭动态路由← 正确答案

答案：ABD。LPU 在编译期把所有调度做死，硬件不参与动态决策，运行时也不存在按需路由的路径选择。共享缓存是 GPU 的思路，与其存储冲突不同，LPU 依靠的是数据流式规划和 SRAM 静态布局。

Q8. Groq LPU 在市场中的定位主要是什么？

单选题 · easy

  • A.全面替代 GPU 训练集群
  • B.专注大模型推理场景← 正确答案
  • C.用于图形渲染加速
  • D.只服务小规模嵌入设备

答案：B。LPU 瞄准的是 LLM 推理市场，用确定性时序和 TSP 架构解决推理延迟问题，不涉足训练和图形渲染。

Q9. 相比 GPU，LPU 目前存在哪些明显短板？

多选题 · mid

  • A.软件生态薄弱← 正确答案
  • B.无法处理大模型
  • C.SRAM 容量受限← 正确答案
  • D.功耗高不可控

答案：AC。LPU 的软件工具链远不如 CUDA 生态成熟，SRAM 容量有限也是多卡扩展的瓶颈。它并非不能处理大模型（单卡已跑 70B），其确定性时序反而让功耗可控。

Q10. “编译期把所有事情定下来，运行时只按表执行”，这最贴近以下哪个生活比喻？

单选题 · hard

  • A.出租车根据实时路况选路
  • B.高铁按预先编制的时刻表运行← 正确答案
  • C.公交车排队依次进站
  • D.快递员按门牌号逐户派送

答案：B。高铁的时刻表由调度中心提前全局编排，司机只需按表驾驶，不临时变道。这精准映射了 LPU 编译器静态调度、硬件无决策执行的设计哲学。