devgo.cn2025 年初，一位在腾讯做了 15 年搜索后台、已经晋升到 T12 的资深工程师，做了一个让周围人意外的决定：卸下管理头衔，去大模型推理工程团队当一名“零级新人”——没有高级 title，不做任务分发，像实习生一样从性能评测、服务部署这些周边琐事做起。这不是组织安排，也不是一时冲动，而是他反复权衡后的主动选择。为什么？因为他算了一笔账：2022 年底 ChatGPT 出现后，基于 Transformer 的大模型席卷全球，“更大的参数带来更高的智能基线”这一规律至今有效。他今年将到不惑之年，正处于心智和经验的巅峰期，如果此刻固守旧业，二十年后面对子辈的追问，就像今天想问父辈“四十年前改革开放迎面而来，你在做什么”一样，无法回答。
他切入的路径也很有代表性。当时搜索产品虽然形态上贴近大模型应用，但内部召回、排序等细分领域仍大量沿用传统技术；多轮对话、长上下文、Agent Runtime 这些概念也还没形成清晰的产品形态。他判断：无论上层产品怎么演进，算力和推理加速这类基础设施永远是不可或缺的底座。于是他没有去赌某个具体的 Agent 产品形态，而是选择了推理工程——离算力最近、最不可能被绕开的那一层。
另一个促使他下决心的因素，是管理者的技术困境。他观察到，面对全新一波技术浪潮，管理者很难做到 100% 专注地学习新技术，结果往往是技术学习流于表面，或者管理水平滑坡。传统路径的答案是放弃技术、转型职业经理人，但他不想过早蜕变成靠信息差生存的人。组织也不可能允许一个人带着高阶管理头衔去当大模型方向的“初学者”。所以当组织调整、需要他去掉管理头衔并切入产品主链路时，他坦然接受了——他信奉的是“决定一个人价值的，从来不是他的头衔，而是他正在做的事情”。
进入新团队后，他花了三个月时间独立做了一次代码重构，摸清核心链路全流程，同时深入阅读了 SGLang 源码。他把这段入门经历总结成了一套方法论，核心是“先总后分”：先建立体系化认知，再逐个击破。具体分四步。
第一步，对模型结构建立体系化认知。当前主流大模型都是 Transformer 架构，要熟悉 Embedding、Attention、FFN、Normalize、Residual、LM Head 这些核心组件，能画出结构简图；同时了解深度学习的基本原理（感知机、梯度下降、反向传播、CNN、RNN、Seq2Seq 等）。他特别提醒，Transformer 模型结构反而是这三类信息里最简单的，推荐借助 AI 或知乎学习，但深度学习基础建议读书，比如《深度学习入门：基于 Python 的理论与实现》和《深度学习革命》。
第二步，对大模型推理工程建立体系化认知。他给了一个很实用的分析框架：先明确两个问题——要解决什么问题、有什么评估体系。推理工程的顶层目标与传统软件工程一致（功能、性能、成本、稳定性），评估体系核心指标包括 TTFT（首 token 延迟，即用户发出请求到收到第一个字的时间）、TPOT（每个输出 token 的平均生成时间）、QPS、TPS、并发数。围绕这些指标，系统层面每一项优化都可以归纳为算力、显存、通信三者之间的资源置换。据此可以抽象出三层模型：顶层是业务目标，中间层是量化评估标准，底层是具体实现手段。落到工程组织上，实现手段又分三个子方向：业务层（推理服务 SDK、推理平台、服务部署与监控、请求流量调度）、调度层（分布式并行、Prefix Cache、Overlap Scheduler、Continuous Batch、Chunked Prefill、Speculative Decoding 等，绝大多数推理加速优化都在这层）、算子层（QKV 计算、Normalize、Linear 等单点计算性能优化）。对业务规模小的团队，不必做这么精细的切分。
第三步，了解主流模型结构的演进趋势。他观察到，大模型时代“算法”和“工程”的岗位边界日益模糊，新一代模型结构演进本质上是算法创新与工程优化深度结合的结果。从最初的 Full Attention + Dense FFN，发展到稀疏注意力、线性注意力、混合架构、MoE（混合专家模型，把一个大模型拆成多个专家子网络，每次只激活部分专家，降低计算量）、Pre-Norm、RoPE、MLA、KV Cache 跨层复用等，模型在变得更智能的同时，也在朝着降低计算复杂度、适配长上下文、降低推理成本的方向演进。DeepSeek 是典型代表——注意力层的 MLA、HCA、CSA 设计，以及 DSpark 推测解码，都是算法与工程结合的案例。他特别强调，现阶段大模型结构演进本质上是“实验科学”：当创新点子变得廉价，昂贵的是验证思路的实验能否更好更快完成，这时候 infra 极其重要。
第四步，深入某个优化方向。他推荐了几个投入产出比高、业界关注度高的子方向：PD 分离（把 Prefill 和 Decode 两个阶段解耦部署，Prefill 是计算密集型、Decode 是显存带宽密集型，分离后能显著提升整机吞吐和资源利用率，对卡资源紧缺的团队尤其关键）；分布式 KV Cache（KV Cache 是大模型推理时缓存中间计算结果的机制，让回答更快；分布式方案能提升多轮交互、长上下文场景的 Prefix Cache 命中率，降低重复计算成本）；推测解码（利用 Decode 阶段算力未饱和的特点，用一个小模型先草拟多个 token，大模型一次验证，大幅提升吞吐）。他还提醒，顺着底层执行链路深挖时往往能发现被忽略的暗礁——比如在特定约束下，Overlap Scheduler 反而可能破坏 Continuous Batch 的批处理效率。
为了检验真实理解而非“看时全都会、做时全不会”的虚假掌握感，他设计了三个自检练习。第一个是同批次共享前缀的注意力优化：同一个 Batch 内多个请求带公共前缀（比如请求 1 是 [a,b,c,1,2,3]，请求 2 是 [a,b,c,4,5,6]），如何避免对前缀 [a,b,c] 的重复 Prefill 计算和 KV Cache 重复写入？这在个性化推荐场景极常见——文档打分任务里输入通常是 user_info + doc_N，前缀 user_info 在同一个批次完全相同。要解答这个问题，需要深刻理解因果掩码（Causal Mask）的构造、KV Cache 的申请和使用、FlashAttention/FlashInfer 等 Attention Kernel 的接口设计、GPU Thread Block 的并行特点。第二个是 Beam Search 的工程实现。Beam Search 是搜索/推荐领域常用的解码策略，每一步不再只保留最优 token，而是保留多个候选 token 作为多条子路径继续推导，按整条子路径累积对数概率排序，保留得分最高的 Beam Width 条继续。关键难点在于：多条子路径共享前缀的 KV Cache 复用、高效率剪枝（当 Beam Width=1024 时要从 1024×词表大小个候选中挑出最佳 1024 个）、约束解码（推荐场景限制只能生成合法 DocID）、以及避免小众功能成为主流功能迭代的负担。他去年在 SGLang 上实现了高性能 Beam Search，做到业界 SOTA 性能，后来 SGLang 官方开发者在分支基础上重构融合，合并到了 v0.5.19。第三个是读懂大模型方向的技术文章——能看懂 HCA/CSA、混合架构、DSpark 等论文或文章的基本原理，是入门的重要标志。
最后他聊了一个让很多 Infra 工程师宽心的观点：AI Infra 不是从零诞生的全新领域，而是传统 Infra 版图的自然扩张。今天对外提供大模型推理 API 服务，底层依然搭建在微服务、分布式、RPC、存储、可观测体系、研效体系这些传统能力之上。二者同源——AI Infra 的多数技能点都建立在通用 Infra 基础上；也有分野——AI Infra、Agent Infra 在资源模型与服务范式上显著区别于传统后台系统。所以对 Infra 工程师来说，学习 AI Infra 不是推倒重来，而是知识边界的自然拓展。他甚至给出了第二条路径：如果不想像他这样归零重来，可以从通用 Infra 逐步渗透到 AI Infra——在一个 AI 产品团队里，AI Infra 绝非仅仅等于 GPU 计算加速，背后依然需要极度扎实的平台化建设、研效提升与稳定性保障，从这些熟悉的切入点入手做“AI 化改造”同样可行。
最让我意外的是他对“管理者”这个身份的态度。他没有把“放弃管理头衔”描述成一种牺牲，而是说“管理本身就是一门严谨的技术，需要持续学习、练习，投入大量精力”——正因为尊重管理，才不愿在技术浪潮来临时用“半吊子管理+半吊子技术”的状态两头应付。这个判断对很多正在犹豫的资深工程师很有参考价值：与其在旧赛道上守着资历，不如在 AI 时代留在离 AI 最近的团队，哪怕从零级新人开始。毕竟，决定一个人价值的，从来不是头衔，而是他正在做的事情。
内容与图片版权归原作者所有 · 原文: https://mp.weixin.qq.com/s?__biz=MjM5ODYwMjI2MA==&mid=2649804238&idx=1&sn=5071d1c07d4c99fac83cbfe0a3860344