GDScript+Vulkan在Godot中运行Gemma大语言模型实验

一个大胆的实验：LLM能否在游戏引擎里原生运行？

最近，GitHub用户 asallay 在Reddit上分享了一个颇具挑战性的实验：不依赖llama.cpp、Python、外部服务器，甚至不用GDExtension，仅凭Godot引擎自带的GDScript与Vulkan计算着色器，直接在游戏引擎内部跑起了一个大语言模型。

这个项目基于Godot 4.7，运行的是gemma-4-E2B-it-Q4_K_M.gguf模型——一个经过4-bit量化的Gemma系列小模型。Gemma是Google DeepMind于2024年推出的开放权重（Open Weights）模型系列，基于与Gemini相同的研究成果和技术蒸馏而来。与完全开源（代码+权重+训练数据全部公开）不同，「开放权重」策略意味着模型参数可免费下载使用，但训练数据与完整训练流程通常不公开——这已成为Meta Llama、Mistral等大型科技公司平衡商业利益与社区影响力的主流选择。通过知识蒸馏（Knowledge Distillation）技术，Gemma能从更大规模的Gemini模型输出分布中学习，使得参数量小得多的Gemma在推理能力上仍可接近其「教师模型」。

Gemma 4是该系列的第四代，采用混合专家架构（MoE，Mixture of Experts）。这一架构将传统前馈网络层替换为多个「专家」子网络，由轻量级「路由器」网络决定每个token激活哪几个专家——通常只激活全部专家中的Top-2或Top-4。E2B后缀表示「Effective 2B」——虽然模型总参数量更大，但每次推理只激活约20亿有效参数，用户感知到的是「2B规模的推理成本」，却能享受到更大模型总容量带来的能力提升，兼顾了能力与效率。

GGUF是由llama.cpp项目于2023年引入的模型权重存储格式，它将模型的权重数据、超参数、词表等所有推理所需信息打包进单一文件，极大简化了模型分发与加载流程。Q4_K_M则代表一种具体的量化方案：将模型权重从32位浮点数压缩为4-bit低精度表示，使用K-means分组策略的中等质量版本，可在精度损失可接受的前提下将模型体积缩减75%以上，使其能在消费级硬件上运行。整个推理流程完全封闭在Godot生态内完成，没有任何外部依赖。虽然作者反复强调「这只是一个实验」，但其技术路径的完整性与可行性，仍值得认真拆解。

技术架构：计算与逻辑的分工

这个项目最有意思的地方，在于它把大模型推理的两大类工作，清晰地分配给了Godot的两套机制。

Vulkan计算着色器负责「算力」

大语言模型的核心是海量的矩阵运算。这些运算的根基是2017年由Vaswani等人在论文《Attention Is All You Need》中提出的Transformer架构。该架构彻底取代了此前主流的RNN/LSTM序列模型，其核心创新「自注意力机制（Self-Attention）」允许模型在处理每个token时，同时关注序列中所有其他位置的信息，突破了RNN因顺序计算带来的长距离依赖瓶颈。注意力计算围绕Q（Query）、K（Key）、V（Value）三个矩阵展开，其计算复杂度为O(N²)——这也正是后文KV Cache优化如此重要的根本原因。

值得一提的是，O(N²)的复杂度不仅是KV Cache优化的直接动因，也催生了整个「高效Transformer」研究方向：Linformer通过将注意力矩阵低秩分解将复杂度压缩至O(N)；Longformer引入局部窗口注意力与少量全局token相结合的稀疏注意力机制，专门应对长文本场景；而FlashAttention则从IO感知（IO-Aware）角度重新设计计算顺序，将注意力矩阵的计算拆分为分块（Tiling）方式，在不改变数学等价性的前提下大幅减少对高带宽内存（HBM）的访问次数，成为目前几乎所有主流推理框架的标配优化。理解了O(N²)这一根本约束，就能理解过去五年GPU推理优化领域绝大部分工作的核心动机。

作者把这些计算密集型任务全部下放到**Vulkan计算着色器（Compute Shaders）**中执行。

Vulkan是由Khronos Group于2016年发布的新一代图形与计算API，旨在取代OpenGL，提供更低的驱动开销和更精细的硬件控制。与OpenGL不同，Vulkan从设计之初就将「图形渲染」和「通用计算」视为平行能力——计算着色器允许开发者直接在GPU上执行任意并行计算任务，而不必将数据伪装成纹理或图形管线的一部分。

GPGPU（通用GPU计算）的理念在2007年随NVIDIA CUDA的发布而进入主流视野。在此之前，将非图形计算任务映射到GPU上需要将数据「伪装」成纹理，代码极难编写维护。CUDA通过为C语言添加少量扩展，让开发者能以接近普通编程的方式调度GPU并行计算，开创了深度学习计算的硬件基础。当前GPU计算生态分为三条主要路径：NVIDIA CUDA（封闭但极致优化，主导AI训练与推理市场）、已逐渐式微的OpenCL，以及以Vulkan/Metal/DirectX 12 Compute为代表的现代图形API计算路径。

值得一提的是，OpenCL由Khronos Group推出，设计目标是跨厂商的通用计算标准，但因不同厂商实现质量参差不齐、缺乏统一优化生态而逐渐式微——Vulkan计算着色器在跨平台性上继承了OpenCL的优势，同时因其与现代图形管线深度集成、驱动开销极低而获得更广泛的工业支持。此外，WebGPU标准亦以Vulkan为主要设计参考，两者在API设计哲学上高度一致，使得本文探索的技术路径与近年来WebGPU环境下的本地LLM运行探索（如WebLLM项目）形成深层技术呼应。

Vulkan的计算着色器在设计理念上与CUDA相似，但更具跨平台优势——同样的着色器代码可以在NVIDIA、AMD、Intel显卡乃至移动端GPU（Mali、Adreno等）上运行，而CUDA仅限NVIDIA硬件。这一跨平台特性在移动端尤为突出：ARM Mali和高通Adreno系列GPU均完整支持Vulkan计算能力，意味着本项目的技术路径理论上可延伸至Android平台，在端侧AI推理快速发展的背景下具有特殊的延展价值。代价是Vulkan缺乏CUDA生态多年积累的针对机器学习负载的高度优化库（如cuDNN、cuBLAS、FlashAttention等专为Transformer架构调优的库），这也是本项目性能与CUDA方案存在差距的根本原因之一。Godot 4在渲染架构上完成了从OpenGL到Vulkan的重大迁移，并通过RenderingDevice API将底层Vulkan能力暴露给开发者，使得在游戏引擎内直接调度计算着色器成为可能。

这意味着，模型的前向传播、注意力机制中的矩阵乘法等运算，实际上跑在GPU上，而调度它们的却是游戏引擎的渲染后端。这是一个相当巧妙的「借力」——把原本为图形渲染准备的GPU通用计算能力，直接用于深度学习推理。

GDScript负责「逻辑」

除了纯计算部分，一个能对话的LLM还需要大量的「胶水逻辑」。作者用GDScript实现了以下几个关键模块：

• GGUF文件加载：解析llama.cpp生态通用的模型权重格式；
• Tokenization（分词）：将输入文本转换为模型可理解的token序列。现代大语言模型并不直接处理字符或单词，而是将文本切分为子词单元。这一机制普遍基于BPE（Byte Pair Encoding，字节对编码）算法——该算法最初是数据压缩技术，后被引入NLP领域：从字符级别出发，反复合并语料库中出现频率最高的相邻符号对直至达到预定词表大小，自然处理了未登录词问题（例如「unbelievable」可被分解为「un」「believ」「able」三个子词）。BPE的一个重要变体是字节级BPE（Byte-level BPE），GPT系列模型采用此方案——它以原始字节而非Unicode字符为基本单位，从根本上消除了未登录字符问题，使得任何语言、任何特殊符号都能被无损编码。Gemma系列使用的SentencePiece分词器则在BPE基础上进一步引入了Unigram语言模型作为备选策略，词表约含256,000个条目，这意味着GDScript需要处理相当规模的词表数据结构；
• Sampling（采样）：从模型输出的概率分布中选取下一个token。大语言模型最后一层输出词表上的logits，经Softmax变换后得到概率分布。常见策略包括：Temperature采样（通过调节系数控制分布的「尖锐程度」，T<1输出更保守，T>1输出更多样）和Top-P采样（动态保留累积概率超过阈值P的最小token集合再采样，避免采到低概率的「奇怪」词），实际部署通常同时使用两种策略。此外，近年来还涌现了Min-P采样（以最高概率token的某个比例为动态阈值）、Mirostat等自适应采样算法，它们在保持输出多样性的同时更好地避免「概率崩塌」问题，已被Ollama等工具默认采用；
• KV Cache（键值缓存）：Transformer模型以自回归（Autoregressive）方式生成文本——每次只输出一个token，再将其追加到序列末尾重新预测下一个token。这一推理流程可细分为两个特征截然不同的阶段：Prefill阶段（将输入prompt的所有token并行送入模型，计算密集型）和Decode阶段（逐token自回归生成，内存带宽密集型）。若不加优化，对于长度为N的序列，生成第N+1个token时会对前N个token重新计算一遍注意力机制中的Key和Value矩阵，时间复杂度为O(N²)。KV Cache通过在显存中持久化存储历史序列的K/V张量，使每次前向传播只需计算新增token的部分，将复杂度降低到近似O(N)，是将生成速度提升数倍的关键优化手段。在多轮对话或长上下文场景下，KV Cache的显存占用会随序列长度线性增长，这也催生了PagedAttention（vLLM采用）等内存管理技术——借鉴操作系统虚拟内存的分页思想，将KV Cache切分为固定大小的「页」动态管理，显著提升了显存利用率。在本项目中，KV Cache由GDScript管理数据结构、由Vulkan着色器读写GPU显存，这种跨语言、跨计算单元的协调调度本身就是相当复杂的工程挑战；
• Chat UI：直接用Godot的UI系统搭建对话界面。

从读取模型文件到最终在界面上输出文字，整条链路都由一门通常被认为「只适合写游戏逻辑」的脚本语言完成，这本身就打破了不少人对GDScript能力边界的固有认知。

性能现实：比CUDA方案慢约10倍

作者坦诚地给出了性能数据：这套方案的运行速度大约是llama.cpp + CUDA的1/10。

这个差距在意料之中，且有其深层的技术原因。llama.cpp是专为LLM推理深度优化的C++项目：在CPU路径上，它使用手写的AVX2/AVX-512 SIMD指令集优化矩阵运算，并为不同量化方案设计了专用的反量化核心；在GPU路径上，CUDA后端利用cuBLAS、CUTLASS等NVIDIA官方库，以及针对LLM工作负载专门调优的自定义CUDA kernel，能充分发挥Tensor Core等硬件单元的吞吐量；此外，FlashAttention等专为Transformer架构设计的分块计算算法通过避免将完整注意力矩阵写入显存，显著降低了内存带宽瓶颈，已成为专业推理框架的标配优化。

在本地推理生态中，MLC-LLM（Machine Learning Compilation for LLM）是另一个值得对比的参照——它基于Apache TVM编译框架，专注于将LLM推理编译到WebGPU、Metal、Vulkan等多个后端，思路与本文项目高度相似。MLC-LLM的核心竞争力在于其编译期自动调优机制（AutoTuning）：针对目标硬件自动搜索最优的计算分块大小、内存布局和调度策略，将通用着色器代码转化为接近手写优化kernel的性能。这一路径代表了「无CUDA依赖本地推理」的一种更成熟的工程方向，也说明了本项目与生产级方案之间差距的主要来源——不是Vulkan作为计算后端的根本性能上限，而是缺乏这一层编译期自动优化的工程投入。

相比之下，通用Vulkan计算着色器虽然跨平台，但目前缺乏这一层级的深度硬件级优化；加之GDScript本身是解释执行的动态语言，在处理分词、采样等逻辑时也无法与编译型C++的性能相比。这10倍的差距，实际上反映了「通用性」与「极致优化」之间不可避免的权衡。

此外，项目目前只支持这一个特定模型，通用性也十分有限。从「实用工具」的角度看，它显然还不成熟。但若将其定位为「概念验证（Proof of Concept）」，它已完美达成目标——证明了在纯Godot环境下运行LLM是可行的。

这个实验的真正价值在哪里？

既然比llama.cpp慢十倍，又只支持一个模型，这个实验究竟有何意义？

零依赖带来的部署想象力

最直接的价值在于部署的极简化。如果一款游戏或应用本身基于Godot开发，内置本地LLM将不再需要打包Python运行时、不需要捆绑llama.cpp二进制文件、不需要额外的GDExtension编译。整个AI能力就是引擎项目的一部分，跨平台特性也能天然继承Godot的能力。

这一探索方向契合了更宏观的行业趋势：AI推理从云端向边缘/本地迁移。这一趋势的驱动力是多维度的——数据隐私法规（GDPR等）要求用户数据不离开设备；网络延迟对游戏等实时交互场景不可接受；云端API调用成本随规模线性增长而本地推理边际成本趋近于零；以及离线场景的可用性需求。2023年前后，llama.cpp项目的出现是本地推理普及的关键节点，其作者Georgi Gerganov证明了在MacBook上流畅运行7B参数模型的可能性，引发社区爆发式跟进，Ollama、Jan等本地推理工具随之涌现。从更长的时间轴看，这一趋势还得到了硬件侧的配合：Apple M系列芯片将CPU与GPU统一内存（Unified Memory）架构带入消费市场，消除了CPU-GPU数据传输瓶颈；高通骁龙X系列PC芯片内置NPU并提供本地AI SDK；Intel Core Ultra系列同样集成了专用AI加速单元。硬件与软件生态的双向演进，正在使「本地运行10B以下参数模型」逐步从技术极客的专属领域走向普通用户。这些因素共同推动了本地推理工具在近两年的快速兴起。对于想在游戏中集成本地智能NPC、对话生成或剧情辅助的独立开发者来说，云端API面临延迟、成本、审核和离线可用性等多重障碍，「一切都在引擎内」的方案因此有着独特吸引力。

对Godot计算能力的边界探索

这个项目同时也是对Godot 4底层能力的一次极限压测。它证明了RenderingDevice和计算着色器接口，已经足够强大到可以承载深度学习推理这类高强度通用计算任务。这为Godot在游戏之外的应用场景（如科学计算、AI工具开发）打开了更大的想象空间。

值得关注的是，Godot 4的RenderingDevice API在设计上刻意暴露了底层Vulkan的大部分能力，包括计算管线（Compute Pipeline）的完整控制权、StorageBuffer的直接读写以及同步屏障（Barrier）管理。这意味着开发者理论上可以在Godot内实现任何可以在Vulkan上实现的通用计算任务，而不仅限于图形渲染。本项目正是将这一设计哲学推向了一个极端的验证场景。

教育与研究意义

由于整个推理流程都用相对易读的GDScript实现，逻辑没有被C++的深度优化所遮蔽，这个项目实际上是一份很好的LLM推理原理学习材料。想理解GGUF格式如何解析、KV Cache如何工作、采样策略如何实现的开发者，可以在这里找到一份不依赖复杂框架的透明实现——从BPE分词、自回归生成的Prefill/Decode两阶段机制，到Temperature/Top-P采样的每一个环节都清晰可见，是学习大模型推理机制难得的「拆开来看」案例。

与之对比，llama.cpp虽是最接近「可读性」的生产级C++实现，但其数万行代码、大量平台特定的SIMD优化路径以及多种量化方案的并行实现，对初学者仍构成不小的认知门槛。本项目的GDScript实现虽然性能有限，但在「让人看懂LLM推理的每一个步骤」这一教育目标上，反而有着独特的清晰度优势。

结语：可能性本身就是意义

作者分享时写下的最后一句话，很能代表这类实验的精神：「Still, I found it interesting that this was possible using only Godot.」（尽管如此，我觉得仅用Godot就能做到这件事本身就很有趣。）

技术社区的很多突破，正源于这种「能不能做到」的纯粹好奇心。这个项目或许永远不会成为生产环境的首选，但它拓展了游戏引擎的能力边界，也为「边缘设备本地AI」这一趋势提供了一个另类而有趣的参考样本。

项目已在GitHub开源（asallay/godot-llm），感兴趣的开发者可以自行研究这套「纯Godot跑大模型」的完整实现。

核心要点