WorldFoundry

WorldFoundry 是一套运行与评测世界模型的开源基础设施。它不是一个新的单一模型架构，而是把模型发现、runtime 准备、推理、artifact 检查、benchmark 执行与证据报告连接成一条工作流，覆盖视频、3D/4D、交互式世界和具身系统：

发现模型，准备 runtime 与资产，生成可检查的 artifact，评测 artifact，再把结果保留为可审查证据。

这里的区别很重要。Catalog 中存在一个模型，不等于它的 runtime 已经可运行；一个效果很好的 demo，不等于已经形成 benchmark 证据；成功导入一个分数，也不等于复现了官方 leaderboard。WorldFoundry 会把这些状态分开记录并明确展示。

它解决的是一个具体研究问题：不同上游项目都能产出有价值的结果，但各自使用不同环境、checkpoint、输入、启动命令、输出 layout 和评测 protocol。WorldFoundry 保留这些原生差异，同时统一它们周围的系统边界。

它解决的问题

世界模型通常以彼此独立的仓库发布。不同项目分别定义环境、checkpoint、输入格式、启动脚本、输出目录、预览工具和评测代码。当团队需要比较多个系统时，往往要为每个模型重复搭建同一层集成胶水。

碎片化首先出现在发现阶段。同一个模型可能同时使用论文名、仓库名、checkpoint 名和本地目录名。WorldFoundry 为模型和 benchmark 提供稳定 ID 与声明式 manifest，让用户在运行昂贵任务之前，就能看清来源、预期能力、runtime binding、所需资产和已知 blocker。

执行阶段也存在同样的问题。WorldFoundry 不再让用户把 checkpoint 和 dataset 放进每个上游脚本偶然约定的目录，而是定义可复用的本地资产根目录和模型专属 runtime profile。Pipeline 与 operator 保留模型的原生差异，同时向系统其他部分提供一致的 request、result 和 artifact 边界。

评测阶段则需要解决证据丢失。视频、mesh、动作和 trace 不应该消失在自定义目录或一次性 notebook 中。WorldFoundry 会保留实际请求、执行状态、生成内容、打分方式、sample 覆盖率，以及仍然阻止官方声明的条件。

它的目标不是用一个极小 API 抹平所有模型差异，而是把差异放回正确的层，同时让端到端研究工作流保持一致。

项目怎样工作

整个设计的核心边界是 artifact。模型 runner 把归一化 request 转成包含视频、几何、动作 trace 或其他输出的 result；benchmark runner 消费这些输出，再产出 metric 与证据。这样，同一份模型输出可以先被人工检查，再交给多个兼容 benchmark 使用，而模型实现不需要耦合 evaluator 内部逻辑。

Catalog 构成这条边界周围的控制平面。它描述系统中有什么、来自哪里、需要什么、如何调度，以及哪些证据支撑当前 readiness。TUI、CLI、Studio、Python 和 MCP 只是操作同一底层系统的不同方式，不是彼此独立的实现。

一个具体 run：Matrix-Game 2

例如，第一次运行 matrix-game-2 时，可以先让 catalog 与本地资产检查回答“模型是谁、checkpoint 是否就绪”，然后只生成一个小型结果：

bash scripts/inference/prepare_model_infer.sh matrix-game-2 --download
python -m worldfoundry.evaluation zoo model-download \
  --model-id matrix-game-2 --check-local --json

bash scripts/inference/test_nav_video_gen.sh matrix-game-2 \
  --output-dir tmp/matrix_game2_first_run

最后一个命令使用动作条件输入运行模型，并把视频及相关运行记录写入指定目录。此时能声称的是“这个配置产生了可检查 artifact”；可以在 Studio 或本地播放器中检查运动与连贯性，也可以把兼容 artifact 交给 metric。它还不能单凭一段视频声称某个 benchmark 已完整跑通。这正是 WorldFoundry 把生成、检查、评分和资格判断拆开的原因。

如果要理解各层、契约和设计理由，请继续阅读设计。

致谢