RhOS-World: Khora 这个项目最值得关注的地方，不是“世界模型”这个标签，而是“千人联机”四个字。世界模型已经讲过很多，但大多数演示还停留在单机房间、单用户交互和离线仿真阶段。如果“千人联机”是一个可运行目标，那就说明世界模型正在从模型 Demo 演变成一套多用户实时共享状态的空间系统。这件事本身就值得单独拆一遍。
我不想复述项目发布物料，我更想聊清楚一件事：把一个世界模型和“联机”放在一起时，技术判断和过去做大模型应用会有明显区别。大模型应用的核心是 prompt、上下文、推理输出；世界模型应用的核心是实体、状态、事件、同步和一致性。如果把这两套逻辑混在一起做，前期可能看不出问题，一旦叠加多用户，问题就会集中爆发。
这篇文章适合正在做 AI 应用产品、游戏服务器、数字孪生平台，或者想在自己的业务里接入世界模型能力的读者。我没有办法拿到项目内部的工程实现，所以下面写的是一整套通用验收思路：不管实际架构是中心服务器、房间分区还是 P2P，只要你准备测一个“千人联机世界模型”，下列问题几乎都会遇到。
1. 世界模型和大模型，到底差在哪里
1.1 大模型的单位是 token，世界模型的单位是状态
很多人会把“世界模型”理解成“一个更聪明的大模型”。这个理解并不准确。大模型更像一个编码器和生成器，把文字编码成内部表示，再生成文字。世界模型的核心任务是预测状态变化，它需要知道环境中有哪些实体，实体之间的位置关系，以及如果执行某个动作会发生什么。
举一个最简单的例子：你问大模型“把一个杯子从桌上推到地上会怎样”，它能给出像样的文本答案。但如果你在世界模型里执行同样的操作，系统需要给出一个可交互的结果：杯子的坐标变化、速度、落地后是否碎裂、相邻实体是否受影响。前者是语言能力，后者是状态推演能力。
所以你在评估 RhOS-World: Khora 这类项目时，不能只问它模型多大、上下文多长、说出来的话是否通顺，还要问它的世界状态是如何表示的，状态更新能不能在多人同时操作时保持一致。
1.2 单机世界模型像单机游戏，联机世界模型像服务端游戏
单机世界模型在工程上相对容易实现。只有一个用户在操作世界，系统可以暂停，可以回滚，可以用一个线程慢慢推演。就算每一步计算耗时 3 秒，用户也可能接受。但一旦加入联机，情况完全不同。
多个用户同时在线时，世界不能因为某个用户的操作导致其他用户等待；同一个场景里的多个用户必须看到一致的状态；服务器还要处理断线、重连、异常操作和大量并发请求。它不再是纯粹的模型推理问题，而是一个实时多人共享系统。
我会把这个判断放在最前面：如果你准备关心“千人联机世界模型”，要关注的不是模型参数，也不是“世界模型和大模型谁能生成更好的文案”，而是这套系统能不能在低延迟、高并发、长运行的前提下保证状态一致。
下面用一张表把区别写清楚：
| 对比项 | 大模型应用 | 世界模型联机平台 |
|---|---|---|
| 核心单元 | token | 实体、事件、状态 |
| 主要场景 | 对话、生成、检索 | 模拟、空间计算、多人交互 |
| 核心指标 | 生成质量、上下文长度 | 状态一致性、并发数、模拟步长 |
| 难度重点 | 提示词、模型微调、内容安全 | 网络协议、服务端状态同步、资源上限 |
| 离线或在线 | 大多数场景可离线单次调用 | 必须考虑长时间在线和断线重连 |
这个表格不是否定大模型的价值，而是提醒你，二者评价标准不同。一个世界模型在单人场景跑得很流畅，不代表它能够在 1000 人同时操作时保持稳定。
2. 千人联机背后要拆的四类工程问题
2.1 第一类：连接模型和网络拓扑
先说连接模型。1000 个人同时在线，最常见的做法不是每个客户端都直接连到其他 999 个客户端上，而是经过一个中心服务端。
中心服务端负责接收用户操作，计算世界状态，再把变化推送给相关客户端。早期小规模场景中，可能只有一个服务进程，客户端把消息发到同一个 WebSocket 或 TCP 端口。规模扩大后，通常就要考虑分区域、分房间、分频道的做法：一个房间或一个地图区域内的用户，只关心这个区域里的状态变化。
这样做的好处很明显，网络压力不会随着用户总数无限放大，而是与“同一区域内的活跃用户数”相关。代价是跨区域交互变复杂。例如用户 A 在世界地图东边操作，用户 B 在世界地图西边，两者可能处于不同同步域。如果业务需要全地图广播，那就另当别论，成本会高出很多。
2.2 第二类：消息量、带宽和模拟步长
很多人评估联机系统只看“能不能连上”，忽略了消息量。我一般会这样估算一条链路的压力：
- 在线用户数；
- 每个用户每秒产生多少次有效操作；
- 每次操作的数据包大小；
- 服务端需要向多少个客户端同步变化；
- 世界模型的模拟步长是每秒几步。
举个例子：假设每个用户每秒只产生 5 个操作，每个操作 256 字节，单人单包很小，但如果服务端需要把所有人的操作广播给同一个房间的其他 200 人，每秒消息量就会急剧放大。
可以用一个粗略表格体现这种放大关系：
| 活跃人数 | 每人每秒操作数 | 每操作大小 | 服务端每秒需要处理的消息量 |
|---|---|---|---|
| 100 | 5 | 256 字节 | 128 KB/s |
| 300 | 5 | 256 字节 | 384 KB/s |
| 1000 | 5 | 256 字节 | 1.28 MB/s |
这只是一个极端简化模型，没有把协议头、ACK、状态快照和模型推理算进去。真实环境里，如果再加上全量广播，数量级会更高。实际多人系统一般不会做全量广播，而是采用“空间格子 + 距离检查”的同步方式，只把消息推给感兴趣范围内的客户端。这样带宽压力会小很多，但对空间索引和服务端实现复杂度的要求更高。
所以，“千人联机”项目如果发布物料没有给出每秒支持多少条消息、单个区域支持多少人、模拟步长是多少，我建议你在验收时把这些数字自己去测一遍。测的时候不要只看客户端是不是流畅，要看服务端 CPU、内存、网络吞吐和事件队列长度。
2.3 第三类：状态一致性和“谁说了算”
多人世界的核心问题是：以谁的状态为准。
你可以在客户端做本地预测，让玩家操作后立刻有反馈；但服务端必须保留一份权威状态。当客户端预测结果和服务端最终状态不一致时，客户端要回滚或纠正。如果没有这一层，就会出现“我明明看到门打开了，但你那边还是关着”的差异。
一个稳妥的联机协议至少会包含：
- 事件编号或时间戳；
- 操作携带用户 ID 和实体 ID；
- 服务端按顺序处理事件；
- 服务端定期下发状态快照；
- 客户端收到快照后，以快照为准校正本地状态。
有些人会认为“这就一个模拟器，不用做得像游戏服务端那么复杂”。如果只是 1 个人用，确实可以简单。但只要进入“千人联机”阶段，状态一致性就必须按照实时服务端的标准来做，否则连“用户反馈不同步”这类问题都无法定位。
2.4 第四类：模型推理和网络线程的相互影响
世界模型通常涉及神经网络推理或复杂仿真计算。一次推理可能需要几十毫秒到几百毫秒，网络消息处理通常要求几毫秒到几十毫秒内完成。如果把两者放在同一个线程里串行执行，很容易出现一个用户触发了重计算，其他用户全部等待。
我在做这类系统时，会比较关注几个问题：
- 模型推理是否放在独立线程池或进程里？
- 模型计算和网络发包是否有队列隔离？
- 如果模型推理超时，网络层会不会被阻塞？
- 大量用户同时触发操作时，是否有排队和限流机制？
这些问题没有统一答案，取决于架构。但作为评估者，你应该把“模型算得准”和“系统能响应”分开看。前者是模型能力，后者是工程能力。能把两者同时做好，才是“千人联机世界模型”真正难的地方。
3. 从单机 Demo 到多人平台，先走完这条最小验证路线
3.1 先把服务端进程跑起来
不管买的是平台服务还是自己部署的开源项目，第一步都是先把服务端进程跑起来。这一阶段最需要确认的，不是有多少高级功能，而是：
- 服务端能否启动并正常监听端口；
- 是否有可用的客户端接入方式；
- 模型权重或依赖是否完整；
- 日志是否可查看；
- 配置文件中的端口、路径、模型目录、数据存储是否正确。
很多人在这个阶段就会卡住。常见原因是模型目录路径不对、依赖版本冲突、端口被占用或数据目录没有写权限。不要急着怪平台，先看启动日志。
如果服务端是一个容器或可执行文件，我一般会先把它放在本地开发环境跑一次，确认日志里出现“ready”或“listening on”这类明确状态。没有成功启动之前，不要进入下一步。
3.2 最小闭环：两个用户进入同一个世界
我强烈建议你从最小闭环开始，不要一上来就追求 1000 人。最小闭环的流程是这样的：
- 启动服务端；
- 客户端 A 连接服务端，创建一个角色或实体；
- 客户端 B 连接服务端，进入同一房间或同一区域；
- A 执行一个可观察的操作，例如移动一个物体或改变一个状态；
- B 端观察变化是否出现；
- 断开 B，重新连接，检查状态是否还能恢复；
- 查看服务端日志里的事件顺序。
这个流程看起来很简单，但它可以验证很多基础能力：连接、登录、实体创建、状态传播、持久化和断线重连。如果这个闭环都不稳定，后面谈千人联机没有意义。
要注意的是，A 的操作要尽量选择一个“有明确结果”的操作。比如移动物体到一个固定坐标，或者把某个开关从关闭状态切换到打开状态。不要选择过于随机的动作，否则你很难判断 B 端看到的结果是否一致。
3.3 接入时需要看的数据字段
如果你不是用现成的客户端，而是需要把自己的 Agent 或机器人接入世界模型，那就要关心数据格式。
一般的联机世界模型会提供某种协议，常见的抽象字段包括：
- entity_id：实体唯一 ID；
- action_type：动作类型，例如移动、拾取、创建、摧毁；
- position：坐标或空间位置；
- timestamp：操作时间；
- payload：附加参数，例如目标实体 ID、物体颜色等。
举一个例子，一次移动操作的 JSON 可能长得像这样：
{ "entity_id": "player_10086", "action_type": "move", "target": { "x": 12.5, "y": 0.0, "z": -8.2 }, "timestamp": 1710000000000 }这只是我常用的通用结构，不是 RhOS-World: Khora 的官方协议。实际字段要以项目文档为准。但你可以按这个思路去看它的协议设计：有没有版本号，有没有事件 ID，有没有服务端回执，能否避免消息重放造成重复操作。
如果协议里没有事件 ID 或服务端回执，那接入后大概率会遇到重复请求、乱序处理等问题。特别是当客户端网络不稳定时，用户点一次操作，网络层可能自动重试，服务端如果不做幂等处理，同一个操作就会被执行两次。
3.4 多用户压测：从 50 人开始，不要直接跳到 1000 人
当最小闭环跑通后，可以做并发验证了。我的经验是分阶段加人：
- 50 人：验证基础并发能力；
- 200 人：验证服务端内存和网络栈是否正常；
- 500 人：观察是否有明显掉线或延迟升高；
- 1000 人：验证峰值能力和长时间稳定性。
测试时可以写一个简单的压测脚本，创建多个虚拟用户，让每个用户周期性地发送移动或查询请求。但要注意，压测脚本里加入随机行为比所有用户用相同命令有效得多，因为真实世界中，用户行为不可能整齐划一。
每个阶段至少运行 10 到 30 分钟，观察日志中的错误率、平均延迟和资源占用。不要只跑 1 分钟，多用户系统经常前几分钟正常，跑到第 10 分钟开始出现内存增长和连接超时。如果你只能做一个测试，就做“持续 30 分钟、500 人随机移动、记录掉线率”的测试，这会比 1000 人秒连更有说服力。
4. 验收多人世界模型，我建议看这几个指标
4.1 连接成功率和稳定在线人数
“千人联机”至少有三种理解：
- 1000 个用户同时在线；
- 1000 个用户在一个小时内陆续登录；
- 1000 个用户同时在一个房间内活跃交互。
这三种场景的要求差别很大。最后一种最难。验收时一定要先搞清楚对方说的“千人”是哪种，再按场景设计测试。
对于持续在线场景，我会先看连接成功率。如果 1000 个客户端发起连接，有 200 个失败，那说明连接层或资源配额有问题。然后再看稳定在线人数，也就是连接成功后能维持住的比例。如果不断有人掉线重连，即使“累计登录人数”超过 1000，也不能叫稳定的千人联机。
4.2 延迟、模拟步长和事件吞吐
真实体验中，延迟不是唯一的判断标准。用户感觉卡顿，可能是因为世界模型模拟步长过慢。模拟步长是指世界状态每隔多长时间前进一步，单位可能是毫秒。如果模拟步长过长，即使网络延迟很低，用户操作后的反馈也会迟钝。
我建议做一张验收记录表，至少包含以下指标：
| 指标 | 观察方式 | 合理信号 |
|---|---|---|
| 连接成功率 | 压测脚本统计 | 接近 100% |
| 服务端 CPU | 监控系统或 top | 不应长时间接近 100% |
| 内存占用 | 监控系统或 ps/jstat | 增长后能稳定，不持续上涨 |
| 网络吞吐 | iftop、云监控 | 线性增长且网卡不饱和 |
| 同步延迟 | 客户端收到状态的时间差 | 波动小，不出现周期性抖动 |
| 错误率 | 日志统计 | 长时间运行接近 0 |
这些数值没有绝对标准，因为取决于机器配置和场景复杂度，但至少你要能在测试时拿到数据。拿不到数据，就无法判断一个系统是不是真的能承受 1000 人。所有宣称“支持千人”但不提供远程测试、压测报告或公开 Demo 的平台，都要多留一个心眼。
4.3 日志和回放机制决定了问题能不能排查
多人世界模型出现不一致时，最怕“无法复现”。用户说“我看到门开了，你看它是关的”，等你要查日志时，现场已经过去了。
所以我一直建议，联机世界模型必须保留完整的事件日志和回放能力。比如服务端每收到一个操作就写一条事件记录，关键状态变化后写一个快照。出现问题后，用事件日志重放，再对比某时刻的状态，就能定位是哪一步导致状态分叉。
如果没有日志，仅凭用户截图判断问题，效率极低。你可以把这当成选型或评估时的关键点：接入协议有没有事件 ID，服务端有没有持久化的状态日志，有没有房间快照。这三样东西在联机系统里比模型本身的“智能程度”更重要。
5. 常见问题排查：先日志，再指标，最后才改参数
5.1 联不上服务端，先查这四层
如果客户端连不上服务端，不要第一时间怀疑世界模型本身。常见原因是：
- 服务端进程没有启动或启动失败；
- 端口被防火墙拦截或云安全组没有放行；
- 客户端配置的服务端地址、端口错误；
- 并发连接数达到系统限制。
我习惯按这个顺序查：日志 → 端口监听状态 → 防火墙和网络连通性 → 配置项。
在 Linux 上可以先用几个基础命令确认状态：
# 查看服务端进程是否在运行 ps aux | grep server # 查看端口是否监听 netstat -tlnp | grep 8080 # 测试端口连通性 telnet 127.0.0.1 8080如果端口在本地能连通，但远程客户端连不上，就要看安全组和防火墙。如果远程能连上但立刻断开，再看服务端日志里的握手记录或鉴权信息。
5.2 卡顿和掉线，先看资源占用和队列
卡顿可能来自模型推理，也可能来自网络同步。最直接的判断方式，是看卡顿发生时服务端 CPU、内存、网络 IO 是否出现尖峰。
如果 CPU 一直居高不下，可能是世界模型推理太慢或代码有死循环；如果内存持续增长，可能是连接或实体没有释放；如果网络吞吐量触顶，可能是广播策略太粗糙；如果数据库响应变慢，可能是持久化成为瓶颈。
掉线问题更复杂。短暂掉线可能是网络波动；大面积周期性掉线，一般会去查超时配置、代理网关、负载均衡健康检查，以及服务端对空闲连接的处理策略。很多长连接服务默认会有 idle timeout，如果客户端没有心跳机制，空闲一段时间就会被服务端踢掉。
5.3 状态不一致，优先对比事件顺序
用户看到不同状态时，一般不先改模型参数，而是先对比事件顺序。
我会找几个关键事件，看服务端实际处理顺序是否与客户端发送顺序一致。如果客户端本地做了预测，还需要看服务端下发纠正帧时，客户端是否按纠正帧更新。很多“状态不一致”的最终原因，是本地缓存或预测逻辑没有处理回滚，而不是世界模型能力不足。
检查方法也很直接：打开服务端事件日志，找到用户 A 和用户 B 的操作记录，把时间戳和事件 ID 对齐。如果 A 的操作先到，B 的操作后到，但最终结果不符合这个顺序，那就要看服务端是不是做了并发合并或延迟批量处理。
5.4 模型输出异常，先区分是推理问题还是同步问题
世界模型可能会出现一些不符合常识的输出。在多人环境里，要先判断到底是模型预测错误，还是状态同步失败导致客户端显示错误。
有一个简单办法：只保留单人场景，复现同一操作。如果单人场景没问题，多人场景才异常，大概率是同步或并发问题；如果单人场景也异常，才考虑是不是模型参数、输入格式、随机种子或权重版本问题。
这个区分很重要。很多人把同步问题当模型问题去调，调了半天模型，结果发现是客户端缓存没有清理。调试的顺序应该是：先确认输入数据一致，再确认事件顺序一致，最后才去动模型参数。
6. 落地建议：先把它当服务，再把它当“世界”
6.1 确定协议边界，不要把模型逻辑堆到客户端
接入一个联机世界模型，最好把它当成一个独立服务来用。对业务系统来说，更合适的做法是：
- 业务服务通过 API 或 SDK 调用世界模型服务；
- 世界模型服务维护世界状态；
- 客户端只负责渲染展示和上传操作；
- 业务规则和世界模型规则尽量解耦。
如果业务逻辑也塞到世界模型服务端，会导致每次修改业务规则都要重新部署模型服务，排查问题时也会分不清是业务代码出错还是模型状态出错。我见过不少项目，最后线上问题都出在“服务端职责不明”上。
6.2 先稳定再扩容，顺序比速度重要
评估“千人联机”时，最忌讳的是盲目追求“一次并发 1000”。更稳妥的路径是先证明 50 人场景足够稳定，再把设计目标放大到 200 人、500 人，最后才加压到 1000 人。
扩容时也不是单纯加机器就行。需要确认系统是否支持水平扩展，例如区域分区、Redis 或消息队列拆分、数据库读写分离。如果架构本身是单房间全量同步，加再多机器也可能难以解决单个房间内的性能瓶颈。
这里有一个容易忽略的成本问题：世界模型推理比普通消息转发更消耗资源。如果 1000 人同时在一个区域里并发触发复杂操作，可能比 10 个区域各 100 人更难处理。所以你应该先确认项目的资源模型：是按在线人数计费，还是按区域数量，还是按模型调用次数。
6.3 长期运行不能少的状态对账机制
多人世界模型的长期运行没有“测试完成”这个终点。用户随时可能加入、离开、断线、重连，也可能同时触发许多操作。服务端需要有定期快照和状态对账机制，保证即使发生异常，也能恢复到一个可接受的状态。
我通常会在上线前准备以下几样东西：
- 心跳检测和超时判断；
- 断线重连时拉取状态快照；
- 关键操作的幂等处理；
- 定期保存世界快照；
- 历史事件日志保留策略；
- 监控告警，覆盖连接数、错误率、内存、模拟步长。
如果这些都没有，就要做好“运行几天后状态越跑越乱”的准备。多人系统最怕的不是单次故障，而是状态在不知不觉中分叉，等到用户发现时已经很难回滚。
注意：不要因为平台自带“状态日志”功能就觉得安全。要确认日志是只记录操作命令，还是能重建某一个时间点的完整世界状态。前者只能告诉你“用户做了什么”，后者才能帮你做对账恢复。
最后留一个我自己的经验看法：千人联机世界模型听起来像是把“世界模型”和“联机”两个热词放在一起，但真正值钱的其实是联机部分。模型演示很容易做，状态同步和长期一致性却很难。RhOS-World: Khora 是否真的做到千人稳定在线，需要实测数据来验证，不能只看发布标题。
如果你准备把它引入自己的项目，最该盯住的不是“它有什么高级模型能力”，而是多人接入时的输入格式、资源占用、失败重试、日志回放和状态快照是否满足你的场景。把这几条链路跑通，其他功能才谈得上落地。
