聊到“大模型技术链路”，很多刚接触这个方向的朋友第一反应是：这不就是调库、调接口、再套一层问答逻辑吗？实际在企业里跑通一个真正能上线的大模型产品，是一条贯穿数据加工、模型训练、推理部署、应用工程与效果评测的长链路。大厂之所以能快速推出AI产品，核心不是某个算法工程师特别牛，而是整条链路上每个环节都有专人负责、有明确的分工和流程。这篇文章我打算把这条链路拆开讲清楚，顺带聊聊大厂AI团队的岗位配置，最后给你一套小白也能直接上手的收藏整理方法，让“收藏夹吃灰”变成“收藏即复用”。
1. 先看懂完整技术链路：从数据到应用的四段旅程
1.1 数据侧：模型效果的天花板其实在这里
我见过太多人拿到开源模型权重就直接部署，跑起来发现效果很差，第一反应是“模型不行，换更大的”。但真正的问题往往出在数据。大模型这条链路里，数据决定上限，训练决定下限，推理决定成本，应用决定价值。
先说数据。企业在做模型时，不会只用网上爬来的通用文本，更多是自己业务场景里的真实数据。比如做一个客服机器人，需要把历史客服对话、故障文档、产品手册、售后政策整理成结构化的问答对。这里有一个关键认知：指令微调阶段（也就是大家常说的SFT）本质上是教模型“学会怎么组织回答”，而不是教它“知识”。知识主要来自预训练阶段和检索增强（后面会讲RAG）。所以如果你给的问答对本身有错、有歧义、逻辑不自洽，模型学得越多反而越糊涂。
我做过一个比较典型的实验：同样一个开源底座模型，只用3000条高质量问答对做微调，回答质量和稳定性明显优于用20000条从各种杂七杂八文档里硬凑出来的数据集。数据质量的重要性，再怎么强调都不为过。
1.2 训练侧：预训练、微调、偏好对齐各自的职责
训练不是一个动作，而是分阶段的一组动作。
预训练是在海量文本上学习语言规律和知识，成本极高，需要几千张显卡跑几个月，这不是一般团队做得起的。企业通常直接采用社区开源底座模型，把预训练这个环节跳过。
SFT微调是用“问题—标准答案”这类有监督数据让模型学会特定场景的回答风格。参数上有一些常见的经验值：学习率一般取1e-5到2e-5，LoRA的rank通常在8到64之间，训练数据量在几千到几万条之间。为什么rank不能盲目放大？rank太大，可训练参数多了，在小数据量下容易过拟合；rank太小，模型学不进去，效果不明显。
偏好对齐是把“好坏偏好”教给模型。常见做法是让模型对同一个问题生成多个回答，人工或规则排序，然后通过强化学习方式让模型学会优选那些排名靠前的回答风格。这个阶段解决的是“模型能力不差，但回答风格不讨喜”的问题，比如语气太生硬、拒绝太多、回答过于啰嗦。
1.3 推理侧：部署一个能用的模型并不简单
训练完之后，模型要对外提供服务，这一步叫推理部署。很多人觉得“模型都训好了，部署不就是起个服务吗？”实际上推理侧优化在大厂是一个非常独立的工种。
先说显存估算。一个70B参数规模的模型，如果用BF16精度存储权重，光是权重就要占大约140GB显存。单张80GB的卡放不下，需要多卡并行。这还只是权重，实际推断过程中还有KV Cache，这个缓存的大小和序列长度成正比。如果把上下文从2K扩到32K，KV Cache会增长约16倍。这也是为什么大厂在长文本场景下要做各种KV Cache压缩、量化、淘汰策略。
现在的通用做法是引入专门的推理引擎来提升吞吐和降低延迟。它们的核心思路是类似分页机制，把显存碎片利用起来，同时把解码过程拆成两个阶段分别优化。原理细节不展开，但你需要记住一个结论：模型权重能装下，不等于服务能稳定跑起来。线上并发一上来，显存、带宽、时延都会暴露问题。
1.4 应用与评测：产品好用才是终点
模型部署好，还没有结束，要跟业务系统结合起来才算完成。这里有两个绕不开的概念：RAG和Agent。
RAG，检索增强生成，核心是“先从知识库里检索出相关内容，再把内容塞给模型作为参考，让模型基于参考作答”。它能解决两个问题：一是模型知识截止时间的问题，二是幻觉问题。业务知识不断更新时，最优做法不是频繁重训模型，而是更新知识库。
Agent则是把复杂任务拆成多步执行。比如用户问“帮我对比这三款套餐并推荐一个”，模型可能要先去查询套餐参数，再按用户条件筛选，最后生成推荐理由。每一步都可以调用外部工具。
评测是最后一个必须重视的环节。上线前跑自动化评测集，上线后持续回归，防止模型优化了一个指标、却在另一个指标上崩塌。大厂内部通常会维护几百到几千条评测样本，覆盖准确性、忠实度、完整性、格式遵循等多个维度。评测集不是一次性的，它是模型的“考试大纲”。
2. 大厂AI团队的岗位配置：不止是一个“算法岗”
2.1 岗位全景：每条链路都有专门角色
很多人想象的大厂AI团队是“一堆算法工程师天天调模型”，实际完全不是这样。大模型从训练到上线，涉及的岗位远远超出算法本身。我按实际项目经验整理了一份典型岗位表：
| 岗位方向 | 核心职责 | 技术落点 |
|---|---|---|
| 算法工程师 | 模型选型、微调、效果优化 | LoRA、全参微调、偏好对齐 |
| AI基础设施工程师 | 训练集群、存储、网络调度 | GPU调度、分布式训练框架 |
| 数据工程师 | 数据清洗、构造、质检 | 数据流水线、规则脚本 |
| MLOps/平台工程师 | 模型版本管理、自动训练流程 | 流水线编排、CI/CD |
| 推理性能工程师 | 量化、推理引擎优化、高并发 | 显存优化、缓存策略 |
| 应用开发工程师 | API服务、业务系统对接 | 服务编写、RAG、Agent |
| 产品经理 | 场景定义、体验标准、反馈闭环 | 需求分析、上线决策 |
| 测试与评测工程师 | 评测集构建、回归测试 | 自动化评测、结果分析 |
你会发现，纯算法岗位只是其中一环，而且往往不是人数最多的。一个稳定的大模型产品，数据工程师和推理性能工程师的工作量常常被低估。
2.2 一个虚拟项目的团队分工样例
我给一个常见配置做参考。某企业内部知识问答项目，20人左右的团队：算法工程师4人，数据工程师3人，推理性能工程师2人，MLOps平台工程师2人，后端开发4人，前端开发2人，产品经理2人，测试评测1人。
为什么算法只有4个人？因为底座模型是开源的，核心工作是把数据质量做好、把评测集建好、把prompt调好。真正拖慢项目进度的往往是数据管道不稳定、推理服务在大并发下崩溃这类工程问题。算法调模型可能是几天就能出结果的事，但数据清洗和评测回归是持续整个项目生命周期的事。
这个配置还有一个特点：每一道环节都有交叉评审。算法调整后，必须跑一遍评测回归，由测试评测岗位确认没有副作用；推理性能工程师优化模型后，要由后端接入线上，再看看有没有接口超时。任何一个环节单独看起来都不是“顶尖技术”，但合在一起就是壁垒。
2.3 小团队和个人如何轻量化复刻这套配置
如果你是个人开发者或小团队，不可能按20人的配置去做。但思路可以复用：先想清楚数据从哪来、评测怎么定义、模型怎么上线。个人实操时，底座模型优先选社区开源权重，微调用LoRA，部署可直接使用主流的推理引擎，评测用脚本维护一个精简测试集。
说白了，个人能外包的环节尽量外包。比如不训练底座模型，用开源权重；不走复杂的分布式训练，用单卡加LoRA；不自己写推理框架，用现成引擎。最不该省的两个环节，一个是数据质量，一个是评测集，这两件事自己亲手做，收益最大。
3. 小白友好“收藏技巧”：把知识攒成自己的技术资产
3.1 收藏之前先定一个分类框架
这个标题里的“收藏技巧”，我是认认真真想讲点实操的。绝大多数人收藏内容，是看到一个好链接就扔进收藏夹，三个月后打开收藏夹，面对几百条内容毫无头绪。
正确做法是：收藏之前先建立一个大类的框架。对大模型领域，我建议按技术链路来分类，也就是顺着“数据—训练—推理—应用—评测”这五段去组织。每一条收藏进来之前，先判断它属于哪个环节，再放进去。
举个例子，你看到一篇讲“如何构造高质量指令数据”的文章，就放进“数据”分组；看到一篇讲“量化部署显存估算”的文章，就放进“推理”分组。不要单独建“大模型干货”这种一个文件夹装所有的分类，那等于没分类。
3.2 “三遍收藏法”：从收藏到内化
光有分类还不够，我建议采用“三遍收藏法”：
第一遍是快速扫读。收藏前先花两分钟扫一遍内容，判断属于哪个环节，值不值得收藏。不值得就直接关掉，这一步能帮你砍掉一半的无效收藏。
第二遍是重写。收藏后一周内，用自己的话把这个资料的核心观点写在一页笔记上。不需要长篇大论，两三句话即可，比如“这篇文章讲了LoRA的rank对效果的影响，建议8到32之间，代码在xx库”。写不出来的，说明没有真的看懂，下来再去原文补一遍。
第三遍是小项目验证。挑一个迷你任务验证学到的内容，不一定非要跑到服务器上训练，可以写一个评测脚本，或者用一个小数据集跑一次LoRA微调。做过的知识才真正属于你。
这个方法的本质是把“收藏”从被动囤积变成主动输入。我实测下来，收藏夹从一百多条精简到十几条，但每一条都知道在哪个环节、能解决问题，使用率高了不少。
3.3 一份可以直接抄的“按链路收藏清单”
下面这份清单是我个人建议小白优先收集的内容类型，你可以按这个方向去扩展：
| 链路环节 | 值得收藏的内容类型 | 收藏重点 |
|---|---|---|
| 数据 | 指令数据格式规范、清洗脚本模板 | 问答对怎么写才规范、如何去重去噪 |
| 训练 | 学习率选择、LoRA参数设置指南 | 各规模模型的经验参数、显存占用估算 |
| 推理 | 显存估算方法、量化方案对比 | 权重、KV Cache、激活值如何计算 |
| 应用 | RAG架构速查、Agent工具调用教程 | 检索分块策略、工具定义写法 |
| 评测 | 评测集样例、人工评估标准表 | 指标如何定义、边界case如何收集 |
按这个链路去收集，你会发现收藏的东西相互之间是有联系的，而不是孤立的知识碎片。
3.4 让收藏可以被检索：做一个简单的资源表
我建议所有重度学习者建一个简单的资源记录表，字段不用多，五列就够：标题、所属链路环节、一句话摘要、是否已验证、备注。
这个表比收藏夹更好用的地方在于，它逼着你每次收藏都做一个判断。三个月后你想找“量化部署的资料”，如果只是收藏夹里几百个链接，你可能要翻很久；但在表格里按“推理”环节过滤，出来就是那几篇，每个还带一句摘要，效率完全不是一个量级。
这算是我个人在大量收藏、大量踩坑之后，摸索出最有效的一套方法了。
4. 常见问题与避坑实录
4.1 坑一：模型选型盲目求大
很多团队一上来就要用最大参数量模型，觉得效果好。实际上模型越大，部署成本、推理延迟、调优难度都会同步上升。我在实际项目里的经验是：6B到14B量级的模型，配合精心整理的业务数据和评测集，在垂直场景里效果完全不输更大的模型，但成本低得多。
选型逻辑我建议这样做：如果只是知识问答场景，优先考虑RAG加一个小模型；如果希望模型严格遵循复杂的指令格式，再做SFT微调；如果场景需要复杂的逻辑推理，那时再考虑切换更大的模型。大模型是最后的选择，不是第一选择。
4.2 坑二：微调之后，效果不升反降
微调后效果变差，八成是数据有问题。最常见的是数据重复度过高，模型反复看同样的内容会出现类似“复读机”的现象。其次是问答对里的回答不符合规范，比如又长又啰嗦、或掺杂了过多语气词，模型会把这种风格一并学过去。
解决方案也很朴素：微调前先做数据清洗，算一下重复率，人工抽样检查100条数据的质量，不要在脏数据上花耐心调参。数据不对，调参是白费功夫。
4.3 坑三：部署时显存爆掉
部署阶段最容易出问题的是显存预估不足。权重只是显存占用的一部分，还包括KV Cache和激活值。建议先按权重、上下文长度、并发数一起估算，再预留约20%的余量。
如果实在塞不下，优先考虑量化，比如从BF16压到8bit或4bit，单卡能容纳的模型规模会大很多。对内部工具和轻量场景来说，量化带来的质量损耗往往可接受。
4.4 坑四：评测只看“看起来对”
“看起来对”和“稳定对”是两回事。同一个问题换几个问法就答偏了，这种问题在人工抽查时很容易漏掉。建议建立三个维度的评测项：幻觉检测，看回答是否忠实于给定材料；拒答率检测，统计模型拒绝回答的比例是否异常；指令遵循检测，用规则去匹配格式要求是否满足。
评测集不需要一开始就很大，先维护50到100条高质量样本，再逐步扩充，重点是覆盖业务里的边界场景，而不是追求数量。
4.5 坑五：盲目追求超长上下文
上下文越长，KV Cache占用越大，推理成本基本线性上升。很多人为了“让模型读完整份文档”，直接把上下文调到几十K，结果单卡根本跑不动。
实际操作中更好的顺序是：先做内容截断和检索，只把与问题相关的片段塞进上下文；不够用再优化检索策略；最后实在不行，才考虑提升上下文长度。这条路是性价比最高的。
我自己带项目的体感是，真正拉开差距的不是谁代码写得花哨，而是数据洁癖和评测习惯。数据不干净，什么模型来了都白搭；评测不系统，改好一个指标却崩了另一个，自己还浑然不觉。最后再分享一个小技巧：每次准备收藏任何资料，先问自己一句“这个资料能帮我解决技术链路中哪个环节的问题”，答不上来就直接不收藏。这个习惯帮我节省了巨量时间，收藏夹里的内容从一百多条减到十几条，但每一条都在实际项目中用上了，这才是“收藏”该有的样子。
