这篇访谈的主角是 Jeff Dean。Google Brain 的核心推动者、TensorFlow 的重要作者也是过去十几年把“深度学习 大规模分布式系统”这条路线真正推到工业界的人。访谈主题是“AI 的下一次范式升级”它讨论的不是某个模型又刷了多少个评测分数而是整个 AI 产业接下来会往哪个方向迁移。从工程师视角看这个问题的价值很直接它决定了我们未来半年到两年要学什么、要改什么部署架构、要为哪些基础设施花钱。范式升级的本质是“应用形态”和“工程方法论”同时发生变化。模型能力只是其中一层更关键的是推理成本、系统可靠性、评估方式和产品交互方式都要跟着变。这篇文章会把访谈里提到的几个升级方向拆开讲结合本地部署、推理服务、Agent 架构和性能优化这些实际工程场景给出一套可以直接落地的技术判断。这里不重复访谈原文重点做技术解读和落地分析。1. 核心观点速览这次范式升级到底指什么Jeff Dean 在访谈里强调的是“系统性的迁移”不是单点更新。从工程角度看可以整理成一张规格表来理解维度过去的核心模式下一次范式升级的方向模型能力快速生成下一个 Token在推理阶段投入更多计算形成“推理系统”应用形态单轮问答、内容生成Agent 执行多步任务自己规划、调用工具、纠错数据范围以文本为中心多模态统一扩展到图像、视频、传感器、物理世界数据系统优化单点算法改进硬件、编译器、分布式系统、模型结构联合设计工程目标追求排行榜分数追求可观测、可评估、低成本、稳定可靠的线上系统这五个方向不是独立存在的它们咬合在一起才构成“下一次范式升级”。下面展开讲每个方向。2. 范式升级的技术脉络为什么是“下一次”要理解“下一次”先要看清前几次。AI 领域过去几十年大体经历了三次大迁移。第一次是统计机器学习。特征工程加传统模型靠人工设计特征模型容量有限能解决的问题边界很窄。第二次是深度学习。神经网络把“特征工程”变成了“表示学习”加上大规模数据和 GPU 计算图像识别、语音识别、机器翻译这些任务被快速重写。第三次是生成式大模型。Transformer 配合自监督学习让模型从“识别”变成“生成”文本、图像、音频、视频都能在一个统一的生成框架下处理。Jeff Dean 谈的下一次范式升级可以理解为第四次迁移。这次迁移不是换一个更大的模型而是把模型从“内容生成器”变成一个可以自主完成任务的“系统组件”。它包含了四个显著特征。第一推理时间计算大幅度增加。模型不再是“看到问题立刻输出答案”而是先内部思考、构造多步推理、甚至搜索多条路径再选答案。第二Agent 开始扮演应用主体。过去用户直接面对模型未来用户面对的是一个能调度模型、工具和数据的代理系统。第三多模态和世界模型融合。文本模型升级为能理解物理世界规律、能操作传感器和机器人的模型。第四软硬件协同设计成为硬约束。模型再强最后都要落到实际卡上的推理成本。谁能在单位电力内跑出更多有效计算谁就掌握下一阶段的部署优势。从工程角度看这次迁移意味着我们不能再把“调 API”当作全部工作。模型选择、推理策略、任务编排、评估体系和成本控制会被重新组合。3. 从“预测下一个词”到“推理系统”过去几年我们习惯了这样的调用方式给模型一段 prompt模型在几百毫秒内把答案流式吐出来。这种模式的特点是“快”但快也意味着模型没有机会进行复杂的内部推演。传统自回归生成是单次前向过程每一步都要选中一个 Token。如果题目本身逻辑链条很长快速生成很难一步到位。推理模型则把“思考”显式地变成计算过程模型会在生成最终答案之前先产生多条推理链再对这些路径进行验证和取舍。这个变化对工程的影响非常大。最直接的一点是延迟不再是唯一指标。一个需要多步推理的问题如果让普通快速模型回答可能在 5 秒内给出答案但错误率很高。让推理模型回答可能要花 40 到 60 秒答案质量明显提升。这时候你要做的是在“快而错”和“慢而对”之间建立分层策略而不是一刀切地全上一个模型。一个可行的做法是配置推理路由按任务难度分配模型# 推理路由示意简单任务走快速模型复杂任务走推理模型 route: - match: [extract_keywords, translate, classify, summarize] model: fast-model max_tokens: 512 - match: [code_generation, math_proof, multi_step_planning] model: reasoning-model max_tokens: 4096这种路由配置可以直接放在网关层也可以作为 Agent 内部的工具选择规则。它的核心思想是为不同复杂度的请求分配不同的推理预算避免所有请求都付推理模型的高成本。从基础设施角度看推理系统化也会改变部署方式。推理模型生成长思维链时需要更大的 KV Cache显存占用会比普通模型高。如果要支持并发请求还需要做前缀缓存、连续批处理和量化压缩。这些优化不是可选项而是上线前就要设计好的部分。判断一个系统是否真正转向“推理系统”的标准很简单看线上请求是否根据任务复杂度动态分配计算资源而不是把所有请求塞进同一个固定参数的模型里。4. Agentic AI从“会聊天”到“能完成任务”Jeff Dean 对 Agent 方向的判断在工程上几乎是共识了。下一阶段的应用不会停留在“聊天框里回答问题”而是一个 Agent 系统接收用户目标之后自己去拆解任务、调用工具、检查结果、修正路线最后完成交付。这背后有几个关键能力在升级。第一工具调用。模型不再只输出文本而是输出结构化的函数调用结果例如搜索订单、执行 SQL、调用第三方 API。工具调用需要稳定可靠的接口协议以及处理工具返回异常的能力。第二任务编排。Agent 要把一个大目标拆成多个子任务决定先做哪一步、哪些可以并行、哪些必须串行。这个能力决定了它不是一个“玩具 Demo”而是一个能处理真实业务流的系统。第三状态管理与记忆。多步任务中间会产生大量中间状态Agent 需要维护短期上下文和长期记忆避免在步骤执行到一半时丢失信息。第四自我反思和失败重试。任务执行过程中一定会遇到工具报错、数据格式不符、结果不符合预期等情况。Agent 必须能读取错误信息调整策略后重试而不是直接中断。工程上实现一个最小可用的 Agent可以考虑下面的配置结构{ agent: { name: batch-ops-agent, tools: [search_orders, call_llm, execute_sql, send_notification], max_steps: 5, retry: 2, timeout_seconds: 120, checkpoint: ./agent_state/checkpoint.json } }这里的关键不是把多个工具塞给模型而是要建立清晰的边界每一步执行前先明确目标和验收条件工具调用必须有超时和重试所有中间结果要落到日志或状态文件执行失败时模型拿到错误信息后重新规划而不是盲目重复同一操作。从落地角度看Agent 不适合一开始就做成“万能助手”。更稳妥的路径是选一个高重复度、高失败率、规则清晰的任务比如“批量处理用户上传的文档并生成结构化摘要”先把一条链路跑稳再扩工具范围。5. 多模态与世界模型文本只是起点文本模型让 AI 理解语言但现实世界的信息远不止语言。下一次范式升级里一个非常明显的方向是让模型在统一框架下处理文本、图像、音频、视频以及机器人传感器产生的连续数据流。多模态统一模型的意义不只是“能看图说话”更体现在跨模态的推理能力。模型可以读取实验记录、分析图表、结合文字描述最后输出完整结论。这类能力在科研、制造、医疗辅助等场景里价值要比单模态模型高很多。部署多模态模型时要额外注意几个点输入编码器会占用额外显存。图像、视频输入的实际显存占用取决于输入分辨率、帧数和编码器结构上线前要在目标显卡上做实测。上下文长度会快速增长。多模态输入会把大量视觉 Token 塞进上下文导致 KV Cache 膨胀影响最大并发数。模态之间的对齐质量决定了输出质量。文本 prompt 和图像 prompt 不能割裂设计必须联合调优。更远一步是“世界模型”。这类模型不满足于理解数据表面而是尝试建立对物理规律、物体运动、因果关系的内部表示。机器人在陌生环境中行动时如果模型能预测“推动杯子会带来什么结果”就能更好地规划动作序列。这个方向目前还处于研究到工程的过渡期。但从部署角度可以提前做准备关注模型是否支持多模态输入、推理框架是否支持动态分辨率、测试集里是否包含真实传感器数据。不要被 Demo 效果迷惑要看它在你的业务数据上是否稳定。6. 软硬件协同设计算力效率比算力规模更重要Jeff Dean 过去在 Google 推动 TensorFlow 和 TPU 的时候就已经把“软件 硬件 编译优化”放在一起设计。这次访谈延续了这个思路模型算法不能脱离硬件约束来谈推理成本会成为范式升级能否落地的决定性因素。在模型规模快速增长的同时单个模型训练和推理的成本也在快速上升。如果只靠堆更多 GPU大多数团队根本摸不到下一阶段的门槛。真正有效的方向是让每一张卡做更多有效计算。对小团队来讲这并不意味着要去造芯片。更实际的理解是模型压缩、量化、蒸馏、批处理策略、服务调度这些技术的重要性会比单纯刷榜更高。一个能稳定支撑 100 路并发的量化模型在业务价值上往往超过一个只跑得动单路请求的满血模型。工程上可以做的几件事优先测量单位请求的 GPU 成本和吞吐而不是只看模型单次生成的延迟上线前用小批量测试模型在不同精度下的效果损失找到效果和性能的平衡点服务层加自动扩缩容避免算力要么跑不满、要么超额申请。这里我特别想强调很多人还在用“单条 prompt 的生成速度”来评判模型服务好坏但系统化推理时代更重要的指标是“单位时间内能完成多少有效任务”。一个模型单次慢一点但错误率更低、重试更少总成本反而更低。7. AI 工程实践范式升级对开发者的落地影响范式升级听起来高远落到日常开发其实是一组可以拆分执行的工程任务。7.1 模型部署与推理服务化过去部署一个模型主要关注加载时间和单请求延迟。现在要关注的是模型在处理思维链、多模态输入时显存是否够用KV Cache 增长速度请求排队策略是否支持动态 batch。建议不要把所有服务写死成单模型调用而是在网关层预留路由能力。这样当推理模型、快速模型、专用模型并存时可以按任务自由切换。7.2 应用架构从“单次调用”变成“多步流水线”传统应用是“用户提问 - 模型生成 - 展示结果”。Agent 应用则更像一个流水线请求进入 - 任务规划 - 工具调用 - 中间结果校验 - 最终答案生成。这意味着你要为流水线中的每一步设计超时、重试、状态持久化。任何一步失败系统都要能记录现场并让大模型根据错误信息重新规划。一个简单的对比脚本可以帮助你理解这个差异# 对比脚本快速模型 vs 推理模型 # 请按实际项目 API 替换 call_llm 实现 import time models { fast: your-fast-model, reasoning: your-reasoning-model, } prompt 请设计一个支持重试的批量任务队列并说明失败处理策略。 for name, model in models.items(): start time.time() result call_llm(model, prompt, max_tokens2048) elapsed time.time() - start print(f{name}: {elapsed:.2f}s, {len(result[content])} tokens)第一次跑这类对比时你可能会发现推理模型慢很多。但如果把“错误率、重试次数、人工修正成本”也放进对比结论往往会反转。7.3 评估体系从“单轮质量”变为“多步成功率”评估 Agent 不能只看最后一次回答是否通顺。更合理的方法是记录整个任务链路任务是否在规定的步数内完成、工具调用是否全部成功、中间异常是否被正确恢复、最终交付是否满足验收条件。评估集建议分成三层单模型能力层评估模型在分类、抽取、摘要等独立任务上的质量Agent 流程层评估完整任务成功率、平均步数、失败原因分布业务结果层评估用户真实反馈、交付物可复用率、成本消耗。有了这套评估体系你才能判断一次升级到底是变好还是变坏。7.4 成本与合规边界推理时计算变多意味着单次请求的算力成本上升。上线前要设定每个任务的最大推理预算比如最长时间、最高成本、最大步数。涉及用户数据、图片、语音、视频内容时还要明确授权边界。Agent 自动操作外部系统前必须确认有权限并且操作记录可回溯。所有批量任务都应该加人工审批节点避免系统在无人干预的情况下执行风险过高的操作。8. 资源占用与性能观察方法不管模型多强最终都跑在真实硬件上。建议用下面这套方法建立自己的性能基线。8.1 先测单请求再测并发用一批固定 prompt 跑单请求记录首 Token 延迟、总生成时间、显存峰值。然后逐步增加并发数观察吞吐上限和错误率。实际数字要按模型、显卡、上下文长度来测不同环境差异很大。8.2 关注 KV Cache 的显存增长推理模型生成思维链时Token 数会明显增加KV Cache 也随之膨胀。如果长期运行 OOM优先检查是否是上下文过长或并发过高而不是盲目调小模型。8.3 用批次测试验证量化效果量化可以显著降低显存占用和推理成本但效果损失因任务而异。建议拿业务真实数据在 FP16、INT8、INT4 各跑一轮比较关键指标。如果业务对错误容忍很低不要为了省显存盲目量化。8.4 降低资源占用的常见方法做前缀缓存重复系统提示词和常用上下文不必重复计算限制最大输出 Token避免模型“话痨”式生成按任务复杂度路由简单任务别走大模型Agent 任务里加入步数上限和超时控制防止失控循环。8.5 避免进程残留和端口冲突启动推理服务时如果多次改配置后端口被占用先查进程再重启# 以 Linux 为例查看占用 8000 端口的进程 lsof -i :8000 # 或 netstat -tunlp | grep 8000服务接入正式环境前确认退出逻辑会释放显存和端口避免调试期反复占用资源。9. 常见认知误区与排查方法范式升级讨论多了容易形成几个典型的认知误区。下面用表格列出判断方法和解决思路。常见误区可能原因判断方式解决方案范式升级就是换更大的模型只看模型排行榜忽略系统约束在业务数据上跑对比实验记录延迟、成本、质量建立分层模型路由按任务难度分配模型Agent 就是把工具链全扔给模型低估了任务编排和状态管理的复杂度观察多步任务失败率和重试率从窄场景开始给 Agent 增加步骤上限和状态持久化推理模型一定比特快模型更好忽略任务复杂度差异用简单任务和复杂任务分别测试按任务类型路由简单任务用快速模型多模态模型直接替换文本模型没有评估跨模态输入的额外开销测不同输入尺寸下的显存和延迟独立评估多模态编码器开销做分层接入上线前只看单条生成时间没有考虑吞吐和错误重试成本统计单位时间有效完成任务数量建立“吞吐 失败率 成本”综合指标排错时有一条通用原则先确认请求到了模型层再确认模型输出符合预期最后确认工具调用和业务链路正确。大多数 Agent 故障都出在中间层而不是模型本身。10. 最佳实践总结与下一步行动范式升级不是一次性切换而是渐进迁移。从工程角度我建议按下面的顺序推进。第一步先选一个具体的业务任务跑通最小验证链路。比如“自动处理用户上传的文件并生成摘要”任务边界清楚效果容易评估。第二步建立评估集和性能基线。记录不同模型在某类任务上的成功率、延迟和成本用数据决定模型升级方向。第三步把推理路由和 Agent 编排做成可配置模块。不要把它写死在业务代码里而是沉淀成网关配置或独立服务。第四步加入可观测性。Agent 每一步的工具调用、模型输出、异常信息、重试记录都要落日志方便排查。第五步明确安全边界。自动执行任务前确认授权范围涉及敏感数据和用户内容时保留人工审批节点。这套小实验做完你会得到一个很扎实的判断你当前的项目到底需要快速模型、推理模型、多模态能力还是完整的 Agent 编排体系。这时候回看访谈里提到的“范式升级”就不再是概念而是一组可以落地的工程基线。下一步可以持续关注的方向是推理模型的成本优化、Agent 可观测性工具链、多模态模型的显存优化、软硬件协同推理。这些方向都处于快速变化期最适合用“小步验证 保留基线”的方式持续跟进。