大模型页游开发实战横评：K3/GLM5.2/Fable5/Hy3对比

这次我们来看一个比较偏实战的横评：把 K3、Fable5、GLM5.2、Hy3 四款大模型放到同一个场景里，用"页游开发"当试卷，看谁更适合拿来干活。横评的目的不是给模型排名，而是解决一个实际问题——如果你现在要做一款 HTML5 网页游戏，需要大模型帮你写核心玩法代码、生成世界观和 NPC 对话、设计战斗数值，甚至跑一批批量生成任务，这四款模型到底怎么选、怎么测、怎么判断好不好用。

先把话说在前面：Fable5 和 Hy3 目前公开资料很少，本文会把它们当作黑盒模型来处理；K3 和 GLM5.2 的版本信息也以官方发布为准。下面会给出一套完整的横评流程，包含测试维度、统一提示词模板、API 批量调用示例、数值模拟脚本、资源占用观察方法和常见问题排查表。你可以直接照着跑一遍，把四款模型的输出结果填进记录表里，最后再下结论。

1. 四款模型是谁：K3、Fable5、GLM5.2、Hy3 的背景与横评定位

先建立共识。大模型横评最忌讳的是"拿 A 模型的 API 和 B 模型的本地包比速度"，起点不一致，后面所有结论都没有意义。所以第四款模型的基本定位要先理清楚。

从搜索趋势看，K3 的出圈点和"本地部署""参数量""细粒度 MoE"高度相关，说明很多人在意它能不能自己跑、资源吃多少。GLM5.2 的热度则集中在代码能力对比，尤其是"写代码到底推荐哪一个"这类问题。Fable5 和 Hy3 在可获取的公开信息里几乎没有技术细节，所以更稳妥的判断是：先跑测试，再谈结论。

有一点需要明确：本文不基于任何单一榜单或宣传口径下结论。大模型在页游场景下的表现，受提示词、上下文长度、输出格式、批量任务设计和部署方式影响很大。后面的每一个测试维度，都要记录"用什么提示词、什么参数、什么环境"。

2. 为什么用"页游"当横评场景

页游是一个被低估的综合测试场景。很多人横评大模型只测"生成一段代码"或"写一篇文案"，维度太单一。而一款现代化的页游，基本是 HTML5 + Canvas 或 WebGL，不依赖 Flash，从零到可运行需要覆盖多种能力：

第一，前端代码能力。游戏主循环、碰撞检测、角色移动、资源渲染、关卡切换，这套代码对逻辑正确性的要求不低，且必须能在浏览器里直接运行。

第二，游戏文案和世界观。页游需要新手引导、NPC 对话、任务描述、剧情背景，这考验大模型的中文表达、上下文一致性和多轮续写能力。

第三，数值策划。角色属性、伤害公式、升级曲线、资源产出，这些不仅要"看起来合理"，最好还能通过脚本模拟验证平衡性。

第四，批量生产与接口能力。实际开发中，你不会只让大模型写一段文案，而是可能一次性生成几十条 NPC 对话或者几十个关卡配置，API 的稳定性、并发能力、失败率会被放大。

所以，用"页游"这个场景横评四款模型，等于把代码生成、长文本、多轮对话、JSON 结构化输出、批量任务放在一个工程闭环里同时验证。这也是本文标题里"做页游横评"的真正含义：不是让大模型去玩页游，而是让大模型像开发成员一样参与页游生产流程。

3. 横评维度与记录口径

横评开始之前，先把评分维度固定下来，否则四款模型的输出很难横向比较。建议使用下面这套维度表，每个维度都按 1 到 5 分记录，并附上"证据文件"。

每次测试建议把输入提示词、模型参数、原始输出、人工评分四项保存到单独的 markdown 文件里。目录结构可以这样建：

pagegame-arena/ ├── prompts/ # 统一提示词模板 ├── outputs/ │ ├── k3/ │ ├── fable5/ │ ├── glm5_2/ │ └── hy3/ ├── scripts/ # 批量调用与验证脚本 └── reports/ # 评分记录和结论

这样的好处是，后期想复现或者换一批模型重测，只需要改模型名，不需要重新设计测试任务。

4. 环境准备与前置条件

横评前需要准备一套通用的运行环境。下面是最小清单，不绑定具体型号，按你自己的设备调整。

• 操作系统：Windows 10/11、Ubuntu 20.04 或 macOS 较新版本均可；Windows 建议用 PowerShell 或 Git Bash。
• Python：推荐 3.10 以上，用于跑 API 调用脚本和数值模拟。
• Python 依赖：requests、openai（部分云厂商兼容 OpenAI 协议）、pandas（可选，用来整理批量结果）。
• API Key 或本地模型权重：如果测试线上 API，准备好对应平台的 Key；如果测试本地部署，确认模型权重和推理框架。
• 硬件：本地部署时准备 NVIDIA 显卡，显存大小视模型版本而定；不确定的话，先用 API 方式完成功能测试，再考虑本地部署。
• 磁盘空间：不管是模型权重还是生成结果，建议预留 50GB 以上；实际以模型文件和输出规模为准。
• 浏览器：Chrome 或 Edge，用来验证生成的 HTML5 游戏 demo 是否可运行。

安装依赖可以在项目目录下执行：

python -m venv venv source venv/bin/activate # Windows 下使用 venv\Scripts\activate pip install requests openai pandas

如果后面要用本地部署，建议先查看官方文档确认推理框架是 vLLM、Ollama 还是 Transformers。不同框架的依赖差异很大，不要照搬别人的启动命令，一定要以实际项目仓库的 README 为准。

5. 接入方式：API 调用与本地部署模板

四款模型的接入方式不完全一样。K3 和 GLM5.2 相对容易找到 API 或部署入口，Fable5 和 Hy3 因为资料少，需要先确认能否从公开渠道拿到权重。更稳妥的路径是：先用 API 完成功能横评，再根据预算决定要不要做本地部署。

5.1 API 通用调用模板

大多数大模型 API 现在兼容 OpenAI 格式。可以先以这种格式写一个通用请求脚本，拿到返回结果后再针对不同平台调整鉴权字段。

import requests import json import time API_URL = "https://your-endpoint.example.com/v1/chat/completions" API_KEY = "<YOUR_API_KEY>" MODEL_NAME = "k3" # 换成 fable5 / glm5.2 / hy3 def chat_once(prompt: str, temperature: float = 0.7, max_tokens: int = 2000) -> str: headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } payload = { "model": MODEL_NAME, "messages": [ {"role": "system", "content": "你是一名资深的网页游戏开发工程师。"}, {"role": "user", "content": prompt} ], "temperature": temperature, "max_tokens": max_tokens } resp = requests.post(API_URL, headers=headers, json=payload, timeout=120) if resp.status_code != 200: raise RuntimeError(f"API error: {resp.status_code} {resp.text}") return resp.json()["choices"][0]["message"]["content"] if __name__ == "__main__": test_prompt = "用 HTML5 Canvas 写一个接水果小游戏，包含角色移动、水果下落、得分和游戏结束判断。" result = chat_once(test_prompt) print(result)

注意，这个脚本只是通用模板。不同平台的鉴权方式、Base URL、模型名参数可能不同，需要按实际接口文档调整。

5.2 本地部署通用模板

如果模型支持本地部署，Ollama 和 vLLM 是两种常见的启动方式。Ollama 适合快速测试，vLLM 适合高并发 API 服务。下面是两种思路的示例，不要直接照搬命令，先替换成实际的模型标识。

Ollama 方式：

# 拉取模型，模型名以官方仓库为准 ollama pull k3 # 启动服务 ollama serve # 单独跑一次生成 ollama run k3 "用 HTML5 Canvas 写一个接水果小游戏"

vLLM 方式：

# 使用 vLLM 启动 OpenAI 兼容服务，模型路径按实际权重位置替换 python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --served-model-name k3 \ --port 8000

启动后可以用 curl 验证接口：

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "k3", "messages": [{"role": "user", "content": "你好"}], "max_tokens": 50 }'

需要特别提醒的是，K3 这类被讨论为"细粒度 MoE + 大参数量"的模型，本地部署的资源需求可能很高。如果没有多卡集群或大显存机器，建议先不要强行本地化，用 API 完成横评即可。

6. 页游代码生成横评测试

代码生成是整个横评里最硬核的部分。这里用一个统一的题目：让四款模型各自生成一个"接水果小游戏"，游戏要求完全一致，然后记录生成代码能否直接运行。

6.1 统一代码生成提示词

请用 HTML5 Canvas 和原生 JavaScript 实现一个接水果小游戏，要求如下： 1. 画布大小为 800x600。 2. 玩家用一个篮子，通过鼠标左右移动来接住从上方掉落的水果。 3. 水果每 1 秒生成一个，下落速度随机。 4. 接到一个水果得 10 分。 5. 每漏掉 3 个水果，游戏结束。 6. 页面需要显示当前得分和剩余漏接次数。 7. 代码必须是单个 HTML 文件，可以直接在浏览器中打开运行。 8. 请把完整代码放在一个代码块里，不要省略任何部分。

这个提示词的关键是"单个 HTML 文件、可直接打开运行"，因为页游开发中最基础的门槛就是代码能不能跑。把同一个提示词分别发给四款模型，输出保存到不同目录。

6.2 代码可运行性判定

拿到代码后，先做三件事：

1. 保存成.html文件，用 Chrome 直接打开。
2. 打开浏览器开发者工具，看 Console 有没有报错。
3. 手动操作一次，确认篮子能移动、水果能下落、得分和结束逻辑能触发。

建议用下面的表格记录结果：

如果某一款模型生成的代码无法运行，不要急着打低分，先补一轮"修复错误"对话，看它能不能根据报错信息自我修正。这也是页游开发里最常用的工作流：先让模型写初版，再把浏览器报错复制回去。

6.3 代码质量的进一步观察

除了能不能跑，还要看代码结构。重点观察这几个点：

• 是否用了requestAnimationFrame而不是暴力setInterval做循环；
• 是否对 Canvas 2D 的上下文做了空值判断；
• 水果对象是否有越界回收机制，避免内存泄漏；
• 篮子移动是否做了边界限制，会不会移出画布；
• 游戏结束逻辑是否清理了定时器。

这些点不会直接决定"能不能跑"，但会影响后续开发维护。页游项目尤其重视浏览器兼容性，如果代码里直接用了很新的特性而没做降级，放到真实页游环境里可能出问题。

7. 游戏文案与世界观生成测试

代码跑通之后，下一项是文案和世界观。很多团队选大模型时只盯着代码，结果游戏做好了，新手引导和 NPC 对话写得像机器翻译，留存率直接受影响。

7.1 统一文案测试任务

给四款模型同一个世界观设定，要求输出一份可以直接用于页游的新手引导文案。设定如下：

你是一款中世纪奇幻题材页游的文案策划。请围绕"玩家扮演一名被选中的冒险者，接手一座破败村庄"的设定，完成以下内容： 1. 一段 150 字以内的村庄背景介绍； 2. NPC 村长接下来说的 3 句引导对话； 3. 第一章主线任务的描述，包括任务目标、任务奖励、大致流程； 4. 全部内容使用中文，语气要符合村庄破败但充满希望的氛围。

然后用同一段提示词分别让四款模型输出，重点看三件事：

• 设定是否一致：村长身份、村庄背景、任务目标之间不能互相矛盾；
• 表达是否自然：有没有"作为一款游戏"之类的 AI 腔，有没有明显语病；
• 可投放度：文案是否可以直接放进游戏 UI，还是需要大量二次修改。

7.2 多轮续写一致性测试

页游文案不是一次性生成，而是需要多轮补充。建议做一个连续剧情测试：先让模型输出第一章任务描述，然后追加"请继续写第二章剧情，并保证与第一章设定不冲突"，看模型能不能记住之前的设定。

这个测试对上下文窗口和长期一致性要求很高。如果第二章里村长突然换了名字或者村庄变成了城市，说明该模型在长上下文场景下的一致性需要扣分。

需要特别提醒的是，AI 生成文案在游戏发布时可能涉及版权归属和内容合规问题。如果是对外发布的商业游戏，建议对生成内容做二次审核，并确认所用模型服务的使用条款是否允许商用输出。

8. 数值策划与平衡性测试

页游里数值决定了玩家体验，但数值策划恰恰是很多大模型的短板。模型能写出"攻击力 100、防御力 50"，不代表它能设计出"足够平滑的成长曲线"。所以这一项要用脚本模拟来验证。

8.1 统一数值策划任务

给四款模型同样的数值设计需求：

请为页游设计一个简化战斗数值模型，满足以下条件： 1. 角色有生命值 HP、攻击力 ATK、防御力 DEF、暴击率 CRIT 四个属性。 2. 玩家从 1 级升到 10 级，每级获得 5 点自由属性点。 3. 初始属性为 HP=100、ATK=10、DEF=5、CRIT=0.05。 4. 普通攻击伤害公式建议为：damage = max(1, ATK * (100 / (100 + DEF)))，暴击时伤害为 1.5 倍。 5. 请给出推荐的每级属性分配方案，并说明 1 级和 10 级时，角色对同级小怪的期望攻击次数。

8.2 数值模拟验证脚本

拿到模型的数值方案后，写一个简单的蒙特卡洛脚本验证合理性。这里以"期望击败一个小怪需要几回合"为例。

import random from dataclasses import dataclass @dataclass class Character: hp: int atk: int defense: int crit_rate: float def simulate_round(player: Character, monster: Character) -> int: turns = 0 p_hp, m_hp = player.hp, monster.hp while m_hp > 0 and p_hp > 0: crit = random.random() < player.crit_rate damage = max(1, player.atk * (100 / (100 + monster.defense))) if crit: damage *= 1.5 m_hp -= damage if m_hp <= 0: break m_damage = max(1, monster.atk * (100 / (100 + player.defense))) p_hp -= m_damage turns += 1 if turns > 50: return 999 return turns def main(): player = Character(hp=150, atk=20, defense=10, crit_rate=0.1) monster = Character(hp=100, atk=12, defense=5, crit_rate=0.05) results = [simulate_round(player, monster) for _ in range(1000)] avg_turns = sum(results) / len(results) print(f"平均击败回合数: {avg_turns:.2f}") print(f"超过 20 回合或失败的样本占比: {sum(1 for r in results if r >= 20) / 1000:.2%}") if __name__ == "__main__": main()

这个脚本本身很简单，但它能把"模型给出的数值方案"变成"可判断的模拟结果"。如果四款模型给出的属性分配方案差异很大，可以直接用模拟结果对比哪个方案在前期更平滑、在后期不崩坏。

数值测试不要只看最终答案，还要看模型是否理解伤害公式的边界：防御力很高时伤害不能为负，攻击力很低时要保证有最小伤害。这些细节往往比"算出一个数字"更重要。

9. API 稳定性与批量生成观察

真实页游项目里，大模型通常不是只生成一次，而是要批量生产内容。所以 API 稳定性必须单独测。

9.1 批量生成任务设计

用一个简单的批量任务来测试：连续生成 50 条 NPC 对话，每条控制在 50 字以内，输出格式为 JSON 数组。每个模型跑同一批任务，记录成功条数、失败条数、平均耗时、最大耗时和 token 消耗。

import requests import json import time API_URL = "https://your-endpoint.example.com/v1/chat/completions" API_KEY = "<YOUR_API_KEY>" MODEL_NAME = "glm5.2" # 换成其他模型名 def generate_batch(model_name: str, batch_size: int = 50): results = [] errors = [] total_tokens = 0 for i in range(batch_size): start = time.time() prompt = f"生成一条 NPC 对话，内容为铁匠铺老板对玩家说的一句话，不超过 50 字。当前是第 {i+1} 条。" try: headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } payload = { "model": model_name, "messages": [ {"role": "system", "content": "你是一名页游文案生成助手，只输出对话内容本身。"}, {"role": "user", "content": prompt} ], "temperature": 0.8, "max_tokens": 100 } resp = requests.post(API_URL, headers=headers, json=payload, timeout=60) elapsed = time.time() - start if resp.status_code == 200: data = resp.json() content = data["choices"][0]["message"]["content"] results.append({"index": i + 1, "content": content, "elapsed": round(elapsed, 2)}) usage = data.get("usage", {}) total_tokens += usage.get("total_tokens", 0) else: errors.append({"index": i + 1, "status": resp.status_code, "text": resp.text}) except Exception as exc: errors.append({"index": i + 1, "error": str(exc)}) print(f"模型: {model_name}") print(f"成功: {len(results)} 条") print(f"失败: {len(errors)} 条") print(f"累计 token: {total_tokens}") print(f"平均耗时: {sum(r['elapsed'] for r in results) / max(len(results), 1):.2f} 秒") return results, errors if __name__ == "__main__": generate_batch(MODEL_NAME)

9.2 观察指标与结论口径

批量测试主要看三个指标：

• 失败率：失败条数占比。页游项目里，如果失败率超过 5%，说明这个模型或 API 不适合大规模内容生产。
• 超时率：单条超过 60 秒视为超时。页面里如果接入了实时生成能力，延迟过高会直接影响玩家体验。
• token 消耗：每条对话消耗的 token 是否稳定。如果模型总在重复解释而不是直接输出，token 成本会失控。

批量任务最容易出现的问题是"格式漂移"。第一次返回的是正常 JSON，到第 30 次突然多了一行解释文字。所以批量脚本里建议加一个 JSON 解析校验，解析失败就记录为一条异常数据。这也是页游生产管线里非常重要的容错机制。

10. 资源占用与部署成本观察

资源占用是横评里容易被忽略的一项。API 和本地部署的成本差异很大，需要根据项目预算判断。

10.1 本地部署如何观察资源占用

如果进行本地部署，用下面两个命令观察基础资源：

# 查看 GPU 显存使用率、功耗、温度 nvidia-smi # 实时监控进程资源占用 top -u $USER # Windows 下查看 GPU 资源 wmic path win32_videocontroller get name,adapterram

本地部署时重点看三组数据：启动阶段的显存占用、单次推理的显存峰值、并发请求后的显存增长趋势。如果模型启动后显存已经占满，那么并发数和上下文长度都会被限制得很死。

需要注意，不同推理框架和量化方式会显著影响显存占用。同一个模型，FP16 权重和 INT8 权重的资源占用可能差一倍。所以在横评记录里，一定要写清楚权重精度、推理框架、上下文长度、batch size 这些参数，否则资源数据没法横向比较。

10.2 API 与本地部署的成本对比

API 模式的成本主要是按 token 计费，无需担心显卡和运维，适合快速验证和中小规模内容生成。本地部署的成本主要是显卡购置、电费、运维时间，适合高频调用、数据隐私要求高的项目。

从页游场景看，如果只是开发期辅助生成文案和代码，API 通常更划算；如果是游戏内置 AI NPC，需要高并发、低延迟、长周期运行，本地部署或私有化 API 可能更可控。具体选哪种，取决于你的调用频率和单次调用成本，不要一概而论。

11. 常见问题与排查方法

横评过程中会遇到一批重复出现的问题，先列一个排查表，后面跑测试时可以对照处理。

12. 最佳实践与合规边界

横评不只是跑一次测试，更重要的是建立一套可持续使用的项目工作流。

建议第一次测试时，先用小参数、小批量跑通流程。token 最大值先设置得小一点，比如 1000，确认输出符合预期后再放大。批量任务一定要设计重试和日志机制。生成结果建议按模型名、日期、任务类型分目录保存，方便复现。输出内容在进入正式游戏包之前，必须有人工复核，尤其涉及付费引导、抽卡概率、用户协议的部分。

合规方面，四款模型可能来源不同，开源协议、商用条款、数据使用边界也不一样。使用 AI 生成内容做商业页游时，要确认模型服务条款是否允许商用输出，AI 参与生成的内容是否需要向玩家说明。涉及用户上传素材时，不能把未授权的数据直接送给模型处理。如果后续在游戏里接入 AI NPC 或实时对话功能，还要考虑内容过滤和未成年人保护。

13. 总结与下一步

四款大模型的页游横评，核心不是"谁排名更高"，而是你能不能复现一套稳定的测试流程。建议你先从第 6 章的代码生成测试开始，用统一的接水果小游戏提示词把四款模型跑一遍，记录可运行性；再进入第 7 章文案测试、第 8 章数值测试，最后做批量 API 压测。每一轮结果都存档，数据积累起来之后，结论自然就出来了。最容易踩的坑是：第一，用不同提示词测不同模型，导致结果不可比；第二，只看生成效果，不验证可运行性和批量稳定性；第三，忽略 API 限流和输出格式漂移。先跑通最小 demo，再慢慢加难度，比一开始就追求"一步生成整个游戏"靠谱得多。