RELAY IR：RELAY VM虚拟机

可视化演示

展示RELAY VM虚拟机三维度：编译执行流程（Relay AST经类型检查和变换Pass后生成字节码由VM解释器逐条分派执行指令包括Alloc Load Call If Ret等）、VM与图执行器对比（VM支持控制流动态形状ADT递归表达力强但解释开销大图执行器静态拓扑序执行内存复用优调度效率高但不支持运行时分支）、控制流与ADT支持（If指令实现条件分支cond为假跳转else配合Goto实现互斥执行AllocADT分配实例含tag和字段GetTag GetField实现模式匹配），三模式切换理解RELAY VM核心机制。

字节码设计

中央厨房拿到一本新菜谱，第一步不是直接下锅，而是把菜谱拆成一沓标准化便签：每张便签固定写“热油”“下葱”“放盐”，用最简短的记号承载一个动作。RELAY VM 做的正是这件事——它把高层 RELAY IR 这本“菜谱”翻译成一串紧凑的字节码（Bytecode）。字节码是 VM 的“便签纸语言”，每条指令由操作码（opcode）和操作数（operand）两部分构成：操作码是动作记号，操作数指明动作的对象。

为什么要绕这么一道弯，而不是直接执行 IR？因为 IR 是嵌套的树形结构，像一本带图表和批注的菜谱，翻起来费劲；而字节码是拉直的、线性的指令列表，VM 像只认记号的厨师，逐张便签照做即可。RELAY VM 会在编译阶段把 IR 的每个节点映射为一条或若干条指令，最终交付一段紧凑的指令序列。运行时，表驱动解码器把操作码当作索引，从一张函数表里找到对应的处理逻辑。

这套设计的关键收益是统一：不管前端把模型表达成什么样的 IR，到了 VM 这里都被收拢成同一种线性格式，便于检查、便于序列化，也让执行器的实现与具体模型结构解耦。

就这样，整本复杂的菜谱被摊成一张张统一格式的便签，现场厨师不识字也能照卡出菜。字节码的“标准化”正是 RELAY VM 一切灵活性的地基。

虚拟寄存器

厨师手边有一排编号小碗：3 号碗放葱花，5 号碗放酱汁。指令里写“把 3 号碗的葱花倒进 5 号锅”，全靠编号定位，手一伸就够到。RELAY VM 的虚拟寄存器（Virtual Register）就是这些编号碗——一块连续的数组，用来存放模型推理过程中的中间结果，通常是张量。每条字节码指令通过寄存器编号读取数据、计算结果，再写回另一个编号的寄存器。

有了这排编号碗，指令就变得非常扁平。比如一条乘法指令，只需写明“从几号碗取左操作数、从几号碗取右操作数、结果放进几号碗”，不需要像 IR 那样嵌套地表达计算关系，存取都是 O(1) 的数组读写。虚拟寄存器没有真实硬件的数量限制，编译器在生成字节码时，会为每个 IR 中间值分配一个寄存器编号，编号可复用——同一只碗用完倒空，下一道菜还能继续用。

虚拟寄存器把复杂的计算图“压扁”成一系列对固定槽位的读写，这既是字节码紧凑性的来源，也是执行循环能快速推进的原因。

碗按编号摆得整整齐齐，厨师随手抓取、倒进倒出，出菜节奏自然流畅。虚拟寄存器在字节码和真实数据之间搭起了一座“随手可取”的工作台。

执行循环

现场执厨的节奏是固定的：从一沓便签的第一张开始，读一张、做一张、划掉一张，直到整沓做完。RELAY VM 的核心同样是一个往复循环——执行循环（Dispatch Loop），三个动作周而复始：取指（Fetch）从内存中读出当前指令，解码（Decode）识别操作码含义，执行（Execute）驱动寄存器完成运算。程序计数器（PC）就像厨师的手指，随时指着正在读的那张便签。

执行循环的调度顺序完全由 PC 决定。取完一张便签，手指自然滑到下一张；遇到“跳到第 7 张”这种便签，手指就被强制拨到指定位置。这意味着 VM 的执行路径在运行时是可变的——同一段字节码，面对不同的输入数据，可能走过完全不同的指令序列。这与图执行器把指令顺序在编译期锁死形成鲜明对比。

PC 的更新规则是 VM 调度的基石。顺序执行只需加一，跳转执行则直接覆写目标地址，两种模式的切换由指令类型决定。

节奏固定而内容自由，便签换一张，菜就换一种。执行循环就是 VM 永不停歇的“出菜节拍器”，每一步都踩在 PC 这个节拍点上。

数据依赖

先淘米才能蒸饭，先切菜才能下锅。便签的纸张顺序可以打乱，但备料的前后次序绝不能乱。RELAY VM 怎么知道哪道工序必须等哪道工序？答案藏在每条指令的“原料清单”里。数据依赖（Data Dependency）描述的是：一条指令的计算结果，被另一条指令当作输入使用。在 VM 中，每条指令有读集（Read Set）和写集（Write Set）：读集列出它要取数的寄存器，写集列出它要写入的寄存器。

如果第一条指令的写集与第二条指令的读集有交集，第二条就依赖第一条。比如“把 5 号碗倒进 3 号锅”之后，“从 3 号锅舀一勺试味”就必须排在那之后。VM 通过这个规则保证：无论执行路径怎么跳转，每条指令读取到的都是最新、正确的计算结果。想调整执行顺序，前提是不破坏这些依赖关系。

依赖约束看似抽象，实则是正确性的保险绳。它决定了指令调度合法性的边界——哪些指令可以交换位置，哪些必须死死钉在原有顺序上。

数据依赖是便签背面看不见的线，把零散的工序串成一条逻辑严谨的备料链。VM 虽然灵活，也终究要顺着这条链行走，才能保证端上桌的菜是熟的。

控制流支持

客人突然喊一句“辣就少放辣”，现场厨师瞟一眼锅里，立刻决定是继续照原卡做，还是跳过两页便签直接执行“改小火”的那张。RELAY VM 对动态模型的看家本领，就是这种“瞟一眼再决定”的能力——控制流支持。VM 提供条件跳转指令，它先检查某个寄存器的取值，条件成立就把 PC 拨到目标地址，条件不成立就继续顺序执行。if/else 分支、while 循环、动态 shape 的路径选择，统统能被编译成这种“看条件跳卡”的指令。

图执行器在编译期把整张图展开成固定的执行序列，遇到分支就提前算好要不要走、走哪条；而 VM 把决定权留给运行时。比如循环次数取决于输入序列长度时，VM 每跑一圈都检查一次“是否还有下一个 token”，有就回跳到循环体开头，没有就落到循环出口。这样同一份字节码就能适配任意长度的输入。

控制流让程序不再是一条笔直的路，而是一棵在运行时才长出枝叶的树。VM 的灵活性正是建立在这些跳转指令的调度之上。

现场厨师能接住临时改单，靠的就是锅边那一眼判断和手中娴熟的跳卡功夫。控制流支持，就是 RELAY VM 递给动态模型的那张“临时改单接受证”。

图执行器对比

中央厨房按标准配方预配食材，一条流水线批量出餐：省人力、速度快、品质稳定——代价是每份菜都长一个样，改不了。图执行器（Graph Executor）就是这座中央厨房：编译阶段把整张计算图静态展开成调度序列，执行时按部就班，零分支判断、极低调度开销。而 RELAY VM 是明档前的现场执厨：每道菜单独起锅、逐条指令解码分发，灵活但多一份逐便签操作的“人工成本”。

两者的性能差异可以用一个简单的开销模型来理解：静态图把大部分成本消耗在编译期的一次性准备上，运行期几乎纯线性推进；VM 则每一轮循环都要付出取指、解码、分发的单位开销。但图执行器的“省”建立在一切提前确定的前提上——一旦 shape 动态变化、分支依赖数据、循环次数运行时才知道，静态图要么无法编译，要么被迫退化成笨重的回退策略，反而更慢。

选哪种执行方式，本质是看你的菜单够不够固定。固定 shape、高吞吐的推理服务，中央厨房更合适；变长输入、控制流密集、动态 shape 的模型，现场执厨才能接得住。

菜单固定时，没人会嫌弃中央厨房的效率和稳定；可宴席上常有临时改单的贵客，这时候就得把厨师请到明档。理解这两套执行模式的开销结构，才能做出不亏本的选型决策。

工程配置与适用场景

用不用现场执厨，取决于餐厅定位：快餐店永远用中央厨房，私房菜馆却把明档当招牌。TVM 也给了开发者一个“请厨师到明档”的选项——RELAY VM 后端。工程上的切换并不复杂：在构建阶段把编译目标切到 VM，生成字节码文件与执行库，运行时加载两者即可。RELAY VM 与图执行器共用前端与算子库，切换后无需改动模型定义，只是执行语义从“静态展开”变为“动态解释”。

配置 VM 时，开发者通常需要指定目标设备（CPU 或 GPU）、生成可执行代码对象，然后在运行时创建 VM 实例并把编译产物喂给它。VM 会基于指令中的张量类型信息在运行时规划内存：动态 shape 的张量按实际大小现场分配，固定 shape 的张量则可以复用预分配空间。这也解释了为什么 VM 特别适合 NLP 中变长序列批处理、强化学习中的 if/else 决策网络、以及需要反复修改图结构的模型调试场景。

内存在 VM 中是“用多少备多少”，动态 shape 越大，所需内存规划空间就越大。这个简单的估算是工程规划的第一把尺子。

配置得当的现场厨师就是镇店之宝：平时按需上场，关键时刻接得住任何临时改单。RELAY VM 不是要取代图执行器，而是在模型动态性面前，给工程师多一把趁手的刀。

AI 应用场景

Python 演示

class MiniVM:    """极简寄存器虚拟机,思想与 RELAY VM 一致"""    def __init__(self, program):        self.program = program        self.pc = 0        self.regs = [0, 0, 0]     def step(self):        if self.pc >= len(self.program):            return None        ins = self.program[self.pc]        op = ins[0]        if op == "LD":            self.regs[ins[1]] = ins[2]        elif op == "ADD":            self.regs[ins[3]] = self.regs[ins[1]] + self.regs[ins[2]]        elif op == "SUB":            self.regs[ins[3]] = self.regs[ins[1]] - self.regs[ins[2]]        elif op == "CH" and self.regs[ins[1]] >= 0:            self.pc = ins[2]            return ins        elif op == "JM":            self.pc = ins[1]            return ins        if op != "HL":            self.pc += 1        return ins     def run(self):        while self.pc < len(self.program):            ins = self.step()            print("PC=%d 执行 %s 寄存器=%s" % (self.pc, ins, self.regs))  def main():    # 程序语义: 若 x>=0 则 r0=x+y, 否则 r0=x-y    program = [        ("LD", 1, 3),        ("LD", 2, 2),        ("CH", 1, 6),        ("SUB", 1, 2, 0),        ("HL",),        ("HL",),        ("ADD", 1, 2, 0),        ("HL",)    ]    vm = MiniVM(program)    vm.run()    print("结果寄存器 r0 =", vm.regs[0])  if __name__ == "__main__":    main()

1. self.regs[ins[1]] = ins[2]LD 指令把立即数写入目标寄存器，相当于往编号碗里放料。
2. elif op == "CH" and self.regs[ins[1]] >= 0:条件跳转，检查寄存器值后决定是否修改 PC，对应 VM 的分支调度。
3. if op != "HL": self.pc += 1非停机指令默认顺序前进，HL 让循环自然终止。
4. vm.run()` 中的 `while self.pc < len(self.program)这就是执行循环本体，不断取指、执行，直到走出便签堆。
5. ("CH", 1, 6)` 之后紧跟 `("SUB", ...)` 和 `("HL",)被跳过的分支用占位指令隔开，真实 VM 中同样靠编译期地址布局实现跳转。

常见误区

面试题