在 AI 技术飞速迭代的当下大语言模型LLM的参数规模一路狂飙从百亿到千亿再到万亿似乎“更大”已经成了智能的代名词。但最近 Hacker News 上有一个讨论帖非常值得关注“AI research 到底需要的是更大的 LLM还是真正意义上的 world models世界模型”这个问题戳中了两个方向的核心矛盾一边是 scaling law 驱动下的暴力美学另一边是认知科学和机器人领域倡导的“对物理世界的理解与模拟”。这篇博客不会站在某个阵营去“站队”而是尽量把两个概念拆开揉碎带你理解它们的本质区别、适用场景、各自的优劣以及在工程实践中如何取舍和结合。如果你是 AI 应用开发者、算法工程师或者正在思考自己项目技术路线的同学这篇文章会给你一个比较清晰的分析框架。我们首先明确一个共识更大的 LLM 解决的是“文本空间里的模式拟合”而 world models 解决的是“真实世界中的因果与状态推演”。两者并不完全互斥但在研究资源分配和技术选型上确实存在一个优先级的问题。接下来我会从概念、技术原理、各自的代码/实验示例、工程落地、常见坑点以及最佳实践这几个维度把这个问题完整地过一遍。1. 背景与核心概念LLM 与 World Models 到底在争什么1.1 什么是大语言模型LLM大语言模型Large Language Model本质上是基于 Transformer 架构在海量文本语料上进行自监督预训练的统计模型。它的核心能力是通过前一个 token 预测下一个 token从而学到一个“文本世界”里的概率分布。从 GPT-3 到 GPT-4 再到各类开源模型LLM 的scaling路线基本遵循“更大参数量 更多训练数据 更强算力”。这种方法的优势非常明显语言理解与生成能力强在文本任务上接近甚至超越人类平均水平具备一定的常识知识和逻辑推理能力能在对话、写作、代码生成、翻译等任务中通用训练框架成熟生态丰富无论是 API 调用还是开源权重部署都很方便。但它的短板同样明显缺乏真实世界的因果建模LLM 是在“文字卡片”上训练的它没有真正经历过“杯子掉在地上会碎”“人饿了会找东西吃”这类物理/生理过程它只是见过太多描述这些过程的文本因此在某些逻辑推理和长程规划任务上容易出现“一本正经地胡说八道”上下文长度限制尽管各家模型在把上下文窗口从 2K 拉到 1M但依然无法真正在推理时动态构建一个持久的环境状态无法与物理环境实时交互单纯靠 pre-training 得到的 LLM 无法直接控制机器人、自动驾驶汽车等需要连续决策的实体。1.2 什么是世界模型World Models提出“世界模型”概念比较有代表性的工作是 2018 年的论文World Models作者是 David Ha 和 Jürgen Schmidhuber。这篇论文相当简洁地展示了在一个模拟的赛车游戏CarRacing环境中用一个循环神经网络RNN学习环境的状态转移规律再用一个策略网络基于这个学习到的“梦中环境”进行规划和控制可以做到只靠视觉输入就能学会驾驶。世界模型的核心是智能体在它的大脑里建立一个对外部环境的内部模拟器。它不只记录“人类说过的句子”而是持续更新“当前世界处于什么状态”“如果执行某个动作世界会变成什么样”。所以英文里经常提到的 world model 通常包含三个组件感知模型Vision/Encoder把高维的观测图像、点云、传感器数据压缩到低维的隐状态表示。动力学模型Memory/RNN/SSM学习状态转移函数即给定当前隐状态和动作预测下一时刻的隐状态。决策模型Policy/Controller在隐空间里做规划或直接输出动作。这里的“世界”可以指真实物理世界机器人、自动驾驶也可以指虚拟环境游戏引擎、仿真器甚至可以是抽象的规则系统棋类、数学推理。1.3 两种路线的核心分歧是什么回到标题中的问题AI research 到底需要世界模型还是更大的 LLM这个问题的本质是如果要让 AI 在真实世界中可靠地解决复杂问题而不只是聊天和写文档我们应该把资源花在扩大语言模型的规模上还是花在构建能够模拟环境动态的模型上从研究界的讨论来看支持“更大 LLM”的一派认为语言中已经隐式编码了大量关于世界的知识只要模型足够大、数据足够多AGI 所需要的推理能力可以量化地涌现出来。支持“世界模型”的一派则认为智能的本质是行动与反馈的循环如果没有对环境的内部模拟能力模型永远只能在“文字的真实”里打转无法应对物理世界的无限细节。在实际工程中这两种路线并不是完全对立的。现在越来越多的框架是把 LLM 作为“推理和语言接口”把 world model 作为“环境动态模拟器”两者通过 Agent 架构互相配合。这也是后面要讲的“融合趋势”。2. 技术原理拆解从 Loss Function 到状态推演2.1 LLM 的“世界知识”是怎么来的我们可以从架构和训练目标两个层面来理解 LLM 为什么缺乏真正的世界模型。架构层面Transformer 本质上是一个 attention 机制构成的序列转换器。它处理的是 token 序列每个 token 通过 embedding 映射成向量然后在多层 self-attention 中根据上下文更新表示。这个过程中并没有什么显式的“物理状态”变量也没有“环境反馈”输入。训练目标层面LLM 的预训练目标是最大化下一个 token 的 log 概率[ L_{\text{LLM}} -\sum_{t} \log P_{\theta}(x_t \mid x_{t}) ]也就是让模型学会“以文本为条件预测最合理的下一个文本片段”。在互联网级别的语料上这个目标确实能学到大量陈述性知识比如“巴黎是法国的首都”但它学不到真正的交互式因果例如“我推了一下杯子它会以什么轨迹倒下”这类连续、物理、状态依赖的过程。更直白地说LLM 的推理是“从记忆/模式中检索并组合答案”而不是在内部模拟一个动态系统然后“观察”结果。它在很多问题上看起来有推理能力但本质上更像是在文本模式的流形上进行插值。2.2 世界模型的核心思想世界模型的做法完全不同。我们拿一个非常简单的例子说明假设我们要训练一个机器人学会“把球推进球门”。传统 RL 或行为克隆的做法需要大量真实轨迹。而世界模型的做法是先让机器人在环境里随机或按某个策略采集一些经验轨迹图像序列 动作序列训练一个 VAE变分自编码器将每一帧图像压缩成隐编码 z_t训练一个 RNN或 Mamba 等序列模型学习隐空间中的动态[ z_{t1}, r_{t1} f_\theta(z_t, a_t) ]在隐空间里执行“想象 rollout”也就是不吃真实数据只用自己的动力学模型不断预测下一步用来训练策略网络。这里的核心区别是模型的输入不仅包括用户指令和文本上下文还包括一个持续更新的隐状态 z_t这个状态是通过真实观测和动作的闭环反馈来维护的。所以世界模型天然支持连续决策、规划和多步推演。2.3 计算复杂度和训练方式的关键差异维度大语言模型 (LLM)世界模型 (World Model)核心输入文本 token 序列观测图像/点云/状态 动作核心输出下一个 token 概率下一时刻状态预测 奖励/代价预测训练目标文本似然最大化状态重建误差 动态预测误差主要架构Transformer DecoderVAE RNN/SSM Policy数据来源互联网文本环境交互轨迹仿真/真实环境交互能力无静态预测有闭环反馈典型任务对话、代码、写作机器人控制、自动驾驶、游戏 AI从数据成本上看LLM 的优势是海量文本可近乎无限获取世界模型则需要专业的环境交互数据往往要用仿真器。从推理性能上看LLM 可以并行生成文本世界模型在隐空间做 rollout 时虽然维度低但需要逐步计算延迟不低。2.4 案例分析为什么 LLM 做长程规划会失效假设你让一个 LLM 设计一个“煮面条”的步骤它通常能给出烧水水沸后放面条煮 5-10 分钟关火捞出但如果你要求它在一个模拟厨房环境里真正完成这个任务比如控制机械臂把锅放到灶台上、开火、取面条包装、撕开包装、把面条放进锅里、调节火力……LLM 根本不知道锅的当前状态、灶台的旋钮角度、面条是否在锅里。它缺少一个关于当前环境的动态状态表示。而世界模型能够在每一步执行前进行“头脑预演”我现在把旋钮向右转 30 度火焰大小会变成某个状态锅的温度会以什么曲线上升。在隐空间里做规划找到一条可靠的动作序列。这个案例很好地说明了语言的推理和真实世界的状态推断是完全不同的两回事而大多数现实 AI 任务需要后者。3. 完整实战案例用代码理解两种模型的差异理论讲完了我们直接进入动手环节。这里我会分别演示一个极简的 LLM 推理代码和一个极简的世界模型训练代码。代码以思路演示为主实际训练需要根据环境调整。3.1 示例一LLM 的静态推理基于 HuggingFace Transformers这是一个非常标准的 LLM 生成代码片段我们观察它的问题在哪里。# 文件路径examples/llm_inference.py from transformers import AutoModelForCausalLM, AutoTokenizer model_name Qwen/Qwen2.5-1.5B-Instruct # 这里可以换成你本地已有的模型 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained(model_name, device_mapauto) prompt 如果我把一个玻璃杯从桌上推落接下来会发生什么 messages [ {role: system, content: 你是一个物理世界助手。}, {role: user, content: prompt}, ] text tokenizer.apply_chat_template(messages, tokenizeFalse) inputs tokenizer(text, return_tensorspt) outputs model.generate( inputs.input_ids, max_new_tokens128, temperature0.7, do_sampleTrue, ) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))运行结果大概率是如果我把一个玻璃杯从桌上推落接下来会发生什么 首先玻璃杯会失去支撑开始在重力作用下向下运动。在接触地面前它会经历自由落体运动。当杯底撞击地面时由于地面是坚硬的杯身会承受巨大的冲击力最终破裂成碎片。碎片可能飞溅到周围区域需要注意安全。这个回答看起来很合理但它只是一个“基于语言模式的生成结果”不是模型在内部模拟了玻璃杯的运动轨迹。如果桌子高度是 0.7 米还是 1.5 米杯子是玻璃还是塑料地面是木地板还是瓷砖这些改变会导致不同的结果但 LLM 不一定会根据这些物理条件变化而精确调整答案因为它没有对这些条件做显式的状态建模。3.2 示例二极简世界模型基于 numpy 一个简单的 RNN 风格训练下面这个示例更接近世界模型的核心思想学习一个环境的状态转移函数。我们使用一个非常简单的二维点运动环境。假设环境里有一个小球它的状态是位置 (x, y) 和速度 (vx, vy)动作是施加一个力 (fx, fy)。我们用一个神经网络学习“给定当前状态和动作预测下一状态”。这里为了演示我直接用了一个线性非线性拟合的网络不引入太重的依赖。# 文件路径examples/mini_world_model.py import numpy as np import torch import torch.nn as nn import torch.optim as optim # 1. 定义“真实环境”一个简单的带阻尼的质点运动 class PointMassEnv: def __init__(self): self.dt 0.1 self.damping 0.98 def step(self, state, action): # state [x, y, vx, vy] x, y, vx, vy state fx, fy action # 真实物理规律速度更新 位置更新 nvx (vx fx * self.dt) * self.damping nvy (vy fy * self.dt) * self.damping nx x nvx * self.dt ny y nvy * self.dt return np.array([nx, ny, nvx, nvy]) # 2. 收集训练数据 env PointMassEnv() data_size 10000 X [] # 输入 [state, action] Y [] # 输出 next_state for _ in range(data_size): state np.random.uniform(-1, 1, 4) action np.random.uniform(-0.5, 0.5, 2) next_state env.step(state, action) X.append(np.concatenate([state, action])) Y.append(next_state) X torch.tensor(X, dtypetorch.float32) Y torch.tensor(Y, dtypetorch.float32) # 3. 定义一个简单的动力学模型World Model class DynamicsModel(nn.Module): def __init__(self): super().__init__() self.net nn.Sequential( nn.Linear(6, 64), nn.ReLU(), nn.Linear(64, 64), nn.ReLU(), nn.Linear(64, 4), ) def forward(self, state, action): x torch.cat([state, action], dim-1) # 正常情况下保留 state 参数 return self.net(x) model DynamicsModel() optimizer optim.Adam(model.parameters(), lr1e-3) loss_fn nn.MSELoss() # 4. 训练 batch_size 256 for epoch in range(100): perm torch.randperm(data_size) total_loss 0 for i in range(0, data_size, batch_size): idx perm[i:ibatch_size] xb X[idx] yb Y[idx] state xb[:, :4] action xb[:, 4:] pred model(state, action) loss loss_fn(pred, yb) optimizer.zero_grad() loss.backward() optimizer.step() total_loss loss.item() * len(idx) if (epoch 1) % 20 0: print(fEpoch {epoch1}, Loss: {total_loss / data_size:.6f}) # 5. 验证用模型预测未来 20 步 test_state torch.tensor([[0.0, 0.0, 0.5, 0.0]], dtypetorch.float32) action torch.tensor([[0.2, 0.0]], dtypetorch.float32) print(\n 模型想象 rollout 轨迹 ) for step in range(20): with torch.no_grad(): next_state model(test_state, action) print(fStep {step}: x{next_state[0,0].item():.3f}, y{next_state[0,1].item():.3f}, vx{next_state[0,2].item():.3f}, vy{next_state[0,3].item():.3f}) test_state next_state运行后你会看到模型在不接触真实环境的情况下通过“自我想象”连续预测的小球运动轨迹。虽然这个例子非常简单但它的原理和 DeepMind 的 Dreamer、Ha 与 Schmidhuber 的World Models论文是完全一致的先用一个模型学习动态然后在模型的“梦境”里做规划。在真实的机器人项目里你可以把这个 DynamicsModel 换成更复杂的 SSM状态空间模型或者 Diffusion World Model训练数据也换成相机图像与关节指令但核心逻辑不变。3.3 示例三在 Agent 框架里把 LLM 和世界模型融合现在更主流的做法是用 LLM 做高层任务分解用 world model 做底层物理规划。我用一个伪代码来说明这种融合架构。# 文件路径examples/llm_plus_wm_agent.py class LLMWorldModelAgent: def __init__(self, llm, world_model, env): self.llm llm # 大语言模型 self.world_model world_model # 世界模型 self.env env # 真实的仿真环境或 robot def plan(self, task: str): # 1. LLM 将自然语言任务分解成子任务 sub_tasks self.llm.decompose(task) # 例如 把杯子放到桌角 - [移动到杯子附近, 抓取杯子, 移动到桌角, 释放杯子] current_state self.env.get_obs() for sub in sub_tasks: # 2. 对于每个子任务用 world model 在隐空间做规划 action_seq self.world_model.plan( goal_embeddingself.llm.encode_goal(sub), start_statecurrent_state ) # 3. 执行动作序列 for action in action_seq: current_state self.env.step(action) # 4. 把真实反馈喂回 world model更新隐状态 self.world_model.update_state(current_state) return self.env.is_goal_reached(task)这个架构的漂亮之处在于分工明确LLM 不用强行去理解“每毫秒的电机电流和关节角度”world model 也不用费劲去生成自然语言指令只需要在低维状态空间做预测和规划。两者结合就构成了一个有“高层认知”又有“物理直觉”的智能体。4. 实际项目中的技术选型应该更侧重哪一边回到最初的讨论AI research 需要 world models 比更大的 LLM 更迫切吗我的观点是取决于你解决什么问题。下面从几个典型场景出发做分析。4.1 需要更大 LLM 的场景如果你做的产品核心是“人类文本交互”比如智能客服、写作辅助、代码生成、知识库问答、翻译等那更大 LLM 带来的收益是很直接的。这类任务本质上是语言流形学习数据越多、模型越强效果越好。在这些场景里world model 几乎帮不上忙。你不需要去预测“用户下一句会显示在屏幕上的位置”或者“点击发送按钮后网络包的路径”你只需要在语义空间中给出合适的回答即可。工程上更值得关注的是上下文长度管理长文档回答如何不丢信息RAG 检索质量给 LLM 提供更准确的证据输出结构化JSON、Function Calling推理成本优化用小模型蒸馏/路由4.2 需要世界模型的场景如果你的任务必须在“连续状态空间”中做决策比如机器人操作抓取、移动、装配自动驾驶预测其他车的轨迹、自车控制游戏 AI实时策略、物理模拟工业控制温度、压力、流量调节多智能体仿真无人机编队、交通流控制那么没有世界模型的 LLM 只能当“大脑皮层”里的语言中枢无法直接产生肌肉记忆和反射弧。在这些领域里数据规模和参数量的优先级会排在“环境交互效率”之后。典型的判断依据是任务是否存在一个明确的“状态”它随时间变化而且动作会影响下一个状态。如果存在你就需要某种形式的动力学模型。4.3 如何评估一个任务是否需要世界模型我总结了一个简单的 checklist你可以拿来判断问题如果“是”更偏向 LLM如果“是”更偏向 World Model输入输出是否都是文本/图像✅❌是否存在连续时间、连续动作❌✅任务是否需要多步物理交互❌✅是否允许试错和使用仿真器不一定✅错误容忍度一次错误回答 vs 一次错误操作回答错误可重试操作错误可能损坏设备最终交付物是文档/代码还是决策/动作文档代码决策动作5. 常见问题与排查思路在实际开发中无论你选择哪条路线都会遇到一些典型问题。下面是我梳理的高频问题排查表。5.1 如果用了更大 LLM 但长程任务仍然失败问题现象常见原因解决思路Agent 执行到第 3 步就遗忘目标上下文污染早期信息被后续中间步骤覆盖用摘要/记忆模块压缩历史关键状态不要把所有历史塞进上下文多步推理结果不一致LLM 没有内部状态约束每一步独立推理引入“状态变量”显式记录例如在执行之前定义 PDDL 或 JSON 状态指令冲突时行为不可控系统提示词被用户输入覆盖做提示词注入防护增加输入校验和角色隔离在物理仿真环境中无效动作太多模型没有动作空间约束用函数调用约束输出格式或加一层 Mask/规则过滤5.2 如果训练世界模型但效果不好问题现象常见原因解决思路想象 rollout 发散误差累积单步预测误差在长程递归中指数增长训练时混合多步预测类似 Truncated BPTT或引入对抗式判别器状态隐变量不连续规划困难VAE 表示空间没有平滑约束增加 KL 正则项尝试用 Deterministic Autoencoder 或 RSSM 等模型结构数据量不足导致过拟合仿真数据有限增加 domain randomization或采用数据增强也可以先预训练视觉 encoder再冻结做动态学习在线部署时状态估计漂移传感器噪声和 Sim2Real gap 太大加入 Kalman Filter/粒子滤波等状态估计模块或者继续用真实数据微调 encoder5.3 融合架构中常见的工程坑问题现象常见原因解决思路LLM 生成的目标描述 world model 无法理解目标表示不够低维/不够向量化定义一个共享的中间表示如“目标物体名称 → 语义 embedding 或位姿信息”加一个对齐层模型训练的隐状态和真实环境状态偏移世界模型在线更新不及时每次真实观测后强制更新隐状态而不是在固定步数后才同步推理延迟高无法实时控制LLM world model 串联推理耗时将 LLM 规划放在一个低频率循环world model 规划放在高频率循环二者异步执行6. 最佳实践与工程建议无论你的选择偏向哪一边下面这些经验都可以帮助你把方案做得更稳健。6.1 不是二选一而是分层决策在实际系统里把问题抽象成“认知层 物理层”会让架构更清晰。认知层解决“做什么、为什么做”物理层解决“怎么做”。LLM 适合在认知层做任务分解、常识推理、人机交互world model 适合在物理层做状态估计、轨迹规划、运动控制。例如一个仓储机器人的任务可以这样分层认知层LLM理解“把A区的箱子搬到B区”结合仓库地图和当前任务队列制定方案物理层World Model预测机械臂抓取某个箱子时的手爪姿态、需要的力度、移动路径执行层PID/MPC把规划轨迹转成电机电流指令。每一层不需要“什么都会”但必须“把自己那部分做扎实”。6.2 安全边界与权限设计在真实物理系统中要让 world model 输出动作必须设置安全边界这比追求更精确的预测更有优先级。规划后的动作要经过安全检查器例如关节限位、速度限制、温度阈值预测误差超过阈值时系统应回到安全状态或请求人类介入使用仿真器训练时加入随机扰动domain randomization以提高泛化能力在涉及生产环境时先在仿真环境做大量验证再逐步灰度到真实环境。6.3 数据效率世界模型的核心瓶颈相比 LLM 可以用“无限量文本”world model 的数据瓶颈往往卡在环境交互成本上。这里有几个可行的实践先在仿真器里预训练再用真实数据微调。仿真器可以快速跑出大量覆盖各种情况的轨迹。重视多任务复用。如果两个任务共享状态转移规律比如搬运方盒子和搬运圆球底层动力学可以共用只在上层感知做区分。使用 Model-based RL 的内循环。让 world model 生成短训练片段hallucinated experience再用这些片段更新策略可以大幅降低真实交互需求。6.4 设计可观测的评估指标做融合方案时除了观察最终任务成功率还要单独监控每一层的质量层指标LLM 计划层任务拆解准确率、步骤顺序合法性、指令遵循率World Model 预测层单步预测误差MSE、多步 rollout 误差、状态重建 PSNR决策执行层成功率、平均完成时间、碰撞次数、能量消耗调度层端到端延迟、CPU/GPU 占用率当系统出现问题时通过指标定位是“拆解错了”还是“预测漂移了”能省去大量排查时间。6.5 不要忽视“低技术”但稳定的中间方案对于很多项目而言完全投入自研世界模型成本太高。在有明确物理规则的情况下先采用传统的运动学/动力学解析模型 Kalman Filter配合 LLM 做任务调度往往比训练一个深度 World Model 更稳定、更可解释。先把流程跑通再逐步在关键环节替换成学习模型。7. 总结与学习路线关于“AI research 是否需要世界模型而不是更大的 LLM”我的结论是它不是一个非此即彼的问题而是一个优先级和资源分配的问题。如果你正在做文本/ChatBot/知识处理类产品继续拥抱 LLM scaling 是正确路径同时要想办法用 RAG、Function Calling、Agent 框架弥补纯文本模型在状态管理上的不足。如果你正在做机器人、自动驾驶、工业控制、仿真游戏等需要与环境闭环交互的任务那么忽略世界模型而去堆更大的 LLM基本是在“缘木求鱼”。接下来建议的学习路线先读透经典论文David Ha 和 Schmidhuber 的World Models、DeepMind 的 Dreamer 系列、以及近年基于 Transformer 的决策模型如 Decision Transformer、Trajectory Transformer。跑通一个仿真环境推荐从 Gymnasium 的 CarRacing、Mujoco 的 HalfCheetah 或 Isaac Gym 入手实现一个最简单的 world model 并在里面做想象 rollout。学习隐空间动力学模型RSSMRSSM 是目前较可靠的状态空间世界模型结构理解了它你能更容易读懂 SSM 和扩散世界模型。把 LLM 接进来在已有的 RL 项目里加一个 LLM 层做任务规划先用规则约束输出格式再逐步放开自由度。工程落地选择一个垂直场景比如“桌面机械臂抓取”从数据采集、模型训练到部署形成闭环记录失败样本持续迭代。AI 领域的发展很快今天还在争论“参数规模 vs 世界模型”明天就可能有新的架构把两者统一起来。技术选型的判断力来源于你对底层概念的理解深度而不是盲目追逐热度。希望这篇文章能帮你把这个问题想得更清楚在研究和工程路上少踩一些坑。