想象你走进一座音乐厅。今晚演出的是贝多芬第五交响曲，听众席上有人窃窃私语，有人开始打哈欠，但台上的乐手们完全不受影响——无论什么时刻、无论观众如何变化，他们总在同一个拍点奏响同一个音符。演出结束时，你看了看表：74分30秒，和节目单上印的一分不差。这就是“确定性”。 现在换一个场景：你走进一家爵士酒吧，萨克斯手开始即兴solo。同一个曲子，昨晚演了9分钟，今晚可能演到12分钟，中间即兴的变化让你永远猜不到结尾。AI芯片的世界里，GPU就像这位即兴的爵士乐手——它的线程调度器在运行时动态决定谁先执行、谁后执行，于是延迟忽高忽低；而LPU（Language Processing Unit，语言处理单元，由[Groq公司](0)设计的AI推理芯片）则像这支训练有素的交响乐团——编译器在“上台”之前就把每一拍的乐谱排定，硬件只负责精准演奏。相同输入，永远产生完全相同的输出与执行时序。本文将带你从乐谱、乐手、指挥三个角度，拆解LPU确定性执行的秘密。

岗位关联

对AI从业者而言，理解确定性执行是掌握“延迟可预测”思维的关键——它能帮你从“祈祷GPU这次别卡顿”的被动调优，升级为“直接承诺P99延迟”的架构自信。

目录
  1. 可视化演示
  2. 确定性定义
  3. 硬件支撑
  4. 编译约束
  5. 延迟预测
  6. 应用价值
  7. 实践验证
  8. 权衡局限
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示LPU编译期静态调度时间线、GPU动态调度与LPU确定性执行延迟对比、多芯片plesiosynchronous同步机制。

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

编译期静态调度执行图 编译器预计算全部执行时序 每个操作精确到时钟周期 t = compile_time + n*cycle 消除运行时协调延迟

确定性定义

古典音乐会正进行到第三乐章，你注意到一件奇妙的事：小提琴手每一次弓弦落下的位置、双簧管每一次换气的瞬间，都精确镶嵌在同一个时间网格里。换成一支爵士乐队，同样的曲目，今晚的间奏是4拍，明晚可能是7拍——这就是“确定性”与“非确定性”的听觉差异，也是理解LPU的第一把钥匙。

在AI芯片领域，这种分野同样清晰。GPU的流处理器旁边坐着一个“即兴指挥”——硬件线程调度器，它在运行时动态决定数万个线程谁先上、谁后上。于是，即使输入完全相同的请求，GPU内部的执行顺序、缓存命中情况、访存等待时间都会不同，最终表现为推理延迟的随机波动。而LPU（语言处理单元）把“即兴权”全部没收：编译器在正式执行之前，就把所有指令的时间和位置排定完毕，硬件只需要照谱演奏。

数学上，“确定性”可以写成这样一个严格的条件：

就像观众无法让交响乐团某一段晚半拍开始，LPU的硬件也无法被任何运行时因素改变节奏。输出可复现、时序可复现，这两个翅膀合在一起，才支撑起“确定性”这只鸟的飞行。

∀x,(y1,t1)=Φ(x) ∧ (y2,t2)=Φ(x)⟹y1=y2 ∧ t1=t2\displaystyle \forall x,\quad (y_1,t_1)=\Phi(x)\ \wedge\ (y_2,t_2)=\Phi(x)\quad \Longrightarrow\quad y_1=y_2\ \wedge\ t_1=t_2
这个公式说的是：任意给定一个输入x，系统Φ执行两次，得到的输出y必须一样，耗时t也必须一样。只要有一条不满足，就不是确定性执行。
  1. ∀x对任意一个输入x，系统都遵循同样的行为规则，不存在“这次心情好就快一点”的特殊路径。
    ∀x\forall x
  2. Φ(x)=(y,t)执行系统Φ处理输入x，得到一个输出y，同时花费时间t。这里的t不仅指总耗时，还包含每个中间步骤发生的时刻。
    Φ(x)=(y,t)\Phi(x)=(y,t)
  3. 两次执行一致性无论执行多少次，输出与耗时都保持相同——这就是确定性。对LPU来说，y的确定性来自“同样的指令序列”，t的确定性来自“没有动态调度来打乱节奏”。
    y1=y2  ∧  t1=t2y_1=y_2 \;\wedge\; t_1=t_2

硬件支撑

为什么交响乐团能精确到毫秒？因为每个乐手各就各位，有自己的谱架、自己的乐器、自己的椅子——没有人需要跑到隔壁去借乐器，不存在“我的谱架被别人占了所以要等”这种意外。LPU的硬件设计遵循同样的哲学：每个处理单元（tile）都配备独立的SRAM（静态随机存取存储器），把“抢资源”从根源上消灭。

GPU延迟波动的元凶之一就是缓存。GPU的显存层次中有缓存，数据命中缓存则快如闪电，未命中则慢如蜗牛；再加上成百上千个线程争抢带宽，延迟自然忽高忽低。LPU干脆走了一条“去缓存化”的路：放弃依赖统一缓存和动态调度，改为在每个tile内部放置SRAM，数据在编译期就被分配到指定位置。所有tile在同一个全局时钟下同步工作，没有任何“等一等”的环节。

于是，端到端推理延迟可以被拆解为每一层计算时间与数据搬移时间之和，且每个分量都是编译期已知的常量：

每个tile的SRAM就像乐手的私人谱架——翻谱时间是固定的，谱架不会被人搬走。硬件把一切不确定性堵死在设计层面，确定性不是靠“运气”挣来的，而是靠“结构”保证的。

Ttotal=∑i=1n(CiPi+DiBi)\displaystyle T_{\text{total}} = \sum_{i=1}^{n} \left( \frac{C_i}{P_i} + \frac{D_i}{B_i} \right)
公式把一条推理链路切成一节节“乐句”，每一句要多久都能事先算清，加起来就是整首曲子的时长。
  1. T_total端到端推理延迟，即从输入进入芯片到输出离开芯片的总时间。
    TtotalT_{\text{total}}
  2. C_i/P_i第i层计算所需的时间。C_i是该层的计算量，P_i是该tile的峰值算力，两者相除得到纯计算耗时。由于算力恒定，这一项是常量。
    CiPi\frac{C_i}{P_i}
  3. D_i/B_i第i层数据搬移所需的时间。D_i是数据量，B_i是tile与SRAM之间的带宽。因为没有共享总线竞争，这一项也是常量。
    DiBi\frac{D_i}{B_i}
  4. 求和从第1层到第n层逐项累加，得到完全确定的总延迟。这在GPU上不可能成立——因为cache miss和动态调度让每一项的实际值都无法预知。
    ∑i=1n\sum_{i=1}^{n}

编译约束

乐谱是交响乐的灵魂。普通观众看到的是音符，但真正的总谱还规定了谁在哪个小节、哪一拍、用多大力道奏响哪个音——演奏的每个细节都在谱面上。LPU的编译器就是这位“总谱作者”：它在编译阶段完成全部调度决策，硬件运行时没有任何自主发挥的空间。

对比一下GPU：GPU的编译器只做粗略规划，真正的调度权在运行时硬件手中；而LPU的编译器拥有绝对权威——指令何时发射、数据放在哪个tile、数据何时搬移、tile之间如何通信，全部在编译期拍板。这就是“静态调度”（static scheduling）与“动态调度”（dynamic scheduling）的分水岭。

这种编译优化本质上是一个约束优化问题：在SRAM容量与硬件同步约束下，寻找总延迟最小的指令调度方案：

乐谱一旦定稿，乐团不会在演出中临时加花、即兴变奏。这正是确定性的来源，也是下一节要讲的“延迟可预测”的前提——因为时间表是提前写死的。

min⁡S  Ttotal(S)s.t.∀k,  Mk(S)≤MSRAM\displaystyle \min_{S} \; T_{\text{total}}(S) \quad \text{s.t.} \quad \forall k,\; M_k(S) \le M_{\text{SRAM}}
编译器像一位争分夺秒的编曲家，要在“所有乐器不打架”（资源不超限）的前提下，把整首曲子排到最短。
  1. min_S在所有可行的调度方案S中，找一个让总延迟最小的方案。
    min⁡S\min_{S}
  2. T_total(S)调度方案S对应的总推理延迟。不同的调度会让计算与搬移的重叠方式不同，延迟也不同。
    Ttotal(S)T_{\text{total}}(S)
  3. s.t.subject to的缩写，表示“受约束于”，后面是不容违背的硬性条件。
    s.t.\text{s.t.}
  4. M_k(S)≤M_SRAM在第k个时间步，所有tile的SRAM占用总和不能超过片上SRAM总容量。这是乐器的“排座约束”——每个tile都必须在自己的SRAM里放下当前的数据。
    ∀k,  Mk(S)≤MSRAM\forall k,\; M_k(S) \le M_{\text{SRAM}}

延迟预测

演出开始前，你问工作人员：“这场音乐会多久？”他能不假思索地回答：“74分30秒。”因为他手里有乐谱，每个音符的时长都能精确计算。AI推理想要这样的“精确预报”，就必须保证运行时的每一个环节都不失控。

LPU做到了这一点。由于没有动态调度、没有cache miss、没有共享总线竞争，对于固定模型和固定batch size，单次推理的延迟几乎就是一个常数。实测中，延迟分布极度集中：P50与P99几乎重合，方差小到可以忽略。这带来的推论是惊人的——系统吞吐量也可以精确预测。

如果用数学语言描述，单次推理延迟L可以写作一个“常量+极小微扰”：

当延迟变成一个“近似常数”，一切上层设计都变得简单：你可以直接说“这个模型推理就是3ms”，而不是“一般5ms，运气差时15ms”。这种确定性，是实时系统最珍贵的礼物。

L=L0+ε,ε∼U(0,δ),δ≪L0\displaystyle L = L_0 + \varepsilon, \quad \varepsilon \sim U(0,\delta), \quad \delta \ll L_0
延迟的主体是编译期就算好的L0，剩下的噪声ε小得可怜——就像交响乐团每次演出可能差出0.1秒，但绝不会差出10秒。
  1. L_0编译期根据指令时间表累加计算出的延迟基线，是“这场演出有多长”的官方答案。
    L0L_0
  2. ε物理层面的微小噪声，来自时钟抖动、温度漂移等非结构性因素，无法完全消除。
    ε\varepsilon
  3. U(0,δ)均匀分布，表示噪声落在0到δ之间——δ远小于L0，例如L0=3ms时δ可能只有0.05ms。这正是“确定性延迟”的含义：不是绝对零偏差，而是偏差小到可以忽略、可以预测。
    ε∼U(0,δ)\varepsilon \sim U(0,\delta)

应用价值

交响乐适合什么场合？不适合咖啡馆的慵懒下午——那里爵士乐更合适；但适合阅兵式、典礼、电影配乐现场——一切需要节拍精确对齐的场合。确定性延迟也是同样的逻辑：它不是万金油，而是特定场景下不可替代的“阅兵式乐团”。

第一个受益者是金融高频交易。交易系统的延迟每波动1ms，都可能让一笔套利成交价完全不同。在GPU上，你可能要按最坏情况预留10ms延迟预算；而在LPU上，你可以精确地告诉风控系统“信号到下单固定2ms”，把整个套利窗口设计得严丝合缝。

第二个受益者是自动驾驶。感知→规划→控制的链条上，每一个AI模型都有严格的时间预算。如果用GPU，缓存命中的运气好坏会直接转化为制动距离的波动；用LPU，工程师可以写下一行钢印式的注释：“本模型推理延迟恒定为4ms，安全裕度验证通过。”

第三个受益者是云服务商。当竞争对手还在承诺“P99延迟低于10ms”时，拥有LPU的云厂商可以喊出“延迟近似常数3.2ms”的独家SLA。整个控制环路的延迟预算可以拆解为：

阅兵式上，仪仗队的每一步都踩在拍点上；确定性延迟让AI系统也具备了“踩点行动”的能力——在高频交易席位上、在自动驾驶的决策回路里，每一次推理都如同一场编排精确的方阵行进。

Lbudget=LLPU+Lnet+Lact\displaystyle L_{\text{budget}} = L_{\text{LPU}} + L_{\text{net}} + L_{\text{act}}
  1. L_budget端到端控制环路的总延迟预算，例如从传感器采集到执行器动作的完整回路。
    LbudgetL_{\text{budget}}
  2. L_LPUAI推理芯片贡献的延迟，这一项被LPU压缩成常数，不再需要乘上3倍的安全系数。
    LLPUL_{\text{LPU}}
  3. L_net + L_act网络传输延迟与执行器响应延迟。这两项每一部分都可以独立测量并求和，整个预算不再依赖统计猜谜。
    Lnet+LactL_{\text{net}} + L_{\text{act}}

实践验证

乐谱写得再精美，听众最终听到的是现场。LPU的确定性执行在实际测试中表现如何？我们可以用一组公开基准与实测数据来检验。

Groq在Llama-2-70B等主流模型的推理测试中，采用逐token流式输出，LPU的每个token生成延迟几乎保持不变；而同级GPU在同一模型上的token延迟则明显波动。真正体现稳定性的指标不是平均值，而是延迟分布的形状——特别是它的“胖尾巴”有多长。工程上常用延迟变异系数（Coefficient of Variation, CV）来量化稳定程度：

在实际部署案例中，有量化基金用LPU替换GPU跑LSTM价格预测模型，端到端延迟从“波动2~15ms”变成“固定约2ms”，交易触发窗口从“猜”变成了“规划”。就像一位挑剔的乐评人每次听完演出都在笔记上写“与上次分毫不差”——LPU用实践的重复性证明了自己不是营销噱头。

CV=σlatencyμlatency\displaystyle \text{CV} = \frac{\sigma_{\text{latency}}}{\mu_{\text{latency}}}
  1. σ_latency延迟的标准差，衡量每一次推理耗时偏离平均值的程度。GPU上常有大规模离散，LPU上几乎为零。
    σlatency\sigma_{\text{latency}}
  2. μ_latency平均延迟，即多次推理耗时的算术平均。
    μlatency\mu_{\text{latency}}
  3. CV标准差除以平均值，得到一个无量纲的波动率。GPU的CV可能在0.3~0.5甚至更高，而LPU的CV通常在0.01量级——P99/P50比值接近1.0，意味着“最慢的一次”和“普通的一次”几乎一样快。
    σlatencyμlatency\frac{\sigma_{\text{latency}}}{\mu_{\text{latency}}}

权衡局限

交响乐的确定性也有代价：你不能在演出中途冲台上喊“来段即兴solo”，乐团只会礼貌地拒绝你。LPU同样如此——确定性是把所有自由度上交给编译器换来的，这份“契约”有它的隐性成本。

第一大局限是灵活性降低。模型结构一变（层数、注意力头数、分支变化），就必须重新编译；更糟的是，新模型可能无法高效映射到LPU的固定硬件拓扑上，导致利用率下降。第二大局限是编译时间增长。大型模型的静态调度空间巨大，编译器可能要跑上数小时才能找到最优时间表，这拖慢了“模型上线”的节奏。第三大局限是动态负载受限：运行中改变batch size、处理动态shape、计算稀疏不规则的图，都会破坏精心排定的时间表。

因此，架构选型时不能只看“确定性强不强”，还要看“确定性值不值”。可以用一个简单的收益成本比来辅助决策：

选择交响乐还是爵士，没有绝对的对错，只取决于你的舞台需要“可预测的稳定”还是“灵活的即兴”。LPU用确定性划定了自己的边界——边界之内，它是无可替代的精确；边界之外，它也需要舞台幕布后的其他伙伴。

Value=RpredCflex\displaystyle \mathrm{Value} = \frac{R_{\mathrm{pred}}}{C_{\mathrm{flex}}}
  1. R_pred延迟可预测带来的收益——SLA承诺空间、实时预算的确定性、系统论证的简洁性。
    RpredR_{\mathrm{pred}}
  2. C_flex灵活性丧失的成本——模型每次迭代的重编译开销、对新结构的适配风险、动态业务的支持损失。
    CflexC_{\mathrm{flex}}
  3. Value判断当模型固定、实时性极高时，Value远大于1，LPU是明智之选；当模型日更、负载形态多变时，Value骤降，GPU的“即兴”反而是优点。
    Value=RpredCflex\mathrm{Value} = \frac{R_{\mathrm{pred}}}{C_{\mathrm{flex}}}

AI 应用场景

量化交易信号触发系统

阶段：推理部署与延迟优化

解决的问题：传统GPU推理延迟分布长尾，最坏情况可达平均值的2~3倍，套利策略无法精确计算“信号出现到下单完成”的时间窗口，只能用保守的延迟预算换取安全，错失大量机会。

具体案例：某量化私募团队用Groq LPU部署LSTM价格预测模型，日交易信号数万次。GPU环境下P99延迟8ms（波动2~15ms），迫使交易系统预留15ms的等待窗口；切换到LPU后，延迟恒定在2ms（波动小于0.2ms），团队把触发窗口压缩到3ms，套利成功率和收益均显著提升。

自动驾驶实时感知链路

阶段：感知模型推理

解决的问题：自动驾驶中感知→规划→控制的每一毫秒都对应着车辆移动的距离。GPU上cache命中率的变化让推理延迟在3~9ms间随机波动，功能安全团队无法严格证明“紧急制动时间预算”是否总是充足。

具体案例：一家自动驾驶公司评估LPU部署BEV鸟瞰视角感知模型，发现端到端推理时间恒定在4ms，波动小于0.1ms。基于此，他们将安全论证从“统计置信区间”升级为“最坏情况即为典型情况”，紧急制动策略的时间预算得到严格数学证明，顺利通过了功能安全评审。

Python 演示

python54 行
import randomimport statistics  class DeterministicExecutor:    """模拟LPU确定性执行: 无动态调度, 延迟为编译期常量"""     def __init__(self, layers):        self.layers = layers        self.base_latency = sum(layers)     def infer(self, x):        return self.base_latency  class DynamicExecutor:    """模拟GPU动态调度: 每次推理延迟受运行时抖动影响"""     def __init__(self, layers, jitter=0.3):        self.layers = layers        self.jitter = jitter     def infer(self, x):        total = 0.0        for layer in self.layers:            total += layer * random.uniform(1.0 - self.jitter, 1.0 + self.jitter)        return total  def bench(executor, n=1000):    lats = [executor.infer(i) for i in range(n)]    mean = statistics.mean(lats)    std = statistics.pstdev(lats)    s = sorted(lats)    p50 = s[n // 2]    p99 = s[int(n * 0.99) - 1]    return {        "mean": round(mean, 4),        "std": round(std, 4),        "cv": round(std / mean, 4),        "p50": round(p50, 4),        "p99": round(p99, 4),        "p99_over_p50": round(p99 / p50, 4),    }  if __name__ == "__main__":    layers = [2.0, 3.0, 1.5, 2.5]    print("LPU deterministic:")    for k, v in bench(DeterministicExecutor(layers)).items():        print("  {} = {}".format(k, v))    print("GPU dynamic:")    for k, v in bench(DynamicExecutor(layers)).items():        print("  {} = {}".format(k, v))
目的：用两个模拟器分别代表LPU与GPU，各执行1000次推理并统计延迟分布指标，直观对比“确定性执行”与“动态调度”在波动率上的巨大差异。
  1. self.base_latency = sum(layers)编译期把各层耗时相加，得到固定延迟基线，对应LPU编译器的“总谱计算”
  2. total += layer * random.uniform(1.0 - self.jitter, 1.0 + self.jitter)每次推理给每层耗时加随机抖动，模拟GPU的调度波动与cache miss
  3. "cv": round(std / mean, 4)变异系数CV，衡量延迟离散程度；LPU的CV几乎为0，GPU则明显偏大
  4. p99 = s[int(n * 0.99) - 1]第99百分位延迟，代表“最倒霉的那次”要多慢；GPU的p99远高于p50
  5. "p99_over_p50": round(p99 / p50, 4)长尾比率，LPU接近1.0，GPU可能达到1.5以上

常见误区

误区LPU不用动态调度，是不是像老式CPU那样一条指令一条指令排队执行？那性能肯定很差吧？

正解LPU是高度并行的多核阵列，拥有数百个tile，确定性不等于串行。它像一支交响乐团：每个乐手同时演奏不同的声部，只是所有人都严格遵循同一份时间表。静态调度反而省去了运行时调度的决策开销，在规则计算场景中效率更高。

为何常见：把“无动态调度”误会成“无并行”，忽略了并行调度也可以是编译期静态排定的，就像流水线生产可以按节拍精确预排。

误区LPU延迟稳定又低，那它一定全方位碾压GPU，任何AI推理都应该选LPU。

正解确定性解决的是“可预测性”，不是“绝对速度”。对于某些不规则模型、稀疏计算或需要频繁变形的负载，GPU的灵活拓扑和成熟生态反而更快。而且模型一上线就定型还好，若频繁迭代，每次重编译的时间成本会抵消延迟收益。

为何常见：把“波动小”等同于“性能强”，看到厂商宣传的平稳延迟曲线就认为全面胜出，忽略了适用边界。

误区芯片运行中总有温度变化、时钟抖动，厂商说“确定性执行”只是拿美化过的数据做营销。

正解确定性是架构层面设计出来的：没有cache所以没有cache miss，没有动态调度所以没有排队抖动，没有共享总线竞争所以没有互相踩踏。剩下的微小噪声（如温度漂移）确实存在，但它可以小到统计上可忽略，且有第三方测试验证P99/P50接近1.0。

为何常见：长期使用GPU让工程师习惯了“延迟波动是物理定律”，实际上波动的大头来自架构的运行时决策，而非物理噪声。

误区GPU上batch size想改就改，LPU也应该支持运行中的动态batch变化。

正解batch size和输入shape都是编译期参数。一旦模型编译完成，运行时改变batch意味着破坏时间表，需要重新编译或在编译期提前准备多个配置。LPU适合“确定好形态然后长期稳定跑”的场景，不适合频繁变化的动态生产环境。

为何常见：以为“可预测延迟”意味着“任意输入都能精准预测”，忽略了输入形态本身是编译期固定约束的一部分。

面试题

Q1. 关于LPU确定性执行的核心含义，以下最准确的是？

单选题 · easy

  • A.相同输入得到相同时序输出← 正确答案
  • B.所有模型推理速度一致
  • C.推理性能必定超过GPU
  • D.支持动态形态无需重编译

答案：A。确定性执行指相同输入产生完全相同的输出与执行时序，A准确。B错在“所有模型”；C把确定性混同于性能；D恰恰相反，动态形态需要重编译。

Q2. GPU推理延迟波动的主要来源是？

单选题 · easy

  • A.编译器进行动态线程调度
  • B.运行时调度与缓存未命中← 正确答案
  • C.芯片温度过高导致降频
  • D.外部网络带宽存在瓶颈

答案：B。GPU的线程调度器在运行时动态分发warp，cache miss让访存延迟随机化，这两者共同造成延迟波动。编译发生在运行前，温度与网络属于次要或外部因素。

Q3. LPU“去缓存化设计”最准确的描述是？

单选题 · easy

  • A.将数据全部放入外部DRAM
  • B.用分布式SRAM替代缓存← 正确答案
  • C.芯片不需要任何片上存储
  • D.保留更小更快的一级缓存

答案：B。LPU在每个tile内放置独立SRAM，用分布式静态存储替代传统的统一缓存层次，从而消除cache miss带来的访存时间不确定性。

Q4. LPU延迟能做到微秒级可预测的根本原因是？

单选题 · mid

  • A.晶体管工艺更加先进
  • B.编译期排定全部指令← 正确答案
  • C.模型规模足够小
  • D.网络延迟已经被消除

答案：B。所有指令的发射时间、数据位置、通信时机都在编译期排定，运行期无任何动态决策，因此每个时间分量都是常量，求和即得精确延迟。

Q5. 下列哪类场景最适合LPU的确定性执行？

单选题 · mid

  • A.固定模型的高频交易推理← 正确答案
  • B.频繁迭代的推荐模型训练
  • C.动态形态的自然语言对话
  • D.稀疏不规则的科学计算

答案：A。模型固定、实时性要求高正是确定性执行的最佳舞台。训练与动态形态需要灵活性重编译代价高，稀疏不规则计算难以映射到静态时间表。

Q6. LPU与GPU在调度策略上的本质区别是？

单选题 · mid

  • A.LPU动态调度而GPU静态调度
  • B.LPU无调度器GPU为动态调度
  • C.LPU静态调度与GPU动态调度← 正确答案
  • D.两者都依赖硬件调度器

答案：C。LPU由编译器在编译期完成全部静态调度决策；GPU保留运行时动态调度器，根据现场情况分发线程。C准确对应用“乐谱排练”与“即兴发挥”的差异。

Q7. 若某推理系统的CV=0.01且P99/P50≈1.0，可以推断该系统？

单选题 · hard

  • A.延迟存在明显长尾效应
  • B.延迟高度稳定接近确定性← 正确答案
  • C.推理吞吐量波动极其剧烈
  • D.系统必须使用GPU完成推理

答案：B。CV小、P99与P50接近，说明延迟分布极度集中、没有长尾，这是确定性执行的典型标志。吞吐量也随之稳定可预测，且与GPU无必然关系。

Q8. 关于LPU的编译约束，以下说法正确的有哪些？

多选题 · mid

  • A.编译器拥有全部调度决策权← 正确答案
  • B.模型结构变化需重新编译← 正确答案
  • C.运行时可动态调整线程分配
  • D.资源分配在编译期显式完成← 正确答案

答案：ABD。LPU将指令调度、内存分配、通信安排全部前移到编译期，运行时不改方案；模型结构一变就必须重编译。C是GPU的动态调度特征，与LPU相反。

Q9. LPU确定性执行带来的实际价值包括？

多选题 · hard

  • A.延迟分布长尾显著改善← 正确答案
  • B.云服务可承诺更紧SLA← 正确答案
  • C.任意模型免编译即可运行
  • D.实时系统按固定预算设计← 正确答案

答案：ABD。确定性压缩延迟方差，P99接近P50，云厂商可承诺更低更可靠的SLA；实时系统可按固定延迟预算进行数学级验证。C错误，LPU必须编译后才能运行。

Q10. 关于LPU确定性与性能的关系，以下论述正确的有哪些？

多选题 · extreme

  • A.确定性解决可预测性而非绝对性能← 正确答案
  • B.模型频繁迭代时确定性收益减弱← 正确答案
  • C.GPU抖动完全由缓存未命中引起
  • D.LPU适合静态高实时场景← 正确答案

答案：ABD。确定性是“可预测性”的架构成就，不是泛化的性能第一；重编译成本让频繁迭代场景收益下降；GPU抖动是调度+缓存等多因素叠加，C过于绝对；静态高实时场景正是LPU最擅长的舞台。