第3章 Runtime推理引擎：对象、内存与调度

第3章 Runtime推理引擎：对象、内存与调度

本章要回答的三个问题：Core、Model、CompiledModel、InferRequest 这四个对象各管什么、生命周期与线程边界在哪里？数据在内存里怎么流动、零拷贝什么时候成立？同步异步、性能提示、多设备模式这三层调度决策怎么做？

为什么会有这一章

第 2 章交付的 IR 还只是一份「图纸」，这一章让它变成跑在设备上的服务。多数教程把这章写成 API 速查——列出类名和方法就完事——结果是读者能拼出能跑的代码，却答不出三个致命问题：为什么每帧都重新编译会把性能拖垮？为什么传进去的张量「看起来一样」却慢了三成？多线程推理到底哪些对象能共享、哪些绝对不能？这三个问题的答案都在机制里：对象的生命周期、张量的内存身份证、调度决策的三层结构。本章按机制组织，API 只是机制的注脚。

还有一层原因：第 4 章以后的优化与排错全部依赖本章的概念——性能归因要报出「配置是否生效」（属性系统），流水线设计要依赖「请求级线程纪律」，量化收益验证要靠「基准与提示对齐」。没有这一章的词汇表，后面几章的对话都无法进行。

读完能解决什么

对照开头的三个问题，读完本章你应当能：写出「贵操作在循环外」的姿势正确推理程序，说清四个对象谁生谁、谁能多线程共享、谁必须一请求一份；把张量四要素当检查清单用，判断一次传递是零拷贝还是隐式拷贝，并把预处理搬进模型省掉一次内存往返；按「调用方式、性能提示、设备编排」三层结构做调度决策——交互场景选同步加延迟优先，持续负载选异步加吞吐优先，通用发布包交给 AUTO；最后，把多路视频这类真实负载的线程模型设计出来，而不是靠试错碰运气。

各节怎么分工

三节的推进逻辑是「骨架、血液、神经」：先立对象骨架，再通内存血液，最后接上调度神经。顺序不能倒——不理解对象边界就谈并发，不理解内存就谈性能，都是空中楼阁。

读完自测：五问检验

一问：Core、Model、CompiledModel、InferRequest 四者中，哪两个的创建开销大到必须放循环外？为什么。二问：单个 InferRequest 被两个线程同时使用，会发生什么？正确做法是什么。三问：一个张量传进推理后布局不符，运行时会报错还是变慢？这个行为差异对排错意味着什么。四问：交互式助手与离线视频转写，各自的调用方式与性能提示组合是什么？把 3.3 节的组合口诀默写出来。五问：AUTO、MULTI、HETERO 三个模式，哪一个适合当性能优化手段？为什么是陷阱。五问的答案没有超出本章三节，但如果任何一问答得犹豫，建议回到对应小节再过一遍——第 4 章之后的所有优化动作，都默认这些纪律已经长在手上。

本章高频追问

两个阅读前的高频疑问先答掉。一问：「我已经能让模型跑起来了，这章是不是只对追求极限性能的人有用？」——恰恰相反，本章的主线是「正确的姿势」而非「极限的优化」：请求复用、线程纪律、零拷贝判断，这些是任何规模的项目都该一次做对的底架，补课的成本远高于一次学对。二问：「三层调度是不是要全学完才能写代码？」——不是，先掌握第一层(同步与异步)就能覆盖原型期的全部需求，第二三层在服务化阶段再回来精读即可；但读第 4 章之前，请至少把 3.3 节的性能提示概念弄清，量化收益的验证要用它。

先决条件

需要第 2 章的出口物：一份合法 IR 与对拍报告。代码层面要求能读写基础 Python；异步与队列的概念会在 3.3 节用到，现场补也来得及。多线程经验不是必须——本章的三条线程纪律正是为没有多线程经验的读者准备的护栏。

往下走到哪

本章的出口是一个「姿势正确的推理骨架」——它是第 4 章优化的载体：量化改变模型，调度与内存的姿势决定优化收益能不能兑现。读完下一章你会发现，性能优化的动作一半在模型侧，另一半早在这一章的调度决策里写好了。