“千人联机世界模型 RhOS-World: Khora 正式发布”这个标题我第一眼看到时注意到的不是“发布”两个字而是“千人联机”这四个字。过去讨论世界模型多数技术文章还停留在单智能体在仿真环境里做状态预测和规划比如用一段视频预测下一帧或者在网格环境里让 agent 预演几步再行动。RhOS-World: Khora 这个名称传递的信号是世界模型正在从“单机推理组件”走向“多人共享世界状态”的平台化形态。这里不尝试复述官方公告也不替任何项目背书而是从工程实践视角拆解这类系统最核心的技术难题世界状态如何表达、预测模型如何切入实时循环、多用户并发如何保持一致、千人规模下如何压测和排错。适合对世界模型概念有初步了解、想从事 AI 实时平台或仿真系统开发的人阅读。文末给出的最小原型和排查清单可以直接作为起步骨架。1. 世界模型不是“会说话的大模型”先把它放在仿真和规划的坐标系里1.1 世界模型在解决什么问题通俗理解大模型处理的是“文本世界”你给它一句话它预测下一个词世界模型处理的是“环境世界”你给它一个当前状态和一个动作它预测环境下一时刻会变成什么样。两者都叫模型但解决的问题完全不同。技术定义世界模型是学习环境转移函数的模型即给定当前状态 $s_t$ 和动作 $a_t$建模 $P(s_{t1} \mid s_t, a_t)$。更完整的系统还会学习观测编码器、奖励模型和策略解码器。早期 World Models 论文把环境压缩成低维隐变量再在隐空间里做规划后来 IRIS、DreamerV3 等把这类思想扩展到视觉输入和长时程决策。把“世界模型”放回 RhOS-World: Khora 这个场景里它不会只是一个论文里跑通的小环境。千人联机意味着不能只由一个 agent 在自己的隐空间里预测未来必须让一千个参与者共享同一套世界状态并且模型的预测结果要实时影响所有参与者看到的画面。这个差异决定了系统架构不可能照搬单机实验。1.2 世界模型和大模型的区别很多人最容易把世界模型和大语言模型混在一起因为当前很多大模型产品已经能生成图片、视频和 3D 场景。但从建模目标看两者差异明显。对比维度大语言模型世界模型输入本质文本 token 序列环境状态、观测、动作序列建模目标预测下一个 token预测下一个环境状态或观测输出形式文本、代码、结构化内容状态编码、下一帧观测、规划结果典型使用方式对话、检索、生成、工具调用强化学习、仿真、规划、控制对实时性要求相对宽松秒级可接受高通常需要毫秒到百毫秒级响应大语言模型擅长把知识压缩成可生成的文本表示世界模型则更关注“环境动态规律”。如果一个系统既用大模型做用户对话又用世界模型做环境模拟它们其实是两个独立服务只不过可能通过同一套调度框架被组织起来。RhOS-World: Khora 如果按命名理解核心资产应该在“世界模型”也就是环境状态动态预测这一层。1.3 世界模型在“千人联机”里承担什么角色世界模型在联机系统里不一定直接画画面也不一定等同于游戏引擎。它更像一个“环境大脑”每个 tick 接收所有用户动作计算状态迁移再把结果交给渲染层和业务逻辑层。在这个意义上世界模型被当成一种“动态服务”使用必须满足三个条件。第一是高吞吐推理。千人同时在线每个 tick 都可能产生近千个动作输入推理服务必须支持批量处理否则算力就会成为瓶颈。第二是支持并发预测。不同玩家可能处在不同区域状态更新不能全局串行。第三是模型版本可回滚。模型升级后如果预测行为突变线上必须能快速切回旧版本否则所有用户会同时看到异常。这三个条件直接决定了后端架构的设计方向。2. 从单机到千人联机四个架构问题比模型本身更难2.1 单机世界模型的最简闭环先看单机场景下的世界模型用法。一个最简单的训练好的世界模型推理循环通常长这样# 单机世界模型推理循环示意 state env.reset() while True: action policy(state) # world model 预测下一状态 next_state world_model.predict(state, action) reward env.reward(state, action) state next_state在这个循环里模型、策略、环境全都跑在同一个进程。没有网络延迟没有并发写入没有状态冲突。这种实验环境非常适合验证模型能力却完全不能回答“千人联机”带来的工程问题。2.2 千人同时在线时四个问题会同时出现第一个问题是状态一致性。A 用户移动了物体B 用户必须在一个可感知的时间窗口内看到同一结果。如果每个客户端各自运行一个世界模型输入顺序稍有不同世界状态就会发散。必须有一个权威来源让所有人都以同一份世界状态为准。第二个问题是并发更新。同一 tick 内1000 个用户同时提交动作世界状态却只有一个。动作按什么顺序应用如果 A 和 B 同时抢同一个物体谁成功这需要在状态服务层设计冲突处理规则而不是把问题丢给模型。第三个问题是实时性。深度学习模型单次推理可能需要几十毫秒到几百毫秒而联机场景通常需要 10Hz 到 30Hz 的状态更新。推理必须批量、异步、可降级不能因为某个用户请求超时就让整个世界停住。第四个问题是可扩展性。一块 GPU 很难在一个 tick 内为 1000 个用户各自推理可能需要按区域分片多个推理服务并行处理。分布式的引入又会带来新的数据一致性和部署复杂度。2.3 架构上从一个模型变成一个系统单机世界模型是把模型当作“函数调用”千人联机世界模型则必须把模型变成“服务”。核心变化有两个。第一状态从“模型内部隐变量”变成“可广播的世界快照”。单机场景里状态只存在于模型内存中联机场景里状态必须结构化成 JSON、Protobuf 或类似格式能够被存储、传输、对比和回滚。第二模型从“同步调用”变成“异步批量推理服务”。客户端发来动作状态服务先接收再批量请求推理集群拿到结果后统一更新世界并广播。这个思路和游戏网络同步中的“客户端预测 服务器权威 定期快照 插值渲染”非常接近。不同点在于下一状态不是固定写死的游戏逻辑而是模型推理结果。模型一旦有随机性或版本差异同步问题会比传统游戏更明显。3. 核心模块怎么设计一份可落地的参考方案下面的设计用于解释工程思路不是任何项目的官方架构。实际落地时模块名称、依赖版本和部署方式都要按团队技术栈重新确认。3.1 整体模块划分一个千人联机世界模型平台按职责可以拆成五个模块。模块职责关键技术点客户端层采集用户操作、渲染画面、本地预测输入上报、快照插值、预测回滚同步网关维护长连接、广播快照、处理重连WebSocket、连接管理、消息去重世界状态服务维护权威状态、tick 调度、冲突处理状态存储、版本号、事件队列推理集群世界模型并行推理、批量处理GPU 推理、批处理、模型版本管理存储层保存快照历史、用户状态、模型配置Redis 缓存、对象存储、数据库一次完整的 tick 流程可以这样理解用户操作通过同步网关进入世界状态服务状态服务把当前状态和动作组装成批处理请求发送给推理集群推理集群返回预测出的下一状态状态服务应用结果后把新的全量快照或增量更新广播给所有相关客户端客户端接收快照后插值渲染。3.2 世界状态的数据结构世界状态必须设计成可序列化、可传输、可版本化的结构。一个简化的快照可以是这样的{ tick: 1024, model_version: 2025.06.rhos, time_ms: 1718000000123, players: [ {id: u1001, x: 12.3, y: 44.0, z: 0.0, action_id: 772} ], entities: [ {id: e1, type: box, state: {pos: [1.0, 2.0]}} ], environment: { weather: clear, global_seed: 42 } }这里要有意识地保留三个字段。tick必须单调递增客户端靠它判断快照是否乱序或过期。model_version非常关键模型升级后不同客户端可能加载了不同版本的本地预测模型只有带上版本号才能判断为什么本地预测与服务器结果偏差变大。action_id用来标记客户端操作是否被服务器正确应用排错时可以快速定位“用户按了键但状态没变化”的问题。真实项目中状态字段可能远不止这些但设计原则是一致的每个字段都要有明确的消费方和生命周期不要把所有临时变量都塞进世界状态。3.3 推理服务接口设计推理集群对外暴露的核心接口是批处理预测接口。请求结构可以这样设计{ batch_id: b-0001, tick: 1023, inputs: [ { player_id: u1001, state_encoding: [0.1, 0.2, 0.3], action: {move: [1, 0]} }, { player_id: u1002, state_encoding: [0.4, 0.5, 0.6], action: {move: [0, 1]} } ] }响应结构{ batch_id: b-0001, tick: 1024, outputs: [ { player_id: u1001, next_state_encoding: [0.2, 0.3, 0.4], confidence: 0.98 } ] }接口设计有三个重点。第一永远批量请求不要为每个玩家单独调用模型接口否则 GPU 利用率会非常低。第二state_encoding是模型需要的隐状态编码不一定是完整场景数据状态服务负责把玩家坐标、实体属性等原始信息编码成模型输入再把模型输出解码成世界快照。第三接口要带超时和降级策略模型推理失败时服务端可以回退到上一个快照或走简化物理规则不能让整个系统卡死。3.4 状态同步与客户端预测在线系统里网络延迟是客观存在的。一种常用的补偿方案是“服务器权威 客户端预测”。服务器每个 tick 广播权威快照客户端在等待服务器结果的间隙先用本地动作预测一个临时状态让画面保持流畅。当服务器快照到达后客户端对比本地预测和权威状态。如果差异很小就直接对齐如果差异过大需要回滚到最近一个可信快照再做平滑修正。这段逻辑不复杂但很容易被忽略。实际项目中我会把“客户端本地预测模型”设计成一个小型蒸馏模型尽量轻量只做短期预测。它不需要像服务器模型那样精确目标是让画面在几十毫秒内不卡顿。真正决定世界走向的必须是服务器权威状态。4. 一个最小原型把世界模型服务、状态同步和千人吞吐跑通这一节将搭建一个最小可运行的原型骨架。它不追求完整功能只验证一件事世界状态服务、批量推理、模拟客户端三者能不能在一个 tick 循环里跑通。4.1 环境准备以常见环境为例需要 Python 3.10 以上版本以及几个通用依赖。这里没有使用任何特定项目的私有组件落地前建议重新确认版本。python -m venv .venv source .venv/bin/activate pip install pydantic fastapi uvicorn numpy如果计划接入真实模型推理再按推理框架补充依赖比如 PyTorch 或 ONNX Runtime。原型阶段可以先写一个模拟推理函数重点把并发和同步逻辑跑通。4.2 最小目录结构rhos_world_khora/ ├── server.py # 服务启动入口 ├── world_state.py # 世界状态和 tick 循环 ├── inference.py # 批量推理服务 ├── sync_gateway.py # 同步网关抽象 └── simulator.py # 模拟客户端批量压测原型阶段保持五个文件就足够。不要一上来就拆几十个文件否则出了问题很难定位。4.3 世界状态和 tick 循环世界状态服务是这个系统的心脏。每个 tick 做三件事接收动作、调用推理、更新状态并广播。import asyncio from dataclasses import dataclass, field from typing import Dict, List dataclass class WorldState: tick: int 0 players: Dict[str, dict] field(default_factorydict) async def tick(self, actions: List[dict], inference_service): # 1. 打包当前状态和动作 batch [] for act in actions: player_id act[player_id] state self.players.get(player_id, {}) batch.append({ player_id: player_id, state_encoding: state.get(encoding, []), action: act[action], }) # 2. 批量推理 outputs await inference_service.predict(batch) # 3. 应用预测结果 for output in outputs: pid output[player_id] self.players[pid] { encoding: output[next_state_encoding], confidence: output[confidence], } self.tick 1 return self.snapshot() def snapshot(self) - dict: return { tick: self.tick, players: self.players, }这里有一个关键点tick里不能直接同步调用模型。模型推理如果是 CPU 或 GPU 密集计算会阻塞事件循环导致所有客户端连接都卡住。正确做法是把推理放到线程池或独立进程中执行。4.4 批量推理服务推理服务负责把异步接口和真实模型隔离开。原型阶段用一个模拟函数代替模型。import asyncio from typing import List class InferenceService: def __init__(self, model_fnNone): self.model_fn model_fn or self._dummy_model async def predict(self, batch: List[dict]) - List[dict]: loop asyncio.get_running_loop() # 把阻塞推理丢到线程池避免阻塞事件循环 outputs await loop.run_in_executor(None, self.model_fn, batch) return outputs staticmethod def _dummy_model(batch: List[dict]) - List[dict]: results [] for item in batch: # 模拟模型推理状态编码原样返回并加一个固定偏移 enc item[state_encoding] results.append({ player_id: item[player_id], next_state_encoding: [v 0.1 for v in enc], confidence: 0.99, }) return results在实际项目中_dummy_model会被替换成加载好的 PyTorch 模型或 ONNX Runtime 推理器。注意模型加载应该放在进程启动阶段不要在每个请求里重新加载。4.5 运行验证用模拟客户端验证基本流程。模拟脚本创建多个客户端会话每个客户端持续发送动作并接收快照。import asyncio import random async def user_session(client_id: int, queue: asyncio.Queue): for step in range(50): action {player_id: fu{client_id}, action: {move: [1, 0]}} await queue.put(action) await asyncio.sleep(1 / 30) async def main(): world WorldState() inference InferenceService() queue asyncio.Queue() for i in range(1000): asyncio.create_task(user_session(i, queue)) for _ in range(200): actions [] while not queue.empty(): actions.append(queue.get_nowait()) if not actions: await asyncio.sleep(0.05) continue snapshot await world.tick(actions, inference) if world.tick % 20 0: print(ftick{snapshot[tick]} players{len(snapshot[players])}) asyncio.run(main())这个脚本只验证流程不代表真实的千人压力。它的作用是确认并发动作能进入队列状态服务能批量推理tick 能持续推进。5. 压测千人联机关键指标、脚本与扩容判断原型跑通后下一步就要回答“能不能扛住一千人”。压测不要只盯着能不能启动要把指标拆开看。5.1 需要观测的关键指标指标含义学习环境参考值生产环境关注点状态同步频率每秒广播多少个 tick20 Hz 以上与模型推理速度直接相关端到端延迟 P50动作发出到快照返回的中位延迟小于 100ms网络、队列、推理各占多少端到端延迟 P95长尾延迟小于 200ms是否存在阻塞或慢请求推理批量吞吐每秒处理的玩家动作数量视资源而定是否接近 GPU 算力上限快照大小每个 tick 广播的数据量越小越好千兆网络下带宽是否耗尽错误率超时、重连、丢消息比例极低是否有雪崩风险压测的核心不是追求绝对数字而是找到延迟增长曲线从平滑变为陡峭的拐点。这个拐点就是系统容量边界。5.2 一个简单的并发压测脚本可以用 asyncio 模拟大量客户端持续发送操作并统计响应时间。import asyncio import time async def pressure_client(client_id: int, state: dict, inference, latencies: list): for _ in range(50): action {player_id: fu{client_id}, action: {move: [1, 0]}} t0 time.perf_counter() await state.tick([action], inference) latencies.append((time.perf_counter() - t0) * 1000) await asyncio.sleep(1 / 30) async def run_pressure(): state { players: {fu{i}: {encoding: [0.0, 0.0]} for i in range(1000)} } inference InferenceService() latencies [] tasks [pressure_client(i, state, inference, latencies) for i in range(1000)] await asyncio.gather(*tasks) latencies.sort() p50 latencies[len(latencies) // 2] p95 latencies[int(len(latencies) * 0.95)] print(fp50{p50:.1f}ms p95{p95:.1f}ms total{len(latencies)}) asyncio.run(run_pressure())这个脚本把每次动作都当成一个独立 tick 处理实际系统会做批量合并。但它能快速暴露一个真问题如果不做批量随机时刻到达的动作会让 tick 碎片化延迟和吞吐都会恶化。真实实现应该把时间窗口内的动作聚合后一起推理。5.3 瓶颈判断与扩容思路压测结果出现异常时先看资源消耗落在哪里。如果 CPU 使用率高世界状态服务和数据编解码可能成了瓶颈需要优化序列化格式或增加状态服务副本。如果 GPU 利用率高模型推理是瓶颈优先做批量优化、模型量化或者切分模型。如果网络带宽高快照太大需要改成增量快照只广播发生变化的部分。如果延迟增长但各项资源都不饱和很可能存在全局锁、串行队列或者事件循环阻塞需要用 profiling 工具排查。扩容不是简单加机器。世界状态如果集中在一个服务里加再多的推理集群也绕不开单点瓶颈。千人规模的合理做法是按区域分片每个分片维护自己的世界状态跨分片交互通过事件网关转发。RhOS-World: Khora 这类带模型推理的系统分片后还要给每个分片分配独立的推理资源避免一个区域的高负载影响其他区域。6. 常见问题排查从现象倒推根因6.1 用户看到的世界互相“穿越”现象不同用户看到的同一实体位置不同A 移动后 B 的屏幕没有变化。可能原因客户端各自运行了自己的世界模型没有服务器权威状态或者服务器广播了快照但客户端在插值渲染时没有按tick排序。检查方式在客户端打印最近三个快照的tick和实体坐标确认到达顺序在服务器端确认每个 tick 是否只发布一次最终状态。处理建议让服务器成为唯一权威状态源。客户端本地预测只用于渲染补偿不能作为世界事实。客户端收到快照后必须忽略tick 当前已应用 tick的旧数据。6.2 所有用户都感觉卡顿延迟缓慢上升现象刚开始正常几分钟后所有用户操作都变得迟钝服务器 CPU 并不高。可能原因异步代码里混入了同步推理调用导致事件循环被阻塞。另一个常见原因是广播队列积压客户端消费速度跟不上服务器生产速度。检查方式查看事件循环延迟Python 中可以用asyncio的调试模式或loop.slow_callback_duration参数查看同步网关的队列长度和消息积压量。处理建议模型推理必须放进线程池或独立进程执行。广播要支持批量合并多个玩家在同一 tick 内可以共享一份快照不要给每个玩家单独发送全量数据。6.3 模型升级后同一状态预测结果突然变化现象发布新模型后用户物体位置突然跳变客户端本地预测频繁回滚。可能原因新旧模型版本对同一个状态编码给出了不同预测而客户端还在用旧模型的本地预测结果。检查方式在快照中检查model_version字段对比新旧模型在相同输入下的预测输出。处理建议发布新模型时必须同时下发模型版本号。客户端发现本地预测模型版本与服务器版本不一致应当关闭本地预测直接使用服务器快照插值。线上模型升级前要先在影子环境跑同一批历史输入评估状态输出差异。6.4 压测时网关内存暴涨现象模拟 1000 个客户端时同步网关内存持续上升直到 OOM。可能原因广播风扇过大每个 tick 都给所有用户发送全量快照客户端处理速度慢网关积压消息或者消息没有清理机制。检查方式监控网关待发送队列长度在压测脚本中模拟客户端是否真正消费消息还是只发送不接收。处理建议把全量广播改成增量广播只发送有变化的实体。网关增加积压水位告警当队列超过阈值时丢弃旧状态或断连慢客户端。生产环境还要对未认证连接做频率限制防止恶意压垮服务。7. 生产环境最佳实践与扩展方向7.1 学习环境与生产环境的差异原型代码只能证明流程能跑通距离生产还有明显差距。维度学习环境生产环境模型模拟推理或单卡模型多副本推理集群、模型灰度配置写在代码里外置配置中心、动态更新日志控制台 print结构化日志、链路追踪监控无CPU、GPU、延迟、队列水位、告警安全无用户鉴权、接口限流、数据加密回滚重启即可模型版本回滚、状态快照恢复、旧包保留数据内存态即可定期持久化、备份恢复方案生产环境的每一步都比学习环境多一层保障不能等项目上线后再补。7.2 发布前的检查清单发布一个千人联机世界模型服务至少需要确认这些事项。模型版本号是否与快照结构中的model_version对齐。推理服务是否有超时、重试和降级策略。客户端能否识别模型版本不一致并安全关闭本地预测。压测数据是否覆盖真实用户行为不只是固定动作循环。同步网关是否有消息积压告警和连接数上限。世界状态是否有定期快照模型异常后能否恢复到最近的稳定 tick。发布流程是否支持先灰度再全量。回滚后客户端是否需要强制刷新重新同步。7.3 扩展方向千人规模的下一步可以从三个方向展开。第一世界分片。把一个大地图划分成多个区域每个区域独立运行世界状态服务和推理实例跨区域玩家通过事件转发交互。这能把“千人一台服务器”拆成“每片 200 人”大幅降低单点压力。第二客户端蒸馏模型。服务器模型可以在线裁剪出一个小模型部署到客户端本地。客户端预测越准等待服务器快照时的画面越平滑回滚概率越低。第三长期记忆机制。当前世界模型通常只建模短期内状态迁移缺少对长期事件和用户行为历史的记忆。可以把历史关键事件压缩成记忆 token在推理时作为额外输入让模型对长期一致性的判断更稳定。回到“千人联机世界模型 RhOS-World: Khora”这个命名本身。它给工程团队的提示很清楚世界模型不再只是论文里的隐空间玩具而是要扛住并发、延迟、一致性和版本演进的实时系统。对开发者来说与其争论它是否真的支持一千人不如先搭一个骨架定义世界状态、封装推理服务、跑通 tick 循环、再做压测。先把这四件事做扎实再谈多模态输入、长期记忆和更复杂的物理规则都会顺手很多。