模型部署手册

外观

简历怎么写：部署工程师能力对标

本页速览 部署工程师的简历最该突出什么？本文给出项目经验 STAR 写法、量化成果公式（延迟/QPS/成本/可用性）、关键词命中的策略，以及部署方向作品集项目的做法与反面教材。

简历怎么写：部署工程师能力对标 ​

部署岗位的简历有一个通病：动词一堆，数字没有。「负责模型部署、熟悉 K8s、做过性能优化」——HR 看完只能记住「这个人好像用过这些工具」，却不知道你解决过多难的问题、带来了多大收益。

本页给你一套可直接套用的方法：面试官怎么看简历 → 量化成果公式 → STAR 项目写法 → 作品集怎么做 → 反面教材避雷 → 自查清单。

先想清楚一件事

简历不是「我学过什么」的流水账，而是「我能解决什么、解决了多难的问题」的证据链。每一行都要回答：你做了什么 → 做得有多好 → 怎么证明。

一、HR 与面试官看简历的顺序 ​

阶段看什么停留时间简历对应策略
HR 初筛（关键词扫描）技能词是否命中 JD：K8s、TensorRT、vLLM、量化…10-20 秒技能词与 JD 对齐，放显眼位置
技术面试官粗读量化成果、项目深度、责任边界1-3 分钟每条经历带数字与结论
面试追问准备挑 2-3 个项目做深挖30 分钟+每个项目都能讲满 10 分钟
最终对比稀缺性、与岗位匹配度——突出「别人没有的」：如端侧量化落地、大规模集群经验

结论：关键词决定你能不能过初筛，量化成果决定你进不进面，项目深度决定你能不能过技术面。 三层都要有。

关键词 ≠ 堆名词

把「熟悉 Python、熟悉 C++、熟悉 Java、熟悉 Go」排成四行，在 HR 眼里等于「都没深入」。关键词只写「用过且能扛住追问」的，命中策略见第五节。

二、量化成果公式与案例 ​

公式 ​

text
[动词/改进] + [具体指标 A→B] + [相对变化 %] + [影响面/资源]

四个可量化的维度（部署岗位最值钱的四个数字）：

维度典型指标示例写法
延迟P50/P99/TTFT/TPOTP99 延迟从 120ms 降至 45ms（-62%）
吞吐QPS、并发、batch 效率支撑 QPS 从 500 提升到 2000（4×）
成本GPU 卡数、显存、带宽、电费GPU 成本降低 40%，从 5 卡降到 3 卡
可用性SLO、故障时长、自动恢复可用性从 99.9% 提升到 99.99%，MTTR < 10 分钟

反面 → 正面对照 ​

反面（平庸）正面（量化）差在哪
做了推理服务优化将 P99 延迟从 120ms 降至 45ms（-62%），支撑 QPS 从 500 提升到 2000有数字、有变化、有量级
熟悉 K8s基于 K8s 搭建 GPU 推理平台，管理 32 卡、支撑 8 个模型灰度上线有规模、有边界
做过量化通过 INT8 PTQ 将模型体积从 4.5GB 降至 1.2GB，精度损失 <1%，推理提速 2.3×有方法、有验收、有效果
会压测用 Locust/wrk 完成 2000 QPS 压测，定位并修复连接池瓶颈有工具、有结果、有动作

数字从哪来？

压测和监控就是你的「取证工具」：跑一次 压测 拿到 QPS/延迟基线，从 监控 里导出优化前后的指标对比。做过项目但没有数字？补一次基准测试就有了，这也是 作品集 的核心产出。

三、STAR 项目写法（四段式模板） ​

每个项目用 背景（Situation）→ 任务（Task）→ 行动（Action）→ 结果（Result） 四段式，控制在 4-6 行：

text
【项目】XX 电商推荐模型推理服务优化（2024.03 - 2024.06）
S: 双 11 大促前，推荐模型 P99 延迟 200ms，GPU 集群水位 85%，面临扩容成本压力。
T: 在不增卡的前提下，将 P99 压到 120ms 以内，并留出 30% 扩容水位。
A: ① 用 torch.profiler 定位瓶颈为动态 shape 导致的 kernel 反复编译；
   ② 引入固定 batch + TensorRT 引擎，支持动态批处理（max_batch 64, 8ms 窗口）；
   ③ 搭建 Prometheus 监控看板，量化上线前后指标。
R: P99 从 200ms 降至 85ms（-57%），QPS 提升 2.6×，无需新增 GPU，节省年成本约 XX 万元。

四段式写作要点：

段落常见错误正确做法
S/T从「我用了 XX 技术」开始先说业务问题与约束（大促、成本、水位）
A列一堆工具名写决策链：为什么选 A 不选 B（如「对比 vLLM 与 Triton 后选择…」）
R写「完成上线」写指标变化 + 影响面（降本/保可用性）

STAR 与本站案例的结构同构

本站 案例研究 每一篇都是「问题→选型→方案→效果」结构，和 STAR 完全一致。写简历前先精读 2-3 个案例，你能直接借用它的分析框架和专业表达。

四、项目选择：作品集怎么做 ​

该做什么 ​

  • 一个端到端可验证的项目，产出真实的数字：见 动手构建你的第一个推理服务
  • 优先级建议：
    1. 一个推理服务 + 压测（覆盖服务化与性能）——通用性最高
    2. 一个量化/转换链路（PTH→ONNX→INT8/TensorRT）——区分度高
    3. 一个 LLM serving（用 vLLM 部署并压测）——LLM 岗必备，见 vLLM 案例
  • 项目贴到 GitHub 并写 README：架构图、压测命令、结论数据。面试时直接把链接甩给面试官。

反面教材 ​

反面做法为什么是坑
复制官方 demo，只改了个端口面试官一问细节就穿帮，还浪费了展示机会
项目没有 README 和数据面试官想验证时看不到任何证据
同时塞 5 个项目每个都浅，不如一个「从问题到数字」的完整故事
只做「跟着教程跑通」没有自己的决策与取舍，无法回答「为什么这样做」

作品集要能扛压测

面试官会追问「你的 QPS 是怎么测的？工具？压测时长？机器配置？」。README 里把这些写清楚，等于给面试官递了追问提纲，你答起来也从容。参考本站 压测方法 的规范。

五、常见反面教材（简历雷区） ​

#反面写法问题修改方向
1「熟悉 K8s、熟悉 Docker、熟悉 Linux」无场景、无深度写成「基于 K8s 搭建 XX，管理 XX 卡」
2「负责模型部署上线」无动词指向、无责任边界「主导 / 负责 / 参与」要分清，配合数字
3堆砌名词：Docker/K8s/TensorRT/vLLM/MLflow 一行全列HR 无从判断按「部署工具链→领域知识→系统基础」分层，标熟练度
4只写项目名，不写你在其中的角色无法评估个人贡献STAR 里写「我负责 X，产出了 Y」
5技能和 JD 关键词对不上过不了初筛逐条对齐目标岗位 JD，见 JD 清单

六、技能清单怎么排 ​

推荐三层的「金字塔」排法，从上到下由具体到通用：

层级内容示例
① 部署工具链（最前）与岗位直接相关的引擎/平台ONNX Runtime、TensorRT、Triton、vLLM、KServe
② 领域知识方法论与理论量化（PTQ/QAT）、性能调优、容量规划、动态批处理
③ 系统基础通用能力Linux、Docker、K8s、Python、监控（Prometheus/Grafana）

配套原则：

  • 熟练度标注：只会「用过」就别写「精通」，写「熟练」「了解」都行，但必须扛得住追问。
  • 每层挑 3-5 项：写满一行就是无效信息。
  • LLM 岗额外加一行：KV Cache、连续批处理、张量并行——这些词单独列出会显著提升命中率，对应知识见 LLM 推理。

七、简历自查清单 ​

投递前逐项打勾：

  • [ ] 技能关键词与目标岗位 JD 对齐（对照 JD 清单）
  • [ ] 每个项目都有 ≥2 个数字（延迟/吞吐/成本/可用性四选二）
  • [ ] 每个项目都能用 STAR 讲满 10 分钟
  • [ ] 没有「熟悉 XX」的裸词，全部带场景
  • [ ] 作品集有 GitHub 链接，README 含压测数据与命令
  • [ ] 技能清单按「工具链→领域知识→系统基础」分层，每层 ≤5 项
  • [ ] 全简历没有一句「我学过」式描述
  • [ ] 针对目标公司做了定制版本（至少改关键词顺序与项目排序）

最后一问

面试官可能会问「简历上哪个项目你最自豪？」——如果你答不上来，说明 ST 写得太泛、R 写得太虚。改到能毫不犹豫答出来再投。

延伸阅读 ​