计算图：静态图/动态图

可视化演示

计算图概念：模型的工序卡

把一道“番茄炒蛋”端上桌，后厨需要一张工序卡：番茄要洗、切、炒，鸡蛋要打散、下锅，每一步之间都有严格的先后顺序。AI模型的计算同样如此——卷积、矩阵乘法、激活函数之间，存在清晰的数据依赖。张量从一层流到另一层，谁在等谁的结果，必须一笔一笔写清楚。这张描述“谁等着谁”的工序图，就是计算图（Computation Graph）。

计算图用节点表示一次运算（也叫算子），用有向边表示数据的依赖与流转。以最简单的式子 \(y=(a+b)\times c\) 为例：先做加法，再做乘法。把这两个动作画成图，节点和边就构成了模型计算的骨架。深度神经网络本质就是一张巨大的计算图，数亿个参数在其中传递，而框架的调度器拿着这张图决定“哪个算子先跑、哪个算子的结果要被谁消费”。

在AI框架中，计算图 \(G=(V,E)\) 是调度和优化的基础。V 是节点集合，E 是边集合。图建得越完整，编译器越能站在全局视角做优化；图建得越零散，调度器越难施展拳脚。因此，计算图不仅是数据结构，更是框架“运筹帷幄”的沙盘。

回到后厨：这张工序卡本身不决定上菜快慢，真正决定快慢的，是后厨按什么方式使用它——是先完整排好流水线（静态图），还是来一单做一单（动态图）。这正是接下来的两节要讲的两种后厨哲学。

静态图原理：中央厨房的流水线

流水斋的后厨从来不在饭点时才开始思考。经理会在前一天晚上把整场宴席的工序写成标准作业流程：食材统一切配，料汁提前调制，灶台按时间轴依次点火。AI框架中的静态图，就是这个思路——它把“构建计算图”和“执行计算”分成两个阶段，先把整张图完整建好，再交给执行引擎统一开火。

这种模式叫“先建后跑”。在构建阶段，你写下的每一行网络代码并不会真正计算数值，而是被框架翻译成图结构里的节点和边，这个过程是惰性求值（Lazy Evaluation）：表达式只是被“记下来”，并不立刻算出结果。只有当整张图构建完毕、调用执行接口时，张量才开始在图中流动。

静态图的杀手锏在于：图是完整的，编译器就拥有了上帝视角。它可以做算子融合，把 \(a+b\) 和结果乘 \(c\) 合并成一个内核；可以做内存复用，提前算出每个中间张量的生命周期，让它们共用一块缓冲；还可以做常量折叠，把能提前算出的分支在编译期就干掉。这些优化，靠“边写边算”的零散执行是做不到的。

中央厨房最适合承办大型宴席，却最怕客人临时改菜单。静态图也一样：一旦模型里有复杂的 Python 条件分支、动态形状，或者你想在中间某个节点打个断点看看数值，事情就变得棘手。这是静态图高效的代价，也是动态图登场的理由。

动态图原理：现点现炒的小灶台

随心小炒的厨房没有任何预案。客人喊一声“番茄炒蛋，多放糖”，大厨立刻从筐里抓起番茄，打蛋、起锅、翻炒，每一步都当场完成，还能随时尝一口调整口味。AI框架的动态图就是这样：代码执行到哪一行，就把对应的算子立刻算出来，不需要预先构图，也不需要等待执行引擎的统一调度。这种模式叫“边建边跑”，学名是即时求值（Eager Execution）。

在动态图模式下，Python 代码就是计算过程本身。你想打印中间变量？直接 print 就好；你想加个断点？IDE 会在执行到那一行时停住。这让调试体验极其自然，也让研究者可以像写普通程序一样写神经网络——改结构、改分支、看中间结果，全部即时反馈。PyTorch 正是凭借这种极致的易用性，赢得了研究者的青睐。

但自由是有代价的。动态图每到一步都要启动一次算子内核，无法跨越多个算子做全局性的融合与内存规划。而且每次前向传播都可能重新构建图结构，重复调度开销不小。就好比小炒店每道菜都从洗菜开始，无法像中央厨房那样批量备料、共享半成品。

现点现炒的厨房，口味灵活、改菜方便，但高峰时段出餐慢；动态图让你写模型如行云流水，但在大规模训练和部署时，逐算子的调度开销会实打实地反映在速度上。静态图的性能优势和动态图的灵活体验，成了 AI 框架必须权衡的两端。

优劣对比：流水线与小灶台的取舍

把流水斋和随心小炒放在同一条街上，就能看清两种模式的利弊。流水斋的优势是稳定与高效：中央厨房可以提前规划所有工序，批量备料、共享灶台、统一出餐。随心小炒的优势是灵活与即时：菜单随时可改，口味随时可调，客人满意是最高优先级。静态图和动态图的取舍，惊人地相似。

性能差异可以用一个简化模型理解：一次前向传播的总时间，约等于所有算子内核的启动开销加上实际计算耗时。静态图通过算子融合把多个小内核合并成一个大内核，减少启动次数；动态图则每个算子独立启动，内核数量多，启动开销自然更高。此外，静态图还能提前规划内存布局，减少碎片和重复分配，这部分收益在长序列、大模型场景中格外明显。

不过，动态图并非毫无优势。它写起来像普通 Python 程序，逻辑直白，分支、循环、调试都自然；静态图则要求模型可静态化，遇到动态形状或复杂控制流往往要改写代码，开发体验大打折扣。所以选择哪种模式，本质上是在问：你更在意出餐速度，还是更在意改菜单的自由度？

宴席选流水斋，下午茶选随心小炒，道理就这么简单。实际工程中，研究阶段追求快速试错，更适合动态图；生产环境追求吞吐和延迟，更适合静态图。但两条街的餐厅不会永远井水不犯河水——接下来看看主流框架是怎么选择的。

框架落地：两大餐厅的经营风格

不同 AI 框架就像不同风格的餐厅。TensorFlow 早期是典型的“中央厨房派”：1.x 时代使用 Graph + Session，用户必须先定义好完整的计算图，再启动会话执行，静态图哲学贯穿始终。PyTorch 则是“现点现炒派”：默认动态图模式，代码即执行，研究者用起来如鱼得水，迅速成为学术界的宠儿。

但这种对立并不绝对。TensorFlow 2 引入了 eager 模式，默认逐算子执行；PyTorch 则推出了 TorchScript 和 torch.compile，试图把写好的动态代码捕获成静态图进行优化。两大框架都在向对方学习，也催生了框架内部的“前后端分离”架构：前端负责把用户友好的 Python 代码翻译成计算图，后端负责高效执行这张图。

这种分离很像餐厅的“前台点单”和“后厨出品”分工。前台服务员只负责记录客人的需求，后厨则按标准配方统一加工。前端决定好不好写，后端决定跑得快不快。同一个计算图，可以交给 CPU、GPU 或 NPU 执行，硬件差异被后端引擎屏蔽。用户感受到的“易用性”来自前端，而“性能”主要来自后端。

框架的经营风格可以不同，但谁也挡不住“既要好吃又要快”的用户需求。于是，两大流派开始同一条路：把动态图的开发体验和静态图的执行性能结合起来。这正是下一节的“动静合一”。

融合演进：动静合一的新后厨

你有没有想过：为什么现代餐厅不能既让顾客自由点单，又让后厨拥有中央厨房的效率？答案是——把“点单”和“备餐”分开。顾客在前台自由选择（动态），后厨按标准化配方批量生产（静态）。AI 框架的融合演进，正是这条路径：用动态图写模型，用静态图优化执行。

实现这一愿景的关键技术是图捕获（Graph Capture）。框架先让动态代码“试跑”一次，用假的输入张量走一遍前向计算，把这次运行的算子调用顺序记录成一张静态计算图。PyTorch 的 torch.compile、TensorFlow 的 tf.function，本质都是这个套路：先把动态函数变成图，再对图做全局优化。

图捕获之后，框架还会进行即时编译（JIT Compile）：对捕获到的图做算子融合、内存规划、循环优化，最终生成一个高效的编译后函数。此后每次调用，都直接执行这份编译产物，不再重复逐算子调度。用户依然写的是动态代码，享受的是静态图的性能，这就是“动静合一”。ONNX 导出和 TensorRT 部署也是同样思路：把训练好的动态模型固化为静态推理图。

这场演进让“流水斋”和“随心小炒”不再是竞争对手，而是同一个餐厅的两个部门。理解了这一点，你就能看懂为什么 PyTorch 2.0 的 torch.compile 让训练提速、为什么 TensorFlow 的 tf.function 能让 Python 代码跑出图执行的速度。那在实际工作中，到底该如何选型呢？

选型思路：你的餐厅该学谁

如果你是研究院的“实验餐厅”，菜单天天变，新菜品层出不穷，点单的客人（或者说论文的 deadline）随时可能提出新需求——动态图是你的最佳选择。快速迭代、随时打印中间张量、像写普通程序一样改模型，这些能力在研究阶段千金不换。PyTorch 在学术界统治性的地位，正源于这种极致的开发体验。

如果你是产品团队的“连锁餐厅”，要服务千万级用户，对延迟和吞吐有硬指标——静态图或编译优化后的执行模式更合适。将训练好的模型导出为 ONNX、TensorRT 或使用 torch.compile 编译，可以让推理速度获得数倍提升。生产环境不在乎开发时多费点功夫，只在乎最终端上桌的速度和稳定度。

现实中最优解常是混合策略：研究阶段用动态图快速验证，部署阶段将模型固化为静态图或编译图。甚至在同一张模型图中，也可以划分静态子图和动态子图：能静态化的大块计算（卷积、矩阵乘）交给编译器优化，必须动态处理的控制流单独保留。这样既保住灵活性，又拿到性能。

回到开头的比喻：世界上不需要两家一模一样的餐厅。研究阶段的食堂要灵活，生产阶段的连锁店要效率，而聪明的餐饮集团，学会了把两种后厨装进一家店。静态图与动态图不是二选一的敌人，而是可以按需组合的两种后厨哲学。

AI 应用场景

Python 演示

import operator  class TinyGraph:    """极简静态计算图：先构图，run 时统一执行。"""     def __init__(self):        self.slots = {}        self.plan = []     def input(self, name, value=None):        self.slots[name] = value        return name     def op(self, name, fn, *deps):        self.plan.append((name, fn, deps))        return name     def run(self, **feed):        slots = dict(self.slots)        slots.update(feed)        for name, fn, deps in self.plan:            args = [slots[d] for d in deps]            slots[name] = fn(*args)        return slots  def eager_calc(a, b, c):    """动态图风格：执行到哪行就算到哪行。"""    s = a + b    print("[动态] 中间结果 s =", s)    y = s * c    return y  def static_calc(a, b, c):    """静态图风格：先把计划写全，再一次执行。"""    g = TinyGraph()    g.input("a")    g.input("b")    g.input("c")    s = g.op("s", operator.add, "a", "b")    y = g.op("y", operator.mul, "s", "c")    print("[静态] 执行前计划:", g.plan)    result = g.run(a=a, b=b, c=c)    return result["y"]  if __name__ == "__main__":    a, b, c = 2.0, 3.0, 4.0    print("动态计算结果:", eager_calc(a, b, c))    print("静态计算结果:", static_calc(a, b, c))

1. self.plan.append((name, fn, deps))把一次运算记入“后厨计划表”，只登记不开火。
2. slots[name] = fn(*args)真正执行：从依赖槽位取值，喂给算子，存入结果。
3. s = a + b动态图风格：这一行执行时就立刻算出数值，还能打印。
4. print("[静态] 执行前计划:", g.plan)静态图在开跑前能看到完整工序表，这是它可全局优化的根基。
5. result = g.run(a=a, b=b, c=c)一次性喂入所有输入，按计划顺序完成全部计算。

常见误区

面试题