这次我们来看的不是一个新模型，而是一场关于 AI 下一步怎么走的访谈。标题里的主角是 Jeff Dean，Google DeepMind 首席科学家，也是 Google Brain 早期建设的核心人物。他谈的“下一次范式升级”，主流观点基本集中在四个关键词上：多模态、规模、智能体和基础设施。这篇文章不打算逐字复述访谈内容，而是把它转成工程视角：范式变化之后，普通开发者和算法工程师应该怎么理解，怎么验证，怎么把变化落到 API、批量任务和本地部署里。
先说结论：如果你只关心模型榜单分数，这篇访谈的参考价值有限；如果你关心模型怎么部署、怎么调用、怎么做 Agent 链路，这篇值得细读。Jeff Dean 一贯不是单纯追模型精度的人，他更关注系统。从 TensorFlow 到 TPU，再到多模态大模型，他的技术主线一直围绕“如何把深度学习带出实验室”。这次谈范式升级，真正值得关注的是系统层面的变化，而不是某一个具体模型又刷新了多少个点。
1. 核心观点速览：AI 范式升级关键词
使用表格快速整理这场访谈背后最值得关注的技术方向，方便你对后续内容有一个整体判断。
| 范式关键词 | 传统形态 | 升级方向 | 工程影响 |
|---|---|---|---|
| 多模态 | 文本输入、文本输出 | 文本、图像、音频、视频统一进入模型 | 数据预处理、存储、API 设计都要兼容非文本内容 |
| 推理 | 单次生成一个回答 | 多步推理、工具调用、智能体协作 | 需要任务编排、状态管理、超时和重试机制 |
| 效率 | 全量参数参与每步计算 | 稀疏激活、动态计算、量化推理 | 显存占用、吞吐量、延迟的平衡重新变成重点 |
| 基础设施 | 单机跑模型或用 GPU 训练 | 大规模分布式训练与推理服务 | 部署方案、批量任务、高可用架构的重要性提升 |
| 数据使用 | 靠人工标注和静态数据集 | 合成数据、在线学习、环境交互 | 数据闭环、评估体系、合规边界都要重新设计 |
这些关键词并不是独立的，而是一条完整链路。模型越来越像“一个能理解多模态输入、会调用外部工具、并能持续执行多步任务的大脑”，而为了让这个大脑真正可用，底层基础设施必须跟上。这也是 Jeff Dean 的工程视角最有价值的地方：他不会只谈算法精度，他更关心算法能否规模化、系统能否稳定运行。
2. 为什么这次范式升级值得关注
过去几年，大家关注的重点是“模型参数量”和“榜单分数”。但从最近的技术演化看，单点能力已经很难继续支撑产品想象力。一个文本大模型可以写文章、写代码，但它无法直接操作文件、调用数据库，也无法真正理解一张图片里的布局。下一阶段的变化，是把这些能力拼装成完整工作流。
从工程视角看，范式升级意味着三个改变。
第一，输入输出从单一模态扩展到多模态。过去我们写的接口大多是“文本进、文本出”，未来可能同时接收图片、音频和视频。这看起来只是数据格式变化，实际会牵扯到上传方式、预处理的 GPU 资源、上下文窗口长度以及输出结果如何渲染。
第二，模型从“聊天对象”变成“任务执行者”。多步推理和 Agent 化之后，一个请求不再是简单一问一答，而是可能触发多个内部步骤。比如用户说“帮我查一下最近的订单，然后生成一份销售摘要”，系统需要先检索数据，再调用工具，最后生成文本。这要求后端服务的状态管理、任务队列和失败恢复能力都要升级。
第三，研发重点从“训练更大的模型”转向“让现有模型更高效地运行”。模型越来越大并不代表一定能落地。部署成本、显存占用、推理延迟才是真实瓶颈。所以量化、蒸馏、稀疏激活这些技术不再是论文概念，而是必须投入生产的工程手段。
这场访谈的重要之处，不在于给一个惊天结论，而在于把这些分散的趋势串联成一张整体路线图。对开发者来说，早一点看懂路线图，就能早点决定自己的技术栈往哪个方向投入。
3. 从访谈中提炼出的四个技术方向
3.1 多模态统一：让模型真正理解世界
文本模型的核心问题是只看到符号，看不到世界。即使模型能回答“一只猫坐在窗台上”，它也没有真正理解像素和声音。多模态统一模型的目标，是把不同模态的输入映射到同一个表示空间。图像、音频、视频都可以作为上下文，模型可以跨模态回答问题，甚至输出图像或音频。
工程上，这一步带来的变化是直接的。你需要设计一套能够同时接收文本、图片、音频的 API；图片需要压缩、传输、解码；视频需要抽帧或分段；音频需要转写或采样。任何一个环节都可能成为性能瓶颈。如果未来你的业务要接多模态能力，建议提前建设一套统一素材接入层，而不是每个模型单独做一套接口。
3.2 从单步生成到多步推理与智能体
下一个范式升级的重要标志，是模型不再只做“单步解码”。它会根据用户目标，自己规划步骤，调用外部工具，观察结果，然后决定下一步动作。这就是 Agent 的基本形态。
要实现这个闭环，模型需要具备三类能力：任务拆解能力、工具调用能力、结果判断能力。任务拆解决定了模型如何把一个大目标拆成多个子任务；工具调用决定了模型如何接入代码解释器、搜索引擎、数据库或业务 API；结果判断决定了模型如何从返回结果中提取有效信息并继续执行。
这一层给后端带来的压力很大。一次 Agent 请求可能对应几十个内部 API 调用，任何一个步骤超时都会影响整体体验。因此，设计 Agent 服务时不能只写一个chat()接口，还需要设计任务状态机、步骤级日志、超时控制、幂等重试以及并发限制。
3.3 模型效率与自适应计算
大模型部署的痛点从来不是“能不能跑”，而是“成本能不能接受”。显存占用、Token 吞吐量、首字延迟，每一项都直接影响产品形态。Jeff Dean 这类系统型研究者通常会强调“自适应计算”：根据输入难度，动态决定模型在哪些层计算更多，哪些层可以跳过或共享参数。
从工程落地角度看，我们可以先不追求论文里的动态路由，而是先把已被验证的手段用起来。量化可以大幅降低显存占用，蒸馏可以用小模型逼近大模型效果，批量推理可以提高 GPU 利用率。与此同时，上下文长度和图像分辨率会显著影响显存占用，所以在压测时要分别控制变量，不能把不同因素混在一起看。
3.4 AI 基础设施与规模化部署
范式升级越深入，基础设施的权重越大。多模态模型训练需要大规模分布式集群，在线推理需要支持高并发和弹性伸缩。Jeff Dean 所在团队长期做 TPU、编译器、分布式框架，本质上都是为了让模型能在更大规模、更稳定地运行。
对普通团队来说，不太可能自己造 TPU，但应该思考如何把公有云 GPU、API Gateway、模型服务框架和监控系统串起来。你需要一个能实时看到“令牌耗尽、延迟升高、显存不足”的监控体系，也要有自动扩容和降级策略。基础设施不是最光鲜的部分，但往往决定了一个 AI 产品能不能从 Demo 走到生产。
4. 范式升级对开发者意味着什么：适用场景与使用边界
先给一张场景对照表，方便判断哪些业务适合跟进范式升级，哪些场景需要谨慎。
| 场景 | 目前适合度 | 工程重点 | 风险边界 |
|---|---|---|---|
| 内容生成 | 高 | 提示词管理、输出审核、成本控制 | 生成内容可能不准确，需要人工复核 |
| 代码辅助 | 高 | 上下文工程、安全扫描、许可证检查 | 生成代码可能包含安全问题，不能直接自动合并 |
| 多模态分析 | 中高 | 图像/视频预处理、批量任务、数据隐私 | 人脸、车牌等敏感信息需要脱敏处理 |
| Agent 自动化 | 中 | 工具调用、状态管理、超时重试 | 自动决策风险高，需要最终人工确认 |
| 客服对话 | 高 | 用户意图识别、多轮对话管理、知识库检索 | 敏感用户数据不能传给外部大模型 |
从上表可以看出，越是直接面向 C 端的场景，越要仔细设计使用边界。多模态能力很强，但如果企业把内部文档、客户资料直接上传到公有 API，就可能带来数据合规风险。涉及人脸、声音、版权素材时，必须确认授权范围，不能因为模型能处理就随意使用。
另外，即使模型能力在升级，它仍然会产生幻觉。Agent 自动化场景中，模型可能把错误的中间结果当作正确输入继续执行。解决办法是给每一步设置人类确认点，尤其是在付款、删数据、发邮件这类高风险操作上。不要让模型拥有完全自主的权限开关。
5. 工程验证路径：先跑通一条最小链路
范式升级听起来抽象，但验证起来并不复杂。你可以不训练模型，只通过 API 或开源小模型，跑通一条“多模态输入 + 多轮推理 + 工具调用”的最小链路。这条链路跑通之后，再决定是否投入更多资源。
5.1 环境准备
先确认你本机的运行环境。如果使用线上 API，只需要一个 Python 环境和 requests 库：
python3 --version pip install requests如果使用本地模型，建议准备一张 NVIDIA 显卡，提前安装好显卡驱动和 CUDA 工具链，并确认nvidia-smi可以正常输出。
nvidia-smi # 如果输出显卡信息，说明驱动环境可用模型版本和 CUDA 版本不一定完全匹配，具体需要按你选的模型框架调整。第一次做验证，建议先小参数、短文本，避免资源占用过高。
5.2 用 OpenAI 兼容接口测试多轮 Agent 请求
目前很多模型服务商提供 OpenAI 兼容接口，先用这类接口验证多轮调用最省事。下面是一个通用 curl 示例，接口地址和密钥需要替换成你自己的服务商配置。
curl https://your-api-endpoint/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_API_KEY" \ -d '{ "model": "your-model-name", "messages": [ {"role": "system", "content": "你是一个可以帮助用户查询天气并生成播报的助手。"}, {"role": "user", "content": "帮我查一下北京今天的天气，然后生成一句播报。"} ], "temperature": 0.7 }'如果服务商支持工具调用，可以在请求中加入tools字段。注意不是所有接口都支持这个字段，具体要以服务商文档为准。
import requests import json url = "https://your-api-endpoint/v1/chat/completions" headers = { "Content-Type": "application/json", "Authorization": "Bearer YOUR_API_KEY" } payload = { "model": "your-model-name", "messages": [ {"role": "system", "content": "你是一个智能助手，需要使用工具完成任务。"}, {"role": "user", "content": "查询北京天气，然后生成一句简短的播报。"} ], "tools": [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市的天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称"} }, "required": ["city"] } } } ] } response = requests.post(url, json=payload, headers=headers, timeout=60) result = response.json() print(json.dumps(result, ensure_ascii=False, indent=2))这个脚本验证的不是最终结果多完美，而是模型能否返回一个结构化的工具调用参数。如果返回内容里有tool_calls字段，说明模型已经开始具备“执行动作”的能力，而不是单纯输出文本。
5.3 用本地小模型观察资源变化
如果你没有外部 API 密钥，也可以用 Ollama 这类工具在本地跑一个小模型。
# 安装 Ollama 后，先拉取一个轻量模型，这里仅作示例 ollama pull gemma2:2b ollama run gemma2:2b启动后，在另一个终端里运行：
nvidia-smi -l 2这样每两秒刷新一次显存占用和 GPU 利用率。你可以观察不同上下文长度下显存的变化，也可以对比 CPU 推理和 GPU 推理的差异。显存占用数字会受模型量化版本、上下文长度、并发数影响，所以不要只记录一次数据，要记录多轮。
5.4 验证效果与失败判断
判断最小链路是否跑通，建议看五个信号：
- 多轮对话是否保留上下文，模型是否能记住前文信息。
- 输入包含图片或音频时，API 是否能正确处理，不报格式错。
- 工具调用是否为结构化 JSON，而不是把调用信息混在自然语言里。
- 批量请求是否稳定，是否存在偶发超时或返回空内容。
- GPU 显存占用是否在预期范围内，会不会随 Token 数线性增长。
如果某个信号不达标，不要急着换模型，先排查输入格式、超时配置和显存限制。很多时候问题不是模型能力，而是接入层没做好。
6. 多模态与 Agent 的接口设计思路
6.1 多模态请求设计
如果你要接入多模态模型，建议先把请求体设计成“文本 + 内容数组”的结构，便于扩展不同模态。
import requests import json url = "https://your-api-endpoint/v1/chat/completions" headers = { "Content-Type": "application/json", "Authorization": "Bearer YOUR_API_KEY" } payload = { "model": "your-multimodal-model", "messages": [ { "role": "user", "content": [ {"type": "text", "text": "请描述这张图片中的主要内容。"}, {"type": "image_url", "image_url": {"url": "https://example.com/test.jpg"}} ] } ], "max_tokens": 300 } response = requests.post(url, json=payload, headers=headers, timeout=90) result = response.json() print(json.dumps(result, ensure_ascii=False, indent=2))这里需要强调的是，图片链接必须是你有权访问的资源。如果图片来自公网，也要考虑链接失效和隐私问题。实际生产环境更建议用 Base64 或私有对象存储上传，避免外网暴露。
6.2 批量任务队列设计
多模态处理的典型场景是批量审核或批量识别。你可以先用脚本扫描本地目录，再逐个调用模型接口。
import os import requests import json import time api_key = "YOUR_API_KEY" url = "https://your-api-endpoint/v1/chat/completions" headers = { "Content-Type": "application/json", "Authorization": f"Bearer {api_key}" } def analyze_image(image_path): with open(image_path, "rb") as f: import base64 base64_image = base64.b64encode(f.read()).decode("utf-8") payload = { "model": "your-multimodal-model", "messages": [ { "role": "user", "content": [ {"type": "text", "text": "请简要输出图片的分类标签和一句话描述。"}, {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{base64_image}"}} ] } ], "max_tokens": 200 } response = requests.post(url, json=payload, headers=headers, timeout=90) response.raise_for_status() return response.json() input_dir = "./test_images" output_file = "./results.jsonl" results = [] for filename in os.listdir(input_dir): if not filename.lower().endswith((".jpg", ".jpeg", ".png")): continue image_path = os.path.join(input_dir, filename) try: result = analyze_image(image_path) results.append({"filename": filename, "result": result}) print(f"processed: {filename}") except Exception as exc: results.append({"filename": filename, "error": str(exc)}) print(f"failed: {filename}, error={exc}") time.sleep(0.5) with open(output_file, "w", encoding="utf-8") as f: for item in results: f.write(json.dumps(item, ensure_ascii=False) + "\n") print(f"done, saved to {output_file}")这段代码适合小规模测试。如果要处理上万张图片，建议引入任务队列，比如 Redis 队列或云上的消息服务，并加上失败重试。批量任务不能只做“成功写入结果”，还要把失败样本单独放到一个目录，方便二次处理。
6.3 稳定性与重试
Agent 和多模态任务比普通文本请求更容易失败。原因很直接：它们往往包括多个子步骤，每个步骤都可能因为超时、限流、参数错误而中断。批量调用时，建议统一设置重试策略：对网络超时和 5xx 错误最多重试三次，每次间隔递增；对 4xx 错误不盲目重试，而是先检查参数和权限。
同时要记录每个请求的输入摘要、输出结果和使用 Token 数。这个日志不仅用于排查问题，也可以用来估算成本。范式升级意味着模型能力更强，也意味着接口调用成本更高，没有成本监控的批量任务很容易失控。
7. 资源占用与性能观察方法
7.1 观察工具
本地部署模型时，最低成本的性能观测工具就是 NVIDIA 自带的命令。
nvidia-smi # 查看当前显存占用和 GPU 利用率如果需要持续监控，可以每两秒刷新一次：
nvidia-smi -l 2也可以用nvtop或htop查看整体负载。观察性能时，不能只看显存占用一个指标，还要同时看 GPU 利用率、显存带宽、CPU 使用率和网络延迟。例如 GPU 利用率很低但显存快满，说明瓶颈可能在批处理大小或数据加载；GPU 利用率很高但首字延迟很大，说明模型本身计算量太大。
7.2 CPU 与 GPU 推理差异
使用表格可以更直观地理解两者差异。
| 对比项 | CPU 推理 | GPU 推理 |
|---|---|---|
| 适合模型 | 量化后的中小模型 | 大模型、多模态模型 |
| 并发能力 | 低，适合单请求调试 | 高，适合生产环境 |
| 显存占用 | 很少，主要吃内存 | 明显占用显存 |
| 延迟 | 通常更高 | 通常更低 |
| 环境要求 | 无额外显卡要求 | 需要 NVIDIA 显卡和驱动 |
从范式升级角度看，如果你要在真实业务中使用多模态或 Agent，GPU 推理基本是刚需。CPU 推理更适合做功能验证、开发调试和轻量文本处理。
7.3 降低显存占用的通用手段
显存不足是本地部署最常见的问题。降低显存占用可以从几个角度入手：
- 优先使用量化模型，例如 8bit 或 4bit 版本。
- 降低单次请求的上下文长度，减少 Token 数量。
- 图像输入先压缩到合理分辨率，不要直接上传超大原图。
- 降低推理并发数，先把单个请求跑稳定。
- 使用流式输出，减少单次返回的峰值内存。
显存占用一定要以实际测试为准，不能用别人的数据直接套用到你的环境。模型版本、量化方式、输入长度都会改变结果。
8. 常见问题与排查方法
这里汇总一套排查清单，供你跑通范式升级最小链路时参考。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 接口返回模型不存在 | 模型名称写错或服务商不支持该模型 | 查看服务商模型列表 | 替换为正确的模型名称 |
| 请求一直超时 | 上下文过长或网络不稳定 | 检查服务端日志和防火墙 | 降低 max_tokens，拆分长文本 |
| 返回结果不是结构化 JSON | 模型能力不足或参数设置不对 | 检查提示词是否明确 | 增加 JSON 输出指令或使用 response_format |
| 显存不足导致进程退出 | 模型太大或上下文太长 | 查看 nvidia-smi 输出 | 切换量化版本，降低上下文长度 |
| 批量任务跑到一半卡住 | 缺少重试逻辑或触发限流 | 查看日志和任务队列状态 | 添加重试、间隔和死信队列 |
| 本地启动失败 | 依赖版本或 CUDA 版本不匹配 | 查看启动日志和依赖列表 | 按官方文档重新安装依赖 |
| 生成结果质量不稳定 | 温度参数过高或输入不完整 | 对比多次输出 | 降低 temperature，增加约束条件 |
| 数据上传到公共 API 有风险 | 接口访问范围过大 | 检查 API Key 权限和网络范围 | 限制 IP，使用私有化部署 |
排查时要记住一个原则：不要同时修改多个变量。很多情况下，改一次参数就重新跑一次，定位问题比追求完美结果更重要。
9. 最佳实践与落地建议
从这次范式升级中，开发者可以沉淀出一套更务实的工程方法。
第一次验证时，不要直接跑大模型。先用 API 接口跑通“输入到输出”的最小链路，确认数据结构没有问题，再考虑本地部署。本地部署时，从量化小模型开始，比直接上十几 B 的模型更稳妥。
配置和提示词要版本化管理。环境变量、模型名称、temperature、top_p、max_tokens、图像分辨率这些参数，都应该记录在配置文件中。这样当输出结果不如预期时，可以快速回溯当时的参数组合。
输入素材、中间结果和最终输出要分目录存放。批量任务最好生成一个results.jsonl文件，每行一个 JSON 对象，方便后续用脚本处理。失败样本单独放在failed/目录，不要和成功样本混在一起。
接口服务要限制访问范围。API Key 不要提交到代码仓库，推荐使用环境变量或密钥管理服务。如果服务暴露在公网，还要加上限流和访问白名单。涉及隐私数据时，优先考虑私有化部署或在本地完成敏感信息脱敏。
合规边界必须放在功能之前。多模态模型可以识别人脸，也可以生成声音和图像，但这不代表可以随意使用。任何涉及肖像、声音、版权素材的内容，都要先确认是否有合法授权。自动化 Agent 的高风险操作要设置人工确认点，避免模型自主执行不可逆动作。
10. 总结：下一步先做什么
范式升级不是遥远的概念，它已经落在接口设计、部署成本和任务编排里。这场访谈最值得记住的一点是：模型能力只是上半场，系统能力才是下半场。如果你是一名后端开发者，可以先找一个多模态 API，跑通“一张图片 + 一段文本 + 工具调用”的链路；如果你有本地 GPU，就用一个小模型测量显存和延迟变化。先跑通最小闭环，再决定是否扩展成批量任务和 Agent 平台。建议收藏这篇文章，等你准备搭建自己的多模态服务时，可以参考这套验证思路。
