从 CPU 性能工程到软硬件协同技术负责人：招聘趋势、能力要求与成长路径
从 CPU 性能工程到软硬件协同技术负责人：招聘趋势、能力要求与成长路径
| 字段 | 内容 |
|---|---|
| 文档类型 | 技术调研报告 |
| 版本 | v1.0 |
| 状态 | 已完成（公开样本调研） |
| 密级 | 公开资料整理 |
| 作者 | Qoder |
| 生成日期 | 2026-09-08 |
| 研究截点 | 2026-09-08；岗位页面按访问日截取 |
| 目标读者 | CPU 性能分析、系统软件、编译器、运行时与 AI 推理工程师；技术管理者 |
| 调研问题 | 主流互联网与芯片公司对 CPU 性能/系统优化岗位的职责和能力要求如何演变；个人怎样成长为能负责 workload 性能与软硬件协同的技术负责人？ |
| 覆盖范围 | Android、Linux、JVM、AI 推理；公开招聘页和官方技术文档；国际与国内代表性样本 |
| 排除范围 | 不统计招聘数量、薪酬或地域供需；不以不可核验的聚合招聘站作为结论证据；不替代具体公司面试题库 |
版本历史
| 版本 | 日期 | 变更 | 结论状态 |
|---|---|---|---|
| v1.0 | 2026-09-08 | 建立岗位样本、技术底座、成长路线和验收框架 | 已完成 |
术语与缩略语
| 术语 | 含义 | 本文语境 |
|---|---|---|
| workload | 能代表真实业务目标的一组输入、并发、数据分布和操作序列 | 一切性能决策的共同输入，不等于孤立 microbenchmark |
| SLO | 服务等级目标 | 含吞吐、P50/P99 延迟、启动/帧时间、成本、功耗或内存上限 |
| PMU | Performance Monitoring Unit | 用硬件事件辅助归因，如周期、缓存未命中和分支行为 |
| Top-down | Top-down Microarchitecture Analysis Method | 把流水线槽位归到前端、后端、错误推测与退休等类别的方法 [S08] |
| PGO | Profile-Guided Optimization | 用代表性执行 profile 指导内联和代码布局等优化 [S11] |
| IR | Intermediate Representation | 编译器中源代码到机器码之间的中间表示 |
| JIT / AOT | 即时编译 / 提前编译 | JVM、ART 等运行时的代码生成策略 |
| EP | Execution Provider | ONNX Runtime 将图或算子交给特定硬件后端的执行接口 [S14] |
| PPA | Performance, Power, Area | 芯片/系统设计中性能、功耗、面积的联合权衡 |
可靠性标记
- 【C】可由单一官方招聘页、官方文档或上游项目页面直接核验的事实。
- 【C*】由多个独立一手来源相互支持的稳定结论。
- 【S】基于有限职位样本归纳的趋势，不代表岗位数或所有团队。
- 【P】面向个人或团队的建议，不是公司公开承诺。
- 【?】公开页面动态加载或职位会下线，无法在本次截点复核的细节。
1. 核心判断（TL;DR）
- 【C*】头部公司的“性能”岗位正在把任务对象从代码片段扩大到真实 workload：Apple 的端侧 ML 性能岗位强调 Apple Silicon 上的模型推理优化与性能分析工具，NVIDIA 的高级性能工程岗位强调 AI/HPC workload 剖析与瓶颈分析 [S01][S02]。
- 【C*】可迁移的底座不是某一平台 API，而是四件事：可代表业务的测量设计、编译/运行时代码分析、基于 PMU 的微架构归因、可复现的端到端验证；Android、Linux、JVM 和推理框架都提供了对应入口 [S05][S06][S07][S08][S11][S12][S14][S16]。
- 【S】职位标题会分成 System Software、Runtime、Compiler、Performance、Inference、Architecture/Modeling，但高级职责的交集是：定义代表性负载和指标，协调软件栈与硬件约束，并交付可持续回归的收益，而非一次性跑分；百度的底层软硬件样本与小米的 Android 框架/内核/显示岗位族体现了同样的跨层拆分 [S19][S20][S22][S25][S28][S32][S35][S36][S37][S38]。
- 【P】成长路线应按责任边界而非年限划分：先能复现和归因，再能稳定优化热路径，继而能对一条 workload 的 SLO 与回归门禁负责，最后把 workload 变成芯片/平台设计输入；见图 2 的四级路线 [S23][S25][S33]。
2. 问题、范围与方法
本报告回答的不是“怎样成为某公司某个职位的候选人”，而是识别这些职位背后稳定的工程契约：谁定义工作负载，谁能解释性能退化，谁能决定优化投入，谁能在架构、编译器、运行时和业务之间处理取舍。Android 是很好的起点，但不是终点：同一套方法可向 Linux 服务、JVM、端侧/数据中心推理和芯片性能模型延伸。
方法分为四步。第一，优先采集仍可访问的官方岗位页，逐条记录岗位职责与显式资格，禁止用职位标题反推未写明的技能；岗位正文动态加载或已下线时，标为【?】而不作为详细要求证据。第二，以 Android、LLVM、OpenJDK、ONNX Runtime、LiteRT、TensorRT、Intel 和 Arm 的官方文档构建方法底座，验证工具确实覆盖测量、代码生成、微架构和推理评估。第三，把岗位样本按“交付对象”归类，而非按公司 logo 分类。第四，把样本趋势转为可操作的能力层级和验收指标。
| 证据层 | 采集对象 | 可支持的结论 | 不支持的结论 |
|---|---|---|---|
| A：直接岗位 | 职责、最低资格、偏好资格 | 某岗位明确要求什么 | 公司整体 HC 数量或薪酬 |
| B：官方工具/上游文档 | 测量接口、优化机制、验证方法 | 方法是否可落地 | 某公司一定采用该工具 |
| C：跨样本归纳 | 多个岗位与技术材料的交集 | 能力方向变化 | 统计显著性或完整市场份额 |
| D：建议 | 能力路线、作品集和门禁 | 推荐行动 | 公司录用保证 |
图 1 给出本文的分析闭环。它刻意把“优化”放在最后：没有可重放的 workload 和稳定基线，任何汇编层面的好看指标都不应被当作产品收益；没有回归门禁，任何局部收益都不能称为平台能力。
图 1：CPU 性能工程的工作负载闭环。来源：依据 Android Simpleperf/Perfetto、LLVM MCA、VTune Top-down、Android PGO 与推理基准文档综合绘制；图中是分析框架，不是职位数量统计 [S05][S06][S07][S08][S11][S14][S16]。
3. 全球技术基线
3.1 四类平台正在共享同一性能方法
Android 的性能工作已不局限于 Java 层。Simpleperf 可以对 Android native code 进行 stat、record 和 report，并分析 CPU cycles 等硬件事件；Perfetto 以 trace 解释复杂系统行为 [S05][S06]。同时，Baseline Profiles 让 ART 在安装时 AOT 编译关键路径，NDK PGO 则以代表性运行 profile 指导内联和代码布局 [S10][S11]。因此 Android 工程师若能把交互路径、Native 热点、调度轨迹和编译产物联立观察，已经具备向系统性能转移的基础。
Linux/CPU 平台侧更强调“计数器不是结论，而是归因入口”。Intel 的 Top-down 方法将流水线槽位分为 Front-End Bound、Back-End Bound、Bad Speculation 和 Retiring，帮助将热点从“函数很慢”推进到“前端供给、内存层次还是错误推测受限”的假设 [S08]。Arm Streamline 同样将 CPU/GPU workload 采样与瓶颈定位作为核心能力 [S09]。静态一侧，LLVM MCA 通过调度模型分析汇编的 IPC 与资源压力 [S07]；它能缩短假设验证，但不能替代真实机器上含 OS、数据和并发扰动的测量。
JVM 与 AI 推理把上述方法进一步暴露为运行时控制问题。JMH 是为 JVM 基准构建、运行和分析而设的 harness，JFR 的 Linux CPU-time profiling 目标是同时观测 Java 与 native code 的 CPU 消耗 [S12][S13]。ONNX Runtime 文档把 profiling、threading、I/O binding、内存管理和 graph optimization 作为性能调优杠杆；LiteRT 明确区分初始化、预热和稳态推理时间，并提供线程数与 delegate 等控制项；TensorRT 则要求稳定时钟、监控热/功耗限制并以端到端指标比较 [S14][S15][S16]。这解释了为什么 AI 推理岗位会同时要求模型、系统、编译器和硬件知识。
| 域 | 可观察接口 | 代码/运行时控制点 | 典型瓶颈假设 | 合格验证 |
|---|---|---|---|---|
| Android | Perfetto、Simpleperf、Macrobenchmark | ART profile、NDK PGO、Native 库 | 启动路径、锁竞争、调度、指令/缓存 | 关键用户旅程的冷/热态与回归 [S05][S06][S10][S11] |
| Linux 服务 | PMU、trace、系统采样 | 线程、NUMA、内存分配、I/O | 队列、带宽、尾延迟、上下文切换 | 固定负载/机器状态下吞吐和 P99 |
| JVM | JMH、JFR | JIT、GC、逃逸/内联、堆配置 | 预热、去优化、分配、GC 暂停 | fork/warmup 后的分位数与资源消耗 [S12][S13] |
| AI 推理 | profiler、layer trace、端到端 benchmark | 图优化、EP/delegate、线程、内存绑定 | 算子、布局转换、同步、带宽、热限制 | init/warmup/steady-state、精度和功耗一起验收 [S14][S15][S16] |
3.2 公开职位样本：高级角色以“负载与交付”命名
Apple 的 On-device ML Performance Engineer 岗位直接写明：在 Apple Silicon 上优化 ML model inference，并开发 performance analysis tools；列出的能力包括 Python/C++、LLM/CNN 等 ML 架构以及 MLIR/LLVM 编译器栈 [S01]。这不是单纯 App 调优，也不是只做算子，而是模型、工具、编译栈和特定硬件的组合。NVIDIA 的 Senior Performance Engineer 样本职责是剖析 AI/HPC workloads 并分析瓶颈，资格包括五年以上经验、RDMA/NCCL 和分析能力 [S02]。两者共同指向跨设备/跨节点 workload 的性能负责。
不能把两个职位当作整个市场的数量统计，但它们提供了清晰的职责锚点：高级性能角色要能把“模型/服务到底慢在哪里”转成可验证的系统假设；要能在编译、通信、运行时或硬件选择中推进一个可以落地的改变；并将工具化和自动化作为产物的一部分。图 3 将四个常见工作域映射到这一共同底座。
| 公司/样本 | 公开岗位职责证据 | 显式技术要求证据 | 可迁移的岗位信号 | 可靠性 |
|---|---|---|---|---|
| Apple | 优化 Apple Silicon 上 ML 模型推理；开发性能分析工具 | Python/C++、LLM/CNN、MLIR/LLVM | 端侧 AI 的性能职位向工具、编译栈和专用硬件扩展 | 【C】[S01] |
| NVIDIA | 剖析 AI/HPC workloads、分析瓶颈 | 5+ 年经验、RDMA/NCCL、分析能力 | 数据中心性能既看 CPU/系统，也看通信与并行负载 | 【C】[S02] |
| 华为招聘门户 | 可访问社会招聘职位详情入口，但正文由前端接口加载 | 本次静态页面无法核验职位正文 | 国内岗位样本必须保留页面时效/动态加载限制，不应把标题当要求 | 【?】[S03] |
| 阿里校园招聘 | 可访问 AI 编译研发职位入口，但正文由前端接口加载 | 本次静态页面无法核验职位正文 | 编译器/AI 交叉是国内平台岗位的明确职位类别；具体要求需以投递时页面复核 | 【?】[S04] |
3.3 更高职级的共性：负载表征、预测模型与跨团队决策
新增岗位样本强化了上述判断。NVIDIA 的 Senior CPU Compiler Performance Engineer 明确写出分析 AI workloads、优化 CPU 编译器、推动软硬件共同设计，并要求 C++、LLVM/MLIR/GCC 与 Arm/RISC-V/x86 架构知识；AMD 的 AI Performance Modeling Engineer 则要求以模型预测生成式 AI/LLM 在 GPU 架构上的性能，并具备现代 C++ 和生产级 Python 能力 [S19][S20]。这两类岗位把“运行后优化”向“设计前预测”延伸。
Arm 的 Runtimes Performance 岗位直接针对受管语言 workload 的 runtime/compiler 性能，Apple 的 Systems Performance Architect 则将应用和 benchmark 的 workload characterization、指令混合与内存访问模式分析列为职责 [S22][S25]。Meta 的 MTIA kernel 角色把 kernel、完整栈根因分析与 silicon/compiler/runtime/framework 协作并置；AWS Neuron 的推理岗位则以 vLLM/SGLang 定制优化和 CUDA kernel 开发为工作对象 [S28][S32]。高级技术负责人的稀缺性由此不在“懂得所有层”，而在于能让各层围绕同一 workload、预测和验收数据协同。
| 角色族与样本 | 职责中的性能对象 | 明确能力要求 | 向负责人的信号 |
|---|---|---|---|
| CPU compiler / co-design：NVIDIA | AI workload、CPU 编译器、预硅协同 | 8+ 年、C++、LLVM/MLIR/GCC、Arm/RISC-V/x86 | 能把 workload 转为编译器与硬件共同设计输入 [S19] |
| AI performance model：AMD | LLM/生成式 AI 在 GPU 上的预测性能 | cycle/performance modeling、LLM、C++/Python | 能在硬件落地前管理性能风险 [S20] |
| Runtime performance：Arm | 受管语言 workload、runtime/compiler | C/C++、汇编级工具、运行时/编译器、开源协作 | 能从应用语义追到 runtime 和机器指令 [S22] |
| Systems architecture：Apple | key applications/benchmarks、指令和内存访问模式 | workload characterization、performance modeling | 能把软件负载翻译成体系结构规格 [S25] |
| Full-stack accelerator：Meta | compute/communication kernels、完整栈瓶颈 | C++/Python、并行架构、内存层次 | 能组织 silicon、compiler、runtime、framework 协作 [S28] |
| Inference platform：AWS Neuron | vLLM/SGLang、CUDA kernels、模型服务 | ML 基础、5+ 年工程、框架/内核经验 | 能把开源框架行为变为特定硬件收益 [S32] |
图 3：平台与芯片公司的性能岗位工作域地图。来源：岗位职责样本与 Android、JVM、推理及微架构工具文档的交集归纳；用于表达能力边界，不表达公司组织结构或招聘数量 [S01][S02][S05][S07][S12][S14]。
4. 国内发展、差距与机会
国内互联网和芯片公司在公开招聘层面面对两个现实：其一，官方职位常由动态接口加载、更新和下线很快，不能仅依靠静态抓取建立“需求数量”结论；其二，职位标题的粒度并不统一，性能工作会分散在 OS、编译器、云基础设施、AI 框架、芯片软件、终端系统等团队。因而，本报告不以“某公司招了多少人”为结论，而以可复核职责、技术要求和工程方法交叉确认能力方向。华为社会招聘和阿里校园招聘存在面向系统/AI 技术岗位的官方入口，但本次访问的两个详情正文无法从静态页面核验，仍需在实际投递时重新确认 [S03][S04]。
可直接核验的国内样本已经显示出“全链路”与“分层专精”并存。百度北京“底层软硬件研发工程师 J100720”将 Linux 内核、虚拟化、训推加速与 CPU/GPU 微架构、集合通信、算子优化、KV Cache 存储的软硬件全链路性能优化并列，明确要求 Python/Shell/C/C++之一、Linux 以及调试、性能优化和测试意识；页面显示 5 个名额、更新于 2026-08-28 [S35]。小米则把 Android Framework、电视端 Android 内核/驱动、显示驱动拆分为相邻职位：前者要求 Linux、C/C++或 Java 与 Framework 经验；内核岗位要求 Linux Kernel/BootLoader、文件系统/驱动/HAL 调试和性能调优；显示岗位要求 Android/Linux 上的 GPU 显示驱动、HAL/Framework 和 C/C++ [S36][S37][S38]。这并非说明所有国内团队按相同方式组织，而是表明高级人才需要既能深挖某层，也能理解上下游接口。
机会并不在于复制国外工具名，而在于把本地硬件、系统版本、负载分布和交付约束做成可持续的性能资产。Linux 内核已有 Alibaba T-Head SoC uncore PMU 文档，说明国内 CPU 生态同样进入了把 SoC 级事件接入标准 perf 观测面的阶段 [S17]。这类入口使团队可以把“CPU cycles 高”进一步拆到互连、DDR、缓存或设备侧事件，但也要求工程师懂事件定义、采样偏差、内核/驱动版本和工作负载再现，而不是只会运行命令。
| 国内样本 | 直接职责/对象 | 明确要求 | 对成长路线的含义 |
|---|---|---|---|
| 百度 J100720：底层软硬件研发 | Linux 内核/虚拟化、训推加速；CPU/GPU 微架构、集合通信、算子与 KV Cache 的全链路优化 | Python/Shell/C/C++、Linux、调试/性能/测试意识 | 从系统到模型服务都需能建立同一条性能证据链 [S35] |
| 小米 Android Framework 系统工程师 | Framework 需求、设计、开发、调试与测试 | Linux、C/C++/Java、2+ 年 Framework | Android 可作为 runtime/API/系统交界的深耕入口 [S36] |
| 小米 Android 内核和驱动 | Kernel/BootLoader、文件系统、驱动/HAL 调试及性能调优 | 内核、驱动、文件系统、进程/内存知识 | Linux 内核路径要把功能交付与性能调试并行训练 [S37] |
| 小米显示驱动 | Android/Linux GPU 显示驱动 | C/C++、显示硬件、HAL/Framework | 图形显示路径同样要求驱动到框架的接口理解 [S38] |
从岗位策略看，国内团队最有价值的候选人通常不是“某一个 benchmark 的高手”，而是能把特定产品负载沉淀为基准集、把性能退化变成 CI 门禁、并能与芯片/编译器/框架团队讨论根因的人。端侧场景的门槛是功耗、温度和交互体验一起约束；云和大模型推理的门槛是多租户、尾延迟、通信与单位成本一起约束；国产 CPU/NPU 的门槛还包括 ISA、编译器调度模型、内核驱动和 perf 事件模型的持续共演。见“能力成熟度对比矩阵”。
能力成熟度对比矩阵
| 维度 | 初级可交付 | 高级可交付 | 技术负责人可交付 | 国内场景的额外验证 |
|---|---|---|---|---|
| 工作负载 | 能复现单一 benchmark | 能解释代表性场景与数据分布 | 定义跨产品的 workload taxonomy 与 SLO | 覆盖目标机型/CPU/NPU、版本和地域流量差异 |
| 性能观测 | 会看 flame graph 或单一 trace | 能关联 PMU、调度、锁、I/O 与代码 | 设计低开销遥测、归因规范与门禁 | 校验 vendor PMU 事件语义和可比性 [S17] |
| 编译/运行时 | 能阅读热点源码 | 能读 IR/汇编，改优化或 runtime 参数 | 决定 PGO、JIT/AOT、ABI 与兼容性权衡 | 建立多 ISA/多后端的代码生成验收 |
| 微架构 | 知道 cache/branch 概念 | 用 Top-down/模型提出并证伪假设 | 将 workload 指标回灌硬件规划 | 明确 PPA、可制造性、固件和驱动边界 |
| 验证 | 能跑出均值 | 有可重放脚本、分位数和置信分析 | CI 门禁、回归归因、跨代决策 | 处理温控、固件、频率策略和供应链变更 |
4.1 国内岗位趋势的可操作判断
【S】对比可核验国际样本与国内直接职位，国内职位名称会更碎片化，但技能交集并未改变：C/C++、Linux、性能工具、编译器/运行时或推理框架至少占其中两类；当工作对象靠近 SoC、AI 加速或云基础设施时，岗位会进一步要求并行、内存、通信、驱动或硬件基础 [S19][S20][S28][S32][S35][S36][S37][S38]。对个人而言，投递策略应以“我能负责的 workload 和证据链”描述项目，而不应以“会 perf / 会 LLVM”罗列工具。
【P】国内团队可将 Android 作为低门槛练兵场：选定启动、滚动、相机后处理或端侧模型等用户旅程，用 Perfetto + Simpleperf 建基线，配合 Baseline Profile/NDK PGO 或 Native 实现调整；再把方法迁移到 Linux 服务或 AI 推理。这样形成的作品能同时证明测量、编译分析与优化验证能力。其风险是端侧样本容易受温控、后台任务、供应商固件影响，必须在提交中记录设备、频率、温度、版本和随机种子。
5. 关键机制深挖
5.1 工作负载理解与观测：先定义“慢”的业务语义
接口与实现依据。 Android 可通过 Perfetto 记录系统 trace，通过 Simpleperf 的 stat、record、report 获取 native code 和硬件事件；JVM 可使用 JMH 建基准、用 JFR 获取 Java/native CPU-time；推理框架则公开 profiler 与 benchmark 参数 [S05][S06][S12][S13][S14][S15]。实现上，应把 workload 定义为输入集、并发模型、数据大小、热/冷状态、设备/频率策略、SLO 与禁止改变的正确性约束，而不是一个没有数据分布的循环。
失效边界。 microbenchmark 在 JIT 预热不足、缓存状态不同、分支分布被简化、线程绑核不同或端侧被热节流时会失真；trace 也可能因采样率、buffer 丢失和插桩开销改变对象本身。把单次平均值当结论、把 benchmark 的优化直接外推到线上 P99，都是失效边界。AI 推理还要防止只测 kernel 时间而遗漏预处理、数据传输、图转换与同步。
验证条件。 每个性能结论至少要有：固定版本/硬件/频率策略；冷态、预热和稳态分开；吞吐与 P50/P99 同报；正确性或模型精度未退化；原始 trace/profile 与生成脚本可复现。对端侧，补充温度、功耗和电池策略；对服务端，补充并发、NUMA、网络和数据集版本。TensorRT 文档要求稳定时钟、监控热/功耗限制并用端到端指标比较，正是该原则的实例 [S16]。
成本与权衡。 高保真代表性 workload 的采集和脱敏成本高；低开销线上观测会牺牲细粒度；覆盖更多硬件组合会降低迭代速度。负责人应明确“用于回归的标准集”和“用于诊断的扩展集”，前者追求稳定与自动化，后者追求可解释性，不能试图用一个脚本同时承担两种职责。
5.2 编译代码与运行时：把热点函数连接到最终机器指令
接口与实现依据。 LLVM MCA 以汇编及目标调度模型估算 IPC、资源压力和瓶颈，是连接代码生成与微架构假设的静态接口 [S07]。Android NDK PGO 则将代表性 profile 输入编译器，以影响内联和代码布局；ART Baseline Profiles 选择关键路径进行 AOT 编译 [S10][S11]。JMH/JFR 分别给出 JVM 基准和 CPU-time 观察接口 [S12][S13]。实现工作要能在 source、IR、优化 remark、反汇编、符号、调用约定和实际 profile 之间建立可追溯链条。
失效边界。 静态调度模型不了解真实 cache miss、分支分布、抢占、DVFS 与其他核竞争；PGO profile 若不是目标 workload，可能把代码布局优化给错误路径；JIT 行为也受 tier、去优化、class loading 和 GC 影响。只因汇编“少了几条指令”就宣布收益，是典型失败边界；同样，盲目强制内联/向量化也可能抬高 I-cache 压力或破坏功耗。
验证条件。 修改编译器或运行时前后应同时保存 IR/汇编差异、静态模型输出、真实 PMU/trace 与端到端 SLO；对 PGO，至少覆盖真实热路径和冷路径，且保留回退构建；对 JVM，必须设置合理 fork/warmup 并验证 GC/分配变化；对 Android，应在 release 配置和目标 ABI 上验证安装、启动和关键旅程。验证不是“benchmark 更快”而是“生成代码的改变能解释 workload 指标的改变”。
成本与权衡。 PGO、AOT 和更激进优化会增加构建时间、包体、profile 管理和兼容性测试；JIT 可降低安装体积却可能引入首次执行抖动；专门化 kernel 可提高单一模型速度却降低模型泛化。负责人需要把收益写成负载与边界条件，而不是泛称“性能提升”。
5.3 微架构建模与软硬件协同：把 PMU 数据变成可证伪假设
接口与实现依据。 Top-down 方法提供了从流水线槽位向前端受限、后端受限、错误推测和退休分类的分析接口 [S08]；Arm Streamline 通过 CPU/GPU workload 采样辅助定位瓶颈 [S09]；LLVM MCA 的 scheduling model 则是编译器和目标微架构之间的模型接口 [S07]。在 SoC 层，T-Head uncore PMU 已进入 Linux 内核文档，表示系统性能还可以观测到 CPU 核外资源 [S17]。实现应将事件选择、事件语义、采样窗口、频率、核/NUMA 绑定和数据布局写入实验协议。
失效边界。 事件命名相同不等于跨 CPU 语义相同；多路复用 PMU 事件会产生缩放误差；Top-down 分类是归因起点而非因果证明；模拟模型可能漏掉 cache、预取器、固件、互连拥塞和 OS 干扰。把“Back-End Bound”直接等同“内存慢”，或把一个芯片上的 tuning 参数搬到另一代 CPU，都会跨越方法的限制。
验证条件。 每个微架构假设至少需要两类独立证据：例如 PMU 分类与可控的工作集/带宽实验相互印证，或静态吞吐模型与真实 cycle、IPC、cache/branch 事件相互印证。若影响硬件规划，还要用 workload suite 覆盖典型与压力路径，明确 PPA、频率、热设计和软件版本；若影响编译器，再验证代码生成与实际事件方向一致。这样才可把“建议增大缓存”升级为有数据边界的设计输入。
成本与权衡。 建立可信模型需要芯片事件手册、编译器模型维护、实验资源和长期回归；更细 PMU 观测可能带来权限、性能和安全限制；面向一类 workload 的硬件特化可能伤害另一类。技术负责人要用覆盖率、收益上限和机会成本决定是否跨团队投入，而不是把所有热点都升级为架构项目。
5.4 AI 推理：将算子速度还原为端到端系统效率
接口与实现依据。 ONNX Runtime 将 profiling、threading、I/O binding、memory management、graph optimization 作为推理调优入口 [S14]；LiteRT 基准区分初始化、预热和稳态时间，可选择线程数和 GPU/XNNPACK delegate [S15]；TensorRT 提供端到端 benchmark 与 layer profiling 指导 [S16]。这些接口使 CPU 性能工程师能从算子 kernel 进入图划分、后端选择、内存复制、线程/亲和性和模型服务并发的联动优化。
失效边界。 单算子 GFLOPS 并不等于业务 token/s 或请求 P99；动态 shape、batch、KV cache、量化精度、host-device 传输和排队会改变结论；端侧还受温度与功耗策略影响。只替换一个 EP/delegate 而不测精度、fallback 和端到端延迟，容易造成“局部最快、整体更慢”。
验证条件。 报告需同时给出模型、版本、shape/sequence 分布、batch/并发、精度校验、初始化/预热/稳态、吞吐/P50/P99、内存和能耗；对多后端路径，收集 fallback 比例与复制/同步时间；对线上负载，保留过载和长尾场景。只有满足这些验证条件，AI 推理优化才可以进入发布门禁。
成本与权衡。 专用 delegate、量化和 kernel fusion 可能增加模型转换、可调试性、精度风险与维护矩阵；扩大 batch 改善吞吐但损害尾延迟；增加线程可能抢占同机服务。负责人必须同时回答“快多少、在哪些 shape 快、牺牲什么、如何检测回退”。
6. 演进方向与情景
图 2 给出了能力成长的责任边界。L1 到 L2 的本质是从“会使用工具”到“能根据多源证据修改系统”；L2 到 L3 的本质是从“优化别人给的 case”到“自己定义 workload、SLO 和回归门禁”；L3 到 L4 的本质是让软件代表性负载参与硬件、编译器和平台的联合决策。后两级不要求个人替代所有专家，而要求建立共用的事实基础、接口和决策节奏。
图 2：从性能工程师到软硬件协同负责人的能力路线。来源：根据岗位职责样本及各平台的测量、代码生成和验证接口综合绘制；等级表示责任范围，不与职级或工作年限一一对应 [S01][S02][S05][S07][S08][S14]。
6.1 三条可迁移的职业路线
| 路线 | 典型起点 | 关键迁移 | 技术负责人的决策对象 | 最应补齐的短板 |
|---|---|---|---|---|
| Android → 平台性能 | App/Framework/Native 性能 | 交互旅程 → 系统调度、ART/NDK、功耗 | 端侧体验 SLO 与设备矩阵 | Linux 调度、PMU、编译代码与功耗实验 |
| Linux/JVM → 云性能 | 服务端、JVM、基础设施 | 单服务 → 多租户/NUMA/网络/成本 | 吞吐、P99、TCO 和容量规划 | workload 生成、内核/驱动、通信与硬件拓扑 |
| AI 推理 → 软硬协同 | 模型部署、推理框架或 kernel | 单模型 → 图、EP、内存、芯片特性 | token/s、P99、精度、能耗与后端策略 | 编译器 IR、PMU、模型/系统联合 profiling |
6.2 2026—2028 的条件式判断
| 情景 | 触发条件 | 岗位需求可能变化 | 个人优先动作 | 可信度 |
|---|---|---|---|---|
| 端侧 agent 扩张 | 本地模型、多模态和功耗约束成为产品差异 | 端侧 ML、runtime、compiler 与系统性能更融合 | 做一个可复现端侧推理/交互 workload | 【S】[S01][S15] |
| 推理成本成为核心 KPI | 模型服务规模扩大、单位 token 成本受关注 | inference performance 与系统/通信职责交叠 | 学会 profile graph、线程、内存与多机通信 | 【S】[S02][S14][S16] |
| CPU 平台异构化 | 多 ISA、大小核、加速器与 SoC 事件更复杂 | PMU、编译器模型和系统调度人才更稀缺 | 建立跨硬件的实验协议而非固化参数 | 【S】[S08][S09][S17] |
| 质量前移 | 性能退化造成线上成本或体验事故 | 招聘更看重 CI、benchmark governance 和 observability | 把一个项目做成可自动回归的门禁 | 【P】 |
7. 建议与验收
7.1 个人 12—36 个月行动计划
第一阶段（0—6 个月）选择一个可公开或可脱敏的 workload，把“慢”定义成业务指标：例如 Android 冷启动+首屏、JVM JSON 服务 P99、ONNX Runtime 单模型吞吐/内存或 Linux 存储链路。用两类观测工具建立基线，并写出实验协议。第二阶段（6—18 个月）至少做一次跨层优化：从 trace/PMU 找到热点，读取反汇编或运行时事件，修改实现/编译/配置后以端到端指标验证，同时加入回归。第三阶段（18—36 个月）把单点项目升格为 workload suite、看板与门禁，并推动一次与芯片、编译器、框架或容量团队的联合评审。这个阶段的目标不是“懂完所有硬件”，而是能让不同专家围绕同一证据决策。
候选人材料应写成“约束—证据—决策—结果—边界”五段式：业务 SLO 与环境约束是什么；用哪些 trace/PMU/profile 定位；比较过哪些方案；收益在 P50/P99/能耗/成本中如何体现；在哪些硬件、输入或版本下不成立。这样比“熟练 perf/LLVM/Android”更能对齐高阶岗位。面试中，应主动说明验证设计如何避免频率漂移、JIT 预热、缓存污染、热节流、统计波动和精度退化。
主张—证据矩阵
| 主张 | 直接证据 | 反例/边界 | 结论等级 |
|---|---|---|---|
| 端侧 AI 性能职位要求模型、工具、编译栈与硬件协同 | Apple 岗位写明 inference、analysis tools、Python/C++、MLIR/LLVM [S01] | 这是一个岗位样本，不能外推为全部端侧团队标准 | 【C】 |
| AI/HPC 性能职位把 workload profiling 作为职责 | NVIDIA 样本写明 AI/HPC workload profiling 与瓶颈分析 [S02] | 不代表所有性能团队都要求 RDMA/NCCL | 【C】 |
| 代码生成与真实 workload 必须联验 | LLVM MCA 是静态模型；NDK PGO、Perfetto/Simpleperf 和推理基准提供动态验证接口 [S05][S06][S07][S11][S16] | 静态分析不能替代真实系统实验 | 【C*】 |
| 国内岗位需求应以能力交集而非职位数理解 | 官方招聘详情页动态加载，无法稳定获取完整正文 [S03][S04] | 需要补充人工投递和长期快照才能做定量结论 | 【S】 |
7.2 团队/技术负责人机制建议
- 建立 workload contract：每条关键链路都记录输入、并发、SLO、正确性、硬件与版本，禁止只保存一个平均分数。
- 建立 证据金字塔：端到端 SLO 为顶，trace/PMU/profile 为中，IR/汇编/静态模型为底；结论至少跨两层相互支持。
- 将 性能回归前移：release/CI 中固定一组标准 workload，超阈值时保存 trace、编译产物、系统配置和可回放命令。
- 建立 软硬协同评审：当某类 bottleneck 连续出现时，由 workload owner 提供数据分布、架构/编译/内核团队给出可选机制与 PPA/维护代价，再做跨代决定。
建议—验收矩阵
| 建议 | 90 天可交付物 | 验收条件 | 验证手段 | 优先级 |
|---|---|---|---|---|
| 固化一个代表性 workload | README、输入集、环境锁定和基线 | 他人可在目标环境复跑，关键 SLO 偏差可解释 | 自动脚本+原始结果归档 | P0 |
| 做一次跨层归因 | trace/PMU/profile 与热点代码链接 | 至少两类证据指向同一瓶颈 | Perfetto/Simpleperf/JFR/推理 profiler + 反汇编 | P0 |
| 完成一项端到端优化 | 补丁、前后指标、正确性报告 | P50/P99/内存或功耗中至少一项改善，未越过约束 | 固定 workload、多次运行、统计与回归 | P0 |
| 建立性能门禁 | CI job、阈值、失败产物 | 人为注入退化后能阻断并定位 | baseline diff + trace/profile 链接 | P1 |
| 参与一次软硬联合评审 | workload 说明、瓶颈假设、设计取舍 | 形成有 owner、可验证指标和回退策略的决议 | 评审记录+实验计划+跨版本跟踪 | P1 |
8. 不确定性与研究限制
- 本报告不是职位数量普查。公开职位会滚动、按地区展示，且国内官方页常以动态 API 加载；因此“趋势”是样本与技术栈的定性归纳，不应解释为真实招聘量排名。
- Apple 和 NVIDIA 样本能直接支持各自岗位的职责/要求，不能证明其他公司或其他职级具有同样要求 [S01][S02]。
- 工具文档说明“可以怎样做”，不等于某招聘公司“正在使用该工具”。本文以其说明能力可迁移性，而不是推断组织内部实现 [S05]—[S17]。
- PMU 事件、频率策略、热设计、固件、驱动和运行时版本均会影响结论。所有案例须附机器和软件版本；跨架构结论应复测，不能由单机结果直接外推。
- 对国内职责的精确判断需要持续保存官方职位快照，并辅以合规的候选人访谈或公开技术分享；本报告明确将本次无法静态核验的岗位正文标为【?】。
参考来源
- [S01] Apple Jobs，On-device ML Performance Engineer, Graphics, Games and Machine Learning，岗位页（访问于 2026-09-08）：https://jobs.apple.com/en-us/details/200680832-0836/on-device-ml-performance-engineer-graphics-games-and-machine-learning?team=SFTWR
- [S02] NVIDIA Careers，Senior Performance Engineer，岗位页（访问于 2026-09-08）：https://jobs.nvidia.com/careers/job/893396516909?domain=nvidia.com
- [S03] 华为招聘，社会招聘职位详情入口（动态加载限制，访问于 2026-09-08）：https://career.huawei.com/reccampportal/portal5/social-recruitment-detail.html?dataSource=1&jobId=32181
- [S04] 阿里巴巴校园招聘，AI 编译研发工程师职位入口（动态加载限制，访问于 2026-09-08）：https://campus-talent.alibaba.com/campus/position/199904140017?deptCodes=
- [S05] Android Open Source Project，Simpleperf Introduction：https://android.googlesource.com/platform/prebuilts/simpleperf/+/782cdf2ea6e33f2414b53884742d59fe11f01ebe/README.md
- [S06] Perfetto，What is Perfetto?：https://perfetto.dev/docs/
- [S07] LLVM，llvm-mca - LLVM Machine Code Analyzer：https://llvm.org/docs/CommandGuide/llvm-mca.html
- [S08] Intel，Top-down Microarchitecture Analysis Method：https://www.intel.com/content/www/us/en/docs/vtune-profiler/cookbook/2024-1/top-down-microarchitecture-analysis-method.html
- [S09] Arm Developer，Streamline Performance Analyzer：https://developer.arm.com/dev2/tools-and-software/streamline-performance-analyzer
- [S10] Android Developers，Baseline Profiles overview：https://developer.android.com/topic/performance/baselineprofiles/overview
- [S11] Android Developers，Profile-guided Optimization - NDK：https://developer.android.com/ndk/guides/pgo
- [S12] OpenJDK，Code Tools: jmh：https://openjdk.org/projects/code-tools/jmh/
- [S13] OpenJDK，JEP 509: JFR CPU-Time Profiling (Experimental)：https://openjdk.org/jeps/509
- [S14] ONNX Runtime，Tune performance：https://onnxruntime.ai/docs/performance/tune-performance/
- [S15] Google AI Edge，LiteRT performance measurement：https://developers.google.com/edge/litert/performance/measurement
- [S16] NVIDIA Documentation，TensorRT Performance Benchmarking：https://docs.nvidia.com/deeplearning/tensorrt/latest/performance/benchmarking.html
- [S17] Linux Kernel Documentation，Alibaba's T-Head SoC Uncore Performance Monitoring Unit：https://docs.kernel.org/admin-guide/perf/alibaba_pmu.html
- [S18] NVIDIA Careers，Senior Performance Compiler Engineer – Triton：https://jobs.nvidia.com/careers/job/893395059432
- [S19] NVIDIA Careers，Senior CPU Compiler Performance Engineer：https://jobs.nvidia.com/careers/job/893396382149
- [S20] AMD Careers，AI Performance Modeling Engineer：https://careers.amd.com/careers-home/jobs/84934?lang=en-us
- [S21] AMD Careers，Principal Compiler Software Development Engineer – AI/ML：https://careers.amd.com/careers-home/jobs/89589?lang=en-us
- [S22] Arm Careers，Staff Software Engineer — Runtimes Performance：https://careers.arm.com/job/cambridge/staff-software-engineer-runtimes-performance/33099/97551975872
- [S23] Arm Careers，CPU Performance – Principal Microarchitecture Exploration Engineer：https://careers.arm.com/job/austin/cpu-performance-principal-microarchitecture-exploration-engineer/33099/92102976272
- [S24] Intel Careers，AI Performance Library Architect：https://intel.wd1.myworkdayjobs.com/en-US/External/job/AI-Performance-Library-Architect_JR0281978-1
- [S25] Apple Jobs，Systems Performance Architect：https://jobs.apple.com/en-us/details/200667941-0836/systems-performance-architect?team=HRDWR
- [S26] Meta Careers，Systems ML: Compilers / Backend：https://www.metacareers.com/profile/job_details/1974850966499630/
- [S27] Meta Careers，Graph Compiler Performance Optimization：https://www.metacareers.com/profile/job_details/913805691774438/
- [S28] Meta Careers，AI Kernels & Performance Optimization (MTIA)：https://www.metacareers.com/profile/job_details/1477723764162264/
- [S29] Meta Careers，MTIA Software Tooling：https://www.metacareers.com/profile/job_details/1504555875026789/
- [S30] Amazon Jobs，Machine Learning Compiler Engineer, AWS Neuron：https://www.amazon.jobs/en/jobs/3119465/machine-learning-compiler-engineer-aws-neuron-annapurna-labs
- [S31] Amazon Jobs，Sr. Machine Learning Compiler Engineer III, AWS Neuron：https://www.amazon.jobs/en/jobs/3168926/sr-machine-learning-compiler-engineer-iii-aws-neuron-annapurna-labs
- [S32] Amazon Jobs，Sr. Software Development Engineer, Inference Team – AWS Neuron：https://www.amazon.jobs/en/jobs/10503981/sr-software-development-engineer-inference-team-aws-neuron
- [S33] Amazon Jobs，Software Development Manager, Compiler：https://www.amazon.jobs/en/jobs/3174232/software-development-manager-compiler
- [S34] Microsoft AI，Member of Technical Staff, Inference Systems Research：https://microsoft.ai/careers/job/4391028009/inference-systems-research/
- [S35] 百度校园招聘，北京-底层软硬件研发工程师 J100720，官方职位列表（访问于 2026-09-08）：https://talent.baidu.com/jobs/list
- [S36] 小米招聘，Android Framework 系统工程师：https://hr.xiaomi.com/job/view/576
- [S37] 小米招聘，Android 内核和驱动开发工程师-小米电视：https://hr.xiaomi.com/job/view/96
- [S38] 小米招聘，显示驱动工程师：https://hr.xiaomi.com/job/view/596
- [S39] 字节跳动招聘，Android 高级/资深研发工程师（性能优化方向），动态页面，仅作方向存在性证据：https://jobs.bytedance.com/experienced/position/7164713026280442143/detail
- [S40] 腾讯招聘，大模型推理性能优化工程师/专家，动态页面，仅作方向存在性证据：https://careers.tencent.com/jobdesc.html?postId=2072330940650270720
- [S41] 阿里巴巴校园招聘，编译器与计算机体系结构开发工程师（RISC-V 方向），动态页面，仅作方向存在性证据：https://campus-talent.alibaba.com/campus/position/199908500002
- [S42] 平头哥招聘，CPU 编译技术 leader，动态页面，仅作方向存在性证据：https://recruitment.t-head.cn/off-campus/position-detail?positionId=7000015504
- [S43] 摩尔线程招聘，GPU 编译器工程师，动态页面，仅作方向存在性证据：https://mthreads.zhiye.com/social/detail?jobAdId=71aa5182-a911-4bf5-be74-2a897de92986
附录：研究方法
样本筛选。 仅引用公司官方招聘页、上游/官方技术文档和官方开源项目页面；搜索结果中的聚合站、论坛与不明转载不进入证据台账。每个岗位页面记录访问时间，并标记静态内容是否可读取。职位详情由客户端接口加载时，仅记录“入口存在”，不从标题猜测具体职责。
趋势判定。 先将直接岗位描述拆为 workload、测量/工具、编译/运行时、硬件/架构、交付与协作六类，再与平台官方文档的可实现接口交叉。只有跨样本的方向性结论标为【S】；没有做职位数量、薪酬、地域和时间序列统计。
复现实验模板。 对任何候选优化，至少保存：代码 commit、构建参数、OS/内核/驱动、CPU/加速器型号、频率/功耗策略、输入集 checksum、并发与随机种子、预热策略、原始 trace/profile、统计脚本、正确性结果与回退条件。该模板既是个人作品集的可信度基础，也是团队性能门禁的最小记录。