2026年如果你打开招聘软件搜“AI大模型工程师”会发现职位描述已经和两三年前完全是两回事JD里不再问你能不能从零预训练一个大模型而是问你能不能把开源大模型稳定部署上线、把推理成本砍掉一半能不能用RAG和Agent把模型塞进真实业务流程以及该微调的时候敢不敢动手调。这篇文章是我这几年从算法转到大模型应用、踩过不少坑之后的个人总结。它不是教科书式的知识清单而是一条尽量贴合2026年真实岗位需求的路线本地部署怎么做、微调什么时候才该做、Agent和RAG在工程里怎么落地、哪些钱和精力可以省、哪些坑千万别踩。无论你是应届生、传统后端转岗还是已经在做算法想往大模型方向靠应该都能从里面找到自己能直接用的东西。1. 2026年的岗位真相要的不是“会炼丹”是能把模型搬进业务1.1 JD的变化从训练基座模型到搞定开源模型落地前两年提到大模型工程师很多人脑海里还是那个画面一排A100跑几个月的预训练盯着loss曲线一点点往下降。但到了2026年绝大多数公司已经不再需要自己做基座模型了。开源模型的能力迭代速度非常快再加上各家API的成熟企业真正缺的是能把现成大模型用起来的人。我看到的真实JD变化是岗位要求从“熟悉Transformer原理、有预训练经验”变成了“熟悉主流开源模型掌握LoRA/QLoRA微调能独立完成模型部署与推理优化有RAG或Agent落地经验优先”。这不是说算法基础不重要了而是市场已经把“大模型工程师”从研究岗推向了工程岗。能力评估的重心从“你会不会训练”转移到了“你能不能交付一个稳定、便宜、效果可控的服务”。这个转变的底层逻辑其实很清晰。基座模型的训练成本和技术门槛决定了它只会集中在少数团队手里绝大多数公司的价值在于场景、数据和业务闭环。你需要做的事情是在别人造好的发动机之上造出一辆能跑的车而不是自己也去炼一炉钢。2026年的大模型工程师本质上是个“将模型能力翻译成业务价值”的角色。1.2 几类相近岗位的边界早认清早定位我见过不少新人把“大模型工程师”当成一个统一的头衔去准备结果面试时发现不同岗位要的东西差异巨大。这里先帮大家把市场上的岗位粗略分成三类方便你对着自己的背景选方向。岗位方向核心产出日常工作重心比较适合谁推理优化/部署工程服务吞吐、延迟、显存占用推理框架、量化、分布式、CUDA优化底层系统/C背景或对性能敏感的开发算法应用工程数据集、微调模型、效果指标数据清洗、LoRA训练、评估集设计有算法基础喜欢跟数据打交道的人大模型应用开发业务功能、Agent/RAG服务Prompt、向量库、Function Calling、后端接口后端开发转岗离业务最近的人这三个方向没有高低之分只有适不适合。推理优化方向需要啃的东西最硬vLLM、SGLang、量化内核、KV Cache优化哪个都不轻松但门槛也意味着护城河。算法应用方向最像传统算法工程师的延续核心功夫在数据、训练策略和评测上。应用开发方向是当前需求量最大的因为几乎所有行业都想往业务里塞AI功能但现实是很多团队连一个能稳定调用模型接口的人都缺。我自己是算法出身后来做了大量应用和部署的工作体感是2026年想在这个领域站稳不能只懂单一方向。你可以有一个明显的主攻方向但周围一圈知识必须补齐至少要达到“能和隔壁岗位的人有效对话”的程度。这也是为什么我不建议新人一开始就扎进最底层的CUDA优化里去先把整条链路跑通再决定把哪一环挖深会更稳妥。2. 学习的先后顺序比学习量更关键先把技术底座搭到“够用”2.1 哪些基础一定要补哪些可以先放一放很多打算入行的人第一个问题是我要不要先把机器学习、深度学习的理论全部学完再动手。我的回答是千万不要。大模型领域知识更新太快如果你追求“学完再开始”可能永远等不到那一天。但我也不是说可以完全零基础裸奔有几个底线内容必须掌握。编程语言方面Python是绝对主力需要熟练到能独立写数据处理脚本、调用类库、调试报错。如果你完全没写过Python建议先花一两周刷完基础语法和常用库的基本用法不用追求精通但列表推导、字典操作、函数、类、文件读写这些要顺手。其次推荐补一点TypeScript或者JavaScript因为很多大模型应用的前端集成、脚本工具会用得到不深学能看懂会改就行。Java背景的同学不用慌如果你的工作环境是Java技术栈Spring AI这类框架确实能把门槛降下来只是整个生态的工具链丰富度仍然不如Python。理论基础方面Transformer是绕不开的但不是让你去把Attention的公式从头推一遍。你需要理解的是token是什么、位置编码大概在解决什么问题、多头注意力为什么能让模型看到不同子空间、KV Cache是怎么回事、上下文窗口意味着什么。这些概念直接关系到后面你做部署时的显存计算、做Agent时对上下文的理解、调Prompt时对效果的判断。深度学习框架至少得会PyTorch因为大部分开源模型的训练和推理代码都以它为主。数学方面线性代数和概率统计的基础概念要有但不需要一上来就啃完整本教材。矩阵乘法在做什么、softmax为什么把分数变成概率、损失函数怎么衡量预测和真实值的差距这些知道大概原理就够启动项目了。真到了要调参、要读论文的时候再回头补不迟。2.2 算力规划别在前期为了硬件浪费一个月算力是另一个让新人纠结到失眠的问题。看了一圈帖子发现大家都在讨论A100、H100再看看自己手里的笔记本瞬间不想学了。但实际上入门阶段对算力的要求远没有你想象中那么高。最推荐的起步方式是使用云GPU平台按小时计费用完就关。以微调一个7B模型的实验为例在24G显存的卡上跑QLoRA通常一两个小时就能完成一个小规模的训练花费可能就是一杯咖啡的钱。国内的云GPU平台、海外的Colab和Kaggle都能提供类似环境关键在于“用完释放”而不是长期包月。不少新人犯的错是一步到位买了一台顶配机器结果一个月用不了几次钱花了学习动力也没见涨多少。如果你手里只有普通笔记本电脑也不是不能学。8B以下的小模型量化之后在部分Mac和稍好些的CPU上也能跑体验虽然慢但用来理解部署流程、测试Prompt足够了。本地没有卡就用云端云端觉得贵就先从最小模型开始。真正卡住你的从来不是算力不够而是迟迟不开始。记住一个原则在入门阶段没有什么实验是必须用顶级卡才能完成的最小可行配置永远是你能立刻上手的那套。2.3 用一次最小闭环把“部署-调用-微调”全串起来我想给所有准备入坑的人一个非常具体的建议不要按“先学Python、再学机器学习、再学深度学习、最后学大模型”的线性路径去走那太慢了。更有效的做法是先搭一个最小的完整闭环下载一个开源小模型在本地跑起来通过接口调用它准备一小批数据做一次LoRA微调再把微调后的模型重新部署。这个过程看起来简单但它的价值在于把大模型工程师日常工作中的所有核心环节都过了一遍。你会遇到第一个关于显存不够的报错会第一次理解量化格式为什么有那么多后缀会在数据清洗时发现模型输出格式乱掉会在部署后对比微调前后的效果差异。这些经验远远比连续看三十节课有用。这个闭环的“最小配置”大概是这样一张12G到24G显存的GPU或一个按小时租的云端实例一个7B到8B量级的开源对话模型用4bit量化加载一份几百条的指令微调数据哪怕暂时用公开数据集也没问题。完成之后你再回头看会发现整个知识体系不再是散点而是连成了一条线。后面无论往哪个方向深挖你都知道该往哪里用力了。3. 本地部署不是把模型拉下来那么简单模型选型与推理优化3.1 选模型先看任务和显存别被跑分带偏每次有新的开源模型发布社交平台上都是一片“屠榜”“超越”的声音。但真正做工程的人应该清楚跑分和实战之间的差距可以非常大。选模型的第一准则不是谁的综合分高而是谁在你的任务场景、你的硬件条件下表现最稳定。我一般按几个维度去筛。第一是参数量档位3B到8B适合做轻量任务、工具调用、边缘部署响应快但复杂推理能力有限14B到32B是当前性价比最高的档位很多业务级应用都够用单卡也有机会跑起来70B甚至更大则适合复杂推理、高难度代码生成但对显存和运维的要求会成倍上升。第二是量化支持度越是主流的模型GGUF、AWQ、GPTQ这些量化格式的社区支持越完善踩坑概率越低。第三要看上下文长度和实际推理表现不要只看宣传的上下文窗口有多大要看在长上下文的压力测试下是否真的不丢信息。还有一个很容易忽略的点选模型的时候要参考“同任务下的口碑”。比如你做中文知识库问答国产开源模型的中文语料优势就非常明显你写代码辅助工具代码专项模型或经过代码指令微调的版本通常表现更好。多去技术社区搜搜别人在同场景下的实测反馈比自己盲测省力得多。3.2 Ollama先做开发验证vLLM再做生产服务本地部署工具的选择很多人一上来就纠结“Ollama好还是vLLM好”。其实这俩根本不是同一个定位的东西没必要二选一。从我的经验看合理的用法是开发调试阶段用Ollama生产服务阶段用vLLM。Ollama的优势是极低的启动成本。安装完之后两条命令就能把一个量化模型拉下来跑起来还自动处理了模型格式转换和基础API暴露对初学者极其友好。我在项目早期验证想法的时候基本都是先用Ollama起一个模型把Prompt方案和业务流程大概调通再说。Ollama也支持从OpenAI兼容的接口调用所以前期写的代码后面可以无缝切到别的推理服务上。# 安装完 Ollama 后拉取一个带量化标记的模型并运行 ollama pull qwen2.5:14b-instruct-q4_K_M ollama run qwen2.5:14b-instruct但要上生产就另说了。Ollama在并发控制、吞吐优化和显存管理上不如专业的推理框架。vLLM使用PagedAttention技术管理KV Cache并且支持Continuous Batching连续批处理能把GPU的利用率拉高很多。同样是单张A100用Ollama硬扛并发和用vLLM做生产服务吞吐量差距可能是几倍。vLLM启动后默认提供OpenAI兼容接口对接现有业务代码几乎没有成本。# vLLM 启动本地模型服务的示例 vllm serve /models/Qwen2.5-14B-Instruct/ \ --served-model-name qwen-14b \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 2另外提一下SGLang它和vLLM类似在某些场景下的性能表现和生产特性也很不错。我个人的选择习惯是如果团队已经熟悉vLLM生态就继续用vLLM如果是新起项目且主要吃长文本和复杂调度SGLang值得做个性能对比。工具本身不是信仰谁在你场景里更快更稳就用谁。3.3 一张推理显存账算清楚再决定要不要上量化部署过程中新人问得最多的一个问题就是我这个卡到底能不能跑那个模型与其反复试错不如自己会估算显存占用。推理显存主要分三块模型权重、KV Cache、中间激活值。模型权重比较容易算。以7B模型为例如果以FP16精度加载每个参数占2字节7B模型所需权重显存大约是14GB。如果转成4bit量化每个参数只占0.5字节权重占用降到大约3.5GB到4GB左右这就是为什么量化能大幅降低部署门槛。KV Cache的大小和模型层数、注意力头数、上下文长度直接相关粗略估算的方式是序列长度越长、并发请求越多KV Cache占用越大通常要为它预留和权重差不多量级的空间。再加上激活值和运行时开销保守建议总显存要留出30%以上的余量。举个具体例子。假设你要在24G显存的卡上部署14B模型FP16权重占28GB已经超出显存直接跑不了。但用4bit量化后权重降到约8GB再给8K上下文和一定并发预留KV Cache24G就变得可行了。这也是为什么很多个人开发者能在消费级显卡上玩转14B甚至32B模型的原因。不过要提醒一句量化不是没有代价的。低比特量化会带来一定效果损失尤其在数学推理、代码生成这类需要精确计算的任务上更明显。所以在生产环境里建议先用FP16或BF16跑基线再用量化版本做效果对比如果你的业务对输出质量极度敏感可能就要放弃极致量化转而升级显卡或减少并发。显存账算清楚之后很多部署决策就不再是靠感觉了。4. 微调的正确打开方式先回答“是不是非得训”4.1 RAG和微调不是竞争关系是两条快慢不同的路我发现一个普遍现象一提到要做垂直领域模型很多人的第一反应就是“我得微调一个”。这个想法可以理解但不一定正确。2026年做垂直场景绝大多数情况下你先要做的不是微调而是检索增强生成也就是RAG。RAG和微调解决的是不同层面的问题。RAG适合那些“知识会变”或“知识需要可追溯”的场景比如企业内部政策、产品文档、售后知识库内容每周甚至每天都在更新。你把文档切块、向量化、存进向量库用户提问时先检索相关内容再把这些内容拼进Prompt让模型回答。优点是更新知识只需要更新文档库不需要重新训练模型成本低而且回答时能引用来源方便追溯。微调适合的是“能力和风格层面的改变”你想让模型学会固定的输出JSON格式想让它模仿某种特定的写作风格想让它在某个专业任务上的表现稳定提升。这些能力不是靠检索能补上的而是需要调整模型的权重。举个例子你有一个工单分类系统要求模型输出结构化的分类结果和置信度这种格式要求即使你把示例写在Prompt里模型还是可能会飘这时候用几百条高质量数据做一次微调效果会稳定很多。一个容易混淆的点是RAG和微调不是互斥的。实际生产里更多是先RAG后微调的组合。先让模型通过检索拿到知识再微调它学会怎么把知识组织成符合业务要求的答案。很多效果不错的企业应用底层其实是一个“RAG管道 一个经过LoRA微调过的小模型”。4.2 QLoRA微调的完整路线与参数记忆点当你确定某个场景确实需要微调之后下一步是选择微调方法。全参微调在2026年已经越来越少见成本高、耗时长、还容易灾难性遗忘除非你有充足算力和数据否则不推荐。LoRA是目前最主流的轻量微调方式它冻结原模型权重只训练注入的低秩矩阵训练参数量只有原模型的很小比例。QLoRA则是在LoRA基础上把原模型量化为4bit加载进一步降低显存需求让单卡微调大模型成为可能。如果你第一次跑QLoRA可以记住这条路线用BitsAndBytesConfig把模型以4bit加载用PEFT库配置LoRA参数准备一份指令数据集然后走正常的Transformers训练流程。下面是关键环节的参考代码from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training import torch bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.bfloat16, ) model AutoModelForCausalLM.from_pretrained( Qwen/Qwen2.5-7B-Instruct, quantization_configbnb_config, device_mapauto, ) model prepare_model_for_kbit_training(model) lora_config LoraConfig( r32, # 秩决定新增训练参数量 lora_alpha64, # 缩放系数一般设为 r 的2倍 target_modules[q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj], lora_dropout0.05, ) model get_peft_model(model, lora_config)有几个参数是我反复实验后的经验值。LoRA的秩r太小了学不住东西太大了训练慢且效果未必更好7B到14B的模型从r32开始试基本合理。lora_alpha一般设成r的两倍也就是64这是社区默认较稳的组合。学习率通常设在1e-4到2e-5之间7B模型用1e-4左右起步更大的模型适当调低。训练轮数建议2到3个epoch就停微调不是预训练轮数过多会导致模型在训练集上过拟合反而丢掉泛化能力。显存方面QLoRA在24G显存上微调7B模型是可行的14B则建议使用30G以上显存或双卡。4.3 数据比模型重要评估比训练重要很多第一次做微调的人把大部分精力花在琢磨训练参数上但真正决定微调效果上限的永远是数据。这个道理有点像做菜锅和火候当然重要但食材不行什么大厨都救不回来。我做过一个工单分类的微调项目最开始的版本用了网上爬来的几万条公开数据看起来数量很大但训练完一测输出格式混乱分类准确率也不理想。后来团队花了几天把业务方提供的真实历史工单清洗了一遍筛选出几千条标注清晰、类别均衡的样本配合一些通用对话数据混合训练效果立刻上了一个台阶。那个项目最后只用了不到五千条高质量数据效果远超之前几万条脏数据。关于数据我强烈建议你自己定一个验证集而且这个验证集要尽可能贴近线上真实场景。不要只写一个脚本看loss降没降训练完成后要在验证集上逐条看输出。我习惯准备二十到三十条“刁钻”的Prompt涵盖边界情况、格式异常、敏感表达等每次微调完先跑一遍这些用例比任何指标都直观。另外要警惕灾难性遗忘问题模型微调后可能在垂直任务上变强了但通用能力和基础对话能力会退化。缓解的办法是在训练数据里掺入10%到20%的通用对话数据或者单独跑几个通用问题做回归测试。5. 应用工程化RAG、Agent与AI编程工具构成了日常主战场5.1 RAG做不好的原因一半出在召回RAG这名字听起来简单——检索、拼接、生成三步但真正落地过的人都知道想做好非常磨人。大量项目把模型从GPT换到开源、从开源换到更大参数效果还是不行最后发现瓶颈根本不在模型而在前面的检索环节。一个可靠的RAG流程通常包括这几步文档解析、文本切块、向量化、存入向量库、召回、重排、拼装上下文、生成。我把建过索引的各种格式文档的经验浓缩成一句话解析和切块决定了检索的上限向量模型决定了相似度计算的质量重排决定了最终进Prompt的内容质量。文档解析不只是把PDF文字抽出来那么简单表格、页眉页脚、多栏排版都会让解析结果变成一堆乱序文本直接影响后续切块质量。切块长度和重叠率也需要反复调切太碎了语义不完整切太大了检索噪音明显一般先从每块300到500个token、块间重叠50个token左右开始试。向量库的选择可以按场景来。个人项目或原型验证用Chroma这类轻量方案最快中小团队和业务系统用Milvus或pgvector比较合适如果只是做一个最小RAG实验甚至直接用内存向量检索也能跑通。我的建议是别过早引入重组件先用最简单的方案把链路通起来。注意当你发现RAG效果差时先查召回再查生成。一个非常实用的排查方法把检索出来的上下文块单独打印出来看如果这些块本身和问题不相关那生成再强也没用。5.2 Agent不是堆功能是给模型一套靠谱的“做事规则”Agent大概是2026年大模型应用里最热闹的方向。很多团队一听Agent就想着把一堆工具全接进去让模型“自由发挥”。但做过几个项目后你会发现Agent的本事不取决于它接了多少工具而取决于你给它的“做事规则”是否清晰可靠。Agent的核心结构可以拆成三块模型大脑、工具集、循环逻辑。模型大脑负责理解用户意图并决定下一步调用什么工具工具集封装了模型能调用的外部能力比如查订单系统、搜知识库、执行一段计算循环逻辑负责让模型在“调用工具-拿到结果-决定下一步”之间反复迭代直到完成目标。实现一个Agent最基础的方式是Function Calling。你不需要教模型怎么写代码调用你的函数只需要把工具的描述和参数结构告诉它它会在需要时输出一个结构化的调用请求你的代码再解析这个请求去真的执行函数。比模型自由发挥更稳的做法是给它一个流程图先做什么、什么情况下用什么工具、失败后怎么重试、最多迭代几次。说白了Agent不是给你一个不需要编程的万能助手而是让你用代码给大模型画出一条“最近可达路径”。另外一个越来越值得关注的方向是MCP。它相当于给不同AI应用定义了一套统一的工具调用协议让工具开发者写一遍就能被多个Agent生态使用。如果你所在团队的工具链比较长可以认真研究一下MCP减少后续“每个Agent接一遍工具”的重复劳动。但也要清醒MCP生态还在快速演进别在一个月内把系统推倒重来两遍。5.3 AI编程工具链Cursor、Claude Code和本地模型的配合2026年的大模型工程师自己写代码的方式也已经被AI改变了。Cursor、Claude Code这类AI编程工具已经从“辅助补全”进化到“能接手一个完整子任务”的程度。它们让我的开发速度明显提升但同时也对工程师本身的代码评审能力提出了更高要求——因为AI生成的代码看起来总是很自信但未必正确。我日常的搭配是这样的重度逻辑开发用Cursor它适合在IDE里做上下文感知的代码生成和修改特别是跨文件重构时能大幅减少机械劳动。命令行场景和批量任务用Claude Code这类工具它可以自己读目录、跑测试、看报错并迭代修改代码像一个不需要休息的初级程序员。但无论哪个工具我都会保留一个核心习惯每条生成的代码都必须经过Review尤其是涉及数据库操作、资金计算、权限控制的逻辑绝不直接信任AI输出。本地模型在这些AI编程工具链中也有自己的位置。有些团队的代码涉及敏感逻辑不允许随便传到外部API这时候就可以把Ollama部署的本地模型配置到Cursor或相关插件里作为代码补全和基础问答的模型。好处是数据不出内网坏处是本地模型的代码能力相比头部API还是有肉眼可见的差距特别是在处理长文件、复杂工程上下文时。我一些朋友的折中做法是普通代码用本地模型复杂任务和最终Review仍走能力更强的商业模型或者人工兜底。这个思路在预算和数据安全之间取得了一个相对合理的平衡。6. 我踩过几次坑之后最想留给新人的几句话6.1 拿API先做基线再决定要不要本地化很多项目从一开始就倾向于本地部署开源模型理由是“数据安全”或“长期成本更低”。但真实原因有时候只是觉得“本地部署更酷”。在这个领域方向错了后面的努力全是白费。我后来定了一条规矩任何新项目先用最容易获得的API方案把效果基线跑出来。如果云端API能解决的问题直接在业务里接入就行最快最稳只有当API方案确实存在不可接受的问题——比如数据出域风险、调用成本过高、响应延迟过大——才考虑换成本地部署。即便是本地部署也应该先选一个中等规模的量化模型快速验证效果再决定要不要为了质量上更大的模型。这个“先API后本地”的顺序能省掉大量试错成本。我见过最典型的反面例子是一个团队花了几周把32B模型部署好结果发现业务效果不好的原因是知识库召回太差跟模型选型毫无关系。6.2 上下文越长不代表越强别为参数牺牲体验上下文窗口是各个模型厂商最爱宣传的指标之一从8K到32K、128K再到更大的数字看得人眼花缭乱。但真正做过长文本任务的人会告诉你宣传的上下文长度和实际可用上下文长度是两回事。模型在短文本下表现很好一旦超过某个长度门槛可能会丢失早期信息、开始答非所问而且推理时间和显存消耗都随长度快速上升。在应用设计上一个常犯的错是“所有的上下文都往里塞”。给模型的Prompt越长不一定效果越好反而可能引入噪音、增加成本、降低响应速度。更专业的做法是给上下文分层核心指令和关键约束放在最前面业务数据经过检索、裁剪后放在中间需要模型重点完成的任务说明放在最后。LLM对Prompt开头和结尾内容的注意力通常更强中间部分容易“视而不见”。这不是玄学是很多人在长上下文评测里总结出来的工程直觉。6.3 2026年更稀缺的是工程判断力如果你把前面所有技术点都学完了还会发现真正拉开差距的是一种不太好量化但极重要的能力工程判断力。具体表现就是在信息不完整、资源有限、需求模糊的情况下你能不能快速决定用什么方案、做到什么程度、怎么验证结果。比如老板扔给你一个需求“搞一个智能客服”。缺乏判断力的人可能立刻开始选模型、搭框架、写代码。有经验的人会先反问现有客服系统长什么样、回答什么类型问题、数据在哪里、多少人用、准确率要做到多少、有没有历史对话样本。这些信息直接决定了这是一个简单的FAQ机器人还是一个完整的RAGAgent项目。又比如两个模型效果差不多一个部署成本低但生态差另一个部署成本高但社区活跃你在资源有限时怎么选背后是风险判断。提升判断力没有捷径只能靠大量真实项目去喂。但新手可以刻意练习一件事接到任何任务先写一页纸的“方案草案”内容包括目标、约束、可行选项、推荐方案、主要风险。写完再动手。这个过程会逼你把模糊的问题变清晰也会让你的Leader更愿意把重要任务交给你。判断力本质上就是高质量决策的积累。如果你决定走这条路不要被“2026年是不是太晚了”“入行门槛是不是太高了”这些问题困住。大模型领域最大的门槛不是数学不是GPU而是你能不能把一个很小的闭环坚持跑完。今晚就可以从装一个Ollama、拉一个7B模型、写一个能聊天的服务开始。只要这个闭环跑通了你就已经走在很多观望者前面了。后面的事是持续地做、持续地踩坑、持续地复盘。