AI Infra 工程师日常工作地图：以 OpenAI 岗位为镜，明自己的学习坐标

前面几篇把 AI Infra 的技术栈铺开了：

• AI Infra 全景思维导图：一个 token 从硬件、算子、推理引擎到服务系统会经过哪些层。
• AI Infra 数学地图：为什么矩阵乘、内存带宽、并行通信和成本模型是底层主线。
• llama.cpp prefill/decode 调用链：从本地推理引擎看一个 token 如何真的跑起来。
• LoRA rank=16 数学直觉：用低秩更新理解模型适配的工程意义。
• 真实 PEFT LoRA 本地跑通记录：把 base model、adapter、merged model 的链路实际跑一遍。

但还有一个更现实的问题：那些在 OpenAI 这样的大公司里做 AI Infra 的工程师，每天到底围绕 AI 做什么？他们不是每天都在从零训练一个模型，也不是每天都在读论文。他们更像是在维护一套巨大的“模型工业系统”：让模型能训练、能推理、能评测、能上线、能回滚、能降成本、能定位故障、能被产品和研究团队持续使用。

这篇不是岗位推荐，也不是招聘信息汇总，而是借 OpenAI 公开岗位描述做一面镜子：看清 AI Infra 的真实问题分类，再把自己的学习路径放进去，知道现在练的东西究竟对准哪一块。

0. 先给一句总括

AI Infra 工程师的核心工作不是“写一个模型”，而是让模型成为可持续运行的生产系统。

更具体地说，他们每天关心这些问题：

训练能不能跑起来？
推理能不能扛住真实流量？
GPU 有没有在做有效计算？
数据能不能稳定、合规、高吞吐地喂给模型？
新模型能不能安全灰度和回滚？
性能退化能不能被及时发现？
研究实验能不能快速变成可复现的生产服务？
Agent 能不能在安全隔离的环境里执行工具和代码？

所以 AI Infra 不是一个点，而是一张网。下面把它拆成九类场景。

1. 训练基础设施：让大规模训练跑得动、断了能续、慢了能查

训练 Infra 面向的是模型训练和后训练的主链路。OpenAI 的 RL Training Infra 岗位描述里提到，这类工作会跨越训练系统、推理、编排、扩展、分布式基础设施、数值问题、硬件失败和评测基础设施。换成白话就是：一个大训练任务不是“点一下 run”，而是一个长时间、高成本、容易出故障的分布式工程系统。

典型日常不是写一个 Transformer block，而是：

• 训练任务启动前，确认数据、checkpoint、配置、并行策略、资源配额都正确。
• 训练过程中，盯吞吐、loss 曲线、GPU 利用率、通信耗时、dataloader 是否卡住。
• 某个节点、GPU、网络链路或存储服务异常时，判断是局部重试、整体恢复，还是回滚配置。
• 训练变慢时，定位瓶颈到底在算子、通信、数据读取、调度、checkpoint，还是评测阶段。
• 把一次次临时救火沉淀成自动化工具、监控、排障手册和更稳的抽象。

这类工作背后的指标很朴素：

tokens/sec
GPU utilization
MFU / HFU
checkpoint time
restart time
step time variance
data loading latency
failed run recovery time

它的难点在于跨层。一个 loss 异常，可能是数据问题；一个 step 变慢，可能是网络拥塞；一个训练中断，可能是某块 GPU 间歇性报错；一个评测波动，可能是模型行为、prompt、采样参数、评测 harness 或数据切分变化造成的。

对个人学习的启发：如果你现在还没有大集群，不需要假装自己在做万卡训练。更可行的练法是做小型可复现系统：

• 用单机训练一个小模型，记录每 step 时间、dataloader 时间、显存占用。
• 人为制造 checkpoint 中断，再恢复训练，比较恢复前后的 loss 和随机性。
• 模拟数据读取变慢，观察 GPU 利用率如何掉下来。
• 做一个小 dashboard，把训练吞吐、loss、显存、耗时打出来。

这不是玩具思维，而是在练真实训练 Infra 的最小闭环。

2. 推理基础设施：让模型在真实请求下又快、又稳、又便宜

推理 Infra 是最贴近用户体验的一层。OpenAI 的多模态推理岗位提到，推理团队要让 GPT、图像生成、Whisper 等模型在不同平台上可用、性能好、可扩展，并把研究能力带到生产环境。它还特别强调高吞吐、低延迟、GPU 利用率、tensor parallelism、硬件抽象层，以及 vLLM、TensorRT-LLM 等推理工具。

这一类工程师每天面对的不是“模型会不会回答”，而是：

• p50、p95、p99 延迟为什么变差？
• prefill 阶段慢，还是 decode 阶段慢？
• KV cache 是否爆显存？
• batch size、sequence length、并发请求之间怎么取舍？
• 多租户流量如何调度，避免一个长上下文请求拖慢所有人？
• 新模型上线后，吞吐、显存、成本和质量是否都能接受？
• 文本、图像、音频、多模态模型的输入输出格式如何统一服务？

这类工作最核心的事实是：推理不是单个 forward pass，而是在线系统。

request
→ tokenizer / input processor
→ scheduler
→ prefill
→ KV cache allocation
→ decode loop
→ sampling
→ streaming response
→ metrics / logs / billing / safety hooks

我们之前读 llama.cpp 的 prefill/decode，就是在贴近这条主线。prefill 是把上下文一次性灌进去，decode 是一个 token 一个 token 地生成。训练时你关心大 batch 吞吐；推理时你同时关心首 token 延迟、持续输出速度、并发公平性和显存碎片。

对个人学习的启发：你现在最适合优先扎推理 Infra，因为它能用本地机器练出真实直觉。

• 跑同一个模型，比较 prompt 长度变化对首 token 延迟的影响。
• 记录 prefill tokens/sec 和 decode tokens/sec，分开看，而不是只看总耗时。
• 做 KV cache 显存估算器：层数、hidden size、head 数、上下文长度、batch size 一变，显存怎么变。
• 用一个简单 FastAPI 包住本地模型，记录 p50、p95 延迟和并发下的吞吐变化。
• 对比 base model、LoRA adapter、merged model 的推理成本和加载方式。

这就是从“会跑模型”走向“能服务模型”的分界线。

3. 性能工程：把“感觉慢”变成可计算的成本模型

OpenAI 的 Inference Performance Optimization 岗位描述非常典型：分析 application、model、fleet 三层的推理性能，用 profiling、benchmarking 和分析找到瓶颈，并把 microbenchmark 转成 cost-to-serve 估算。这里的关键词不是某个框架，而是“可解释的性能模型”。

性能工程师每天会问：

• 这次优化是减少了计算量，还是减少了内存访问？
• bottleneck 在 kernel、显存带宽、网络、调度，还是应用层等待？
• 一个模型每百万 token 的服务成本是多少？
• batch size 增大后，吞吐提升多少，延迟恶化多少？
• 量化后节省了多少显存，质量损失是否可接受？
• 新硬件、新模型、新上下文长度会怎样改变容量规划？

这里最关键的能力是从第一性原理建模：

latency ≈ compute_time + memory_time + communication_time + scheduling_overhead
cost_per_token ≈ hardware_cost_per_second / tokens_per_second
capacity ≈ available_gpu_seconds / seconds_per_request

当然真实系统比这复杂得多，但这个骨架很重要。没有这个骨架，优化就会变成“试试这个参数，看看会不会快”。有了这个骨架，实验才有方向。

对个人学习的启发：

• 写 microbenchmark：矩阵乘、attention、KV cache 读写、tokenizer。
• 同一模型跑 fp16、int8、int4，记录显存、速度、输出质量变化。
• 给本地推理写一个成本估算表：每秒 token、单次请求耗时、并发数、显存峰值。
• 读 vLLM、llama.cpp、TensorRT-LLM 的设计时，不只问“怎么实现”，还问“它解决的是哪类瓶颈”。

LoRA rank 的数学直觉也属于这里的一部分。rank=16 不是“更新 16 个大张量维度”，而是在大权重更新矩阵里限制一个低维变化子空间。它的工程收益不是玄学，是显存、存储、训练时间、adapter 分发和多任务切换成本都下降。

4. 数据基础设施：让训练和评测吃到可靠、可追踪、可治理的数据

很多人低估数据 Infra，因为它不像 GPU 那样显眼。但 OpenAI 的 Data Infrastructure 岗位描述提到 Spark、Iceberg、Delta、Kafka、Flink、Airflow、特征工程、数据湖、metadata、exabyte-scale 架构、高吞吐 streaming、低延迟 ingestion、安全治理和 on-call。这说明数据不是“下载几个 JSONL”，而是一套生产级供应链。

AI 数据 Infra 每天面对的问题包括：

• 数据从哪里来，经过哪些清洗、去重、过滤、标注和版本化流程？
• 训练集、评测集、线上反馈数据之间如何隔离，避免泄漏？
• 数据 schema 变化后，下游训练任务是否会悄悄坏掉？
• 海量数据如何分片、shuffle、压缩、缓存、流式读取？
• 研究员怎样快速抽样、回溯、复现实验用到的数据版本？
• 数据访问权限如何控制，敏感数据如何治理？

这类工作看似离模型远，实际上直接决定模型质量上限。训练代码再漂亮，数据版本混乱也会让结果不可复现；评测集污染，模型指标会虚高；数据读取慢，GPU 就会等数据。

对个人学习的启发：

• 做一个小数据管线：raw data → clean → dedupe → split → versioned dataset。
• 给每个样本保留来源、清洗规则、hash、版本号。
• 用一个小评测集演示数据泄漏：把答案混入训练数据，观察指标虚高。
• 用 streaming dataset 模拟大文件读取，观察 batch 构造和吞吐变化。

这是从“拿数据跑模型”走向“管理模型的数据生命线”。

5. GPU 集群、调度、网络与硬件健康：把稀缺算力变成稳定机器

Frontier Clusters Infrastructure 岗位描述里有非常清晰的画面：启动和扩展大规模 Kubernetes 集群，自动化 bare-metal bring-up，做固件和系统升级，统一多个集群，对接网络和硬件健康系统，把集群重启时间从小时级降到分钟级，并在极端负载下保持稳定。

这类工作是 AI Infra 的“地基层”。它关心的不是某个模型，而是所有模型共享的算力工厂：

• 新 GPU 节点如何从裸金属变成可调度资源？
• 某批机器固件升级后，训练任务是否会出现新故障？
• 哪些 GPU 是 intermittent failure，需要隔离？
• 调度器如何理解 GPU 拓扑、NVLink、IB 网络、机架位置和作业优先级？
• 大任务和小任务如何共享集群？
• 资源配额、抢占、排队、公平性如何设计？
• 节点、交换机、存储、Kubernetes、训练框架之间如何联合观测？

这一层最容易让初学者感到遥远，因为个人电脑上没有数据中心。但你仍然可以练它的抽象：

• 用 Docker Compose 或本地 Kubernetes 模拟服务调度、失败重启、健康检查。
• 写一个 toy scheduler：输入任务资源需求和机器容量，输出排队与分配结果。
• 模拟一个节点故障，观察任务如何迁移、重试或失败。
• 学 Linux、容器、网络、存储和观测，因为大模型集群最后还是这些基本功。

AI Infra 的特殊之处在于 GPU 极贵、作业极长、失败代价极高。所以普通云原生经验有用，但还不够。你还要理解 GPU 拓扑、通信库、显存、算子、训练和推理工作负载。

6. 可靠性与可观测性：让问题在用户发现前先被系统发现

可靠性不是一个独立功能，而是所有 AI Infra 团队的共同责任。OpenAI 的多个岗位描述都提到 production operations、on-call、critical incidents、metrics、logs、traces、dashboards、observability。对 AI 系统而言，可观测性比普通后端更复杂，因为模型问题既可能是系统问题，也可能是行为问题。

AI Infra 的可靠性问题有几类：

• 系统可靠性：服务是否挂了，GPU 节点是否异常，队列是否堆积。
• 性能可靠性：p95 延迟是否升高，tokens/sec 是否下降，batching 是否失效。
• 质量可靠性：新模型是否在某类任务上退化，安全策略是否误伤。
• 成本可靠性：某个流量模式是否让 GPU 成本异常上升。
• 实验可靠性：同一个实验配置能否复现，评测结果是否稳定。

普通服务的日志里常见的是 HTTP status、RPC latency、DB query；AI 服务还需要看：

prompt length
output length
time to first token
decode tokens/sec
KV cache usage
batch occupancy
GPU memory allocated
model version
adapter version
sampling parameters
eval suite version

对个人学习的启发：

• 给本地推理服务加结构化日志，不只打印最终答案。
• 每次请求记录 prompt tokens、completion tokens、首 token 时间、总耗时。
• 做一个简单 dashboard 或 CSV 分析，观察长 prompt、短 prompt、不同 batch 的差异。
• 写失败注入：模型文件不存在、adapter 加载失败、显存不足、请求超时，看看系统如何报错和恢复。

真正的 Infra 能力，不是系统永远不出错，而是出错时知道在哪里、为什么、影响多大、如何恢复。

7. 评测、实验与发布：把“模型变好了”变成可验证的上线决策

模型不是写完就上线。一个新模型、新 adapter、新 prompt、新 tool policy、新 decoding 参数，都需要经过评测、灰度、回滚和线上监控。

这类工作每天会处理：

• 离线 eval 是否覆盖目标任务和失败模式？
• 新版本在总体分数上变好，但是否在某些关键子集退化？
• 自动评测、人工评测、线上 A/B 指标之间如何互相校验？
• canary 流量比例如何设定，触发什么指标就回滚？
• 模型质量、延迟、成本、安全之间如何权衡？
• 评测集和线上数据如何版本化，避免“今天的分数”和“昨天的分数”不可比？

这一层和你前面学的 LoRA 很相关。LoRA adapter 不是“训练出来就算成功”，真正生产里还要问：

adapter 是否真的提升目标任务？
有没有让通用能力退化？
加载 adapter 后延迟增加多少？
合并 adapter 后输出是否一致？
多 adapter 共存时如何路由？
adapter 版本如何回滚？

对个人学习的启发：

• 给本地 LoRA demo 增加一个小 eval harness，而不是只看一两个输出样例。
• 设计 20 到 50 条固定测试 prompt，记录 base、adapter、merged 三种输出。
• 用简单打分规则或人工标注比较任务成功率。
• 每次修改参数都保存模型版本、adapter 版本、prompt 版本和评测结果。

这是从“我感觉这个输出更好”走向“我能证明它在目标任务上更好”。

8. Agent Infrastructure：让模型在隔离环境里使用工具、执行代码、完成任务

Agent Infra 是近几年非常关键的新分支。OpenAI 的 Agent Infrastructure 岗位描述提到，团队要构建训练和部署高可用 AI agents 的系统，给模型提供能执行代码、调试问题、开发软件的 workspace，并支撑 Codex、Operator、ChatGPT 工具使用和未来 agentic 产品。岗位还提到容器编排、FastAPI、gRPC、Terraform、虚拟化和容器化技术，如 Kata、Firecracker、gVisor、Sysbox。

这说明 Agent Infra 的核心不只是“给模型接一个工具调用 API”，而是：

• 给模型一个安全、可重置、可观测的工作环境。
• 允许模型执行代码、访问文件、调用浏览器或终端，但要有权限边界。
• 记录完整 trajectory：模型看到了什么、调用了什么工具、环境返回了什么。
• 支撑训练时的大规模环境模拟，也支撑生产时的真实用户任务。
• 对工具失败、超时、权限错误、环境污染、沙箱逃逸做防护。
• 把 agent 的行为转成可评测、可训练、可复现的数据。

Agent Infra 和普通后端的区别在于：普通后端执行的是程序员写死的流程；Agent Infra 执行的是模型动态选择的行动序列。系统必须允许灵活性，又要约束风险。

对个人学习的启发：

• 做一个最小 agent sandbox：模型只能在临时目录里读写，命令有白名单和超时。
• 记录每次工具调用的输入、输出、耗时、退出码和错误类型。
• 做一个可复现任务集：比如修一个小 bug、改一个测试、整理一个文件。
• 给 agent 加评测：是否完成任务，是否越权，是否产生不可解释副作用。

这和前面“参数化 skill”“Program-as-Weights”的思想可以连起来看：模型能力可以内化进权重，也可以外化成工具环境。AI Infra 要做的是让这两种能力协作，而不是只押一个方向。

9. 安全、权限与开发效率：让组织能快，但不乱

OpenAI 的 Build Systems / CI 岗位描述强调 Bazel、Buildkite、test selection、remote caching、CI observability、flake isolation、reproducible builds、hermetic builds、developer productivity。Cloud Infrastructure 岗位强调 Kubernetes、cloud abstractions、networking stack、reliability、security。它们看起来不像“AI 模型岗位”，但在大模型公司里非常关键。

原因很简单：模型研发越快，工程组织越需要可靠的地面系统。

安全与平台工程每天会处理：

• 谁能访问模型权重、训练数据、日志、评测结果和用户数据？
• CI 是否可信，测试是否 flaky，构建是否可复现？
• 一个 PR 会影响哪些模型服务、数据管线或推理路径？
• 密钥、镜像、依赖、模型 artifact 如何管理？
• 内部平台如何让研究、产品、Infra 团队都能快速发布，又不牺牲正确性？
• 失败信息能否被自动归因和解释，减少工程师在 CI 上耗费的时间？

这类工作容易被忽视，因为它不直接产出一个更聪明的模型。但如果构建慢、测试不可信、权限混乱、日志不可查，整个组织的 AI 迭代速度会被拖住。

对个人学习的启发：

• 给自己的 AI demo 写 Makefile 或 npm scripts，让环境、运行、评测一键化。
• 固定依赖版本，记录模型版本和 adapter 版本。
• 加 CI 检查：格式、类型、单测、最小推理 smoke test。
• 写 README，让别人能复现你的实验，而不是只能在你机器上跑。

这就是工程成熟度。

10. 九类场景放到一张表里

场景	他们每天解决什么	核心指标	你可以练的小项目
训练 Infra	大规模训练、后训练、checkpoint、分布式故障	tokens/sec、GPU 利用率、step time、恢复时间	小模型训练监控、checkpoint 中断恢复
推理 Infra	在线服务、prefill/decode、KV cache、batching、流式输出	TTFT、p95 延迟、decode tokens/sec、显存	本地推理 API、KV cache 估算器
性能工程	profiling、benchmark、成本建模、容量规划	cost/token、吞吐、利用率、带宽	microbenchmark、量化对比、成本表
数据 Infra	数据湖、streaming、清洗、去重、版本化、治理	ingestion 延迟、数据新鲜度、错误率	数据版本管线、泄漏实验
集群与硬件	GPU 调度、Kubernetes、裸金属、网络、硬件健康	节点健康、排队时间、重启时间	toy scheduler、故障恢复演示
可靠性观测	日志、指标、trace、告警、on-call、事故复盘	SLO、错误率、p99、MTTR	推理服务结构化日志和 dashboard
评测发布	eval、A/B、canary、回滚、质量与成本权衡	eval score、退化率、回滚时间	LoRA adapter 小评测集
Agent Infra	沙箱、工具调用、trajectory、虚拟化、环境模拟	任务成功率、越权率、工具失败率	最小 agent sandbox
安全与效率	CI、构建、权限、artifact、开发者平台	build time、flake rate、cache hit	可复现 AI demo 和 CI smoke test

这张表有一个重要用法：不要把每一行都当成下一步任务。你应该先选一个主线，再选两个支撑面。

11. 以他们为镜：我现在应该站在哪里

结合前面几篇学习记录，我当前最合理的坐标不是“全栈 AI Infra”，而是：

主线：推理 Infra
支撑 1：性能工程
支撑 2：评测发布
旁路理解：Agent Infra 与 LoRA/skill 的关系

原因很现实：

• llama.cpp prefill/decode 已经在推理主线上。
• LoRA/PEFT 已经碰到 adapter 加载、合并、部署和评测问题。
• rank=16 的数学直觉可以自然过渡到显存、吞吐、成本模型。
• Qwen3 学习地图帮助建立模型栈全局视野。
• Agent skill 和 Program-as-Weights 能连接到 Agent Infra，但不宜一开始就把虚拟化、容器调度、RL 环境全吃下。

所以短期不需要把目标写成“我要懂 OpenAI 的全部 Infra”。更清晰的目标是：

我能解释并实现一个小型 LLM 推理服务：
能加载 base model 和 LoRA adapter，
能区分 prefill/decode 成本，
能记录 token 级延迟和显存，
能用小评测集比较版本，
能在失败时定位问题，
能写清楚成本和取舍。

这已经是 AI Infra 的真实缩影。

12. 接下来 30 天怎么练

如果把 OpenAI 这些岗位当成镜子，我不会直接复制它们的要求，而是把它们压缩成一个可执行学习闭环。

第 1 周：推理链路拆解

目标：把“模型生成一个回答”拆成可观测步骤。

• 继续读 llama.cpp 或 vLLM 的入口。
• 分开记录 prefill 时间、decode 时间、首 token 时间、总 token 数。
• 做不同 prompt length 的实验。
• 写一篇短记录：为什么长上下文主要伤 prefill 和 KV cache。

交付物：

一个本地推理脚本
一份 latency CSV
一张 prompt length vs TTFT 图
一篇解释 prefill/decode 的笔记

第 2 周：LoRA 从训练结果走向服务形态

目标：理解 adapter 不是论文概念，而是一种生产交付单元。

• 跑 base、active adapter、merged model 三种推理。
• 记录加载时间、显存、输出差异。
• 做 20 条固定 prompt 的小评测。
• 解释什么时候保留 adapter，什么时候 merge。

交付物：

LoRA adapter 对比表
小评测结果
一份 adapter 发布 checklist

第 3 周：服务化和观测

目标：把脚本变成小服务，并开始像 Infra 工程师一样看指标。

• 用 FastAPI 或类似框架包一层 /generate。
• 给每次请求记录 prompt tokens、completion tokens、TTFT、总耗时、错误类型。
• 用并发请求压测 p50、p95。
• 故意制造超时、模型路径错误、adapter 错误，观察报错质量。

交付物：

一个可启动的本地推理 API
结构化日志
简单压测结果
失败注入记录

第 4 周：评测、回滚和复盘

目标：把“能跑”升级成“能判断能不能上线”。

• 固定一组 eval prompts。
• 对比两个模型版本或两个 adapter 版本。
• 设定一个简单发布门槛：质量不降、p95 不超过阈值、错误率不升。
• 写一次复盘：如果指标退化，如何定位是模型、参数、数据、服务还是硬件问题。

交付物：

eval harness
版本对比报告
发布门槛
一次故障定位复盘

这 30 天不是为了做一个大项目，而是为了把 AI Infra 的思维肌肉练出来：每个实验都能测量、复现、解释、对比和回滚。

13. 结论：看见他们的工作，是为了看清自己的下一步

OpenAI 这类公司的 AI Infra 工程师每天做的事情，表面上分散在训练、推理、数据、集群、可靠性、评测、Agent、安全、CI。抽象起来，其实都在回答同一个问题：

如何把不稳定、昂贵、快速变化的大模型能力，
变成可靠、可扩展、可观测、可迭代的工程系统？

这就是 AI Infra 的核心。

“以他们为镜，明其身”的意思不是照着岗位描述焦虑，也不是把每个关键词都塞进学习计划。镜子的作用是校准方向：知道哪些问题是真问题，哪些练习能迁移，哪些知识只是好听但暂时离主线太远。

我现在最应该抓住的主线是推理 Infra。继续从 token 级推理、KV cache、LoRA adapter、延迟观测、小评测和服务化做起。等这条链路打通，再往上接 Agent Infra，往下补算子与硬件，往旁边扩数据和集群。

这样学，才不是在追热点，而是在一层层接近真实的 AI 工程系统。

参考资料

以下链接均为 OpenAI 公开岗位页面，访问时间为 2026-07-06。岗位页面可能随时间变动，本文只把它们作为公开样本来抽象 AI Infra 的问题分类。

• Software Engineer, Cloud Infrastructure
• Software Engineer, Inference - Multi Modal
• Software Engineer, Inference - Performance Optimization
• Software Engineer, Agent Infrastructure
• Software Engineer, Data Infrastructure
• Software Engineer, Frontier Clusters Infrastructure
• Software Engineer, RL Training Infra
• Software Engineer, Build Systems / CI