LLMUnity：把 llama.cpp 塞進 Unity 場景的 C# 封裝
Create characters in Unity with LLMs!
秒懂
- 它是什麼？
- LLMUnity 讓 Unity 專案在執行期直接載入本機 LLM，並附帶一套 RAG 語意檢索。它的價值在於離線與跨平台，代價是把模型檔、記憶體與推論後端的管理責任一併交到開發者手上。
- 適合誰用？
- 如果你做的是單機、離線、玩家與 NPC 對話為核心的 Unity 專案，而且能接受把模型檔與記憶體預算納入發行規劃，LLMUnity 值得進到原型階段實測；若你的對話必須靠雲端大模型維持品質，或團隊沒有處理原生後端與模型授權的人力，就不該選它。動手前先確認三件事：LlamaLib 在你的目標平台是否有可用的預編譯後端、你打算散布的模型檔採用哪一種授權、以及目標裝置的記憶體能否同時容納模型與 Unity 本身。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 140 天前。
- 用什麼語言寫的？
- 主要是 C#（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「遊戲裡要有會回話的角色」這件事
Unity 本身沒有推論能力。要在遊戲裡放一個能自由對話的 NPC，常見做法是呼叫雲端 API，但這會帶來連線依賴、延遲波動與玩家資料外流的問題。LLMUnity 的定位就是把推論搬到使用者裝置上：README 寫明「Runs locally without internet access. No data ever leave your game!」，並同時保留遠端伺服器模式。目標讀者是做角色扮演、對話驅動或訪談模擬類遊戲的 Unity 開發者，C# 是主要工作語言。README 列出的採用案例集中在敘事與對話類作品，例如 Verbal Verdict、Case Closed、Murder in Aisle 4，以及一個 VR 模擬面試專案，題材分布相當一致。
LlamaLib 是中間層，不是 llama.cpp 的直接綁定
README 對後端的說明只有一句：LLM backend 是 LlamaLib，建構於 llama.cpp 之上，並以獨立的 C++/C# 函式庫形式提供。這意味著 Unity 端看到的 C# API 與 llama.cpp 之間隔了一層由 UndreamAI 維護的封裝，llama.cpp 的更新不會自動流到這個套件。推論路徑因此是：Unity 場景中的元件呼叫 C# 介面，介面穿過 LlamaLib 的原生層，最後由 llama.cpp 在 CPU 或 GPU 上執行。README 提到支援 Nvidia、AMD 與 Apple Metal，也提到 CPU 推論，但沒有說明各平台的後端是以預編譯二進位或原始碼形式提供，這一點在評估行動裝置與主機發行時必須自行確認。
RAG 用 ANN 檢索，但檢索品質取決於你切資料的方式
套件內含一套 Retrieval-Augmented Generation 系統，README 描述為對你的資料做語意搜尋，用來擴充角色知識，並在功能列表中標明使用 ANN 搜尋。這代表流程是先把資料切塊、轉成向量、建索引，對話時以玩家輸入檢索出相關片段，再塞進提示詞交給模型。ANN 是近似最近鄰，換取的是檢索速度，代價是可能漏掉真正相關的片段，而 README 沒有提供任何召回率或延遲數據。實際效果高度取決於切塊粒度與嵌入模型選擇，這兩件事文件沒有替你決定。如果你的知識庫規模只有幾十條固定問答，直接寫進系統提示詞會比建一套向量索引更省事，也更可預測。
啟動方式與模型管理的實際形狀
README 的 Quick start 段落把安裝與首次呼叫放在同一條路徑上，但清理後的內容沒有保留具體程式碼，因此這裡只能確認流程輪廓：透過 Unity 套件安裝後，在場景中加入對應的 LLM 元件，再以 API 送出對話請求，README 在功能列表中形容為「call with a single line of code」。模型管理則有獨立章節，並提到支援主流 LLM 模型。可以確定的是，模型權重不會隨套件附上，必須由你自行取得並放進專案，這也意味著發行檔案的體積會直接反映你選擇的模型大小。至於模型檔要放在哪個目錄、以哪個欄位指定路徑，清理後的 README 沒有留下可引用的設定鍵，請以官方文件 undream.ai/LLMUnity 為準。
最大的風險是記憶體與平台後端，不是程式碼
本機推論的成本不會消失，只是從伺服器帳單移到玩家的裝置上。一個能講出通順對話的模型，權重加上執行期的 KV cache 會佔用可觀記憶體，而 Unity 場景本身已經在吃同一份預算。README 聲稱支援 PC、mobile 與 VR，但沒有給出任何最低記憶體需求或各平台的實測數字。行動裝置與一體式 VR 頭盔的記憶體上限遠低於桌機，這是選型時最容易低估的一項。另一個限制是後端相依：LlamaLib 由 UndreamAI 維護，若你的目標平台不在其支援清單內，就得自行處理原生建置。README 標示測試過的 Unity 版本為 2021 LTS、2022 LTS、2023 與 Unity 6，其他版本沒有承諾。
與雲端 API 路線的差別在於誰承擔推論成本
最直接的替代方案是接雲端 LLM API。兩者的差異不在 API 好不好用，而在推論發生在哪裡：雲端路線的模型能力由服務商決定，你可以隨時換成更大的模型，代價是每次對話都要連線、要付費，且玩家輸入會離開裝置。LLMUnity 把這三件事反過來：離線、單次成本固定、資料留在本機，但模型能力被玩家硬體鎖住，而且你必須自己處理模型檔的散布與授權。對一款對話量極大的遊戲，本機推論的邊際成本接近零；對一款只有少量關鍵對話、且要求最高語言品質的遊戲，雲端路線反而更合理。這個選擇沒有中間解，先想清楚你的對話是量的问题還是質的問題。
授權與後續維護要分開看
套件本身採用 Apache-2.0，README 也寫明個人與商業用途皆可免費使用，這對商業發行相對寬鬆。但這個授權只涵蓋 LLMUnity 的程式碼，不涵蓋你載入的模型權重，而模型授權各家不同，部分對商用或使用人數設有限制。這是兩份獨立的授權，必須分別確認。維護成本方面，最近三個版本 v3.0.1 到 v3.0.3 集中在 2026 年 1 月到 3 月，主分支最後推送時間為 2026 年 4 月，節奏穩定，但這只反映提交活動，不代表 API 已經凍結。由於中間隔著 LlamaLib，升級時要同時追蹤三層：Unity 套件、LlamaLib、以及底層 llama.cpp 的變動。這條鏈越長，回歸測試的範圍就越大。
編輯結論
如果你做的是單機、離線、玩家與 NPC 對話為核心的 Unity 專案，而且能接受把模型檔與記憶體預算納入發行規劃，LLMUnity 值得進到原型階段實測；若你的對話必須靠雲端大模型維持品質，或團隊沒有處理原生後端與模型授權的人力，就不該選它。動手前先確認三件事：LlamaLib 在你的目標平台是否有可用的預編譯後端、你打算散布的模型檔採用哪一種授權、以及目標裝置的記憶體能否同時容納模型與 Unity 本身。這三項在 README 裡都沒有替你決定。
社群筆記