结论：openpilot 的 modeld 走的是「捕获图一次链接、逐帧重放」的执行链，而不是每帧重新生成模型：lower_and_compile() 按编译键去重并把 SINK/PROGRAM 编译为程序，CapturedJit.linear 首次访问时 link_linear(..., allow_cache=False) 并把链接结果缓存。要替换推理硬件，不只是实现一个算子 API，还必须同时保持 Buffer 映射、命令提交、同步与编译产物契约。源文档列出四类已用后端（CPU:LLVM、METAL、QCOM、USB+AMD:LLVM），并明确后端类存在不等于当前机器能打开设备。
从 JIT 到执行器：捕获图如何被补齐
modeld.ModelState.__init__() 装入模型/warp 产物，对捕获图调用 lower_and_compile()。后者识别尚未完成的 SINK/PROGRAM，按编译键去重，编译为程序并替换进调用图。它不等同于每帧重新生成模型。
_TinyJit.__call__() 在重放时比较输入名称与输入视图、变量、dtype、设备等签名；CapturedJit.linear 首次访问时调用 link_linear(..., allow_cache=False)，把链接结果缓存在该捕获对象中。随后 CapturedJit.__call__() 替换需写入的输入，调用 run_linear(..., jit=True)，返回捕获时的返回对象。
run_linear() 的 jit=True 路径直接执行已链接的 LINEAR；普通路径先 compile_linear() 和 link_linear()。pm_exec 将 COPY、PROGRAM、graph、校验等调用分发到不同执行器；带 HCQInfo 的调用经 exec_hcq() 处理地址表、队列执行及必要同步。
在这条 HCQ 路径里，hcq_compile() 对调用图进行缓冲参数替换、复制 staging、分批、命令编码和程序编译，hcq_link() 处理链接期缓冲与地址。源文档据此总结：推理硬件替换不仅是实现一个算子 API，还要保持 Buffer 映射、命令提交、同步和编译产物契约。
内存与传输的四条边界
| 边界 | 已核对实现 | 对新硬件的含义 |
|---|---|---|
| 缓冲别名 | Buffer.view() 保留 base/offset；allocate() 为视图取得底层存储并追踪已分配视图 |
输入切片与跨帧状态不能被当成独立存储；重置和释放顺序要保持别名关系 |
| 输入复制 | Buffer.copy_from() 构造 COPY 的 LINEAR 并调用 run_linear()；exec_copy() 依设备能力选择传输 |
一次 copy_from() 是逻辑上传，不保证任何后端都只做一次物理 DMA 或没有同步 |
| 外部图像指针 | Tensor.from_blob() 用 external_ptr 分配但不接管原内存；QCOM 分配器进入用户内存映射 |
座舱图像指针必须在 GPU 使用完毕前有效；相机 ringbuffer 重用和重连需要台架验证 |
| 回读 | Buffer.as_memoryview() 对 host 可见存储先同步，否则经 PYTHON 缓冲复制 |
输出 .numpy() 是同步/传输边界，不能仅用 GPU kernel 耗时估计帧级延迟 |
源文档把「外部图像指针」与「回读」特别分开：Tensor.from_blob() 用 external_ptr 分配但不接管原内存，QCOM 分配器进入用户内存映射，因此座舱图像指针必须在 GPU 使用完毕前保有效；相机 ringbuffer 重用与重连需要台架验证。
四类设备后端与各自待验证项
| 路径 | 关键入口及源码行为 | 尚需验证 |
|---|---|---|
PC CPU:LLVM |
CPUDevice 选 HostAllocator、LLVM renderer 和 CPUProgram；程序可通过本机可执行内存调用 |
目标 CPU 指令集、编译器/LLVM 版本、数值和最坏时延 |
macOS METAL |
MetalDevice 创建设备与命令队列；程序绑定缓冲并提交命令，wait 时检查错误 |
macOS/Metal 版本、虚拟化环境 graph 限制、异步错误和回读时延 |
AGNOS QCOM |
QCOMDevice 打开 KGSL、创建上下文并校验 GPU 代际；_gpu_map() 处理外部 CPU 指针 |
SoC/KGSL 兼容性、相机内存映射、缓存一致性及异常后的输出门控 |
Chestnut USB+AMD:LLVM |
AMDDevice 选接口与 renderer；USB 接口发现特定设备，经控制窗口和 VRAM 管理提交 |
USB 断连/复连、传输峰值、显存故障、超时回退及大小模型切换后的状态一致性 |
Device.__getitem__() 懒加载设备，Compiled._select_renderer() 按 DEV 目标挑选 renderer；源文档明确后端类存在不等于当前机器能打开设备。Compiled.synchronize() 等待本设备 timeline 与跨设备 pending，并在超时/故障时进入 on_device_hang()；这只是运行时故障检测，不是车辆安全退出策略。
四类后端都通过 DEV 目标选择 renderer，但设备打开方式、命令提交与同步机制各不相同：CPU 走本机可执行内存，METAL 走命令缓冲，QCOM 走 KGSL 与外部映射，USB+AMD 走控制窗口与 VRAM 管理。源文档把外部指针失效、USB 断连、GPU 挂起与配置不匹配列为需要故障注入的对象，并明确这些结论来自对 modeld 实际调用路径的审阅，不代表 tinygrad 全部算子、调度优化或设备驱动均已审计。
modeld 设置 AMD 等待超时并保留小模型回退。车辆控制仍必须由 selfdrived/panda 安全链约束，推理后端的替换不能改变这条约束。
验证缺口与顺序
现有测试入口有 JIT 单元测试、JIT 后端测试和 HCQ 测试，但本次未运行，不能替代 openpilot 实际模型及设备验证。源文档给出的顺序是：先补齐 LFS 与编译产物，在目标平台运行固定日志的道路/座舱模型数值对比；随后测量上传、warp、模型、回读和异常切换的分项与最坏时延；最后做外部指针失效、USB 断连、GPU 挂起和配置不匹配的故障注入。测试通过前不应把该后端视作可上车的插件。
源文档还列出 modeld 对 AMD 的等待超时与小模型回退属于待验证项，其大小模型切换后的状态一致性要与 USB 断连/复连一起测试。
常见问题
每帧推理都会重新编译模型吗？
不会。lower_and_compile() 识别尚未完成的 SINK/PROGRAM 并按编译键去重，编译一次后替换进调用图；CapturedJit.linear 首次访问时链接并把结果缓存到该捕获对象，重放时按签名校验后直接执行。
一次 copy_from() 是否等于一次物理 DMA？
不等同。源文档指出它是一次逻辑上传：Buffer.copy_from() 构造 COPY 的 LINEAR，exec_copy() 依设备能力选择传输、磁盘复制、共享 host 映射或 CPU 拷贝，不保证只做一次物理 DMA 或没有同步。
输出 .numpy() 能用来估算帧级延迟吗？
不能直接用来估算。Buffer.as_memoryview() 对 host 可见存储先同步，否则经 PYTHON 缓冲复制，源文档明确它是同步/传输边界，只能配合分项时延测量使用。
后端类存在是否说明当前设备可用？
不说明。Device.__getitem__() 懒加载设备、Compiled._select_renderer() 按目标挑 renderer，源文档明确后端类存在不等于当前机器能打开设备。
延伸阅读
- tinygrad 张量调度与内存 —— 执行链上游的调度与内存布局基础。
- tinygrad GPU 显存分配与页表所有权 —— 缓冲分配与外部指针的所有权细节。
- 推理硬件后端 USB 快照契约 —— 另一处设备后端与主机传输的边界定义。
- Chestnut USB/AMD 桥 —— USB+AMD 路径从设备发现到提交的展开。
参考资料
- 项目 02 ——
openpilot-research/TINYGRAD_ENGINE_BACKENDS_DEEP_DIVE.md（取用了 JIT 到执行器的调用链、内存与传输边界表、四类后端待验证项清单）。
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11
发表回复