把大模型塞进手机游戏：LLMUnity 与 MLC-LLM 的端侧部署实战

一、先在 Unity 编辑器里跑通#

第一步用 LLMUnity 插件在编辑器里把链路打通。模型选 Qwen 0.6B / 1.7B 这个量级——端侧设备的现实约束下，参数量只能这么大。挂好插件、配好模型路径后，编辑器里的对话 demo 可以正常工作：

接着尝试接入更大的 Gemma3-4B，验证插件对不同模型结构的兼容性。

第一个坑在构建环节：打 Android 包时报错，排查下来是 Gradle 8.13 + Kotlin 2.1.0 组合的兼容性问题，需要调整版本搭配才能出包。

二、真机运行与滑动窗口修复#

包打好后部署到 Android 真机。长对话场景下遇到一个典型问题：上下文超出窗口后模型输出异常。原因是 LLMUnity 的滑动窗口（sliding window）处理有缺陷，上下文淘汰逻辑需要手动修复。修复后长对话可以稳定运行：

三、LLMUnity vs MLC-LLM 性能对比#

两条路线在同一台 Android 设备上做了推理速度对比：

结论有点反直觉：

• LLMUnity（llama.cpp 路线）更快——但它在 Android 上走的是 CPU 推理。CPU 长时间满载意味着发热、耗电、以及和游戏本身的渲染线程抢资源，对一个要长时间运行的游戏来说不可接受。
• MLC-LLM 支持 GPU（OpenCL/Vulkan）推理，架构上更适合游戏场景，但工程链路复杂得多。

所以真正的工程问题不是”哪个快”，而是怎么把推理从 CPU 挪到 GPU。

四、MLC-LLM 的现实困难#

切到 MLC-LLM 路线后遇到的第一个问题：官方 Unity 相关的预编译产物只带了 RedPajama-INCITE-Chat-3B——一个明显过时的老模型。

解决办法比较”野”：下载 MLC 官方最新的 Android apk，解包提取出其中的 jar/运行时库，再用官方工具链自己编译目标模型（Qwen 系列），把新运行时和新模型组装进 Unity 工程做成 SDK。

这条路走通后，Android 上的 GPU 推理最终落地，替换掉了 CPU 方案。

五、经验总结#

1. 端侧模型选型先看设备预算：0.6B–1.7B 是目前手机上体验和资源占用的平衡点，4B 已经是上限
2. “快”要看在什么硬件上快：llama.cpp 的 CPU 推理速度不差，但游戏场景必须把 CPU 让给渲染和逻辑，GPU 推理是刚需
3. MLC 生态的预编译产物普遍滞后：想用新模型就要接受自己编译的成本，解包官方 apk 提取运行时是可行的捷径
4. 长对话必须验证上下文淘汰：滑动窗口的正确性在 demo 阶段很容易被忽略，上线前一定要做长对话压测

端侧 LLM 在游戏里的应用还处在”能跑”到”好用”之间，但链路已经完整验证：模型量化、引擎插件、构建适配、GPU 推理，每一环都有坑，也都有解。