想象你是一位身怀绝技的老主厨，脑中装着一道传承三代人的招牌菜做法——食材配比、火候时机、颠锅翻勺的每一个细节都清清楚楚（这就是活在内存里的计算图）。可你的徒弟们散落在全国各地开分店，不可能每天飞到你身边“读取记忆”。怎么办？你只能把这道菜的做法一字一句写下来，变成一份纸质的菜谱（这“写下来”的动作，就是序列化）。徒弟们拿到菜谱，按图索骥把菜复刻出来（这“照着做”的动作，就是反序列化）。菜谱写得好不好、有没有漏掉关键步骤、用的是普通纸还是防水塑封纸、老店改配方后老菜谱还能不能用——这些看似琐碎的问题，恰恰就是计算图序列化技术的全部内核。AI 模型要部署到手机、云端、自动驾驶芯片上，都必须先把“脑中的计算图”落纸成谱，再在目标设备上按谱还原。这篇内容，就带你把“写菜谱”这件事彻底看明白。

岗位关联

掌握计算图序列化，是打通模型训练到部署落地的“最后一公里”关键能力——任何 AI 模型要上线，都绕不开这道工序，这是 AI 编译器工程师的必备基本功。

目录
  1. 可视化演示
  2. 序列化反序列化
  3. 序列化格式选型
  4. ONNX标准规范
  5. 图拓扑编码
  6. 元数据保留
  7. 版本兼容处理
  8. 工程实践流程
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示计算图序列化五步流程（计算图→序列化→存储/传输→反序列化→计算图），对比Protobuf/JSON/ONNX三种格式的体积、速度和类型。

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

图序列化五步流程 计算图→序列化→存储/传输→反序列化→计算图 序列化前后图结构保持一致，元数据不丢失 跨平台模型部署的核心基础

序列化反序列化

老主厨要把招牌菜做法传给分店，第一步想清楚一件事：脑中的做法是“活的记忆”，纸上的菜谱是“死的文字”——把活的记忆变成死的文字，就是序列化。内存里的计算图由一个个张量节点和算子节点组成，它们之间通过指针互相引用的关系网盘根错节，这是活的；而文件里只能存“井井有条的字节流”，排成一行行规格统一的数据，这是死的。序列化要做的，就是用一套规则把指针网络变成线性的字节排列。

反序列化是逆过程：分店大厨拿到菜谱，逐条读出食材、步骤，在自己的厨房里重建出一个可以开火做菜的状态——读文件、解析字节、重建节点对象、重新连接数据流边。理想情况下，还原出来的图与原图“等价”：结构一致，输出一致。

这个“等价”并非天然保证。序列化和反序列化之间的映射若不对称，哪怕丢了一个字段，还原出的图也会产生偏差。我们把这种理想的映射关系写成：

理解了这对“活↔死”的转换，你就抓住了序列化的命门：一个负责任的序列化器，必须做到“写出去什么，读回来就是什么”，如同老主厨的菜谱连盐放几克、锅烧几成热都写得清清楚楚。

G′=ϕdeserialize(ϕserialize(G))\displaystyle G' = \phi_{deserialize}(\phi_{serialize}(G))
这个公式说的是：先把原图 $G$ 交给序列化函数打包，再把打包结果交给反序列化函数还原，得到的 $G'$ 和当初的 $G$ 必须等价。就像你照着菜谱复刻了一道菜，尝起来必须和原版一致才算成功。
  1. 序列化函数把内存中的计算图对象转换成字节流，是“写菜谱”动作的数学表达。
    ϕserialize:G→bytes\displaystyle \phi_{serialize}: G \rightarrow bytes
  2. 反序列化函数把字节流还原成内存计算图，是“照谱做菜”动作的数学表达。
    ϕdeserialize:bytes→G′\displaystyle \phi_{deserialize}: bytes \rightarrow G'
  3. 等价性检验还原出的 $G'$ 与原图 $G$ 在结构上同构、数值上一致。
    G′≡G\displaystyle G' \equiv G

序列化格式选型

老主厨想清楚要写菜谱后，接着面对一个材料问题：用普通信纸写，还是用防水塑封袋装？信纸人人能读，但怕水怕油，带不长；塑封袋密封防潮，但普通人打不开，得配专用工具。这对应着序列化格式的选择。

JSON 就像普通信纸——人类可读、上手简单，调试时直接打开文件就能看明白“哦这里写着 input 是 224”。代价是体积膨胀得厉害，一个数字 3.14159 要存成 8 个字符，而计算机底层其实只需要 4 字节。Protobuf 则是塑封袋——用二进制紧凑编码，字段按编号配对本体和类型打包，体积通常是 JSON 的 1/5 到 1/10，编解码速度也快一个量级，代价是文件打开后全是乱码，必须借助 schema 描述文件才能读懂。FlatBuffers 更进一步，支持零拷贝直接读取——不需要先完整解析，就能从字节流中按偏移量取到想要的字段。

三种格式在 AI 编译器领域各有归宿：小模型调试用 JSON、跨框架交换用 Protobuf、追求极致推理延迟的移动端部署用 FlatBuffers。如果用 Protobuf 的 schema 定义一组图结构字段，序列化后的体积可以表达为：

选格式没有银弹。老主厨看清了这点：日常在店里自己看用信纸（JSON），给外地分店传总店秘方用塑封袋（Protobuf），给颠簸的海运邮包则用抗压的特制铁盒（FlatBuffers）——对应到 AI 工程，就是“场景决定格式”。

Sproto=∑i=1nLtag(i)+Llen(i)+Lval(i)\displaystyle S_{proto} = \sum_{i=1}^{n} L_{tag}(i) + L_{len}(i) + L_{val}(i)
这是 Protobuf 单条字段的存储开销公式：每条字段由“字段标签 + 值长度 + 实际值”三部分构成。相比之下 JSON 还要额外付出为每个键写全名（如 "op_type"）的字符开销。
  1. 字段标签开销记录“这是第几号字段、什么类型”的元信息，是塑封袋上的标签。
    Ltag(i)=1∼2 bytes\displaystyle L_{tag}(i) = 1 \sim 2 \text{ bytes}
  2. 值长度开销变长字段需要记录数据占了多少字节，方便读取时切分。
    Llen(i)=Varint(i)\displaystyle L_{len}(i) = Varint(i)
  3. 实际值开销真正存数值或字符串的载荷，是菜谱的内容本身。
    Lval(i)=strlen(vi) or 4/8 bytes\displaystyle L_{val}(i) = strlen(v_i) \text{ or }4/8 \text{ bytes}

ONNX标准规范

分店越开越多，麻烦来了：A 徒弟学的是川菜记谱法，B 徒弟学的是粤菜记谱法，同样一道宫保鸡丁，两本菜谱对照着看，步骤顺序、计量单位全不一样。这时需要一个行业公会出面，制定一本“通用菜谱标准”——这就是 ONNX（Open Neural Network Exchange）在 AI 世界扮演的角色。

ONNX 将计算图统一为一种标准结构描述：一个模型文件由 ModelProto 包裹，内含图结构 GraphProto、算子集版本号 opset_import、生产者信息 producer_name 等字段。任何框架——PyTorch、TensorFlow、PaddlePaddle——只要遵循这个公约导出模型，任何推理引擎——ONNX Runtime、TensorRT、OpenVINO——只要遵循这个公约加载模型，就能无缝对接。从此各家厨子不需要互通各自的行话，只要都按标准菜谱书写即可。

ONNX 模型文件的结构可以用集合形式描述：

ONNX 的伟大之处不在技术多高深，而在于它让整个行业“说同一种语言”。就像通用菜谱公约让川菜师傅和粤菜师傅能合作开一家店——它把本该各自为政的 AI 框架连成了一体。

ModelProto={producer_name,  opset_versions,  GraphProto=(V,  E,  initializers)}\displaystyle ModelProto = \{ producer\_name,\; opset\_versions,\; GraphProto = (V,\; E,\; initializers) \}
ONNX 规定一个模型文件是谁生产的、用什么版本的算子标准写的、图里有哪些节点（顶点 $V$）、哪些数据流边（边 $E$）、哪些直接内嵌的常量权重（initializers）。它把计算图拆成了一张“标准申请表”，任何人都能看懂填写规则。
  1. 生产者信息记录模型来自哪个框架和版本，如"pytorch 2.0"，是菜谱出处。
    producer_name=string\displaystyle producer\_name = string
  2. 算子集版本规定这套图用了哪一版算子规则，避免同名算子在不同版本语义不同。
    opset_versions=(domain,  version)\displaystyle opset\_versions = (domain,\; version)
  3. 图结构用顶点集合、边集合和初始权重三元组完整描述一个计算图。
    GraphProto=(V,  E,  initializers)\displaystyle GraphProto = (V,\; E,\; initializers)

图拓扑编码

菜谱写什么才算合格？光有食材清单（节点）不够，必须写清楚“先切葱还是先热锅”的先后顺序以及“每步之间谁等谁”的依赖关系——这就是图的拓扑结构编码。

最常见的编码方式是双表制：一张节点表（Node Table）记录每个算子的编号、类型、属性；一张边表（Edge Table）记录每条数据流从哪个节点输出连到哪个节点的哪个输入。节点表相当于菜谱的主料名录，边表则相当于做法步骤里“把步骤 A 的产物倒入步骤 B 的锅里”这类流程说明。还有一种常用做法是基于拓扑序的紧凑编码——先对图做拓扑排序，保证每条边的起点排在终点之前，然后把节点按序排列、边用起点相对序号表示。

拓扑序的合法性约束是序列化正确性的底线：

拓扑编码是菜谱的“叙事逻辑”。如果老主厨的菜谱里步骤七说“倒入步骤二的汤汁”，却被写成了“倒入步骤九的汤汁”，整道菜就全毁了。图拓扑编码的任务，就是确保这个“步骤引用”永远正确无误。

∀e=(u,v)∈E:ord(u)<ord(v)\displaystyle \forall e = (u, v) \in E: \quad ord(u) < ord(v)
这条公式说的是：图中任意一条从 $u$ 指向 $v$ 的边，在序列化存储的排列顺序里，$u$ 的序号必须小于 $v$ 的序号。只有满足这一点，“先有原料再下锅”的因果逻辑才不至于在还原时颠倒。
  1. 边集提取先列出图中所有数据流依赖关系，是什么边就记什么边。
    E={(u1,v1),(u2,v2),… }\displaystyle E = \{ (u_1, v_1), (u_2, v_2), \dots \}
  2. 拓扑排序把节点排成一个线性序列，保证每个节点的前驱都在它前面。
    ord(u)<ord(v),∀(u,v)∈E\displaystyle ord(u) < ord(v), \quad \forall (u,v) \in E
  3. 边表压缩以节点相对位置代替全局节点 ID，存储更精简。
    e=(ord(u),  ord(v)−ord(u))\displaystyle e = (ord(u), \; ord(v)-ord(u))

元数据保留

菜谱上除了步骤，老主厨还会写些看似不起眼但至关重要的细节：「火候八分热」「蒜末必须 2mm 见方」「高汤用鸡架熬 4 小时」——这些细节在 AI 计算图里就是元数据（Metadata）。它们是支撑图的每个节点正确执行所必需的附加信息。

张量元数据包括形状（如 [1, 3, 224, 224]）、数据类型（如 float32）、布局（如 NCHW）、名称映射（把文件里的张量名对应回源码变量名）；算子元数据包括属性参数（如卷积的 kernel_shape、strides、padding），这些属性是算法行为的调节旋钮。序列化时保留得越完整，反序列化还原出的图就越“保真”。

元数据映射可以形式化为一组键值对应关系：

有人轻视元数据，以为“能跑就行”。但就像老主厨那句“蒜末必须 2mm 见方”——少记录了这行字，各地分店做出来的菜味道就千奇百怪。AI 部署中，一个 layout 字段记错或漏掉，模型在目标硬件上的性能可能差出三五倍。

M:name↦(shape,  dtype,  attrs,  layout)\displaystyle M: name \mapsto (shape,\; dtype,\; attrs,\; layout)
这表示：序列化文件里必须保存一张“名字 → 属性”的对照表，让还原器知道名为 "input_0“ 的张量长什么样、是什么类型、携带着哪些算子属性。它相当于菜谱附页的”食材规格明细表"。
  1. 形状元数据记录张量每个维度的大小，决定数据排布空间。
    shape=(d1,d2,…,dk)\displaystyle shape = (d_1, d_2, \dots, d_k)
  2. 类型元数据记录每个张量的数据类型，如 float32、int64。
    dtype∈{float32,  int64,  … }\displaystyle dtype \in \{float32,\; int64,\; \dots\}
  3. 算子属性集记录算子级参数，如卷积核大小、步长等。
    attrs={kernel_shape,  strides,  pads}\displaystyle attrs = \{ kernel\_shape, \; strides, \; pads \}

版本兼容处理

老主厨晚年对招牌菜做了改良：糖从两勺减到一勺半，增加了三道摆盘工序。新版菜谱印出来后，老主厨突然发现一个问题——还在用旧版菜谱的分店怎么办？那些只有老菜谱的新学徒，又怎么看懂新版里的“增味提鲜”新术语？

这正是计算图序列化的版本兼容难题。模型文件格式会随 AI 框架升级而演进，新格式引入新字段、新算子类型，但老文件不该因此作废，新文件也不该让旧加载器彻底无法读取。业界为此设计了三条策略组合拳：向后兼容（新版加载器能读旧文件）、向前兼容（旧版加载器遇到新文件时读取已知字段、忽略未知字段）、版本号字段加默认值兜底（对新字段提供合理默认，读不出来就用默认值顶上）。

版本兼容的检查逻辑可以抽象为一个条件：

版本策略就像老主厨对菜谱编号管理——“本菜谱第 3 版，若你手头是第 2 版，步骤 4 的糖量请按一勺半处理”。没有这套规矩，AI 模型的“保质期”就极短，旧模型在新环境里加载就会莫名报错。

Vloader≥Vfile    或    Vloader<Vfile⇒∃ fallback(Vfile−Vloader)\displaystyle V_{loader} \ge V_{file} \;\; \text{或} \;\; V_{loader} \lt V_{file} \Rightarrow \exists \text{ fallback}(V_{file} - V_{loader})
这条规则说的是：如果加载器版本不低于文件版本，直接放心读；如果加载器版本低于文件版本，则必须存在一条“兜底路径”（忽略新字段、用默认值替代），否则就应给出清晰报错而非崩溃。
  1. 版本号字段每个序列化文件开头都要写清格式版本，是老菜谱的“第 N 版”标识。
    magic_number+version_id\displaystyle magic\_number + version\_id
  2. 向后兼容判定新加载器带旧文件，满足版本号判定则安全。
    Vloader≥Vfile⇒safe read\displaystyle V_{loader} \geq V_{file} \Rightarrow \text{safe read}
  3. 向前兼容降级旧加载器见新文件时按需忽略新字段，用默认值兜底。
    Vloader<Vfile⇒skip unknown fields\displaystyle V_{loader} < V_{file} \Rightarrow \text{skip unknown fields}

工程实践流程

老主厨的菜谱体系从无到有，最后沉淀为一套完整流程：定标准格式、写菜谱、检查错漏、寄给分店、分店复刻上桌。AI 工程里计算图序列化的完整链路也是如此。先用训练好的 PyTorch 模型导出 ONNX 文件（导出流程）；然后用 onnx.checker 做结构校验，确保节点类型合法、边引用完整（加载校验）；推理引擎加载文件后重建计算图，交给调度器分配执行设备，最终完成推理（推理链路）；一旦线上模型出了状况，还能借助可视化工具把序列化文件画成图来排查问题（故障排查）。

整个链路可以用一条管线表示：

整条管线的价值在于“一份菜谱，处处能做”。AI 工程师只要把模型导出成符合标准的文件，任何支持该标准的推理引擎都能把它变成线上服务。

Pipeline:    Train→exportONNX→checkIR→loadIEngine→runOutput\displaystyle Pipeline: \;\; Train \xrightarrow{export} ONNX \xrightarrow{check} IR \xrightarrow{load} IEngine \xrightarrow{run} Output
这条管线串起序列化的全生命周期：训练框架把模型导出为标准 ONNX 文件，经校验后生成内部中间表示（IR），推理引擎加载 IR 重建计算图并执行，最终产出推理结果。它对应老主厨从“研发新菜”到“分店上桌待客”的完整链条。
  1. 导出环节框架把动态内存图固化到静态文件，是菜谱从口述变誊写。
    Graph→torch.onnx.exportmodel.onnx\displaystyle Graph \xrightarrow{torch.onnx.export} model.onnx
  2. 校验环节检查文件是否符合标准 schema，是上桌前试菜找毛病。
    check(model.onnx)⇒{ok,  errors}\displaystyle check(model.onnx) \Rightarrow \{ok,\; errors\}
  3. 加载重建推理引擎反序列化生成可执行 IR，是分店按谱备菜。
    model.onnx→loadIR\displaystyle model.onnx \xrightarrow{load} IR

AI 应用场景

跨框架模型转换与部署

阶段：模型导出与交付阶段

解决的问题：训练团队用 PyTorch 开发的模型，部署团队却要求 TensorRT 格式，传统做法是人工重写模型代码，极易出错。通过 ONNX 序列化，PyTorch 模型一键导出为 model.onnx 文件，TensorRT 加载反序列化后转为自己的引擎格式，全程零手写代码。

具体案例：某安防公司的目标检测模型在 PyTorch 上训练，需部署到 NVIDIA 边缘盒子。工程师调用 torch.onnx.export 导出 ONNX 文件，用 onnx-simplifier 简化图结构，再在 TensorRT 中反序列化并做 FP16 量化，最终推理延迟从 30ms 降到 8ms，全程未改动一行模型代码。

模型版本灰度发布

阶段：模型运维与更新阶段

解决的问题：线上模型迭代后，部分流量仍走旧版本，新旧模型文件并存于同一套推理服务中。借助序列化格式中的版本号与元数据字段，推理服务加载不同版本模型文件时自动分配合适的算子实现，实现平滑灰度。

具体案例：某推荐系统团队需要将精排模型从 v3 升级到 v5。他们将 v3 与 v5 两个模型分别序列化为带不同 version_id 的文件，推理服务根据流量比例动态加载两份文件，各跑各的图，离线对比 AUC 指标后再逐步切流，全程无需停服。

端侧模型加密与分发

阶段：端侧部署阶段

解决的问题：手机端 App 内置的 AI 模型文件容易被逆向提取，传统明文格式一拉一拽就被扒走。将计算图序列化为加密的 Protobuf 格式，再配合仅服务端可见的 schema 文件，使得拿到字节流也无法解析出图结构。

具体案例：某美颜 App 的人像分割模型需内置到 Android 客户端，工程师使用自研的加密序列化器将 ONNX 文件转为密文 .bin 格式，客户端启动时用内置密钥反序列化重建计算图，有效防止模型参数被直接窃取。

Python 演示

python59 行
import json  class GraphNode:    def __init__(self, name, op_type, inputs=None, attrs=None):        self.name = name        self.op_type = op_type        self.inputs = inputs or []        self.attrs = attrs or {}  class GraphSerializer:    FORMAT_VERSION = 3     def serialize(self, nodes, metadata=None):        graph_dict = {            "format_version": self.FORMAT_VERSION,            "metadata": metadata or {},            "nodes": [                {                    "name": n.name,                    "op": n.op_type,                    "inputs": n.inputs,                    "attrs": n.attrs,                }                for n in nodes            ],        }        return json.dumps(graph_dict, indent=2).encode("utf-8")     def deserialize(self, data):        graph_dict = json.loads(data.decode("utf-8"))        if graph_dict["format_version"] > self.FORMAT_VERSION:            raise ValueError("模型版本过高，请先升级运行环境")        nodes = [            GraphNode(                name=item["name"],                op_type=item["op"],                inputs=item["inputs"],                attrs=item["attrs"],            )            for item in graph_dict["nodes"]        ]        return nodes, graph_dict["metadata"]  if __name__ == "__main__":    raw_nodes = [        GraphNode("input_0", "Placeholder", [], {}),        GraphNode("conv_1", "Conv", ["input_0"], {"kernel_shape": [3, 3]}),        GraphNode("relu_1", "ReLU", ["conv_1"], {}),        GraphNode("output_0", "Softmax", ["relu_1"], {}),    ]    serializer = GraphSerializer()    blob = serializer.serialize(raw_nodes, metadata={"model_name": "demo"})    restored, meta = serializer.deserialize(blob)    print("还原节点数:", len(restored))    print("元数据:", meta)    print("首个算子:", restored[1].op_type, restored[1].attrs)
目的：演示一个简化版计算图序列化器——把节点列表打包成带版本号与元数据的字节流，再反向还原出原图结构。
  1. graph_dict = {...}组装序列化的字典骨架，相当于“菜谱的目录页”：先写版本号，再写元数据，最后按序排节点。
  2. "format_version": self.FORMAT_VERSION在文件开头写入格式版本号，这是版本兼容策略的基石，加载器要先看这里。
  3. json.dumps(...).encode("utf-8")把字典转成字符串再编码为字节流，完成内存对象到文件的“活→死”转换。
  4. json.loads(data.decode("utf-8"))字节流还原为字典，这是反序列化的第一步“读出生字”。
  5. if graph_dict["format_version"] > self.FORMAT_VERSION向前兼容保护：遇到高版本文件主动报错，避免静默解析出错误结构。

常见误区

误区JSON 能读能写还不用定义 schema，开发效率高，为什么生产环境还要用 Protobuf？我觉得 JSON 就是最好的序列化格式。

正解开发调试阶段 JSON 的确更友好，但生产环境模型文件动辄几百 MB，JSON 体积通常比 Protobuf 大 5~10 倍，解析耗时高出数倍，且浮点数字符串化后存在精度损失风险。就好比信纸写菜谱看一眼就懂，但要说传给全国几百家分店，还是密封档案袋更省运费更防潮。

为何常见：初学者多在调试阶段接触 JSON，看到的是 JSON 的可读性优势，没经历过大规模部署时的存储、带宽和延迟瓶颈。

误区Python 里用 `pickle.dump()` 不就把计算图存下来了吗？还要学什么序列化格式，直接用 pickle 不就完事了？

正解pickle 是语言私有的序列化，换一种语言（比如从 Python 换到 C++ 推理引擎）后完全无法解析。计算图序列化的核心诉求是跨语言、跨框架的互操作性，必须用语言无关的标准格式（ONNX/Protobuf），就像菜谱不能只写给你自己看，得写成任何人拿到都能做的通用格式。

为何常见：很多人在单语言环境里写脚本，没接触过异构系统间交换数据的场景，容易把小范围工具方案当成通用解决方案。

误区我以为 ONNX 文件就是一个巨大的权重文件，存的是所有神经元的参数数值，图结构是推理时重建出来的。

正解ONNX 文件的主体是计算图结构——节点、边、算子属性——权重只是图里 initializer 字段附带的一小部分。反序列化时首先是重建图结构，然后把权重填入对应节点，最后才执行。就像菜谱的主体是做法步骤，配料表只是附带的一页附录。

为何常见：模型文件动辄几百 MB，大多数体积都是参数矩阵，给人造成了“序列化文件 = 权重”的错觉。

误区序列化和反序列化就像复制粘贴，写进去什么读出来就应该是什么，不可能出问题。

正解浮点数精度、未知算子、缺失的元数据、版本不匹配都可能导致还原出的图与原图有偏差甚至直接失败。比如 float64 的权重被序列化成 float32，精度就悄悄丢失了；新增算子在旧加载器中没有实现，文件根本加载失败。序列化设计时必须显式考虑这些“易碎点”。

为何常见：计算机基础课里常说“内存复制是无损的”，很多人把这一直觉错误推广到了跨格式、跨版本的序列化场景。

面试题

Q1. 计算图序列化的核心目标是什么？

单选题 · easy

  • A.让模型在内存中运行得更快
  • B.把内存图转成可存储传输的字节流← 正确答案
  • C.提高训练时的梯度计算精度
  • D.减少模型推理时的显存占用

答案：B。序列化的本质是把内存中靠指针关联的计算图对象“写下来”变成线性字节流，B 准确描述了这一目标。A、C、D 分别涉及运行性能、训练精度、显存优化，与序列化无直接关系。就像写菜谱是为了把做法传出去，而不是为了让菜做得更快。

Q2. 反序列化的作用是什么？

单选题 · easy

  • A.把字节流还原为内存计算图← 正确答案
  • B.把计算图压缩为更小体积
  • C.把模型权重做量化处理
  • D.把训练框架切换为推理框架

答案：A。反序列化是序列化的逆过程，将文件中的字节流解析并按 schema 重建节点、边、元数据，得到可执行的内存图。B 是压缩、C 是量化、D 是框架切换，均不涉及“从字节流还原对象”这一核心动作。

Q3. 相比 JSON，Protobuf 在计算图序列化中的主要优势是？

单选题 · mid

  • A.文件可读性强易于调试
  • B.编码紧凑且编解码性能高← 正确答案
  • C.天然支持加密算法
  • D.无需定义 schema 即可用

答案：B。Protobuf 使用二进制编码，字段以编号+长度+值紧凑排列，体积约为 JSON 的 1/5~1/10、编解码性能高一个量级。A 是 JSON 的优势；C 与序列化格式无关；D 恰好相反，Protobuf 强依赖 schema 定义文件。

Q4. ONNX 中 opset_import 字段的作用是什么？

单选题 · mid

  • A.记录模型生产者的框架名称
  • B.声明模型使用的算子集版本号← 正确答案
  • C.存储训练数据的标签信息
  • D.指定模型推理的目标硬件

答案：B。opset_import 是 ONNX 模型的版本语义锚点，它声明图里使用的算子遵循哪个版本的规范，防止同名算子在不同版本中语义漂移。A 对应 producer_name，C 是数据集元数据，D 是部署配置信息。

Q5. 以下哪些属于计算图序列化时需要保留的元数据？

多选题 · mid

  • A.张量的形状信息← 正确答案
  • B.张量的数据类型← 正确答案
  • C.模型训练时的学习率
  • D.算子属性参数← 正确答案

答案：ABD。形状（shape）、数据类型（dtype）、算子属性（attrs）都是反序列化还原计算图所必需的元数据，缺少它们图无法正确执行。训练学习率是训练阶段参数，推理时无用途，无需序列化保留。就像菜谱要写火候和刀工细节，但不用写厨师当年学艺时的学费。

Q6. 旧版加载器要读取包含新字段的模型文件，最合理的处理策略是？

单选题 · hard

  • A.拒绝加载并退出程序
  • B.忽略未知字段并使用默认值← 正确答案
  • C.自动升级模型文件版本
  • D.删除新字段后继续执行

答案：B。向前兼容的标准做法是跳过未知字段、对缺失的新字段使用 schema 中定义的默认值兜底，从而让旧加载器尽量读取已知信息。A 过于粗暴导致旧文件无法使用；C 越权修改文件版本；D 直接删除字段破坏文件完整性。

Q7. 计算图拓扑序列化时，保证“节点先于后继存储”的顺序是什么？

单选题 · mid

  • A.字典序排列
  • B.拓扑排序← 正确答案
  • C.随机打散排序
  • D.按权重大小排序

答案：B。拓扑排序保证每条边的起点序号小于终点序号，序列化后的顺序才能让还原器按序重建依赖关系。字典序与图的因果无关；随机和权重排序都会破坏数据流依赖的先后约束，导致还原失败。

Q8. 以下哪些是主流的计算图序列化格式？

多选题 · easy

  • A.Protobuf← 正确答案
  • B.JSON← 正确答案
  • C.FlatBuffers← 正确答案
  • D.HTML

答案：ABC。Protobuf、JSON、FlatBuffers 都在 AI 编译器生态中被广泛用于计算图存储与交换，分别以高效二进制、高可读性、零拷贝解析见长。HTML 是网页标记语言，与计算图序列化无关。

Q9. 反序列化还原出的图结构与原图不一致，最不可能的原因是？

单选题 · hard

  • A.浮点数序列化时发生精度截断
  • B.图拓扑排序时破坏了边依赖顺序
  • C.元数据中张量名称映射错乱
  • D.模型文件存储时的磁盘碎片← 正确答案

答案：D。磁盘碎片只影响物理存储效率，不影响文件内容的逻辑解析，反序列化结果与之无关。A 的精度损失、B 的拓扑序破坏、C 的名称映射错误都会直接导致还原失真。

Q10. 设计模型序列化格式时，需要重点考虑哪些方面？

多选题 · hard

  • A.跨语言跨框架互操作性← 正确答案
  • B.版本演进的兼容策略← 正确答案
  • C.元数据完整保留机制← 正确答案
  • D.训练数据的标签分布

答案：ABC。互操作性决定格式能否在不同生态中通用，版本兼容策略保证新旧文件可共存，元数据机制确保图结构还原完整——这是序列化设计的三根支柱。D 训练数据标签分布与模型文件格式设计无关，正如菜谱无需记录顾客的口味统计。