不考虑性能权衡，仅搭载GPU的设备能否独立运行OS？

先给明确结论：哪怕完全忽略延迟问题，现有通用GPU也无法原生独立运行完整的通用操作系统，核心限制根本不在计算能力，而是硬件架构和配套能力的底层差异。

• 首先是架构设计的核心定位差异
  CPU是为通用串行控制流设计的，自带复杂的独立控制单元、分支预测逻辑、多特权级支持、硬件中断处理机制，这些都是操作系统内核的核心依赖——操作系统绝大多数时间不是在做并行计算，而是在处理中断、调度进程、切换上下文、管理外设，这些逻辑都是强串行、强控制依赖的。而GPU的SIMT架构是为并行计算设计的，几十上百个计算核心共享一套取指、译码单元，根本没办法独立处理不同核心的异构串行控制流，原生不支持中断、特权级切换这类操作系统必需的硬件特性。

• 其次是指令集和硬件控制能力的缺失
  x86、ARM等通用CPU的指令集原生支持MMU页表操作、权限校验、外设IO控制等指令，而CUDA、ROCm等通用GPU的指令集完全是为并行计算设计的，没有这类控制类指令的硬件实现，连最基础的内核态/用户态隔离、进程地址空间隔离都做不到，根本没办法把通用操作系统内核移植到纯GPU上运行。

• 最后是外设交互能力的天然不足
  通用GPU本身只是PCIe总线上的一个外设，没有集成独立的中断控制器、存储控制器、外设总线控制器，没办法直接接管硬盘、网卡、输入设备等其他外设的控制权，连操作系统启动最基础的「从存储介质加载内核镜像」这个步骤都没办法独立完成，更别说后续的系统运行了。

如果你说的「运行操作系统」包含用GPU软件模拟完整CPU架构的场景，那理论上确实可以实现——毕竟图灵完备的计算系统都可以互相模拟，但这种场景本质上是把GPU当计算载体跑CPU模拟器，不是GPU原生运行操作系统，而且延迟会高到完全不可用，刚好被你提到的「不考虑延迟」的前提覆盖，但没有实际工程意义。目前市面上没有纯GPU设计能覆盖CPU的控制类硬件能力，哪怕是集成了GPU的异构SoC，本质上还是靠CPU模块来运行操作系统，GPU只是计算加速单元。

内容的提问来源于stack exchange，提问作者Averrous Saloom