这一篇横评，我们故意不谈画质。原因很简单：世界模型和空间智能的 Demo 越漂亮，越容易让人忽略一个更硬的问题——你到底能不能用、敢不敢用、用得起用不起。对技术从业者来说，算账比看脸更有用：一份模型值不值得跟，取决于许可证、硬件和数据的真实成本，而不是发布会上的那一分钟。本站横评一贯的口径是只算账，不算脸面。下面先把口径钉死，再上对比。
一、评测口径：我们只算四本账
先声明本篇的边界，也避免和站内既有横评打架。本站已经发过三篇相关横评，分工如下：图像能力看 reasoning-image-models-comparison-review，Agent 长上下文成本账看 agent-long-context-cost-review，语音的云与本地账看 cloud-vs-local-voice-ai-review。本篇只做一件事：把开源世界模型这六个字拆开，看看哪些是真开源、哪些是假商用、哪些卡你根本买不起。想追 LingBot-World 2.0 的热点脉络，可看姊妹篇 LingBot-World 2.0 热点姊妹篇；想了解 gods-eye-view 的开源资源，可看 gods-eye-view 开源资源姊妹篇；想照着在小机器上本地部署，可看 本地部署 SOP 姊妹篇。
我们固定看四本账，顺序就是选型顺序，这个顺序别乱：
第一本账，开源程度。这里必须把权重公开、代码公开、部署代码公开三件事拆开。很多项目把权重往平台一扔就自称开源，但推理脚本、部署服务和训练代码一个都不给，这种开源只能叫能下载的闭源。星数高不代表你能复现。
第二本账，许可证的商用边界。这是本篇的核心。开源协议分三档：MIT 和 Apache-2.0 是商用友好档，CC BY-NC-SA 4.0 是明确禁商用档，中间还有要求声明、要求同协议衍生的一堆细节。选型第一步不是看星数，是看许可证能不能覆盖你的用途。
第三本账，硬件门槛。所有硬件数字我们都标官方口径或工程估算。官方 README 写的和仓库脚本写的，常常不是一回事；媒体宣传口径又常常比官方更激进。冲突时并列标注，并以官方代码仓为准。
第四本账，数据与控制权。模型跑在谁的服务上、数据落到谁的库里、你能不能导出、关不掉会不会被锁，这些才是长期成本。闭源订阅型产品在这本账上天然吃亏。
本篇所有数字来自 GitHub API 在 2026-09-14 的实核快照，文中标注公开报道口径的，属于媒体或官方博客口径，非我们实测。核不到的单价的写以官方为准，绝不编造价格。
二、四本账拆解
第一本账：开源程度（权重、代码、部署，三者分开看）
LingBot-World 2.0（仓库 Robbyant/lingbot-world-v2）把 14B 与 1.3B 两种规模的权重和一部分代码公开了，但官方明确不开源部署代码。这意味着你能拿到模型和训练相关代码，却拿不到它线上跑起来的那套服务，复现成本和二次部署成本都压在你自己身上。Genie 3 是另一极端，完全闭源，只通过 Gemini Ultra 订阅体验，连权重都没有。gods-eye-view（bilawalsidhu/gods-eye-view）是代码全开、浏览器本地跑的聚合式项目，开源程度最高。lingbot-map 与 lingbot-world v1 都是代码开源的 Apache-2.0 项目，部署代码开放。把开源这个词拆成三层之后，你会发现这七个项目其实落在三个不同的开放程度上，绝不是一句都开源能概括。
第二本账：许可证的商用边界（本篇核心论点）
这是整篇最想讲清楚的一件事：开源不等于可商用。LingBot-World 2.0 用的是 CC BY-NC-SA 4.0，NC 即 NonCommercial，明确排除任何商业用途；SA 即 ShareAlike，要求你的衍生作品也必须用同一协议开源。换句话说，你拿它做产品、做付费服务、甚至做内部商用系统，都踩在协议红线上。更隐蔽的坑在于：SA 条款会传染——你基于它做的改进若对外发布，也得开源成同协议，等于把你的私有价值强制公开。gods-eye-view 用 MIT，随便商用、随便闭源再分发，只要保留版权声明。lingbot-map 和 lingbot-world v1 用 Apache-2.0，商用友好，但要求保留声明、注明改动，且涉及专利的部分有默认授权。三档一摆，选型的第一刀应该切在许可证上，而不是星数上。
第三本账：硬件门槛（官方 README、仓库脚本、媒体口径，三者常常打架）
典型案例就是 LingBot-World 2.0。官方 README 的推理示例里，1.3B 模型用的是 4 卡；但同一仓库里的 run_fast.sh，参考设置是 1.3B 用 2 卡、14B 用 8 卡。两个数字都是官方口径，却差了一倍。媒体宣传里又常直接写消费级显卡可跑。做预算时我们建议以仓库脚本为准，因为那才是真能复制的命令，README 的示例往往是为了让人觉得门槛低而写的乐观版本。Genie 3 的 720p@24fps 属于公开报道口径，硬件门槛由 Google 服务端承担，用户端零门槛但零控制权。gods-eye-view 跑在浏览器本地，依赖 Node 24.x 或 26.x，硬件门槛最低。lingbot-map 做流式 3D 重建，工程估算需要中高端 GPU，具体算力以官方为准。
第四本账：数据与控制权
Genie 3 把数据和运行都锁在 Google 订阅里，你生成的内容归属和使用条款由对方定，控制权最低。LingBot-World 2.0 不开源部署代码，意味着你想私有化部署得自己造轮子，数据主权在你但工程成本高。gods-eye-view 聚合的是真实公开数据（航班、船舶、卫星、地震、交通、公共摄像头），localhost 绑定、数据不出本机，控制权和隐私最好，也最适合对数据出境敏感的场景。lingbot-map、lingbot-world v1 这类开源项目，数据与控制权天然在你手里，前提是你有能力自己部署。对于受合规约束的企业，这一本账往往比画质更决定选型。
三、横向对比表
下表列了七个项目，其中 OpenWorldLib 与 LightX2V 为补充项，数字以 2026-09-14 快照为准。所有硬件与成本标注，凡官方未给单价的，统一写以官方为准。读表时请先盯类型/层级这一列，它决定了一张表到底在比什么。
| 项目 | 类型/层级 | 开源程度 | 许可证与商用边界 | 硬件门槛（官方口径） | 部署代码是否开放 | 快照日期 |
|---|---|---|---|---|---|---|
| Robbyant/lingbot-world-v2（LingBot-World 2.0） | 生成式世界模型 | 权重+代码公开 | CC BY-NC-SA 4.0，禁商用，衍生须同协议 | 1.3B 参考 2 卡 / 14B 参考 8 卡（run_fast.sh） | 否 | 2026-09-14 |
| Genie 3（Google DeepMind） | 生成式世界模型 | 闭源 | 闭源订阅，商用边界由 Google 决定 | 720p@24fps（公开报道口径），用户端零门槛 | 否 | 2026-09-14 |
| bilawalsidhu/gods-eye-view | 前端聚合式空间视图 | 代码全开源 | MIT，商用友好 | 浏览器本地，Node 24.x 或 26.x | 是 | 2026-09-14 |
| Robbyant/lingbot-map | 重建式 3D / 空间智能 | 代码开源 | Apache-2.0，商用友好（须声明） | 流式 3D 重建，工程估算中高端 GPU | 是 | 2026-09-14 |
| Robbyant/lingbot-world（v1） | 生成式世界模型（v1） | 代码开源 | Apache-2.0，商用友好（须声明） | 工程估算中高端 GPU | 是 | 2026-09-14 |
| OpenDCAI/OpenWorldLib（补充） | 世界模型工具库 | 代码开源 | Apache-2.0 | 未确认 | 是 | 2026-09-14 |
| ModelTC/LightX2V（补充） | 视频生成加速库 | 代码开源 | Apache-2.0 | 未确认 | 是 | 2026-09-14 |
把这张表读对的方式，是先看类型/层级这一列。生成式的（LingBot-World 2.0、Genie 3、lingbot-world v1）、重建式的（lingbot-map）、前端聚合式的（gods-eye-view），根本不是同一个问题域。把它们塞进同一张表比谁更强，比的是你想解决哪一环。一个想做数字孪生工厂的团队，和一个想做游戏实时生成场景的团队，答案会完全不同；用同一把尺子量，只会得出错误的结论。
四、分层选型建议
按三类读者给结论，避免一句都很好的废话。选型的顺序永远是：许可证、部署开放度、硬件、星数。
个人研究者。你的目标通常是复现论文、跑通 Demo、发自己的实验。优先看开源程度和硬件门槛。gods-eye-view 的 MIT 与浏览器本地运行，是个人把玩和教学成本最低的选择；想碰生成式世界模型，lingbot-world v1 的 Apache-2.0 比 2.0 的 CC BY-NC-SA 4.0 更适合做研究衍生，因为 v1 不卡商用转化的后路。补充项 LightX2V 适合做视频生成加速实验。提醒一句：个人研究虽不商用，但若未来想转产品，从 v1 起步比从被 NC 卡死的 2.0 起步省掉一次重写。
小团队做产品。这里是许可证红线最要命的一层。如果你准备做付费或对外服务，LingBot-World 2.0 的 CC BY-NC-SA 4.0 直接出局，别犹豫。gods-eye-view 的 MIT 可以放心闭源包装；lingbot-map 的 Apache-2.0 能做商用，但记得保留声明、写清改动，并把专利条款读一遍。硬件上，gods-eye-view 几乎零边际成本，lingbot-map 的工程估算门槛需要你先确认 GPU 预算。小团队最忌先上线再补合规，NC 协议一旦商用就是侵权，不是补张声明能救的。
商用集成（大厂或乙方）。控制权这本账对你最重要。闭源的 Genie 3 适合做先验证需求的快速原型，但长期集成要把数据和条款锁死的风险算进去，订阅涨价或条款变更都可能让你交付失败。真正能私有化、可审计的，是 Apache-2.0 或 MIT 的开源项。我们的建议是：先用开源项搭骨架，把商用边界写进采购和法务评审，再决定要不要接闭源订阅做补充能力。对受数据合规约束的行业，开源且部署代码开放是硬门槛，Genie 3 这类闭源订阅从根上就不在候选里。
五、冷思考：这波热度的水分在哪
第一，星数不等于可用性。gods-eye-view 三万多星，部分是聚合公开数据的炫酷前端带来的流量，它解决的不是世界模型的生成问题，而是看得见真实世界的呈现问题。把它和生成式模型比谁是世界模型，是比错了维度。星数是社区注意力的滞后指标，不是工程可用性的先行指标。
第二，闭源订阅的零门槛是糖衣。Genie 3 用户端零门槛，但代价是零控制权、按订阅计费、条款随时可变。对做产品的团队，这种依赖是定时炸弹：今天能跑的 Demo，明天可能因为条款改了就跑不了。把核心能力押在别人的订阅上，等于把命脉交出去。
第三，官方开源和能部署的开源中间隔着一条河。LingBot-World 2.0 开源了权重和代码，却不开源部署代码，复现成本被悄悄转嫁给你。看开源程度时，务必把部署代码是否开放单独问一句，这一句往往决定你三个月后能不能上线。
第四，硬件口径的注水最容易被忽略。README 示例、仓库脚本、媒体宣传三个数字互相打架时，媒体那版往往最乐观，README 次之，仓库脚本最保守。预算请认准仓库里能复制的命令，并以官方为准。
第五，热闹不等于成熟。这一波世界模型里，有生成、有重建、有聚合，三类成熟度天差地别：生成式最炫但协议最紧、工程最重；重建式最实但离世界最远；聚合式最轻但根本不是生成。把不同成熟度的东西炒成一个概念，是这波热度最大的水分。
一句话收尾：这波世界模型的热度里，真正值得跟进的是分层这件事——生成、重建、聚合是三件不同的事，选错了层，再强的模型也救不了你的需求。
常见问题
Q1：开源协议到底怎么分商用边界？
A1：简单分三档。MIT 最宽松，商用、闭源、再分发都行，只留版权声明。Apache-2.0 也商用友好，但要求保留声明、注明改动，并附带专利授权条款。CC BY-NC-SA 4.0 的 NC 禁商用、SA 要求衍生同协议，做产品基本出局。选型第一步看许可证，不是看星数。
Q2：LingBot-World 2.0 我能拿来商用吗？
A2：不能，至少不能直接商用。它用 CC BY-NC-SA 4.0，NonCommercial 明确排除商业用途，ShareAlike 还要求你的衍生作品同协议开源。做付费服务、对外产品、甚至内部商用系统都踩红线。想用生成式世界模型做商用，改看 lingbot-world v1 的 Apache-2.0 或 gods-eye-view 的 MIT。
Q3：硬件门槛到底以哪个数字为准？
A3：以仓库里能复制运行的脚本为准，通常比 README 示例和媒体宣传更保守。LingBot-World 2.0 就是典型：README 示例 1.3B 用 4 卡，run_fast.sh 参考 1.3B 用 2 卡、14B 用 8 卡。做预算认脚本，冲突时以官方代码仓为准，媒体口径只作参考。
Q4：gods-eye-view 算世界模型吗？
A4：它不算生成式世界模型，而是前端聚合式空间视图。它把航班、船舶、卫星、地震、交通、公共摄像头等真实公开数据在浏览器本地聚合呈现，解决的是实时看见真实世界的问题，不是生成虚拟世界。把它和生成式模型放一起比，要比的是你想解决哪一环，而不是谁更强。
Q5：选型第一步该看什么？
A5：先看许可证能不能覆盖你的用途，再看开源程度里部署代码是否开放，最后才看星数和 Demo。星数是流量，许可证是生死线。商用项目尤其要先把 CC 类协议排除掉，再去谈模型和硬件。