在单台电脑上同时运行本地大语言模型（LLM）和高负载游戏，往往面临显存瓶颈。典型游戏显卡的 16GB 显存难以同时支撑高质量模型与游戏，极易导致数据溢出至低速系统内存。然而，惠普最新推出的 OmniBook Ultra 16 笔记本打破了这一局限。
该机型搭载英伟达 RTX Spark 芯片，集成 20 核 Arm CPU 和拥有 6,144 个核心的 Blackwell GPU，并配备 128GB 统一内存。实测显示，借助 Qwen 3.8 Flash Next——一个拥有 1,250 亿参数的混合专家（MoE）模型，用户可在局域网内让 AI 机器人加入《我的世界》（Minecraft）。得益于充足的显存空间，即便模型在后台控制机器人，游戏仍能流畅运行。
Mindcraft：将大模型转化为游戏玩家
该实验基于 Mindcraft 项目，该项目依托于创建 Minecraft 机器人的 Node.js 库 Mineflayer。Mindcraft 将机器人作为普通玩家接入游戏，并通过聊天窗口交互。当用户下达指令时，模型会调用工具命令。例如，要求收集 10 根白桦木原木时，模型发送“!collectBlocks("birch_log", 10)”，随后由 Mindcraft 执行移动、挖掘和库存管理，模型则负责决策和行为叙述。
配置过程简便：将游戏开放至局域网固定端口，连接 Mindcraft 并运行脚本即可启动 Web 仪表板，实时监控机器人状态。虽然 Mindcraft 无专用 llama.cpp 选项，但其 LM Studio 集成支持配置 OpenAI 兼容 API 地址，可直接指向本地 llama.cpp 服务器。此外，用户还可启用视觉功能，如“!lookAtPlayer”命令可捕获第一视角图像供模型分析，或通过“!newAction”命令在本地执行 JavaScript（测试中已禁用此功能以保安全）。
共享内存互不干扰，游戏帧率稳定
英伟达提供了针对 RTX Spark 的 llama.cpp 优化方案。测试采用 Qwen3.8-Flash-Next 配方，包含视觉支持和用于推测解码的 MTP 草稿模型，通过端口 9931 提供 OpenAI 兼容 API 服务。基准测试显示，短上下文下生成速度约为每秒 46 个令牌（token），32,000 令牌长度下降至略低于 42 个。
Qwen 3.8 Flash Next 虽拥有 1,250 亿参数，但每令牌仅激活约 60 亿参数，且其 510 亿参数的 n-gram 嵌入从存储流式传输而非全量驻留内存。尽管这对本地 LLM 而言资源消耗巨大，但笔记本的 128GB 统一内存池提供了充足缓冲，确保模型与游戏并行无碍。
值得注意的是，《我的世界》可在 Windows on Arm 上原生运行，支持 Arm64 版 Java 及图形库，无需依赖微软 PRISM x86 模拟层。全程游戏帧率维持在约 120 FPS。此外，该效果无需特殊 GPU 调度。尽管英伟达 NVIGI SDK 支持 AI 负载下的游戏优化，但其 CUDA in Graphics 功能目前在 RTX Spark 上尚不支持。这意味着 llama.cpp 服务器与游戏直接共享 GPU 资源，鉴于《我的世界》配置需求不高，并未出现明显性能衰减。
智能表现：热情但略显笨拙
接入游戏后，AI 机器人表现出类似“热情但困惑的朋友”的特质。它会主动打招呼、叙述行为并在空闲时询问指令。从发出指令到执行动作存在明显延迟，因模型需处理对话并生成下一步命令。在收集材料任务中表现尚可：成功交付树苗后，面对收集 30 块泥土的要求，它直接开始挖掘，但过程并不顺利。
机器人的回复并非预设，而是由语言模型实时生成，增强了互动真实感。但它也会犯错：曾因背包为空却承诺交付物品，随后迅速自我纠正；也曾因尝试调用被禁用的代码执行命令而陷入逻辑循环，最终承认限制并切换回标准命令。最戏剧性的一幕是，它在助跑后跳入洞穴导致断连，重连后却若无其事地继续任务，甚至在被困后通过内置脱困系统重试，最终交付了半组泥土。
这些导航错误主要源于 Mineflayer 路径规划的缺陷，而非模型智能或性能问题。尽管机器人执行力有待提升，但模型能准确理解用户意图。令人印象深刻的是，整个实验完全在本地完成，无需云 API，且未因运行 1,250 亿参数模型而牺牲游戏体验。这证明了在大显存支持下，本地 AI 与高负载应用共存的可行性。