最近 AI 圈子里有一条人事变动消息引发了非常多讨论OpenAI 研究副总裁 Barret Zoph 离开 OpenAI正式加入 Google出任研究副总裁。很多开发者看到这条新闻的第一反应是又一个大佬跳槽了但这件事的看点远不止人事本身。它同时涉及 RLHF、推理时扩展、大模型后训练、开源与闭源生态竞争、开发者 API 选型等一系列技术问题。本文不打算做新闻搬运而是从技术视角把这条消息拆开Barret Zoph 是谁、他做过的技术为什么重要、OpenAI 与 Google 在模型路线上的差异在哪、普通开发者应该如何理解这类行业变化以及我们在实际开发中如何应对多模型生态并存的局面。无论你是做大模型应用开发、Agent 开发还是刚入门 LLM 的初学者这篇文章都能帮你把分散的碎片信息串成一条清晰的技术脉络。1. 事件背景一次值得关注的人才流动1.1 这则消息为什么值得关注在大模型行业里一线研究者的人数并不少但真正同时具备核心论文作者和研究团队负责人两种身份的人其实很有限。Barret Zoph 属于其中比较有代表性的一位他既参与过 OpenAI 早期对齐技术的核心工作也以研究负责人的身份带领过 o1 这类推理模型的推进。业界关注这次人事变动本质上不是关心某一位个人的职业选择而是关心这条消息背后释放的技术路线信号。一个做过 RLHF、带过推理模型团队、又回到 Google 体系的研究副总裁会直接影响 Google 未来在后训练 推理时扩展方向上的投入节奏。而 OpenAI 失去这位核心人物之后后训练与推理侧的研究组织方式会不会调整也是很多人观察的重点。1.2 Barret Zoph 的履历与技术贡献根据公开信息Barret Zoph 在 OpenAI 期间有两个比较突出的技术标签。第一个标签是 RLHFReinforcement Learning from Human Feedback基于人类反馈的强化学习。InstructGPT 那篇论文是让大模型学会遵循用户指令的关键工作其核心思想是预训练模型虽然已经学会了大量语言知识但它并不天然知道用户想要什么格式的回答。通过收集人类对多个回答的偏好排序训练一个奖励模型再用强化学习去微调策略模型模型的输出就会明显更符合人类期望。ChatGPT 后来能够迅速被大众接受和这套对齐流程密不可分。第二个标签是推理模型。Barret Zoph 在 OpenAI 后期参与并推动了 o1 系列的工作。o1 类模型改变了过去模型必须立刻给出答案的范式而是让模型在生成最终答案之前先生成一段内部的思考过程用更多的推理时计算换取更准确的结果。这种思路后来被业内称为 推理时扩展test-time compute scaling。1.3 研究副总裁这个岗位到底做什么研究副总裁听起来是一个纯粹的学术职位但在大模型公司里这个岗位的实际职责比学术头衔复杂得多。它至少要承担三件事制定研究方向、协调研究到产品的转化、以及搭建研究团队。也就是说Barret Zoph 加入 Google 后不只是自己写论文、做实验而是要决定Google 的模型两年后应该长什么样推动研究团队去做那些短期没有收益、但长期决定竞争力的方向。这类岗位的每一次变动都比单个员工的流动更能反映一家公司的战略重心变化。2. 从 OpenAI 到 Google技术路线差异的两个样本2.1 OpenAI 的强项后训练、产品飞轮与工程执行力OpenAI 在过去几年里建立了非常强的研究 → 产品 → 数据回流闭环。ChatGPT 本身就是最好的例子模型上线后海量用户对话数据又成为后续对齐和评估的素材产品反馈反向推动研究迭代。OpenAI 在后训练post-training方向上投入很大因为后训练是让基座模型变成好用产品的最后一段路。与此同时OpenAI 也在往上游硬件走近期行业里也出现了关于 OpenAI 自研芯片的报道例如有消息称其自研 3nm 芯片已经在推进。对于推理模型来说长思维链和高并发推理对算力的需求非常大掌握硬件能力就等于掌握成本控制能力。2.2 Google 的强项基础研究、全栈算力与端侧生态Google 是 Transformer 架构的诞生地也是 TPU、AlphaGo、AlphaFold 这些标志性工作的发源地。在基础研究积累上Google 有非常深的护城河。过去两年 Google 在 Gemini 系列上持续发力同时把 AI 能力铺到了云、端侧和开发者工具等多个层面。从开发者视角看Google 的生态覆盖面很广Google AI Studio 可以在线调试 Gemini APIMediaPipe 负责端侧机器学习AI Edge Gallery 提供了面向端侧部署的模型与工具集合。这意味着 Google 不仅在做大模型本身还在构建从云端到手机的完整 AI 栈。2.3 人才在大厂之间流动是行业常态很多开发者看到某核心人物离开某公司就容易悲观甚至联想到公司不行了。但从行业规律来看AI 领域顶尖人才在全球几大实验室之间流动本身就是正常现象。Google、OpenAI、Anthropic、Meta 之间的人员往来一直存在甚至同一个研究者的不同职业阶段也可能会因为研究方向、团队氛围和资源条件而选择不同平台。更值得关注的是流动背后的技术趋势。Barret Zoph 的研究重心在 RLHF 和推理模型Google 现在最需要的也是这两块能力。与其说这是从一家公司跳槽到另一家公司不如说这是一个信号推理时扩展和后训练对齐已经成为头部大厂的统一主战场。3. 技术拆解从 RLHF 到推理时扩展3.1 RLHF 的核心逻辑理解这次人事变动绕不开 RLHF 这条技术线。我们先用一个例子说明它解决什么问题。假设你用一个非常大的语料库预训练了一个语言模型它可以续写文本但如果你问它周杰伦是哪一年出道的它可能会输出一大段和问题无关的联想文本。原因是预训练任务只要求模型预测下一个词并没有告诉它回答问题要简洁、准确、格式正确。RLHF 做的就是在预训练之后用人类偏好数据把模型拉回到符合对话习惯的方向上。整个流程分三步第一步收集人类的偏好数据。针对同一个问题让模型生成多个候选回答再由标注人员对这些回答排序。第二步训练一个奖励模型。奖励模型的输入是问题 回答输出是一个分值分值越高表示这个回答越符合人类偏好。第三步用强化学习微调策略模型。常用的算法是 PPO策略模型在生成回答后会得到奖励模型给出的分数然后通过强化学习不断调整参数让高分输出出现的概率变大。下面我给出一个用于理解奖励模型训练的最小示例。请注意这只是一个概念演示代码生产环境中的奖励模型规模和数据流程会复杂得多。# 文件train_reward_model.py # 最小奖励模型训练示例用于理解 RLHF 中打分能力的实现思路 import torch import torch.nn as nn from transformers import AutoModel, AutoTokenizer class RewardModel(nn.Module): 奖励模型输入一段文本输出一个标量分数。 实际 RLHF 中奖励模型通常是基于预训练模型 回归头的结构。 def __init__(self, base_model_namebert-base-uncased): super().__init__() self.encoder AutoModel.from_pretrained(base_model_name) self.head nn.Linear(self.encoder.config.hidden_size, 1) def forward(self, input_ids, attention_mask): outputs self.encoder(input_idsinput_ids, attention_maskattention_mask) # 取 [CLS] 位置的向量作为整段文本的表示 pooled outputs.last_hidden_state[:, 0, :] return self.head(pooled).squeeze(-1) tokenizer AutoTokenizer.from_pretrained(bert-base-uncased) model RewardModel() good_text 周杰伦出生于1979年。 bad_text 周杰伦是音乐人他的生平非常复杂需要结合历史背景来看。 inputs tokenizer([good_text, bad_text], paddingTrue, truncationTrue, return_tensorspt) scores model(input_idsinputs[input_ids], attention_maskinputs[attention_mask]) print(好的回答分数:, scores[0].item()) print(差的回答分数:, scores[1].item())训练时奖励模型的损失函数会让好的回答得分高于差的回答得分。这个看似简单的排序目标在后续 PPO 阶段会直接影响语言模型每一步生成的策略。3.2 o1 类模型把计算从训练搬到推理如果说 RLHF 是在训练阶段让模型变得更听话那么 o1 类模型则是在推理阶段改变了模型的计算方式。传统 LLM 生成回答的过程是逐 token 进行的模型每生成一个 token就把它拼接回上下文再生成下一个 token。这个过程本质上是一个从左到右的自回归过程模型没有机会停下来想一想。o1 类模型在回答复杂问题之前会先生成一段内部的推理链也就是我们常说的 thinking 过程。模型通过这段推理链对问题进行分解、验算和纠错最终再输出面向用户的答案。这种设计把一条很难的问题路径转化为多条小步骤的推理路径虽然推理时消耗的 token 数量和计算资源成倍增加但它在数学、代码、逻辑推理等任务上的正确率也明显提升。业内把这种通过增加推理时计算量来提升效果的做法称为推理时扩展。在这个方向上OpenAI 的 o1/o3 系列和 Google 的 Gemini 系列都在持续发力。现在回头看Google 把 Barret Zoph 招入研究体系显然是希望把训练后对齐 推理时扩展这条经验线完整地复制到 Gemini 的迭代过程中。3.3 为什么推理时扩展是当前最重要的战场之一推理时扩展之所以重要是因为它改变了大模型能力的增长方式。过去的模型能力提升主要靠更大规模的预训练但预训练数据已经接近枯竭训练成本却越来越高。推理时扩展则提供了一条以算力换准确率的新路径模型不需要重新训练只需要在推理时生成更长的思维链就可以在垂直任务上拿到更好的结果。对于追求性价比的团队来说这意味着同一个模型可以通过不同的推理预算适配不同难度的问题。但推理时扩展也有明显的成本问题。一个复杂问题的 thinking 过程可能消耗几万甚至几十万 token这对推理基础设施提出了很高要求。这也解释了为什么头部大厂都在做自研芯片和推理成本优化——OpenAI 在推进自研芯片Google 则有完整的 TPU 体系。模型、算法、硬件三者的协同才是推理时扩展能够真正落地的地基。4. 对开发者的直接影响多模型 API 生态下的选型思路4.1 OpenAI 与 Google 的 API 生态差异这次人事变动短期不会让任何一家公司的 API 立即变化但它提醒了开发者一个事实现在的 AI 应用开发已经进入多模型并存阶段提前了解不同平台的接入方式是有必要的。OpenAI 生态的特点是接口简洁、框架兼容度高。目前很多开源项目都把 OpenAI 兼容接口 作为默认标准例如 vLLM、Ollama 等本地推理框架都提供了 OpenAI 格式的接口。这个设计带来的好处是开发者只要熟悉一套接口就能在云端模型和本地模型之间灵活切换。Google 生态的特点是云端 端侧 硬件一体化。Gemini API 可以通过 Google AI Studio 在线调试也可以和 Vertex AI 等云服务深度集成。端侧开发则可以使用 MediaPipe 和 AI Edge Gallery 提供的模型与工具在手机、浏览器等设备上跑机器学习任务。如果你做的是端侧 AI 应用Google 生态的覆盖度目前是领先的。4.2 代码示例同一个任务在两种平台上的调用下面用一个简单的任务演示两种平台的基本调用差异。假设我们要让模型解释什么是推理时扩展先用 OpenAI Python SDK 实现# 文件openai_demo.py # 前提已安装 openai 库且已配置可用的 API Key # pip install openai from openai import OpenAI client OpenAI(api_keyyour-openai-api-key) resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一位擅长用通俗语言解释技术概念的助手。}, {role: user, content: 请用两句话解释什么是推理时扩展。}, ], ) print(resp.choices[0].message.content)再来看 Google Gemini 的调用方式# 文件gemini_demo.py # 前提已安装 google-generativeai 库并已获取 Google API Key # pip install google-generativeai import google.generativeai as genai genai.configure(api_keyyour-google-api-key) model genai.GenerativeModel(gemini-1.5-flash) resp model.generate_content(请用两句话解释什么是推理时扩展。) print(resp.text)可以看到两个平台的调用方式整体上很接近核心差异主要在模型命名、方法名和配置方式上。对于较大规模的应用推荐使用 LangChain 这类框架做一层封装避免把代码绑定在单一平台上。# 文件langchain_multi_model_demo.py # 通过 LangChain 同时对接 OpenAI 与 Google Gemini方便后续切换 # pip install langchain-openai langchain-google-genai from langchain_openai import ChatOpenAI from langchain_google_genai import ChatGoogleGenerativeAI openai_llm ChatOpenAI(modelgpt-4o-mini, api_keyyour-openai-api-key) gemini_llm ChatGoogleGenerativeAI(modelgemini-1.5-flash, google_api_keyyour-google-api-key) for name, llm in [(OpenAI, openai_llm), (Google, gemini_llm)]: resp llm.invoke(请用一句话介绍你自己对应的模型生态。) print(f[{name}] {resp.content})如果你在本地用 vLLM 部署了开源模型还可以用 OpenAI 兼容接口直接调用本地服务这也是目前一种比较主流的混合部署方式# 文件local_vllm_demo.py # 前提本地已启动 vLLM 服务默认地址为 http://localhost:8000 from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, # 本地服务通常不校验 Key ) resp client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[{role: user, content: 你好请做一句话自我介绍。}], ) print(resp.choices[0].message.content)4.3 开发者应该如何选择模型平台我的建议是不要被单一人事新闻左右选型而是要基于功能、成本、数据合规、生态工具四个维度做决策。如果团队的主要场景是文本对话、Agent 流程、结构化输出且希望快速接入大量开源工具OpenAI 生态的开源兼容性优势明显。如果团队做的是多模态、端侧推理或者对与 Google Cloud 服务的集成度要求高Gemini MediaPipe AI Studio 的组合会更顺滑。如果你所在的公司有严格的数据合规要求还可以考虑在本地通过 vLLM 或 Ollama 部署开源模型用 OpenAI 兼容接口保留项目未来的迁移能力。5. 工程视角大模型团队如何迭代高质量模型5.1 研究、工程与评估的协同看了很多行业分析之后开发者更需要理解的是一个优秀模型不是某一位研究者的个人作品而是研究 数据 工程 评估四个环节持续协作的结果。研究者提出新的训练方法数据团队提供高质量的对齐数据工程团队把实验代码打磨成稳定可复现的训练流程评估团队则负责回答新模型到底比旧模型好在哪里。任何一个环节缺失模型的最终体验都会打折扣。5.2 一个可运行的评估回归脚本评估是模型迭代中最容易被低估的环节。很多团队在训练完模型后只凭几个示例判断效果导致模型上线后出现大量回归问题。这里分享一个非常简单的评估脚本思路准备一组测试用例每次模型更新后都跑一遍记录通过率。# 文件eval_regression.py # 一个极简的模型回归测试脚本核心思路是同一批用例定期回归 from openai import OpenAI client OpenAI() test_cases [ {question: 11等于几, expected: 2}, {question: Python 中如何创建一个空列表, expected: []}, {question: RLHF 的全称是什么, expected: Reinforcement Learning from Human Feedback}, ] passed 0 for case in test_cases: resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: case[question]}], temperature0, ) answer resp.choices[0].message.content hit case[expected].lower() in answer.lower() passed int(hit) print(f问题: {case[question]}) print(f期望包含: {case[expected]}) print(f模型回答: {answer[:60]}...) print(f结果: {通过 if hit else 未通过}) print(- * 50) print(f通过率: {passed}/{len(test_cases)})在真实项目中测试用例通常有几百上千条并且会按能力领域分组比如数学、代码、逻辑、有害内容拒答等。模型每次版本升级之前都要跑完整个回归集才能决定是否可以发布。5.3 数据、后训练与安全的边界随着推理时模型的普及对齐和安全工作也在变化。过去对齐主要解决模型输出是否符合人类偏好现在还要额外处理模型在内部思考过程中是否隐藏了有害意图的问题。这也是为什么头部大厂都在投入可解释性和安全评估。对于普通应用开发者来说如果要接入推理模型建议在业务层做必要的输出过滤和敏感内容检测不要把安全完全寄托在模型自身。6. 常见问题开发者最关心的事6.1 这次人事变动会影响现有 API 服务吗短期内不会。OpenAI 的 API 服务和 Google 的 Gemini API 都是庞大的工程体系不依赖某一个个人。模型的训练、部署、推理、计费都有成熟流程不会因为一位研究负责人离开就中断。真正可能变化的是两家公司未来一年到两年的模型迭代方向和技术公开节奏这需要持续观察。6.2 OpenAI 会失去推理模型优势吗目前 OpenAI 的推理模型在公开评测和实际体验中仍然处于第一梯队但这种优势并不是绝对的。Google 在基础研究和算力上的积累非常深加上这次引入了在 RLHF 和推理模型方向上有完整经验的团队负责人后续 Gemini 系列的后训练水平很可能会有明显提升。对开发者来说多一个强有力的竞争者通常意味着更低的价格和更好的服务这反而是好事。6.3 普通开发者要不要每天刷 AI 行业新闻可以关注但不要焦虑。行业人事、融资、芯片传闻这些信息真正能影响你日常开发的其实只有很小一部分。对大多数开发者而言更值得投入时间的是这些相对稳定的能力理解 Transformer 和 RLHF 的基本原理、熟练使用主流模型 API、掌握评估和回归测试方法、能够针对具体业务做模型选型和成本估算。这些能力不会因为某一位研究者跳槽而失效。6.4 在哪里获取一手信息更靠谱建议以官方渠道为主OpenAI 官方文档和开发者博客会发布 API 变动与模型更新Google 的 AI Blog 和 Google AI Edge 相关资源会同步说明 Gemini 与端侧工具的最新进展GitHub 上 OpenAI Codex Harness 这类开源仓库也会持续更新。可靠的一手信息比二手解读更适合作为技术判断依据。信息类型推荐渠道说明OpenAI API 与模型变动OpenAI 官方文档以版本更新日志为准Google Gemini 与端侧工具Google AI Blog / AI Studio包含模型与工具发布开源推理与部署工具vLLM / Ollama / LangChain 仓库关注兼容接口变化安全对齐研究arXiv 相关论文学术进展参考7. 总结与后续学习建议Barret Zoph 从 OpenAI 加入 Google 这个事件可以看成大模型行业从预训练军备竞赛转向后训练与推理时扩展竞争的一个缩影。对开发者来说真正值得记录的并不是谁去了哪家公司而是 RLHF、推理时扩展、对齐评估这些技术关键词正在变得越来越重要。如果你想在这个方向持续积累建议按下面的路径走先理解 Transformer 和自回归生成的基本原理再动手实现一次最小化的 RLHF 流程包括奖励模型训练和 PPO 微调接着切换到推理模型观察不同推理预算对结果的影响建立对推理时扩展的直观认识最后搭建自己的评估回归集这才是保证模型迭代质量最可靠的工程手段。行业新闻每天都有技术基本功才是长期有用的东西。如果你正在做大模型应用开发建议把本文中的 API 调用示例和评估脚本保存下来下一轮模型选型或做回归测试时可以直接参考。