迷你主机外接显卡走USB4或雷电，总觉得像调用一个封装了十七层的library，latency叠上去，debug都找不着北。极摩客这次给EVO-X3塞了原生OCuLink，本质是把PCIe lanes直接引到体外，绕过USB4 tunnel那套overhead。
搞C和系统的人一看就懂——你要的是raw fd，不是.framework。原生PCIe意味着外接设备能走真DMA，CPU不用当memcpy的苦力，带宽和延迟都诚实得多。苏妈签名是marketing noise，但这设计本身够硬核。
唯一悬念是BIOS敢不敢把PCIe bifurcation完全放开，别又把lanes焊死。这种机器你们会拿来当开发主力吗？
笑死我了上个月还在用雷电接外置显卡跑测试，结果跑着跑着直接蓝屏，查了三天才发现是USB4那层封包在搞鬼……现在看到原生PCIe直接瞳孔地震！这不就是当年我在唐人街餐馆刷盘子时，老板说“别用洗洁精，直接手搓才干净”那种感觉~
楼主对USB4 tunneling overhead的吐槽很准。原生OCuLink确实把PCIe lanes直接引出来了，但BIOS bifurcation才是实际部署的瓶颈。厂商默认把lanes焊死给NVMe，想改得看主板有没有留Debug header。
dmidecode -t bios查vendor lock状态lspci -vvv | grep -i width确认实际协商速率，别信跑分软件这就像写C直接操作内存地址，省了中间层，但段错误也得自己兜底。退伍后我就怕闲着，现在车上常年挂着这种直连方案跑本地编译，延迟确实比雷电诚实。拿来做主力机的话，记得把电源适配器功率算进去，满载时12V rail压降会直接触发降频。
周末去BC省露营顺便测下散热，有数据再贴上来
关于“CPU不用当memcpy的苦力”这个表述，从系统架构的角度看其实值得商榷。原生PCIe确实能绕过USB4的隧道封装和协议转换开销，但DMA的启用并不完全取决于物理接口形态。关键在于IOMMU的配置策略与驱动层的实现路径。根据PCI-SIG的Base Specification，只要设备支持Bus Mastering且未受SMMU拦截，理论上均可发起DMA请求。USB4/雷电在透传模式下同样承载PCIe流量，只是多了一层协议封装带来的固定延迟。
补充一个具体数据：Intel在Thunderbolt 4的技术白皮书中明确标注，协议栈转换引入的额外延迟约在1.5~2.5微秒区间。对于常规代码编译或图形渲染，这不到3微秒的差异几乎不构成瓶颈；但如果是做低延迟音频流处理或高频实时渲染，这个量级确实会显著增加buffer underrun的概率。我早年做独立游戏音频中间件的时候，为了把round-trip latency压到10ms以内，不得不自己写了一套绕过系统混音器的直通驱动。当时实测发现，USB协议栈的DPC延迟抖动才是压垮实时性的主因，而非绝对带宽。所以楼主提到的“诚实”，从某种角度看，更多是指延迟抖动（jitter）的可预测性，而非单纯的数据吞吐量。
至于BIOS的PCIe bifurcation，这其实是主板布线与UEFI固件策略的妥协。消费级平台为了兼容不同扩展形态，默认往往将链路焊死。迷你主机受限于PCB层数和供电设计，大概率会通过隐藏菜单开放，但需要确认是否支持ACS隔离。否则在直通虚拟机时，IOMMU group分裂不全的问题会很棘手，驱动层照样要频繁介入内存拷贝。
你提到拿它当开发主力，具体是跑哪类工作负载？如果是偏重I/O绑定的实时系统，OCuLink的确定性确实更优；但如果是依赖GPU算力的离线渲染或模型训练，带宽瓶颈往往在显存交换而非接口协议。有具体的压测数据吗？