Vulkan

核心事件 一名开发者在 Godot 4.7 引擎中成功实现了 Gemma 4 模型的原生运行，该项目完全基于 GDScript 和 Vulkan 计算着色器（Compute Shaders），彻底摆脱了对 llama.cpp、Python 或其他外部推理框架的依赖。 ▶ 技术突破：通过 Vulkan 计算着色器直接处理模型计算，并利用 GDScript 完成 GGUF 权重加载与分词（Tokenization），实现了真正意义上的“引擎原生”AI 推理。 ▶ 性能现状：作为实验性原型，其运行速度目前比经过高度优化的常规后端慢约 10 倍，主要受限于通用计算着色器的优化程度。 ▶ 适用范围：目前仅针对 gemma-4-E2B-it-Q4_K_M 模型进行了适配，展示了在游戏引擎内部构建闭环 AI 逻辑的可能性。 八卦洞察 这一项目的意义不在于其当前的推理速度，而在于它打破了 AI 与游戏引擎之间的“中间层壁垒”。长期以来，在游戏中集成 LLM 往往需要依赖复杂的外部库或 API 调用，这增加了分发体积和跨平台兼容性的难度。通过将推理逻辑直接写入 Vulkan 计算着色器，开发者证明了游戏引擎本身就具备成为“AI 运行时”的潜力。这种“去中间件化”的趋势，预示着未来动态 NPC 和即时叙事逻辑可能会像粒子效果一样，成为引擎底层渲染管线的一部分，而非昂贵的外部插件。 行动建议 对于独立游戏开发者和引擎架构师，建议关注 WebGPU 和 Vulkan 在非渲染计算领域的应用。虽然现阶段性能尚不足以支撑实时交互，但针对 1B-3B 规模的小型模型进行着色器级别的优化，将是实现低延迟、零依赖本地 AI 体验的关键路径。建议探索如何将矩阵运算与现有的 GPU 资源调度进一步解耦，以缩小与专用推理库的性能差距。

开发者 Piotr Wilkin (pwilkin) 近期在 llama.cpp 提交了编号为 #25051 的关键 PR，旨在让 Vulkan 后端的张量并行 (Tensor Parallelism, TP) 达到实际可用状态，这标志着非 NVIDIA 硬件在多显卡协同推理效率上迈出了重要一步。 ▶ 跨平台多卡协同： 该 PR 解决了 Vulkan 在多 GPU 环境下的同步与内存瓶颈，使得 AMD、Intel 及混合硬件阵营能够利用张量并行提升推理吞吐量。 ▶ 通信效率优化： 相比传统的流水线并行（Pipeline Parallelism），高效的 TP 能够显著降低多卡间的延迟，是运行超大规模参数模型（如 Llama-3-70B/405B）的核心技术。 八卦洞察 长期以来，多 GPU 扩展一直是 CUDA 的“领地”，尤其是 NVLink 提供的硬件级支持让 NVIDIA 在大模型推理市场稳坐江山。然而，llama.cpp 对 Vulkan TP 的持续优化，本质上是在软件层面通过算法补偿来抵消非 NVIDIA 硬件在互联带宽上的劣势。Piotr 的这一尝试如果成功，将极大释放存量 AMD/Intel 显卡的计算潜力，使得“廉价多卡集群”成为本地大模型部署的可行方案，进一步削弱 CUDA 的生态霸权。 行动建议 硬件部署： 建议拥有多块 AMD 显卡或混合显卡环境的开发者密切关注该 PR 的合并进度，在生产环境中尝试从流水线并行迁移至张量并行。 性能压测： 针对 70B 以上规模的模型，应重点测试 Vulkan TP 在不同 PCIe 带宽下的扩展效率，以评估其在非 NVLink 环境下的性能损耗比。 技术储备： 关注 Vulkan 1.3 及其相关扩展在分布式推理中的应用，这可能是未来绕过闭源生态实现高性能 AI 算力的关键路径。

核心事件 在 AMD Strix Halo（gfx1151）平台上，基于 llama.cpp 的基准测试显示，Vulkan 后端在运行 Qwen3.6-35B-A3B 模型时，其推理性能意外优于 AMD 原生的 ROCm 后端。 八卦洞察 ▶ 驱动成熟度鸿沟：ROCm 虽然作为 AMD 的高性能计算栈，但在消费级/移动端架构（如 Strix Halo）上的优化优先级仍滞后于通用的 Mesa RADV 驱动。 ▶ 跨平台抽象的胜利：Vulkan 作为一种图形 API，其在异构计算上的通用性正在弥补专用 AI 框架在特定硬件上的软件栈短板。 行动建议 ▶ 开发者：在 AMD 新架构硬件部署时，不要局限于 ROCm，应将 Vulkan 作为性能基准测试的必要选项。 ▶ 硬件厂商：AMD 需加速 ROCm 在移动端架构的兼容性与性能调优，避免在边缘 AI 市场被“通用驱动”反超。