米哈游崩坏 AI 研发团队与清华大学、北京大学、中国科学院大学、香港大学、新加坡国立大学等机构联合开源的 GameScaling 系列游戏模型已上线，8 个检查点覆盖 0.8B 至 27B 四档参数规模，代码和权重按 Apache 2.0 许可证放出。IT之家 10 月 22 日从项目 GitHub 与 Hugging Face 页面确认了这批模型。
模型的输入不是游戏内部数据，而是画面。按项目技术说明，GameScaling 基于 Qwen3.5 视觉语言模型继续预训练，读取当前游戏画面以及此前的部分画面和操作记录，直接生成后续键盘、鼠标操作指令来驱动角色。它面向实时游戏，每次调用输出约 200 毫秒的操作，折合每秒 5 次决策；这 200 毫秒里包含 6 个 33 毫秒的操作步骤，另有独立的鼠标移动与滚轮指令。
规格方面：
- 规模：0.8B、2B、9B、27B 四档，每档分 S1、S3 两个版本，合计 8 个检查点
- 训练数据：各版本均使用 1600 小时游戏过程；S1 只用《我的世界》，S3 为多游戏混合数据，《我的世界》占 27%
- 部署：0.8B、2B、9B 权重可单卡运行，27B 需要两卡张量并行，支持 vLLM
- 许可：Apache 2.0
四档规模乘两种数据配比的排布，本身就是一组对照实验：同一套训练配方下把参数量拉大，看游戏场景里的操作表现怎么走，这也是项目名里 Scaling 的由来。对想复现的人来说，S1 与 S3 的差别有直接参考价值：只喂单一游戏，和多游戏混着喂，在跨游戏迁移上的表现不是一回事。
任务覆盖上，官方给出的场景包括《我的世界》里的采矿、合成物品和对抗僵尸，《毁灭战士》里的战斗与寻路，以及密室场景的解谜逃脱。三类任务对模型的要求并不相同：采矿和合成更依赖对界面与物品栏的识别，射击游戏考验连续帧里的走位判断，密室逃脱偏长序列推理。
部署门槛上，27B 双卡张量并行不算轻，普通开发者更现实的选择是 9B 及以下；单次 200 毫秒的推理窗口也意味着端到端延迟得压在这个量级内，否则指令会滞后于画面。项目方给出的任务类型集中在规则明确、反馈即时的游戏里，这类环境数据好采集，也便于和已有基准对齐。
项目主页：gamescaling.github.io；GitHub：github.com/THUSI-Lab/GameScaling；Hugging Face：huggingface.co/THUSI-Lab/GameScaling。技术论文题为《Scaling in Games: Continued Pre-Training for Embodied Agents in Diverse Virtual Worlds》，编号 arXiv:2610.28698。
