结论：Chestnut（USB+AMD:LLVM）推理后端不是一条本地 GPU 数据路径，而是「USB 桥控制内存 + VRAM 映射 + PCIe BAR」三层地址空间叠加双缓冲拷贝协议的组合。主机侧分配即使请求 host=True 也仍落在 VRAM，CPU 访问必须经 USB 桥映射；一次逻辑 COPY 会被拆成多次 USB 传输与 GPU 端复制。因此「USB 接口能打开」既不等于 GPU 就绪，也不等于模型输出有效。以下为固定源码快照 c8fb906 及固定 tinygrad 归档的静态结构分析，缺少 LFS 模型实体与 Chestnut 实板，所有时序与故障判断均为源码推导。
从模型入口到设备的初始化链
load_oob() 在 Chestnut 路径选择 USB+AMD:LLVM；modeld.main() 先按模型产物、设备或线缆判断是否尝试大模型，并把 AMDDevice.wait_timeout_ms 设为 3000 ms，加载或运行失败的回退属于上层逻辑，不是 USB 后端自身的保证。AMDDevice.__init__() 负责选接口、校验 AMD 目标架构、初始化设备属性；USB 分支采用 USBAllocator，设置 4 MiB 运行时分配区，并安装 pm_usb_batch、pm_usb_lower 与 pm_usb_bufferize。一般的 PCI/KFD 路径不走这套 USB 改写。
USBIface.__init__() 从两个 USB VID/PID 集合中选设备，构造 USBPCIDevice 和 AMDev。后者先取得跨进程锁，创建 USB3，随后由 CustomASM24Controller 检查 LTSSM：未到 0x78 时尝试上电并复查，再配置 PCIe BAR。USB3 会读取产品字符串、必要时解绑内核驱动并重置设备、设置 configuration 并 claim interface。
这里必须区分三层资格：VID/PID 匹配、PCIe 链路建立（LTSSM 到 0x78）、AMD 架构校验。任何单一的 chestnutPresent 位都不代表 GPU 已准备好执行推理。
三种地址空间与缓冲所有权
USBIface.ctrl 把系统页、计算队列页和 512 KiB SRAM 映射到 GPU 虚拟区，主机持有桥的 dma_view；初始化时清空 fence 与 SRAM，防止沿用旧哨兵。USBIface.alloc() 与 USBAllocator.map() 的语义容易被误读：即使请求 host=True 也落在 VRAM，CPU 侧访问需通过 USB 桥映射，并非本机普通 DRAM。
| 层次 | 关键函数 | 源码契约 |
|---|---|---|
| USB 桥控制内存 | USBIface.ctrl |
系统页、计算队列页与 512 KiB SRAM 映射到 GPU 虚拟区；初始化清空 fence 与 SRAM。 |
| VRAM/CPU 可见视图 | USBIface.alloc()、USBAllocator.map() |
即使 host=True 也落在 VRAM；CPU 访问须经 USB 桥映射。 |
| PCIe BAR、XDATA、SRAM | USBMMIOInterface |
BAR 读写需 4 字节对齐；桥 XDATA 用 0xE4/0xE5，SRAM 用 0xF2 加 bulk 端点。 |
| 主机 staging 与传输结构 | _host_block()、_xfer() |
常驻 CPU 缓冲保存 libusb handle/context 与双半区 staging；提交后仍需保留源缓冲直至完成。 |
USB3.list_devices() 带 functools.cache，结果中的设备指针用 libusb_ref_device 保留。该实现未在此函数内定义重枚举失效，因此断开后同一进程再次选设备是否拿到最新列表，须通过模拟或实板验证，不应假设缓存会自动更新。
双缓冲复制协议与双半区
常量 HALF/CHUNK/SLOT 分别是 0x40000、0x40000-512、0x4000 字节：每个 SRAM 半区末尾预留哨兵块。usb_wire() 为载荷加 512 字节并向 slot 对齐；usb_chunks() 对输入用一个 CHUNK、对输出用两个 CHUNK 作为窗口，因此逻辑 COPY 可能拆成多次 USB 传输和 GPU 端复制。
usb_copy_rewriter() 只针对 host 与远端设备跨界的 COPY，按复制方向形成连续 run 并给每块编号；usb_copy_slicer() 在 GPU 提交图中插入等待、SRAM 复制、清哨兵与 usb_fence 更新。主机侧先用 usb_drained() 等待上轮完成，再通过 0xE5 设置 fence。
| 方向 | 主机侧 | GPU 侧 |
|---|---|---|
| host → GPU | usb_copyin() 轮换两个半区；usb_chunk() 等前次 transfer 与 fence、填 staging 哨兵、发 0xF2，再异步 bulk OUT。 |
等对应 SRAM 哨兵，复制载荷到目标 VRAM，清哨兵并更新 fence。 |
| GPU → host | usb_copyout() 先发 0xF2 arm read、写 usb_go，然后 bulk IN，再将两半区载荷复制回目标 host 地址。 |
等 usb_go，将 VRAM 复制到 SRAM 两半区，清 completion queue 并更新 fence。 |
usb_reap() 和 usb_drained() 都是条件轮询，本身没有显式墙钟超时。libusb 传输有各自的 timeout，USB3.bulk_wait() 会抛异步错误，但不能据此推断任一桥接 fence 永远有界完成。对新硬件必须分别故障注入「传输成功、GPU 不更新 fence」与「GPU 更新、USB 回执丢失」两类状态。
USB 访存降级与提交开销
pm_usb_lower 将远端参数缓冲的标量 load/store 改成 USB 读/写；usb_copy() 对可识别的连续 copy/fill 循环合并为 stream，不能识别时退为逐元素写。64 位 kernargs 写入由 usb_store() 拆为两个 32 位 0xF0 写；usb_load() 则通过桥的 PCIe read stream 读取。这些路径决定命令提交开销与异常时可能的部分写入状态，不是普通进程内内存赋值。
底层 USB3 使用控制传输与同步/异步 bulk；异步完成回调把状态锁存到 _async_err，等待方通过 bulk_wait() 消费事件并检查失败。桥的 pcie_request() 对读请求/配置写回执重试，对部分写操作走不等回执的快速路径。
| 故障层次 | 含义 | 不能推出 |
|---|---|---|
| USB 传输成功 | bulk/控制事务完成 | PCIe TLP 已被 GPU 接受。 |
| PCIe TLP 被接受 | 桥层读写回执正常 | GPU 队列已完成该命令。 |
| GPU 队列完成 | fence 被更新 | 模型输出数值有效。 |
| 模型输出有效 | 上层得到可用结果 | 安全放行条件成立。 |
测试证据与硬件验收
仓库存在 MockUSB3 和 mock GPU 环境，可作为后续隔离测试入口，但本文未运行 USB/AMD 模拟测试，也没有实板。建议先固定模型与目标固件版本、建立逐帧输入/输出数值基线；再量测分块、bulk、SRAM、VRAM、GPU 与回读的延迟分布；最后故障注入断连、重枚举、短传输、哨兵未清、fence 停止与 GPU 挂起。
模型回退、ChestnutActive 与 selfdrived 的控制退出需要联合验证，不能把 USB 接口可打开当作安全放行条件。
常见问题
Chestnut 路径下 host=True 的分配真的在主机内存吗？
不是。源文档说明 USBIface.alloc() 与 USBAllocator.map() 即使请求 host=True 也落在 VRAM，CPU 侧访问必须通过 USB 桥映射，并不是本机普通 DRAM。
USB 传输成功就说明 GPU 已经算完了吗？
不等价。源文档把故障归因分为四层：USB 传输成功、PCIe TLP 被接受、GPU 队列完成、模型输出有效。它们逐层递进，任一层成功都不能推出下一层成立。
一次 COPY 会变成几次 USB 传输？
不固定。逻辑 COPY 可能被拆成多次 USB 传输和 GPU 端复制：usb_chunks() 对输入用一个 CHUNK、对输出用两个 CHUNK 作为窗口，usb_copy_rewriter() 还会按方向形成连续 run。
拔插设备后同一进程会重新枚举吗？
源文档未给出重枚举失效机制。USB3.list_devices() 带 functools.cache，设备指针用 libusb_ref_device 保留，但该函数没有定义缓存失效，须通过模拟或实板验证，不能假设会自动更新。
延伸阅读
- Chestnut USB 固件：刷写与设备告警边界 —— 本文只谈运行时数据路径，刷写与告警另见固件专题。
- 硬件后端 USB 快照契约 —— USB 后端如何描述设备快照与资格层次。
- panda USB 分片组装 —— 另一处把大载荷拆成多次 USB 传输的实现对照。
- openpilot 的 100 Hz 控制回路 —— 推理后端延迟最终要落进控制节拍的时延预算。
参考资料
- 项目 02 ——
openpilot-research/TINYGRAD_CHESTNUT_USB_AMD_BRIDGE_DEEP_DIVE.md（USB/AMD 初始化链、三种地址空间、双缓冲复制协议与故障分层）。 - 项目 02 ——
openpilot-research/同目录 Chestnut 与 HCQ 专题（固件刷写、通用队列链接作为相邻边界参考）。
说明：本文为对固定源码快照的静态结构分析，未运行完整测试套件、未连接硬件、未验证目标车型的真实参数组合。文中所有阈值、行号索引与配置均出自源文档，标注为未验证的结论保留其原有边界。
更新记录
首次发布 2026-10-11 最近核对：2026-10-11