找回密码
立即注册
搜索
热搜: Java Python Linux Go
发回帖 发新帖

3007

积分

0

好友

413

主题
发表于 15 小时前 | 查看: 3| 回复: 0

2026年初,一则消息在系统与基础设施工程圈内引发了广泛讨论:性能工程领域的标志性人物Brendan Gregg宣布加入OpenAI,负责ChatGPT相关的性能优化工作。

Brendan Gregg LinkedIn个人资料及系统架构图

对许多人而言,这似乎是一次“跨界”——一位长期深耕操作系统内核、CPU性能分析与数据中心优化的专家,选择进入一家以大模型闻名的AI公司。但若深入思考,这其实是一次高度符合技术发展内在逻辑的选择。它清晰地表明:AI已经从“模型算法问题”演进为“复杂的系统工程问题”

本文将从三个层面分析这一事件:

  1. Brendan Gregg选择OpenAI的背后逻辑。
  2. 其个人博客《Why I Joined OpenAI》传递的核心判断。
  3. 这一选择对广大系统与基础设施工程师职业发展的启示。

一、事件回顾:Brendan Gregg在OpenAI的角色

Brendan Gregg是系统性能工程领域公认的权威,他是Flame Graph(火焰图)的提出者,也是经典著作《Systems Performance》(中文译名《性能之巅》)的作者。在加入OpenAI前,他长期担任Intel Fellow,在CPU、操作系统及数据中心性能优化方面积累了深厚的专业知识

Brendan Gregg工作经历截图

在OpenAI,他的职位是技术专家(Member of Technical Staff),并非从事模型训练或算法研究,而是聚焦于 ChatGPT性能工程方向,工作重点在于解决大规模AI数据中心的效率、成本与可持续性问题。

这一角色定位本身就是一个强烈的信号:AI公司的核心竞争力,正在从“谁的模型更大更准”,转向“谁能更高效、更经济地运行模型”

二、解读博客:Brendan Gregg的真实动机与行业判断

在其个人博客《Why I Joined OpenAI》中,Brendan Gregg给出了非常直接且工程化的理由,而非泛泛的愿景叙事。

1. AI数据中心已进入“极端规模”阶段
他指出,AI数据中心的成本和能耗正在以惊人的速度增长,这已经超越了单纯的商业成本问题,演变为关乎能源与环境的全球性议题。传统的性能工程方法在这一前所未有的规模下可能开始失效。AI成为了系统复杂度的放大器,模型、GPU、网络、存储、调度、操作系统之间的耦合度远超传统互联网负载。

2. 性能工程首次成为“核心业务命脉”
在传统互联网公司,性能优化往往是支撑性的“成本中心”;但在AI公司,每1%的性能提升都直接转化为巨大的算力节省与成本收益。这使性能工程的价值被提升到了战略高度。同时,OpenAI作为一个相对年轻的组织,没有太多“不可改变的历史包袱”,这为从系统底层进行重新设计与深度优化提供了绝佳环境。

3. AI技术已深度融入日常生活
博客中讲述的发型师日常使用ChatGPT的故事颇具代表性。它说明AI技术已走出实验室,成为普通人日常工作与生活的助手。这意味着,性能优化将直接影响全球数亿用户的真实体验,让这项工程工作从技术挑战升级为具有广泛社会影响力的实践。

三、背后的行业趋势:系统工程价值的重塑

Brendan Gregg的选择并非孤例,而是更大趋势的缩影。

1. AI正在重新定义“稀缺技术能力”
在AI时代,以下传统的系统工程能力变得前所未有的关键:

  • 操作系统与内核的深度理解。
  • CPU/GPU架构与内存层级知识。
  • 大规模网络与分布式系统性能分析。
  • 端到端的可观测性、性能剖析与追踪能力。
  • 数据中心级的资源调度与能耗优化。
    这些正是资深系统工程师长期积累的核心能力。

2. 从“单点优化”到“系统级思维”
大模型服务的瓶颈往往不在于单一硬件或软件组件,而在于整体系统的协同效率。推理延迟可能受GPU计算、KV Cache管理、网络延迟、NUMA架构、任务调度策略等多个环节的共同影响。没有全局的、系统级的视角,优化就如同盲人摸象,无法真正释放潜力。这也解释了为何Brendan Gregg认为需要构思“新的工程方法”。

3. “推理成本即销售成本”成为商业现实
对于提供AI服务的公司而言,推理成本直接构成了其销售成本(COGS) 的主要部分。效率优化从此不再是“锦上添花”,而是关乎企业盈利与生存的“雪中送炭”。这种巨大的经济压力,必然驱使头部AI公司像OpenAI招募Brendan Gregg一样,在基础设施层投入顶级人才与资源。

四、给技术人的现实建议:如何向AI基础设施方向演进

Brendan Gregg的路径启示我们,转型的关键不是去死磕Transformer公式,而是将现有能力进行场景迁移与升级。

1. 重构系统能力,而非抛弃
强大的系统工程背景不是劣势,恰恰是AI时代的坚实底座。需要做的是将传统技能映射到新场景:

  • 内核与资源管理:从理解CPU内存管理,扩展到理解GPU显存管理、CXL技术以及NUMA在CPU-GPU异构计算中的影响。
  • 分布式系统:从微服务间的RPC调用,深化到对集合通信库(如NCCL)和RDMA网络拓扑的理解。
  • 可观测性:掌握使用eBPF等低开销技术,来追踪横跨CPU、GPU乃至整个数据中心的AI工作负载请求路径,这正是性能工程在现代数据中心中的核心实践。

2. 深入理解AI工作负载的独特性
主动跳出“调API”的层面,去分析底层的技术瓶颈:

  • 性能剖析能力:学习使用Nsight Systems、PyTorch Profiler等工具,分析CUDA Kernel执行、显存访问模式。
  • 瓶颈识别:能够判断工作负载是受限于计算(Compute-bound)、显存带宽(Memory-bound)还是通信(Communication-bound)。
  • 成本与效率意识:理解KV Cache对显存的占用原理,以及PagedAttention、FlashAttention等优化技术如何从系统层面解决问题。

3. 培养“跨层工程能力”
未来高价值的工程师画像,是能同时在模型算法、系统软件和硬件架构三个层面进行思考与权衡的“全栈”基础设施专家。Brendan Gregg的职业路径,正是这一方向的极致体现。

五、结语:AI的下半场属于理解系统的人

Brendan Gregg入职OpenAI,并不是系统工程师的“转行”,而是系统工程在AI时代重新成为核心竞争力的标志性事件

这向我们揭示了一个重要判断:AI竞争的下半场,优势将不属于只懂模型的人,而属于那些能真正驾驭复杂系统,在极端规模下将算力、效率与成本做到极致的人。

对于有志于此的技术人而言,现在正是将深厚的系统功底与前沿的AI场景相结合,开拓职业生涯新篇章的最佳时机。持续学习与实践,参与云栈社区等技术社区的交流,或许能帮助你更清晰地看到这条演进路径上的下一个里程碑。

附录:Brendan Gregg博客《Why I Joined OpenAI》译文摘要

原文标题:Why I joined OpenAI
原文链接https://www.brendangregg.com/blog/2026-02-07/why-i-joined-openai.html
发布日期:2026-02-07

(以下为博客核心内容意译)

AI数据中心惊人且快速增长的成本,正在呼唤一种前所未有的性能工程;这不仅仅是为了节省成本,更是为了应对全球性的能源与环境挑战。我已加入OpenAI来直接应对这一问题,初期重点是优化ChatGPT的性能。

这里的规模是极端的,增长令人难以置信。作为该领域的从业者,我意识到传统的性能工程方法可能已不足以应对,我正在构思新的方法论,以发现更大的优化空间并更快地实现它们。这是一生难遇的机会,而且这里没有“因为太难而不能改变”的领域。

为什么是OpenAI?
一次理发的经历让我坚定了想法。我的发型师Mia在得知我可能与AI相关工作后,兴奋地向我分享了她如何使用ChatGPT来规划旅行、处理小企业文书甚至排解思念远方朋友的忧愁。她对于ChatGPT的熟悉和依赖程度超过了我曾工作过的许多科技品牌。这让我深刻体会到,这项技术已经真正成为了普通人生活中不可或缺的一部分。它带来的社会连接与助力是真实而深刻的。

当然,除了产品的广泛影响力,专业的工程环境与优秀的同事也至关重要。OpenAI拥有许多我钦佩的工程师,包括前同事,他们正在解决从GPU到整个软件栈各个层面的、极其有趣的工程问题。

我的角色
我现在是OpenAI的技术专家(Member of Technical Staff),在澳大利亚悉尼远程工作,向Justin Becker汇报。我加入的是ChatGPT性能工程团队,并将与公司内其他性能团队协作。我的首批任务之一是参与制定跨组织的性能提升与成本优化策略。

未来,无论是eBPF、Ftrace还是硬件性能计数器,我将从实际需求出发,运用一切合适的技术来寻找性能瓶颈。如果这一切听起来让你感到兴奋,那么值得注意的是,OpenAI正在招聘。




上一篇:Python pydoll库深度解析:asyncio事件循环监控与异步应用调试指南
下一篇:从Win32消息循环到AI Agent:OpenClaw PI引擎揭示的永恒事件驱动架构
您需要登录后才可以回帖 登录 | 立即注册

手机版|小黑屋|网站地图|云栈社区 ( 苏ICP备2022046150号-2 )

GMT+8, 2026-2-10 19:31 , Processed in 0.317154 second(s), 38 queries , Gzip On.

Powered by Discuz! X3.5

© 2025-2026 云栈社区.

快速回复 返回顶部 返回列表