在 4GB 显存上跑 Laya：部署记录与能力边界实测

这是在一台游戏本上完成的本地实验记录。站点本身不提供在线演示，也没有部署任何模型后端。

先说结论

环境跑通和判断可用，是两件不同的事。

Laya 装在我这台 RTX 3050 Laptop（4GB 显存）上：装包、换一次 PyTorch、跑通第一次推理。它能稳定加载、稳定输出，预热后每次判断只要 25 到 46 毫秒。

然后我把它放到中文游戏决策里测试，在“攻击必定死亡、逃跑可以存活”这种把结论都写进输入的状态下，它给出 fight 82.32%。

这篇文章记录两段：前面是怎么装成功的，后面是怎么发现它不靠谱的。后者更有用。

环境与最终状态

运行时实测：首次加载 259 秒（包含下载 5 个文件，权重主体约 846MB，缓存约 1.5GB），显存峰值 1.46GB，预热后单次判断 25 到 46 毫秒。

装了一半的坑：PyTorch 是 CPU 版

pip install laya 会一并装上 PyTorch。问题是它装上的那个是 CPU 构建——torch.cuda.is_available() 返回 False。

这一步很容易被误读成“这台机器的显卡不支持这个模型”。实际上 CUDA 不可用只说明当前装的是哪个 PyTorch 构建，和显卡能力无关。修复方式是卸掉 CPU 版，换成 cu124 构建：

import torch

print(torch.__version__)            # 2.6.0+cu124
print(torch.cuda.is_available())    # True
print(torch.cuda.get_device_name(0))  # NVIDIA GeForce RTX 3050 Laptop GPU

cu124 指的是 PyTorch 的 CUDA 12.4 构建，它的存在不能证明系统另外装了 CUDA Toolkit。这个区别在排错时值得分清。

三个警告，只有一个是真问题

加载模型时控制台会刷出三类警告，它们的严重程度差别很大：

第三条是关键。它意味着模型输出里的概率没有经过校准，相关条目的 confidence 应该当作未校准值看待。也就是说，后面那些百分比能反映“当前输出偏向哪一边”，不能读成“这个选择有 82% 的概率是对的”。

中文决策测试

测试设定很简单：给模型一段中文游戏状态，让它从 fight 和 run 里选一个。criteria 用来描述两个选项各自的含义。

第一组：改 criteria 能翻盘，但代价不对称

最初的 criteria 只有两句话：“fight 攻击敌人，run 逃离敌人”。在 1 血、无甲、无武器、被 5 只僵尸包围的状态下，模型选了 fight 69.39%。

把 criteria 写细之后——fight 描述为生命值充足、装备良好、敌人较弱时攻击；run 描述为低血量、缺武器或护甲、敌人多、死亡风险高时逃跑，并让 instructions 优先生存——同一个状态的结果翻了过来：

危险状态从 69% 修正到 9%，看起来是成功了。但同一份新 criteria 让本该果断进攻的状态从 83.28% 掉到了 58.25%——它没有只在错的地方生效，而是整体向 run 移动了。

这说明 criteria 是一个有效的调节手段，但不是一个可以定向扭转的旋钮。

第二组：危险程度梯度

固定装备条件，只改变敌人数量；再固定敌人数，降低装备和血量：

僵尸从 1 只增加到 20 只，fight 从 78.70% 掉到 65.27%，方向是对的，但 20 只僵尸几乎没比 5 只更危险。真正让它翻转的是装备和血量：半血铁甲就够让它转向 run。

最极端的状态——1 血、无甲、无武器、被 20 只僵尸包围——run 只有 53.61%。这不是一个判断，这是接近两可的抛硬币。

需要说明：这一组的数值和第一组不是同一批 criteria 下的结果，输入措辞也有调整，所以两组的数字不能直接对比，只能各自看内部趋势。

第三组：把结论写进输入

如果模型对状态的理解有问题，那么把结论直接告诉它应该能解决。我试了两条：

第二条是本轮测试里最关键的一次失败。输入已经明确给出了行动后果——攻击必死，逃跑能活——模型仍然以 82.32% 的置信度选择了 fight。

为什么会出现 82%

第一反应是怀疑硬件或者 CUDA 配置。但环境在这里是干净的：显卡被识别、CUDA 可用、显存够用、推理耗时正常。问题不在部署层。

criteria 是语义描述，不是 if/else

criteria 提供的是“选项标签 → 选项含义”的语义映射。就算你写“低血量时逃跑”，它也不是程序里的条件分支，不会强制那个动作被选中。它做的是把选项描述和状态描述放在同一个语义空间里比较相似度。

这是设计使然，不是 bug。但如果把它当规则用，就会得到上面这种结果。

同一状态，换选项顺序答案翻转

另一个探测更能说明问题。状态是“生命值 15/100，无护甲，手持木棍，前方 2 只狼人”，criteria 描述完全不变，只交换两个选项的顺序：

[fight, run]  →  run   92.2% / 7.8%
[run, fight]  →  fight 66.6% / 33.4%

同样的状态、同样的描述，答案相反。

这里值得先排除一种误判：如果这是位置偏好，那么四个互斥类别做全排列应该也会乱。我另外做过一次 24 种排列的测试，24/24 全部正确，置信度在 0.95 到 0.98 之间。所以它不是简单的位置偏置。

真正的原因是两份 criteria 的语义重叠，加上状态本身就是临界的。模型在模糊地带退化成读措辞，而不是读逻辑。

confidence 不等于正确率

一次英文测试的输出里同时有这些字段：probabilities 显示 fight 72.04%、run 27.96%，而同一结果里 confidence 是 0.1452、answer_confidence 是 0.7204。

三个数字量级差得很远，混用会得出完全错误的结论。概率校准是大量样本上的统计性质，单个案例完全可能高置信度地出错。加上前面提到的温度校准警告，这些数值只能当作“倾向强度”来用。

那还能用来做什么

Laya 把自己定位成 single-pass classifier——单次前向的分类器，属于快速决策那一层。它的优势不是想得深，而是想得又快又便宜。

所以正确的用法是把它放在一个分层结构里，而不是让它单独决定行动：

游戏状态
  │
  ├─ 1. 硬规则过滤：排除必死、不可执行、违反约束的动作
  ├─ 2. Laya 在剩余选项里快速选择（25ms）
  └─ 3. 程序执行，观察新状态

遇到需要目标分解或多步规划的局面
  → 交给推理模型（DeepSeek / GPT 类）
  → 结果仍然要回到第 1 步过一遍硬规则

规则和模型的分工要说清楚：硬规则负责它擅长的确定性和安全底线，Laya 负责它擅长的快速语义判断，推理模型负责多步规划。三者都不能越界。

比如在一个已知“攻击会死亡、逃跑可存活”的局面里，程序应该直接排除 fight，根本不必问模型。过滤之后如果只剩一个可行动作，直接执行；如果一个都不剩，走预设兜底流程或者请求重新规划。

Laya 不应该有覆盖硬规则的权限。上面那个 82.32% 就是这条边界的实证：如果让模型直接决定，它会带着很高的置信度走进必死选项。

适合与不适合

适合：文本分类、意图识别、请求路由、工单分级、风险打分、通关前的廉价预筛，以及在明确任务定义下的快速语义判断。

不适合：坐标计算、连续动作的后果推演、复杂战术、多步生存规划、需要精确字段抽取的任务。这些该交给程序规则或具备推理能力的模型，并且结果必须验证。

下一次怎么测

这一轮是手工测试，每个条件只跑了一次，criteria 和措辞在不同轮次间有变化。这些都不足以支撑“稳定能力”的判断。

再测一次的话，应该固定住这些变量：checkpoint、instructions、criteria 原文、选项顺序、软件版本，然后每个状态跑多次取分布，把测试输入和完整输出都留存下来。

尤其要把顺序排列的多数表决加进流程——对于临界状态，单次调用的答案不具备参考价值。

在拿不准的地方设计一个“置信度不够就问人”的出口，也比事后解释一个 82% 的错误便宜得多。

这套分层结构真正实现出来、中间踩了两个坑的完整过程，记录在《先约束，再决策：Laya 网格世界的两轮调试》里。