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 人每秒消息量就会急剧放大。可以用一个粗略表格体现这种放大关系活跃人数每人每秒操作数每操作大小服务端每秒需要处理的消息量1005256 字节128 KB/s3005256 字节384 KB/s10005256 字节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实体唯一 IDaction_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 是否真的做到千人稳定在线需要实测数据来验证不能只看发布标题。如果你准备把它引入自己的项目最该盯住的不是“它有什么高级模型能力”而是多人接入时的输入格式、资源占用、失败重试、日志回放和状态快照是否满足你的场景。把这几条链路跑通其他功能才谈得上落地。 
长河君 · 2026/8/28 3:57:52 · 阅读 1.2k 千人联机世界模型：从模型Demo到实时状态同步的工程挑战
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 人每秒消息量就会急剧放大。可以用一个粗略表格体现这种放大关系活跃人数每人每秒操作数每操作大小服务端每秒需要处理的消息量1005256 字节128 KB/s3005256 字节384 KB/s10005256 字节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实体唯一 IDaction_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 是否真的做到千人稳定在线需要实测数据来验证不能只看发布标题。如果你准备把它引入自己的项目最该盯住的不是“它有什么高级模型能力”而是多人接入时的输入格式、资源占用、失败重试、日志回放和状态快照是否满足你的场景。把这几条链路跑通其他功能才谈得上落地。