大模型岗位最近一年的风向变化比很多人预想的要快得多。我身边几个团队招人简历上写着“精通大模型微调”的候选人并不少但第一轮技术面往往会卡在同一个问题上你负责的模型线上跑一次要多久、能抗多大并发、显存和带宽够不够你心里有数吗这一问其实把大模型岗位的真实需求问出来了。企业现在要的不是“懂原理”的科学家而是“能交付”的工程人。所谓交付落到具体技能上大致就是三条线推理服务、RAG、Agent。模型本身的能力早已不是稀缺品部署不上去、检索不准、智能体跑不稳才是所有问题真正的瓶颈。这篇文章就围绕这三条线展开把大模型岗位的工程能力清单掰开揉碎地讲清楚。无论你是准备转行进入大模型赛道的学生还是已经在一线做算法、想补足工程侧积累的开发者都可以照着这份清单自查一遍哪块是短板哪块已经是你的加分项。1. 招聘风向变了从“懂算法”到“能不能上线”1.1 为什么“能交付”成了硬门槛过去两年大模型赛道明显换了节奏。最早是“模型为王”谁家的模型能力强谁就有话语权大家比的是参数、榜单、论文。最近一年风向变了模型能力逐渐同质化开源模型和商用API都足够好用企业之间的比拼转移到了谁能把模型真正用起来、跑顺、变成稳定产品。招聘时默认的潜台词变成了模型能力是基础设施那不是你的核心竞争力工程能力才是。这个变化直接导致算法岗和工程岗的边界越来越模糊。做LLM应用的人如果不懂推理服务的部署和优化开会时面对“这个延迟能不能降下来”“显存是不是浪费了”说不出所以然如果不懂RAG的检索评估搭出来的知识库只会在小规模演示里自嗨如果不懂Agent的工程化控制写出来的智能体一上真实任务就疯狂循环或者烧穿token预算。说白了岗位要的是一个能对最终效果负责的人而不只是一个能复述概念的人。1.2 大模型岗位的三条能力线在面试和带项目的过程中我习惯把大模型岗位的工程能力拆成三块正好对应标题里的三个关键词。推理服务解决的是“模型怎么稳定高效地跑起来”核心是部署、加速、压测、成本控制。RAG解决的是“模型怎么知道更多业务细节”核心是文档解析、检索链路、重排序、评估体系。Agent解决的是“模型怎么自己动手完成任务”核心是任务规划、工具调用、记忆管理、可观测性。能力线核心问题关键工程点常见交付物推理服务模型怎么稳定跑起来GPU选型、推理框架、量化方案、压测指标带QPS和延迟指标的服务接口RAG模型怎么知道业务细节文档解析、切块、混合检索、重排序、评测集可回答内部问题的知识库APIAgent模型怎么自己完成任务循环控制、工具层治理、记忆体系、Trace跑通多工具任务的智能体系统从岗位匹配的角度看三块里有一块达到“能独立交付”另外两块做到“能理解、能配合”就基本符合大多数公司对LLM工程师的要求。如果三块都只是“知道概念但没跑过真项目”简历关大概率过不了。1.3 工程能力和“背概念”在面试里怎么区分面试官想判断一个人是否真的做过工程其实非常简单。问几个具体问题就行你的推理服务OOM了第一步怎么排查如果只回答“加显存”或者“减小模型”说明没做过。如果回答“先看并发趋势判断是KV Cache撑爆还是模型权重加载问题再决定加大gpu-memory-utilization、换量化方式还是限制单请求上下文长度”说明是踩过坑的人。再比如问“RAG检索不到正确内容怎么办”没做过的人会泛泛而谈“调大相似度阈值”做过的人会说“先看解析后的文本是否完整再看切块大小和重叠最后测重排序模型有没有把正确文档挤下去”。这种差异是装不出来的也是“能交付”这三个字最直接的体现。2. 推理服务把模型变成一条能扛住压的生产线2.1 训练会跑不等于推理会跑不少候选人自己手里有显卡本地跑过7B、13B模型的对话觉得推理没什么难度。但训练和推理是两个物种训练的注意力在loss曲线推理的关注点在延迟、吞吐、稳定性、成本。类比一下训练是把一个能工作的样机做出来推理是把它变成一条能24小时运转的生产线。样机可以用手调生产线必须自动、稳定、可监控。本地跑一个对话任务batch size为1生成一两百个token哪怕慢个三五秒也没人在意。线上服务不一样几十几百个用户同时请求每个请求还要流式返回。每一轮推理占多少显存、KV Cache如何分配、请求如何排队、超时怎么办这些全是工程问题。没做过线上部署的人第一次看到并发一高服务直接OOM是会懵掉的因为这不是代码逻辑错误而是资源层面的结构性失配。2.2 显卡选型先卡显存再看算力和带宽推理部署的第一步永远是选卡。很多人上来就问“A100还是H100”但绝大多数业务场景根本用不上那么贵的卡。选卡的逻辑很简单先根据“模型大小量化方式上下文长度”算显存需求再根据“并发量响应速度”定算力等级最后才谈预算。显卡显存适合场景备注RTX 409024GB7B~14B模型的小并发推理个人开发与中小业务综合性价比最高RTX A600048GB14B~32B模型或24B模型的中等上下文单卡显存友好适合本地研发H2096GB主流开源模型推理国产合规算力环境的常见选择算力偏弱但显存大适合服务部署A100 80GB / H100 80GB80GB70B级大模型、高并发或长上下文成本很高绝大多数场景用不到选型时最隐蔽的坑是上下文长度。24B模型本身的权重可能不到50GB但把上下文开到32K之后KV Cache会吃掉大量显存。24GB显存跑14B带长上下文同样会吃紧。所以选卡时算的是“权重KV Cache激活值”的总和不是只看模型文件大小。这个账算错后面调优会非常被动。2.3 推理框架为什么必须用裸的Transformers代码做推理速度慢到没法上线一方面是没有高效批处理另一方面是KV Cache和显存管理粗放。vLLM、TensorRT-LLM、SGLang、TGI这些框架存在的意义就是通过批量调度和显存优化把GPU利用率拉起来。vLLM有两个核心点值得写进简历也值得真正理解。第一是Continuous Batching。传统批处理必须等一个批次里所有请求都生成完才能让下一批请求进入慢的那个请求会拖住整批。Continuous Batching允许一个请求生成完就立刻腾出位置让新请求进来GPU利用率直接上一个大台阶。第二是PagedAttention它把KV Cache按固定大小的页来管理避免显存碎片化单位显存下能容纳的并发请求数明显提升。理解了这两个思路换任何推理框架都只是换接口的事。部署一个开源模型现在非常成熟举个例子vllm serve Qwen/Qwen2.5-14B-Instruct \ --tensor-parallel-size 2 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --enforce-eager参数含义分别是tensor-parallel-size表示用几张卡切分模型max-model-len限制最大上下文长度gpu-memory-utilization表示允许框架用掉多少比例的显存enforce-eager是不做kernel融合以节省显存。实际部署时这些参数就是你和运维、后端同学讨价还价的资本。2.4 量化是有损的别无脑上量化是部署绕不开的话题。FP16跑70B要两张A100INT4量化后一张A100就能放下。但量化一定是有损的尤其INT4在小模型上做数学、代码等精确推理时精度下降会比较明显对话、摘要、文档问答这类任务损失通常可控。提示我的选择习惯是能FP16或FP8就尽量FP16/FP8显存实在不够再考虑AWQ或GPTQ的INT4。下手之前先在评测集上跑一轮对比看关键任务指标掉了多少再决定是否接受。还有一个容易踩的坑显存利用率配到0.9不代表永远安全。并发一旦涨起来KV Cache骤增服务照样可能OOM。所以生产环境要做的事不是把显存填满而是留出缓冲并设置合理的max-num-seqs。这些细节才是线上稳定和实验室跑通的最大区别。2.5 上线前必须压测的指标交付推理服务时我至少会盯四个指标。TTFT首Token延迟用户发出请求后到第一个token出现的等待时间建议控制在2秒以内TPOT每个输出token的时间决定流式生成速度30到80毫秒是比较舒服的范围吞吐量单位时间内完成的请求数或token数直接决定服务成本并发决定显存峰值和排队策略并发从8涨到32时延迟曲线会明显变化。压测不是随便拿并发工具刷一遍需要记录完整曲线。我自己的习惯是固定输入长度和输出长度分别测并发1、8、32、64下的TTFT和TPOT再和业务方确认可接受的延迟阈值。曾经有项目在并发8的时候一切正常并发32时TTFT突然飙升到7秒就是因为KV Cache溢出触发了隐性的排队和换入换出。这种问题只有压测才能暴露出来。3. RAG工程知识库不是“塞进去”就行得“查得准、给得快”3.1 解析阶段决定召回上限RAG项目最常见的误区是以为把文档切一切、向量化一下就算完事。真实业务里文档解析决定召回的上限PDF双栏、表格、扫描件、图片版式只要解析一步丢掉信息后面检索再怎么优化也找不回来。那些线上回答得驴唇不对马嘴的情况很多不是模型笨而是检索上来的上下文本身就是残缺的。我建议处理中文PDF时优先用支持版面分析的解析工具把双栏拆开、表格转成Markdown、扫描件走OCR。解析完之后务必抽查几页确认标题层级和正文没有混在一起再进入切块环节。这个步骤听着基础但在实际项目里一半以上的badcase能在这里找到源头。3.2 切块与向量化召回质量的第二个战场切块大小直接影响检索效果。块太小语义不完整模型回答时没有足够上下文块太大噪声多向量检索的相关性下降。我们常用的经验值是普通文档按512到1024个字符切重叠20到50个字符结构化较强的文档按章节切并保留标题层级作为元数据。向量化模型的选择也很关键。中文场景下bge系列、gte系列用得比较多多语言或专业领域则要自己拿评测集跑一跑。很多新手会忽略元数据设计其实chunk里带上文档标题、章节路径、页码、来源URL不仅能做过滤还方便答案引用溯源。这一层做扎实了后面接重排序、接Agent工具查询都会非常省事。3.3 混合检索重排序召回精度最快的提升手段只做向量检索语义上相近但字面完全不同的句子容易被漏召回只做BM25关键词检索遇到同义词改写又无能为力。产品级RAG几乎都会走混合检索向量检索和BM25各自打分再用RRF等融合策略合并排序。这一步对召回的提升非常明显工程成本又不高。真正拉开体验差距的是重排序。Rerank模型对粗召回的前几十条重新精排把最相关的几条顶到最前面。实测下来在问答质量偏低的RAG系统里加一个Rerank答案质量的提升往往比换一个更强的Embedding模型还要明显。所以你要是想在RAG链路上做增量重排序是性价比最高的加装件没有之一。3.4 评测体系交付前必须回答“好不好”RAG项目最容易在演示时人人叫好、上线后一地鸡毛根子是没有评测集。我建议每个RAG项目至少准备100条真实业务问题覆盖简单直问、多跳问题、否定问题、长尾内部术语等类型。指标上可以用RAGAS那一套重点看三个上下文相关性、回答忠实度、答案相关性。其中回答忠实度最关键它衡量答案里的每个断言是否都能在检索到的上下文里找到依据。如果忠实度低于80%基本可以断定检索链路有需要排查的地方要么召回不完整要么重排序把关键文档挤掉了。评测集的建设很枯燥但它是RAG项目从“演示能跑”走向“可交付”的唯一标准这部分偷懒后面上线就会被线上问题追着跑。4. Agent难点不在调API而在失控管理4.1 循环能力会失控先定好纪律Agent本质上是一个“推理-行动-观察-再推理”的循环ReAct框架把这个循环固定下来配合工具调用。但工程里这个循环随时可能失控模型重复调用同一个工具、在一个错误上反复自我修正、迭代次数无上限导致token烧穿预算、或者被某次工具返回的超长JSON撑爆上下文。演示Demo里这些都看不见一上真实任务就现原形。我一般会给Agent设四条纪律最大迭代次数、单次任务的最长执行时间、token预算上限、停止条件。最大轮次通常压到10到15轮预算到顶就强制结束并返回已有结果和失败原因而不是让它无限循环下去。Agent工程和普通API开发最大的区别就是你不能再用“输入-输出”的确定性思维去写代码必须预设一套容错和熔断机制。4.2 工具层是Agent的“手”需要标准化Agent能调用的工具本质上就是一组API。工程上要做好三件事统一工具Schema并注册支持并发与嵌套调用对调用失败做重试和降级。工具的描述文本极其关键LLM是靠描述来决定何时调用工具的描述一团模糊模型就会乱调。写工具描述时把大模型当成一个新来的实习生参数格式要写清楚单位要标注返回结构要给样例。比如查天气的工具描述里就要写“接受城市中文名返回温度、天气、风力温度单位为摄氏度”必要时补一两个示例。实习生能看懂模型基本也能看明白。这个习惯养成了工具接入再多也不会乱。4.3 记忆体系分多层别把所有历史往上下文里塞很多Agent项目图省事把所有历史对话直接塞进上下文。这样token消耗惊人还容易被无关内容干扰导致越聊越乱。成熟的Agent项目通常分三层记忆短期记忆用于当前会话的对话记录长期记忆存放从历史对话中提取的事实性摘要放进向量库工作记忆则记录当前任务的执行状态比如哪些子任务已完成、当前正在处理什么。长期记忆的核心是“摘要沉淀”而不是“原样存储”。每天或每会话结束时先用模型把当次对话的关键事实抽成结构化摘要再写入向量库。下次任务直接把相关摘要召回进来。这个改动不大但会让Agent的多轮体验明显变稳也是从“会聊”走向“会干活”的关键一步。4.4 可观测性没有Trace的Agent别上线Agent和普通接口最大的区别是你很难预测它下一步会做什么。所以上线前必须给它装上仪表盘记录每一轮思考、工具调用参数、返回结果、token消耗。没有这些逐层日志出问题时你只能对着一条报错干瞪眼完全无法定位是哪一轮、哪个工具、哪段上下文出了问题。用LangSmith、Langfuse或者自己打结构化日志都可以关键是能回答这几个问题这个任务一共跑了几轮调了哪几个工具哪一步消耗的token最多是不是某次工具返回了一大坨JSON把上下文撑爆了这些信息是Agent上线后做优化的出发点。没有Trace就去谈Agent优化等于闭着眼睛开车。5. 面试与简历怎么让面试官相信你“能交付”5.1 简历项目要按“指标链路排障”写简历里写“熟悉RAG”等于没写写“自建RAG链路回答忠实度从60%提升到85%”才有效写“做过Agent开发”没用写“多工具Agent系统上线日处理任务2000平均单次任务token消耗2.8K”才有说服力。面试官筛简历时就是在找这种能证明交付能力的量化描述。项目描述我习惯按三要素组织问题场景一句话技术方案链路两三行量化结果一行。比如这样写企业内部物料问答系统解决文档格式混杂、答案幻觉率高的问题。技术链路为MinerU解析PDF - 章节级切块 - bge向量检索BM25混合召回 - bge-reranker精排 - Qwen2.5-14B生成。构建126条内部问题评测集回答忠实度由62%提升至87%单次问答延迟2.1秒。这种描述比任何形容词都管用。面试官一眼就能看出你做了什么、怎么做的、结果如何。5.2 技术面高频问题提前准备换到面试官视角我筛选候选人的时候三个方向各有一批高频问题。推理服务方向vLLM的continuous batching解决了什么问题KV Cache爆了先看什么INT4量化和FP16比精度差多少RAG方向某个业务问题总是检索不到怎么排查chunk大小怎么定重排序为什么有效Agent方向多轮任务状态怎么管理工具调用失败怎么恢复token预算怎么控制这些问题都没有标准答案面试官真正想听的是你有没有真实的排查经验和取舍逻辑。哪怕你的方案在专家眼里不够优雅只要能讲清楚为什么这样做就已经是合格的工程候选人。最怕的是只会背概念一问到“你实际遇到过什么问题”就卡壳。5.3 起步路线把三个小Demo做成闭环如果现在还没有相关项目经验最快的办法是自己把三个小Demo跑通。推理服务用一台带显卡的机器或云GPU部署一个14B开源模型用vLLM启动服务再写个脚本做并发压测记录TTFT和吞吐曲线。RAG用开源的解析和Embedding工具搭建一个内部文档问答库配上50条问题的评测集。Agent用LangGraph这样的Agent框架或者任何你顺手的编排工具接两个真实工具比如天气API和数据库查询把多轮任务跑通。这三个Demo做完工程手感就有了。面试时聊起来你至少有真实的延迟数字、真实的badcase、真实的排查过程可以讲和那些只背概念的人立刻拉开差距。别小看这些“小项目”它们正是从“懂算法”走向“能交付”的必经台阶。最后说点个人体会。我带人的时候最看重的不是候选人背了多少概念而是能不能对着一个具体问题说出“我之前遇到过当时是怎么处理的”。大模型岗位的技能栈更新很快但工程能力的内核一直没有变能拆解问题、能设计链路、能量化结果、出了问题能顺着日志找到根因。这份能力清单你不必当成知识点背把它当成自查表用。每两周给自己一个小目标把RAG的评测集补到50条或者给Agent加一层长期记忆或者把推理服务压测跑出一张完整的延迟曲线。交付过的东西越小越具体积累就越扎实。真正到了面试或项目现场你的底气不是来自读了多少文档而是来自你亲手把一件事从无到有做成过的经验。