RTX Spark 筆電同跑 125B 本機模型與《Minecraft》的意義

圖片：Wikimedia Commons／Pang Ka Kit（CC BY 2.5）

TechLab 編輯部（譯）·2026-10-28

XDA Developers 編輯 Adam Conway 以配備 Nvidia RTX Spark、128GB 統一記憶體的 HP OmniBook Ultra 16，嘗試在同一部電腦上運行 125B 參數的本機語言模型，並讓模型透過 bot 參與《Minecraft》。他的測試中，遊戲在大部分時間維持約 120 FPS；不過，bot 指令回應有延遲，亦曾誤判物品、跌進坑洞及因卡住而斷線重連。

這次示範的價值，不在於 AI 已能可靠地當遊戲隊友，而是顯示大記憶體 AI PC 有機會把本機推論、遊戲和 agent 工作流放進同一個使用情境。限制同樣清楚：這是單一媒體、單一遊戲及特定設定下的實測；《Minecraft》本身負載較輕，不能據此推論大型 3D 遊戲也能在運行大型模型時保持相近表現。

125B 模型如何接入遊戲

測試所用的 Qwen3.8 Flash Next 是 mixture-of-experts（MoE）模型，總參數量為 1,250 億，但來源指每個 token 約只有 60 億參數啟用；其 510 億參數的 n-gram embedding 則由儲存裝置串流，而非全數常駐記憶體。XDA 按 Nvidia 提供的 llama.cpp 設定運行模型，並以 OpenAI 相容 API 在本機 port 9931 提供推論。

遊戲端採用開源專案 Mindcraft。它建基於 Mineflayer，以一般玩家身分連入 LAN 世界；玩家在遊戲聊天欄提出要求，模型決定下一步並產生指令，Mindcraft 則負責移動、採礦和背包管理。由於 Mindcraft 的 LM Studio 整合支援可設定的 OpenAI 相容 API 位址，XDA 得以把它指向本機的 llama.cpp server。

這種接法的意義，在於不少現成 agent 工具未必需要專門支援每一個推論引擎；只要能對接相容 API，本機模型便可接入既有工作流。對希望避開雲端 API、又想試用 agent 的用家，兼容層往往比單一 app 的原生支援更實際。

記憶體容量是關鍵，遊戲表現仍須逐項驗證

XDA 指出，模型在短 context 下約為每秒 46 tokens，context 增至 32,000 tokens 後降至略低於每秒 42 tokens。與此同時，《Minecraft》可在 Windows on Arm 原生運行，毋須經 PRISM x86 模擬，因此減少了一項額外負擔。

該機的 128GB 統一記憶體，讓模型與遊戲可同時駐留；這正是示範得以成立的硬件前提。分析上，這不代表所有「AI 加遊戲」組合都會順利：模型大小、context 長度、量化方式、遊戲的 GPU 負載，以及 agent 是否頻繁調用視覺輸入，都會爭奪同一組運算與記憶體資源。XDA 亦指出，這次並未使用針對 AI 與圖像工作負載並行的 CUDA in Graphics 優化，因該功能現時不支援 RTX Spark。

因此，約 120 FPS 更適合視為「輕量遊戲與大型本機模型可以並行」的個案，而非 RTX Spark 在 AI 負載下的通用遊戲基準。XDA 自己亦預期，若換成負載更高的遊戲，表現受影響會大得多。

Agent 的瓶頸仍在執行可靠性

bot 可完成收集樺木、泥土等簡單工作，亦能根據實際背包狀態修正先前承諾；但它有時會嘗試使用被關閉的 !newAction 指令，並在採集期間卡住。來源認為，部分問題源自 Mineflayer 的尋路與 Mindcraft 的執行層，未必是語言模型理解指令的失誤。

這個分工值得留意：LLM 負責理解和規劃，工具層負責把計劃落地，任何一環不穩定都會令整個 agent 看起來「不聰明」。Mindcraft 的 !newAction 更可讓模型在電腦上運行 JavaScript；XDA 在測試中已關閉此功能。若將類似架構由遊戲延伸至桌面自動化，用家需要先收窄工具權限及檢視可執行操作，不能只看模型是否能對答。

下一步值得觀察的，是更多實測會否比較不同遊戲負載、context 長度和 agent 任務時的延遲、畫格率及失敗率。現階段，這個案例較能說明高記憶體 AI PC 的本機工作流潛力，而未足以證明它已可穩定兼顧大型模型與所有遊戲。