这次我们来看一个比较偏实战的横评把 K3、Fable5、GLM5.2、Hy3 四款大模型放到同一个场景里用页游开发当试卷看谁更适合拿来干活。横评的目的不是给模型排名而是解决一个实际问题——如果你现在要做一款 HTML5 网页游戏需要大模型帮你写核心玩法代码、生成世界观和 NPC 对话、设计战斗数值甚至跑一批批量生成任务这四款模型到底怎么选、怎么测、怎么判断好不好用。先把话说在前面Fable5 和 Hy3 目前公开资料很少本文会把它们当作黑盒模型来处理K3 和 GLM5.2 的版本信息也以官方发布为准。下面会给出一套完整的横评流程包含测试维度、统一提示词模板、API 批量调用示例、数值模拟脚本、资源占用观察方法和常见问题排查表。你可以直接照着跑一遍把四款模型的输出结果填进记录表里最后再下结论。1. 四款模型是谁K3、Fable5、GLM5.2、Hy3 的背景与横评定位先建立共识。大模型横评最忌讳的是拿 A 模型的 API 和 B 模型的本地包比速度起点不一致后面所有结论都没有意义。所以第四款模型的基本定位要先理清楚。模型代号社区关注方向本次横评处理方式K3常与 Kimi K3 关联讨论集中在参数量、细粒度 MoE、本地部署等方向按已有公开信息做背景说明实际能力用统一测试用例验证Fable5公开资料较少无法确认开源状态、参数规模和架构细节按黑盒模型处理不预设技术架构GLM5.2社区讨论中常见于代码场景常被拿来和 DeepSeek V4 Flash 等模型对比写代码重点观察代码生成与逻辑稳定性Hy3命名上可能指向混元系新一代版本但可确认的官方资料有限按黑盒模型处理只记录输入输出行为从搜索趋势看K3 的出圈点和本地部署参数量细粒度 MoE高度相关说明很多人在意它能不能自己跑、资源吃多少。GLM5.2 的热度则集中在代码能力对比尤其是写代码到底推荐哪一个这类问题。Fable5 和 Hy3 在可获取的公开信息里几乎没有技术细节所以更稳妥的判断是先跑测试再谈结论。有一点需要明确本文不基于任何单一榜单或宣传口径下结论。大模型在页游场景下的表现受提示词、上下文长度、输出格式、批量任务设计和部署方式影响很大。后面的每一个测试维度都要记录用什么提示词、什么参数、什么环境。2. 为什么用页游当横评场景页游是一个被低估的综合测试场景。很多人横评大模型只测生成一段代码或写一篇文案维度太单一。而一款现代化的页游基本是 HTML5 Canvas 或 WebGL不依赖 Flash从零到可运行需要覆盖多种能力第一前端代码能力。游戏主循环、碰撞检测、角色移动、资源渲染、关卡切换这套代码对逻辑正确性的要求不低且必须能在浏览器里直接运行。第二游戏文案和世界观。页游需要新手引导、NPC 对话、任务描述、剧情背景这考验大模型的中文表达、上下文一致性和多轮续写能力。第三数值策划。角色属性、伤害公式、升级曲线、资源产出这些不仅要看起来合理最好还能通过脚本模拟验证平衡性。第四批量生产与接口能力。实际开发中你不会只让大模型写一段文案而是可能一次性生成几十条 NPC 对话或者几十个关卡配置API 的稳定性、并发能力、失败率会被放大。所以用页游这个场景横评四款模型等于把代码生成、长文本、多轮对话、JSON 结构化输出、批量任务放在一个工程闭环里同时验证。这也是本文标题里做页游横评的真正含义不是让大模型去玩页游而是让大模型像开发成员一样参与页游生产流程。3. 横评维度与记录口径横评开始之前先把评分维度固定下来否则四款模型的输出很难横向比较。建议使用下面这套维度表每个维度都按 1 到 5 分记录并附上证据文件。横评维度测试内容判定标准代码可运行性同一份游戏 demo 需求生成 HTML/JS浏览器能否直接打开、有无控制台报错代码逻辑质量输入处理、循环、碰撞、状态切换逻辑是否完整有无死循环、未定义变量文案一致性世界观、NPC 对话、任务链前后设定是否矛盾风格是否统一中文表达提示文案、界面文本是否有明显语病、翻译腔、滥用感叹号数值合理性属性公式、升级曲线、资源消耗是否满足边界条件能否用脚本模拟出稳定区间结构化输出JSON/CSV 配置生成能否直接解析字段是否对齐批量稳定性连续生成 50 条以上内容失败率、超时率、token 消耗是否可控部署接入成本API 接入或本地部署环境依赖、显存需求、启动时间是否在预算内每次测试建议把输入提示词、模型参数、原始输出、人工评分四项保存到单独的 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: fBearer {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, headersheaders, jsonpayload, timeout120) if resp.status_code ! 200: raise RuntimeError(fAPI 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 代码可运行性判定拿到代码后先做三件事保存成.html文件用 Chrome 直接打开。打开浏览器开发者工具看 Console 有没有报错。手动操作一次确认篮子能移动、水果能下落、得分和结束逻辑能触发。建议用下面的表格记录结果模型能否直接运行Console 报错交互是否正常代码完整度备注K3待测待测待测待测Fable5待测待测待测待测GLM5.2待测待测待测待测Hy3待测待测待测待测如果某一款模型生成的代码无法运行不要急着打低分先补一轮修复错误对话看它能不能根据报错信息自我修正。这也是页游开发里最常用的工作流先让模型写初版再把浏览器报错复制回去。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. 初始属性为 HP100、ATK10、DEF5、CRIT0.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(hp150, atk20, defense10, crit_rate0.1) monster Character(hp100, atk12, defense5, crit_rate0.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 字。当前是第 {i1} 条。 try: headers { Authorization: fBearer {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, headersheaders, jsonpayload, timeout60) 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. 常见问题与排查方法横评过程中会遇到一批重复出现的问题先列一个排查表后面跑测试时可以对照处理。问题现象可能原因排查方式解决方案API 返回 401API Key 错误或鉴权字段不对检查请求头和 Key 是否过期重新生成 Key核对文档中的鉴权格式API 返回 429触发限流或并发超限查看响应头中的 Retry-After降低并发数增加重试和退避请求超时单次生成 token 过多或服务端过载缩短 max_tokens检查网络降低输出长度提高 timeout分批请求生成代码打开后空白Canvas 未初始化或 JS 运行时错误打开浏览器 Console 看报错把报错信息回传给模型要求修复输出 JSON 解析失败模型在 JSON 前后添加了解释文字打印原始响应检查格式解析时提取代码块或 JSON 片段增加容错批量任务中途卡住单条请求无响应或网络中断查看进程日志检查失败请求索引给批量任务增加超时和重试机制本地部署显存不足模型权重过大或并发太高用 nvidia-smi 查看显存占用使用量化版本、降低 batch size、减小上下文长度端口冲突服务默认端口被占用查看端口占用情况启动命令中更换端口12. 最佳实践与合规边界横评不只是跑一次测试更重要的是建立一套可持续使用的项目工作流。建议第一次测试时先用小参数、小批量跑通流程。token 最大值先设置得小一点比如 1000确认输出符合预期后再放大。批量任务一定要设计重试和日志机制。生成结果建议按模型名、日期、任务类型分目录保存方便复现。输出内容在进入正式游戏包之前必须有人工复核尤其涉及付费引导、抽卡概率、用户协议的部分。合规方面四款模型可能来源不同开源协议、商用条款、数据使用边界也不一样。使用 AI 生成内容做商业页游时要确认模型服务条款是否允许商用输出AI 参与生成的内容是否需要向玩家说明。涉及用户上传素材时不能把未授权的数据直接送给模型处理。如果后续在游戏里接入 AI NPC 或实时对话功能还要考虑内容过滤和未成年人保护。13. 总结与下一步四款大模型的页游横评核心不是谁排名更高而是你能不能复现一套稳定的测试流程。建议你先从第 6 章的代码生成测试开始用统一的接水果小游戏提示词把四款模型跑一遍记录可运行性再进入第 7 章文案测试、第 8 章数值测试最后做批量 API 压测。每一轮结果都存档数据积累起来之后结论自然就出来了。最容易踩的坑是第一用不同提示词测不同模型导致结果不可比第二只看生成效果不验证可运行性和批量稳定性第三忽略 API 限流和输出格式漂移。先跑通最小 demo再慢慢加难度比一开始就追求一步生成整个游戏靠谱得多。