能力对标：简历该突出什么

一句话定义：推理部署岗的简历不是你的经历清单，而是一份"证据链"——用一段段可验证的事实，向面试官证明"我能把这个岗位要求的能力交付出来"。简历的本质是说服，不是罗列。

把一份推理部署岗的简历想象成性能测试报告：面试官（评审）只相信有数据支持的陈述。你说"我精通 vLLM"——证据呢？你说"我有大规模推理经验"——证据呢？你说"我能优化性能"——证据呢？没有数据的声称，在 HR 眼里约等于没写；而一份证据充分、每个项目都带"延迟从 X 降到 Y、吞吐从 A 升到 B、GPU 利用率从 C 到 D"的简历，能让面试官在见到你本人之前就默认你合格了一半。

本文是 career 模块的第三站：前两站JD 清单告诉你"市场上在招什么"，能力地图告诉你"你会什么、不会什么"，本页负责把两者的差拍合成一份简历——用面试官的眼光重写你已有的经历，而不是从头编造。写作全程用"数据 + 源码 + 复盘"说话，请先建立一个残酷的设定：面试官默认你简历上的一切都可能是假的，你要做的是让每一条都经得起追问。

一、推理部署岗简历的"三要素"

推理部署岗的简历与算法岗最大的差异在于：算法岗讲 AUC / 准确率，部署岗讲延迟 / 吞吐 / 成本。三要素按权重排序：

┌─────────────────────────────────────────────────────┐
│ 要素一  性能数据（最高权重）                          │
│         延迟从 X ms 降到 Y ms                         │
│         吞吐从 A token/s 升到 B token/s               │
│         GPU 利用率从 C% 提升到 D%                      │
│         成本节省 E% / 月节省 F 万美元                  │
└─────────────────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────────────┐
│ 要素二  系统理解（中等权重）                          │
│         能讲清 vLLM 的 Scheduler / KV cache / batching│
│         能定位 Nsight 报告里的瓶颈                    │
│         能解释 TP / PP / EP 的通信代价                │
└─────────────────────────────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────────────┐
│ 要素三  工程能力（基础权重）                          │
│         Python / C++ / Linux / K8s 实战               │
│         CI / CD / 监控 / 灰度                         │
│         与团队协作、与算法团队对接                    │
└─────────────────────────────────────────────────────┘

三要素缺一不可

只讲性能数据不讲系统理解 → 像运维，不懂为什么； 只讲系统理解不讲性能数据 → 像 PPT 工程师，没真做过； 只讲工程能力不讲性能数据 → 像 SRE，没碰过推理本身。 三要素齐备的简历才是"推理部署工程师"的简历，否则只是其中一面的偏科生。

1. 三个"简历神话"和它们的反面

神话	真相
简历写得越满越好，能填的都填上	信息密度不等于证据密度；每多一行噪音，就稀释一行证据
把做过的每件事都列一遍，总有一项打动 HR	打动 HR 的不是"你做过"，而是"你做到了什么、做得多好"
技能堆得越全越安全	堆名词经不起追问；一个"精通 vLLM 源码"被问穿，全页可信度崩塌

把"做过的事情"翻译成"做到的结果"，是整份简历唯一的核心动作。做不到这个翻译，简历就只是"经历流水账"——HR 每天读一百份流水账，多你一份不多。

2. 证据链模型：JD 要求 → 能力项 → 证据

一个合格的求职者与一份合格简历之间的关系是这样的：

┌────────────────────────────────────────────────────────────┐
│  岗位要求（JD）                                              │
│  例：熟悉 vLLM 或 TensorRT-LLM，有大规模推理服务部署经验     │
└─────────────────────────┬──────────────────────────────────┘
                          │ 拆解
                          ▼
┌────────────────────────────────────────────────────────────┐
│  能力项（可以被"会/不会"检验的单元）                        │
│  ① vLLM 源码级理解（Scheduler / PagedAttention / KV cache）│
│  ② 大规模部署经验（多副本、灰度、监控告警）                  │
│  ③ 性能调优经验（量化、batching、spec decoding）           │
└─────────────────────────┬──────────────────────────────────┘
                          │ 逐项配对
                          ▼
┌────────────────────────────────────────────────────────────┐
│  证据（简历上的每一条，都可被当场验证）                      │
│  项目：内部 LLM 服务从 vLLM 0.5 升级到 0.8 + chunked        │
│        prefill，TTFT 从 1.8s 降到 0.6s，吞吐 +120%         │
│  开源：为 vLLM 贡献 3 个 PR（block_table 索引优化）         │
│  博客：写了一篇 PagedAttention 原理拆解，2000+ 阅读         │
└────────────────────────────────────────────────────────────┘

一条证据的标准形态是**"我做了什么 + 怎么做 + 做到了什么程度"**，而不是"我做过什么"。这三者缺一则证据不完整：只说"我用过 vLLM"，面试官无法判断你的深度；只说"TTFT 降了 70%"，面试官无法判断这是不是你调参调出来的。

3. 面试官读简历，实际在检索三样东西

• 硬技能证据：你的"vLLM / CUDA / 量化"是"用过"还是"会"还是"精通"？讲得出 PagedAttention 的 block table 长什么样吗？——这决定你能不能过技术初筛。
• 交付证据：你有没有把一个推理服务从头做到尾、拿到可量化的结果？——这决定面试时项目深挖有没有料。
• 自省证据：你讲不讲得清失败与取舍？踩过什么坑？——这决定你值不值得长期培养。

证据的三条硬性标准

①可验证：面试官随手一查能确认（GitHub 仓库在、PR 在、benchmark 报告在、博客在）；②可量化：能用数字表达的都别用形容词；③可追问：每一个数字背后，你都能讲出三句话以上的细节。满足不了其中任何一条的"证据"，都先降级为"经历"，再考虑要不要写。

二、JD 能力对标法：把岗位要求拆成证据清单

岗位差异极大，但方法只有一套：把 JD 的每条要求拆成能力项，再为每个能力项找到至少一条证据。找不到证据的能力项，要么补（做项目、改 PR、写博客），要么放弃投这个岗位——而不是硬写。

1. 拆解示范：一份真实的推理引擎工程师 JD

假设目标 JD 的任职要求是这样的（已做脱敏简化）：

任职要求：①本科及以上学历，计算机/电子/自动化相关专业；②熟练掌握 Python 与 C++，熟悉 Linux 环境；③深入理解 PyTorch 内部机制，有 vLLM / TensorRT-LLM / SGLang 任一推理引擎源码阅读经验；④有大规模 LLM 推理服务部署经验优先；⑤熟悉 GPU 性能分析（Nsight / PyTorch Profiler），有 CUDA / Triton 算子经验加分；⑥良好的沟通协作能力。

拆解结果：

JD 要求	能力项	证据从哪来
② Python / C++ / Linux	工程级代码能力	项目里的代码量、CI/CD 配置、性能分析案例
③ PyTorch 内部 + 引擎源码	vLLM 源码阅读 + 改造	开源 PR、内部 fork patch、技术博客
① 专业背景	科班出身	学历栏（如实写）
④ 大规模部署	服务化能力	项目里的多副本部署、灰度发布、监控告警
⑤ 性能分析 / 算子	CUDA / Nsight 实战	项目里的延迟优化案例、kernel 改写
⑥ 沟通协作	与算法团队对接	项目角色描述、跨团队案例

2. 证据的四种来源，信任度从高到低

证据来源	举例	信任度	备注
实习/工作	公司项目、上线效果、SLO 数据	★★★★★	最硬，但可遇不可求
作品集项目	端到端项目，有仓库、有 README、有 benchmark	★★★★	完全可控，必做；怎么做见作品集项目
开源贡献	vLLM / SGLang / TensorRT-LLM 的 PR	★★★★★	推理部署岗最硬的"加分项"，可查证
论文 / 博客	技术博客、arXiv 论文	★★★★	体现深度，但要写得好
课程 / 证书	在线课程、认证证书	★★☆	只能证明学习意愿，不能单独作数

别把"学习过程"当证据

"2025 年在 Coursera 完成《LLM 推理优化》课程"这种条目，写出来等于告诉面试官"我没有实战经验"。课程是打地基用的，不是简历素材；简历素材必须是你产出过的东西。课程背景可以放进"教育经历"的补充说明，但绝不能占据项目的位置。

推理部署岗的特殊加分通道：

• 开源 PR 是最硬证据：给 vLLM / SGLang / TensorRT-LLM / llama.cpp 贡献 PR，是面试官一键 GitHub 就能验证的"硬通货"。一个合并的 PR 比五个项目经历都值钱。
• 技术博客比课程证书有效：写一篇"PagedAttention 原理拆解 + 实测对比"，发表在知乎 / Medium / 个人博客，既有深度又可验证。
• benchmark 报告比简历自评有效：发一份"vLLM vs TensorRT-LLM 在 Llama-70B 上的对比 benchmark"，附 GitHub 仓库与可复现代码，比简历里写"精通 vLLM"强一百倍。

3. 实操步骤：一份 JD 十分钟拆完

1. 把 JD 中所有动词短语圈出来（"熟悉""掌握""有……经验""了解"），逐条转成能力项。
2. 用能力地图对自己逐项打分：会 / 半会不会 / 不会。
3. 为每个"会"的能力项找到对应证据；"半会不会"的决定是否在投递前补；"不会"的不要硬写。
4. 对照结果判断人岗匹配度：匹配度低于 60% 的岗位，除非是学习型岗位，否则投入产出比很低。
5. 把拆解结果存成文件，每次投递前按目标 JD 重新过一遍——这就是"按 JD 微调简历"的原料（见第八节）。

三、项目经历的写法：STAR 法推理部署版

项目经历是简历的承重墙。写法的总原则一句话：用 STAR 结构，把"做了什么"升级成"在什么情境下、为了解决什么问题、采取了什么行动、拿到了什么可量化的性能数据"。

1. STAR 的推理部署版改造

经典 STAR 四要素：情境（Situation）、任务（Task）、行动（Action）、结果（Result）。在推理部署语境下，四个要素各对应一个必须回答的技术问题：

要素	通用问题	推理部署版必须回答	反面示例
S 情境	背景是什么？	业务场景、模型规模、硬件、QPS、约束	"我做过 LLM 部署"
T 任务	你要解决什么？	优化什么指标？TTFT / TPOT / 吞吐 / 成本？基线是谁？	"部署 Llama"
A 行动	你具体做了什么？	引擎选型、调参、改源码、写 kernel，为什么这么选，踩了什么坑	"用了 vLLM"
R 结果	结果如何？	性能指标 + 业务指标，注明对比基线	"效果不错"

注意行动项里的两个关键词："为什么这么选" 和 "踩了什么坑"。前者证明你有判断力而非只会调参，后者证明你真的做过——没做过的人编不出真实的坑。

2. 性能数据的"四类指标"

推理部署岗的性能指标按层次分四类，简历里至少要写两类：

层次	定义	例子	常见错误
延迟指标	单请求响应快慢	TTFT、TPOT、E2E latency、P50/P99	只给平均值不给 P99
吞吐指标	系统级产出	QPS、token/s、RPS	不注明 batch size 与 seq_len
资源指标	硬件利用	GPU 利用率、显存占用、HBM 带宽利用率	不给基线对比
业务指标	业务受益	成本节省、可用性、灰度成功率	完全没写，暴露"没有业务感"

写法上注意四点：

1. 永远带对比基线："TTFT 600ms"没有信息量，"TTFT 从 1.8s 降到 600ms（vLLM 0.5 → 0.8 + chunked prefill）"才有——对比对象可以是旧版本、另一引擎、或团队此前的指标。
2. 延迟与吞吐要能自洽：讲"1000 QPS"却不讲"延迟是多少 P99"，可信度大打折扣；高 QPS 通常以延迟换吞吐，要写清两者的取舍点。
3. 诚实标注口径：离线 benchmark、单卡实测、线上 A/B、全量上线，口径不同数字不可比，写清楚。
4. 数字要经得起除法和追问：写"延迟降了 80%"前先想清楚是相对谁——面试官一定会问。

四、典型项目经历重写范例（6 个）

下面给 6 个推理部署岗典型项目的 STAR 重写范例。每个范例都按"❌ 普通写法 → ✅ 好写法"对照，最后给"可追问点"——这些追问点是你面试时被深挖的入口，必须自己想清楚。

范例 1：LLM 推理服务上线

❌ 普通写法（流水账，三句都在说"做了什么"）：

基于 vLLM 部署 Llama-3-8B 推理服务 使用 Python 和 FastAPI 封装 API，部署到 K8s 集群。配置了 PagedAttention 和 continuous batching，服务稳定运行。

✅ 好写法（证据链，四要素齐全）：

Llama-3-8B 推理服务上线 —— 内部文档智能助手后端

• 情境：内部 AI 助手日均 50 万调用，原 TGI 服务 P99 达 12s，业务侧投诉集中在"等回答等到超时"；硬件 4×A100 80G，K8s 集群 8 副本，预算固定。
• 任务：以"P99 < 3s、QPS > 200"为目标，迁移到 vLLM 0.8，支持流式输出与多模型共存。
• 行动：①对比 vLLM 0.8 / TGI / TensorRT-LLM 三引擎，在 8B 模型 + 2k context + batch=64 的负载下，vLLM 吞吐最高且 TTFT 最低；②开启 PagedAttention 与 chunked prefill，调整 max_num_batched_tokens=4096，重写 LLMEngine 的优先级调度策略，让 VIP 用户请求优先；③用 Nsight Systems 定位到 attention kernel 是瓶颈，切换到 FlashAttention-2 后 TTFT 再降 25%；④用 Helm + ArgoCD 部署，Prometheus + Grafana 打点 TTFT / TPOT / queue length 三大指标。
• 结果：P99 从 12s 降到 2.4s（-80%），QPS 从 80 升到 240（+200%），GPU 利用率从 35% 提升到 72%；服务上线后支持 8 个业务线接入，月度 GPU 成本节省 18 万元。

可追问点：①vLLM 0.8 vs TensorRT-LLM 你的选型依据？②chunked prefill 的 max_num_batched_tokens 你怎么调的？③FlashAttention-2 你测过 1 vs 2 vs 3 的差异吗？④你的优先级调度怎么实现的？

范例 2：INT8 量化落地

❌ 普通写法：

对 Llama-70B 模型做 INT8 量化，节省显存。使用 GPTQ 算法，校准数据集 128 条。模型大小从 140GB 降到 35GB。

✅ 好写法：

Llama-70B INT8 量化部署 —— 单卡推理落地

• 情境：业务需要单卡 H100 80G 跑 70B 模型，FP16 推理需 140GB 显存必须双卡 TP=2，硬件成本与跨卡通信开销都不可接受。
• 任务：用 INT8 weight-only 量化，让 70B 模型在单卡 H100 上跑通，且吞吐相对 FP16 不下降超过 15%、 perplexity 不上升超过 1%。
• 行动：①对比 GPTQ / AWQ / SmoothQuant 三种量化方案，在 Llama-70B + WikiText-2 上跑 perplexity 对比，AWQ 在 group_size=128 时 perplexity 上升最小（+0.4%）；②改 vLLM 的 AWQLinearMethod，支持 group-wise 量化，提了一个 PR（vllm-project/vllm#12345）合并到主线；③用 Nsight Compute 测 INT8 算子，发现 dequantize kernel 是瓶颈，写了一个 Triton fused gemm + dequant kernel，吞吐相对原版 +30%。
• 结果：模型权重从 140GB 降到 35GB（-75%），单卡 H100 可跑 70B；推理吞吐相对 FP16 双卡 TP=2 提升 8%（无跨卡通信开销），相对 FP16 单卡 OOM 之前从"跑不起来"到"跑得动"；perplexity 上升 0.4%，业务侧盲测无感知差异。

可追问点：①GPTQ 与 AWQ 的机制差异？②为什么 LLM 主推 weight-only 而非 weight+activation？③你的 Triton fused kernel 怎么写的？④group_size 怎么选的？

范例 3：大规模推理服务扩容

❌ 普通写法：

负责推理服务扩容，从 4 副本扩到 16 副本，支持高峰流量。用 K8s HPA 自动扩缩容。

✅ 好写法：

LLM 推理服务扩容与 SLO 保障 —— 双 11 大促推理保障

• 情境：双 11 期间推理 QPS 预估峰值 4 倍于日常，原 8 副本 K8s 部署满负载时 GPU 利用率 95%、P99 飙到 8s；扩容预算上限 16 副本，硬件 A100 80G，硬件采购周期 6 周不可短期补货。
• 任务：用现有 16 副本承载峰值 1000 QPS、保持 P99 < 2s、零 P0 故障。
• 行动：①用 vLLM --gpu-memory-utilization=0.92 + max_num_seqs=256，单副本可承载 65 QPS（原 50）；②改 Triton Server 配置开启 dynamic_batching，最大 batch delay 从 5ms 调到 2ms，减少队列积压；③写了一个流量调度器（基于 OpenResty + Lua），按 prompt 长度把请求路由到"长上下文副本"与"短上下文副本"两组，长 prompt 走 chunked prefill 副本，短 prompt 走 throughput 优化副本；④Prometheus 自定义告警：queue > 50 持续 30s → 自动扩容 2 副本。
• 结果：峰值 1100 QPS 时 P99 维持 1.8s，GPU 利用率 88%，零 P0；大促期间比预估节省 4 副本预算，月度成本节省 12 万元。这套调度策略沉淀为内部"流量分级"组件，被另外两个业务线复用。

可追问点：①HPA 你为什么没用而自己写调度器？②流量分级怎么避免短 prompt 副本饿死长 prompt？③queue > 50 这个阈值怎么定的？④大促期间有没有出过告警？

范例 4：vLLM 源码贡献

❌ 普通写法：

为 vLLM 开源项目贡献代码，修复了若干 bug。

✅ 好写法：

vLLM 开源贡献 —— PagedAttention block_table 索引优化

• 情境：内部 Llama-70B 长上下文（16k+）推理时，发现 PagedAttention 在某些 prompt 长度组合下出现性能抖动，TTFT 飙升 3 倍。
• 任务：定位性能抖动根因，修复并贡献回 vLLM 主线。
• 行动：①用 Nsight Systems trace 定位到 attention_decode kernel 在 block_table 索引 > 256 时出现 cache miss 飙升；②读 vLLM 源码，发现 block_table 索引使用 int32 而非 int16，长 prompt 下 L2 cache 命中率从 85% 降到 62%；③把 block_table 元素类型改为 int16（block 数 < 32768 时安全），加 fallback 逻辑；④在 vLLM 0.8 上跑 benchmark 验证，TTFT 抖动消失，整体吞吐 +4%；⑤给 vllm-project/vllm 提 PR #12345，附 benchmark 报告与回归测试，3 周后合并到主线。
• 结果：内部 70B 推理 TTFT 抖动消失；PR 已合并，影响 vLLM 0.8 之后所有版本；GitHub 链接见简历顶部。

可追问点：①你怎么定位到 block_table 索引起的 cache miss？②为什么 int16 在 block > 32768 时要 fallback？③你提 PR 的 review 过程经历了什么？④后续 vLLM 团队有没有延续你的方案？

范例 5：端侧 LLM 部署

❌ 普通写法：

在 iPhone 上跑 Llama-3.2-1B，用 llama.cpp 框架。模型量化到 INT4，可以离线推理。

✅ 好写法：

iPhone 端 Llama-3.2-1B 部署 —— 离线助手原型

• 情境：团队探索"无网络环境下的 AI 助手"原型，目标在 iPhone 14 Pro 及以上机型跑 1B 模型，硬件预算 0（不允许云端推理兜底），首 token 延迟 < 500ms，生成速度 > 15 token/s。
• 任务：用 llama.cpp + INT4 group-wise 量化在 iPhone 14 Pro 上跑通 1B 模型，并打包成可分发的 App 原型。
• 行动：①对比 llama.cpp / MLC-LLM / CoreML+MPS 三条路径，llama.cpp 在 M2 上跑得最快但 iPhone 上 Metal 后端不成熟；MLC 编译复杂但能利用 ANE；最后选 llama.cpp + Metal，原因是开发周期短、生态最成熟；②用 llama.cpp quantize 工具做 INT4 group-wise（group_size=32），模型从 2.2GB 降到 480MB（-78%），加载时间从 4s 降到 1.2s；③发现 Metal 后端在 batch=1 时 matmul 性能仅达 A100 的 8%，瓶颈是 Metal kernel 的 threadgroup malloc；④写了一个 malloc → threadgroup async copy 的 patch（参考 Metal Best Practices），首 token 延迟从 1200ms 降到 380ms。
• 结果：iPhone 14 Pro 上 Llama-3.2-1B INT4 推理 18 token/s、首 token 380ms、模型 480MB；原型 App 进入内测，被产品同学认可"离线可用"。后续给 llama.cpp Metal 后端提了一个 PR（ggml-org/llama.cpp#6789）。

可追问点：①为什么选 llama.cpp 而不是 MLC？②INT4 group_size=32 怎么定的？③Metal 的 threadgroup malloc 你怎么发现是瓶颈的？④端侧推理的瓶颈与服务器侧有何不同？

范例 6：分布式推理优化

❌ 普通写法：

负责大规模 LLM 推理的 TP / PP 部署，用 vLLM 分布式版本。在 8 卡 H100 上跑 70B 模型。

✅ 好写法：

Llama-70B 跨节点分布式推理 —— 多节点 TP 优化

• 情境：业务需要部署 Llama-3-70B，单机 8×H100 装不下（70B FP16 = 140GB，单机 8×80G = 640G 但 KV cache 需额外空间），需要跨 2 节点 16 卡部署；现网 NVLink 仅在机内 8 卡间存在，跨节点走 InfiniBand 200GB/s。
• 任务：跨节点 TP 推理，吞吐不低于单机 TP=8 的 70%，TTFT 不超过 1.5s。
• 行动：①用 vLLM 的 tensor_parallel_size=16 跑通基线，发现跨节点 all-reduce 占 forward 时间 38%；②用 Nsight Systems 定位到 NCCL 跨节点通信走 PCIe 而非 IB（驱动配置问题），改 NCCL NET_GDR_LEVEL=5 后走 RDMA，通信时间降 60%；③开 speculative decoding + EAGLE（接受率 0.6），减少 forward 次数 40%；④开 CUDA Graph，减少 kernel launch 开销，单 forward 时间再降 8%。
• 结果：跨 2 节点 16 卡 TP 吞吐相对单机 8 卡 TP=8 的 88%（超过 70% 目标），TTFT 1.2s，月度成本相对"双机 TP=16 朴素部署"节省 32%；这套跨节点优化方案被沉淀为内部"多节点推理"标准配置。

可追问点：①跨节点 TP 为什么慢？②NCCL NET_GDR_LEVEL 你怎么调的？③EAGLE 接受率 0.6 你怎么测的？④CUDA Graph 捕获时遇到什么坑？

五、技术栈怎么列：分层，别堆名词

技能列表是"堆名词重灾区"：一行二十个工具名，面试官扫一眼就知道没深用过。正确做法是分层 + 标注熟练度 + 与证据挂钩。

1. 四层结构：语言 / 引擎 / 算子 / 平台

层级	内容	示例	标注方式
语言	编程语言	Python（精通）、C++（熟练）、Go（了解）、Rust（了解）	熟练度必须诚实
引擎 / 框架	推理引擎与训练框架	vLLM（精通源码）、TensorRT-LLM（熟练）、PyTorch（熟练）、Triton Server（熟练）	标注"源码 / API / 听过"
算子 / 硬件	CUDA / Triton / Nsight	CUDA（熟悉，能写 reduction）、Triton DSL（熟悉）、Nsight Systems（精通）、FlashAttention（熟悉原理）	标注能力深度
平台 / 工具	工程与基础设施	Docker、Kubernetes、Prometheus、ArgoCD、Helm、Linux	只写真正上过手的

分层的好处是让面试官一眼看清你的能力结构：语言是地基，引擎是日常工具，算子 / 硬件是优化能力，平台说明工程落地能力。四个层次里，"引擎 / 框架"和"算子 / 硬件"层最值钱——它们直接对应 JD 的能力项，也是项目证据所在。

2. 标注熟练度的自洽规则

• 只能选一档：「精通 / 熟练 / 了解」，别用"熟悉""掌握"这类模糊词。
• "精通 vLLM"必须能讲源码：精通 vLLM 意味着你讲得出 Scheduler / Executor / block_manager 的实现细节、能给 vLLM 提合并的 PR；写"精通"前先自问敢不敢接受 30 分钟源码追问。
• 熟练度要与项目证据一致：项目里用过的写"熟练"，面试官打开仓库就能验证；没用过只学过的写"了解"。

堆名词的代价：一条被戳穿，全页归零

"熟悉 vLLM、TensorRT-LLM、SGLang、LMDeploy、TGI、ONNX Runtime、OpenVINO、Triton Server、TensorFlow Serving……"——面试官随手挑一个冷门的问你源码细节，你答不上来，剩下的所有"熟悉"都会被打问号。技能列表宁少勿滥：写五项经得起追问的，远胜写十五项的。真实感 > 覆盖面，这条法则在整个求职过程中都成立。

六、深度 vs 广度：按岗位决定突出什么

"面面俱到"在简历上是贬义词——它意味着没有任何一面足够深。简历必须有主攻方向，而主攻方向由目标岗位决定。

岗位类型	优先突出	次要展示	简历上的体现
推理引擎工程师	引擎源码 + 算子优化深度	服务化能力	项目里写清源码改造、PR、benchmark 对比
LLM 系统工程师	服务化广度 + SLO 数据	引擎源码了解程度	项目里写清 K8s、灰度、监控告警、故障处理
推理优化工程师	性能调优案例 + 算子经验	部署能力	项目里写清 Nsight 案例、量化、kernel 改写
ML Infra / MLOps	平台化能力 + 多模型调度	单模型极致优化	项目里写清模型仓库、CI/CD、灰度、成本
算子工程师	CUDA / Triton 深度 + 硬件理解	引擎使用	项目里写清 kernel 改写、SASS 分析、bank conflict
端侧推理工程师	llama.cpp / MLC + 硬件适配	服务端推理	项目里写清端侧部署、量化、平台适配
推理框架研发	框架架构 + 论文复现 + 调度算法	算子 + 系统双能力	项目里写清新调度算法、新内存管理

一句总原则

深度靠"一个点挖到底"，广度靠"一条线走到尾"。 简历上的项目应当体现：至少一个项目你挖到了源码 / kernel / SASS 层（深度），同时每个项目都覆盖了完整链路（广度）。一个"既深又完整"的项目，胜过五个"每个都只到 vLLM API 调用"的项目。此条与作品集项目里的"1 主线 + 1 辅线"结构完全一致。

七、简历常见致命伤：10 个反例

以下 10 个问题按杀伤力排序，每一个都会直接导致被筛掉。完整的工程侧踩坑清单另见常见陷阱与反模式——那里是项目侧的，这里是简历侧的。

反例 1：堆名词不解释

❌ "精通 vLLM、TensorRT-LLM、SGLang、LMDeploy、TGI、ONNX Runtime……" ✅ 改为分层技能区，只留经得起追问的，并把最相关的两三项挂到项目证据下。

反例 2：只写课程，不写项目

❌ 教育经历下罗列五门网课，项目经历为空。 ✅ 网课只作一行背景，把时间投进作品集项目——哪怕只有一个 vLLM PR，也远胜十门课。

反例 3：性能数字经不起追问

❌ "TTFT 提升 50%""吞吐提升 3 倍"——相对谁？口径是什么？batch 多大？seq 多长？ ✅ 给出对比基线与口径："TTFT 从 1.8s 降到 600ms（vLLM 0.5 → 0.8 + chunked prefill，batch=64，seq=2k，A100 80G 单卡）"。

反例 4：把别人的项目写到自己名下

❌ 团队里别人的 vLLM patch，一字不改写成"我负责"。 ✅ 如实标注角色与贡献范围；面试官追问细节时，你连 block_table 改了哪一行都要讲得出——写下来就必须讲得出。

反例 5：只写工具，不写判断

❌ "使用 vLLM 部署 Llama，使用 TensorRT 优化性能。" ✅ 每个工具背后都补一句"为什么"："因 70B 模型 + 长 prompt 场景，选 vLLM 0.8 + chunked prefill，TTFT 比 TGI 低 35%"。

反例 6：格式混乱

❌ 五种字号、三种对齐、彩色图标、PDF 导出后乱码、错别字。 ✅ 单栏或双栏统一模板、全文字体一致、重点用加粗而非颜色、导出前检查三遍拼写——错别字在推理部署岗简历里近乎一票否决（"细节"即证据）。

反例 7：信息冗长无重点

❌ 两页半、每段八行、把不相关经历（前端实习、销售兼职）都写进来。 ✅ 应届一页、有经验两页内；每段经历不超过 5 行；与目标岗位无关的经历直接删除。

反例 8：只报喜不报忧

❌ "服务上线后稳定运行"，对回滚、故障、踩坑只字不提。 ✅ 如实写一句复盘："首版因 max_num_batched_tokens 设过小导致长 prompt 队列积压，调整为动态值后恢复"——面试官要的不是完美，是真实与反思。

反例 9：没有个人关键词

❌ 整页读完，面试官说不上来你是"做过 vLLM 源码的人"还是"做过 K8s 部署的人"。 ✅ 第一屏（姓名下方）用三行"个人定位"锁定主攻方向，其余内容全部向它收敛。

反例 10：投递不微调

❌ 同一份简历海投 50 个岗位，JD 里写的"熟悉投机解码"在你的简历里找不到对应证据。 ✅ 按第八节流程，针对每个目标岗位调整能力项排序与项目详略。

最贵的错误不是上面这些

上面 10 条都是"写不好"，最贵的是"造假"。简历造假（编造学历、虚构项目、冒用他人 PR）在推理部署这个小圈子里极其容易被发现——GitHub 仓库、PR 历史、levels.fyi 薪资记录、HR 背调，样样可查。一次造假被识破，代价是这个行业的人脉与口碑。宁可简历单薄，不可简历失实。

八、投递策略：按 JD 微调简历，把作品集变成可点击的证据

简历写完只是完成了一半，另一半是"投递"。这一节三条策略，全部服务于同一个目标：让初筛的人在三秒内看到"这个人就是为这个岗准备的"。

1. 按 JD 微调：十分钟的定制化

不要海投同一份简历。微调不是造假，而是改变叙述的重心：

• 重排证据：JD 第一条要求是什么，简历第一屏就放对应的证据。投引擎岗把 vLLM PR 放第一；投系统岗把 K8s 部署放第一。
• 替换关键词：JD 用"continuous batching"你就写 continuous batching，JD 用"in-flight batching"你就沿用它的词——关键词与 JD 对齐能显著提高通过初筛的概率（很多公司用关键词初筛）。
• 删减不相关：JD 完全不提的内容，除非极亮眼，否则删掉或后置。

2. 作品集链接：推理部署岗的"硬通货"

推理部署岗简历上能放链接的地方都放上：GitHub、vLLM PR 主页、benchmark 仓库、技术博客。注意三点：

• 链接必须是可访问的（检查过）、有内容的（README 齐全、能跑起来）——一份打不开的 GitHub 比没有更糟；
• 作品集的完成度标准与写法见作品集项目，面试前把它过一遍常见陷阱与反模式里的自检清单；
• 在项目描述里主动指向作品集："完整 benchmark 代码与 Nsight 报告见 GitHub 链接"——面试官去看了，你的可信度就完成了一次飞跃。

推理部署岗的特殊加分：把你的开源 PR 链接放在简历最显眼处。一个合并到 vLLM 主线的 PR，比任何项目描述都硬。

3. 投递节奏与数据化复盘

把投递当成一个带指标的项目来运营：

• 用表格记录：岗位、JD 关键词、投递日期、是否微调、是否进面试、面试反馈；
• 若连续 20 份投递零面试，先怀疑简历而不是怀疑市场——回到第二节重新做能力对标，找内行朋友做一轮"五秒初筛"测试；
• 若进入面试但没过，把面试问题记下来，对照面试题库补课，同时回改简历——被追问到答不出的点，就是简历需要改写的点。

关于"作品集一定要部署上线"的澄清

很多教程要求作品集必须部署到线上服务器。部署是加分项不是必选项：一份能 clone 下来、按 README 三步跑通、benchmark 报告完整的仓库，已经足以支撑面试深挖；部署到可访问的演示环境是锦上添花。不要为了部署消耗掉打磨 vLLM 源码细节与 Nsight 报告的时间。

九、简历模板骨架：一份可直接套用的 Markdown 模板

以下是一份覆盖上述所有原则的模板骨架，【】内为说明，替换成你自己的内容即可。所有"为什么"与"对比基线"都别删——它们是你区别于流水账的全部所在。

# 姓名｜目标岗位：推理引擎工程师

> 联系电话 ｜ 邮箱 ｜ GitHub（PR 链接） ｜ 技术博客 ｜ 所在城市
> 一句话定位：3 年 LLM 推理引擎研发经验，主攻 vLLM 二次开发与算子优化，主导过 70B 模型跨节点 TP 部署，给 vLLM 主线贡献过 3 个 PR。   【反例 9 的个人关键词】

## 教育经历
- **XX大学 · 计算机科学与技术 硕士**（20XX.09 – 20XX.06）
  - 方向：高性能计算 / GPU 编程；GPA：x.x/4.0（前 20%）
  - 相关课程：计算机体系结构、并行计算、操作系统、C++ 高级编程

## 项目经历（按含金量排序，优先放与目标 JD 最相关的一个）
### 项目名｜一句话定位（"XX 模型在 XX 场景的推理优化"）
- **情境**：业务场景 / 模型规模 / 硬件配置 / QPS / SLO / 预算约束。
- **任务**：优化指标 X（基线 Y，来源为旧版本 / 另一引擎 / 团队此前指标）。
- **行动**：分 2-3 点写"做了什么 + 为什么这么选 + 踩了什么坑"，
  例如引擎选型对比、源码改造、kernel 改写、Nsight 定位过程。
- **结果**：延迟（含对比基线）+ 吞吐 + GPU 利用率 + 业务指标（含口径），如实写复盘。
- 技术栈：Python / C++ / vLLM 0.8 / Triton / Nsight / K8s   【与技能区互相印证】

### 项目二｜……（同上结构；若为开源贡献，附 PR 链接）

## 实习/工作经历（如有）
### 公司 · 推理工程师（20XX.06 – 20XX.09）
- 负责 XX 模块，做了什么、为什么、结果如何——同样遵循 STAR。

## 开源贡献 / 论文 / 博客（信任度第二梯队）
- vLLM 主线 PR：vllm-project/vllm#XXXXX（block_table 索引优化，TTFT 抖动 -100%）
- 技术博客：《PagedAttention 原理拆解 + 实测对比》—— 链接
- 论文《……》（投递/发表于 XX 会议/期刊）

## 技能（分层，宁少勿滥，必须经得起追问）
- **语言**：Python（精通）、C++（熟练，能读 CUTLASS 模板）、Go（了解）
- **引擎 / 框架**：vLLM（精通源码，提过 3 个合并 PR）、TensorRT-LLM（熟练）、PyTorch（熟练）、Triton Server（熟练）
- **算子 / 硬件**：CUDA（熟悉，能写 reduction / scan）、Triton DSL（熟悉）、Nsight Systems（精通）、FlashAttention（熟悉 FA1/2/3 原理）
- **平台 / 工具**：Docker、Kubernetes、Prometheus、ArgoCD、Helm、Linux（熟练）

模板的两个使用要点

① 应届生若实习为空，把"项目经历"上移、删掉"实习"栏，用作品集顶上来——但绝对不要删掉"结果"那一行的量化与对比，这是全篇的命门。② 每个项目写完自测一遍：把每一条读给一个不懂这个项目的人听，他能复述出"你做了什么、做得多好"吗？不能，就再改。

十、延伸阅读

本站继续读：

• 写简历之前先看清岗位：模块导读与岗位版图 → JD 清单
• 拆 JD 时给能力项打分：能力地图
• 简历里的项目从哪来、怎么做到可深挖：作品集项目
• 项目与工程侧的踩坑自检：常见陷阱与反模式
• 简历过筛后的下一关：面试题库
• 整体求职节奏与学习主线：求职冲刺线；术语口径统一：术语表

外部真实资源（仅列可查证的原生资料）：

• vLLM Project Issues & PRs —— 推理部署岗最硬的"加分项证据"通道
• TensorRT-LLM Examples & Plugins —— NVIDIA 官方推理引擎仓库，可参考其 examples 写作品集
• SGLang Project —— 新一代推理引擎，开源贡献空间大
• llama.cpp Project —— 端侧推理方向的开源贡献通道
• levels.fyi —— 海外薪资与职级数据，评估目标岗位薪酬量级
• Indeed Career Guide: STAR method —— STAR 面试法的官方方法论出处
• Harvard OCS Resumes and Cover Letters —— 哈佛职业中心简历指南，通用格式与措辞规范的权威参考
• Andrew Ng. Machine Learning Yearning —— 工程化思维训练，可与简历故事互证

最后一句话：推理部署岗的简历不是给别人看的作品，是给面试官留的问号清单——让每一个问号都指向你能讲 20 分钟的"源码 + 数据 + 复盘"。写简历的时间花在"想清楚自己做过什么、做得多好、为什么这么做"上，永远不亏。