2026大模型工程师实战：从本地部署到AI Agent落地

2026年再提"AI大模型工程师"这个title，圈内人的心情其实挺复杂的。一方面，这确实是过去两年里薪资涨幅最离谱、需求最旺盛的技术方向之一；另一方面，市面上顶着这个名头的人太多了——有会调API就敢写进简历的，有用LoRA跑通一个demo就号称懂微调的，也有真能把模型压到生产环境里稳定服务几万QPS的。差距之大，几乎不像同一个职业。

我做了多年大模型相关的工程落地，也带过不少人从零转岗到这个方向。结合2026年这个时间节点，以及大家最近高频搜索的那些词——本地部署、ollama、微调、AI Agent、GPU资源、大模型应用开发——我把"大模型工程师"这个角色真正需要掌握的东西，按实际工作流重新梳理了一遍。这篇不是课程大纲，就是一个过来人告诉你：这个岗位到底在解什么题，以及你该往哪儿使劲。

1. 2026年的大模型工程师，到底在解决什么问题

1.1 岗位定位已经变了：不是"调参侠"，是"模型落地的总负责人"

先纠正一个过时的认知。很多人以为大模型工程师的核心工作是训练模型、调loss曲线、刷benchmark分数，所以一上手就猛啃Transformer论文、复现BERT、研究各种SOTA架构。不能说完全没用，但在2026年的实际工作场景里，这套东西的占比远没有想象中高。

现在企业招大模型工程师，解法基本是这几类：

• 把开源模型（如Qwen、Llama、DeepSeek系）部署到自己的GPU集群或云上，做成对内对外的API服务
• 用RAG（检索增强生成）解决私有知识库问答，让模型"知道"公司内部文档
• 用微调（尤其是LoRA/QLoRA这类参数高效微调）让模型适配特定风格、特定任务
• 基于Function Calling或Agent框架，让模型能调用工具、操作数据库、完成多步任务
• 做模型效果评估、数据回流、prompt迭代，让系统越用越准

你会发现，这些工作几乎没有一项是"从零训练一个大模型"。因为2026年的共识已经很明确了：基座模型的能力天花板由那些大厂和头部实验室决定，绝大多数公司（甚至绝大多数国家实验室）既没有算力也没有数据去重训一个更好的基座。工程师的价值不在于"造模型"，而在于"把已有的模型用出花来"——就像今天的后端工程师不需要造数据库，但需要知道怎么把MySQL用到极致。

所以如果你想在2026年入行或者转型，先调整心态：你的核心竞争力是工程化能力 + 对模型行为的深入理解，而不是复现论文的能力。

1.2 从招聘JD倒推能力矩阵

我看了不少2026年的大模型工程师JD，也帮团队面试过几十个候选人，筛人的标准其实可以浓缩成一张能力矩阵表：

看到没？没有一行是"精通Transformer架构推导"。不是说原理不重要，而是原理是为这些工程决策服务的——你不需要手推Attention公式，但你需要知道context len变长为什么会带来显存暴涨，为什么LoRA的rank不是越大越好，为什么Agent的system prompt会影响工具调用的成功率。

2. 本地部署与模型选型：从ollama到生产级推理的全链路

2.1 为什么人人都从ollama开始，但它离生产还差几步

本地部署是热搜词里出现频率最高的方向，ollama几乎成了入门标配。确实，ollama把"下载模型 + 启动服务 + 提供OpenAI兼容API"这件事简化到了极致：

# 一键拉模型并启动 ollama pull qwen2.5:14b ollama run qwen2.5:14b # 或者直接走OpenAI兼容接口 curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "qwen2.5:14b", "messages": [{"role": "user", "content": "你好"}]}'

这套东西拿来学习、做demo、甚至给内部小团队用，完全够了。我自己就经常用ollama在本地起一个小模型，配合VS Code里的Claude Code插件（或者类似的AI编程助手）做代码补全和重构，把代码相关的请求全部导向本地模型，既省了API费用，也避免了代码片段外传的合规风险。这个用法现在很流行，本地16G显存的机器就能跑得很舒服。

但如果是线上生产环境，ollama就有几个绕不开的问题：

1. 并发吞吐上不去：ollama的底层推理优化相对保守，并发高了之后排队严重，对输出速度也没有精细控制
2. 缺乏生产级特性：比如连续批处理（continuous batching）、前缀缓存（prefix caching）、多模态输入的路由等，这些在vLLM这类专用推理框架里是标配
3. 可观测性薄弱：生产环境你需要知道每次请求的TTFT（首token延迟）、TPOT（每token生成时间）、显存占用曲线，ollama在这些方面几乎是黑盒

所以我的建议是：ollama留给你做本地实验和个人开发，生产部署认真考虑vLLM。这不是说ollama不好，而是工具定位不同，就像你不能拿开发服务器当生产环境用一样。

2.2 显存计算：一张A100到底能跑多大的模型

部署环节最常被问到的就是"我的卡能跑多大的模型？"这个问题其实可以算得很清楚。核心公式是：

推理显存占用 ≈ 模型权重 + KV Cache + 激活值 + 运行时开销

粗略估算时，模型权重的显存可以用一个简单经验值：FP16精度下，每10亿参数约占2GB显存（因为每个参数2字节）。所以：

• 7B模型 FP16：约14GB，一张24GB的RTX 4090勉强能跑，但留给KV Cache的空间就很紧张了
• 14B模型 FP16：约28GB，需要40GB以上的卡，A100 40G可以，4090就悬了
• 70B模型 FP16：约140GB，单卡没戏，至少需要4张A100/H100

所以你会看到大家本地部署时特别执着于量化。INT8量化能把权重占用减半，INT4量化再减半。一个14B模型用INT4量化后权重只有约7GB，普通消费级显卡就能跑，这就是ollama上各种"14b-q4_K_M"这类tag的由来。

但注意，量化不是免费的午餐。INT4量化通常会让模型在复杂推理任务上的表现打折扣，尤其是数学、代码、逻辑推理这些对精度敏感的场景。我的经验是：能用INT8就不用INT4，除非显存真的紧张。

KV Cache这块经常被忽略，但其实吃显存吃得很凶。它的大小和max_length（最大上下文长度）强相关，粗略公式是：

KV Cache大小 ≈ 2 × 层数 × 头维度 × 序列长度 × batch_size × 字节数

这也是为什么同样的模型，你从max_length=2048调到max_length=8192，显存占用会明显上涨的原因。部署时不要无脑拉高上下文长度，够用就好。

2.3 生产级推理框架怎么选

2026年这个时间点，推理框架的选择基本已经收敛了：

我的默认选择是vLLM，它提供的OpenAI兼容API让你从前期的ollama实验平滑切换到生产，代码几乎不用改：

from openai import OpenAI client = OpenAI( base_url="http://your-server:8000/v1", api_key="EMPTY" ) resp = client.chat.completions.create( model="qwen2.5-14b", messages=[{"role": "user", "content": "用Python写一个快排"}], temperature=0.3 ) print(resp.choices[0].message.content)

这里顺手提一个很多人踩过的坑：vLLM启动时的--max-model-len和--gpu-memory-utilization要仔细设。你如果把max-model-len设得过高，而实际请求的prompt都很短，大量的显存会被KV Cache预分配策略浪费掉；设得太低，则偶尔来一个长文档请求直接报错。gpu-memory-utilization默认0.9，但如果你的卡还要跑别的进程，建议调低到0.7~0.8，否则容易OOM。

3. 微调不是炼丹，而是一套工程方法

3.1 LoRA/QLoRA的原理边界：什么能微调，什么微调也救不了

现在只要提到微调，基本绕不开LoRA（Low-Rank Adaptation）。它的核心思想很巧妙：冻结原模型的全部权重，只在每一层旁边加一个低秩的旁路矩阵，训练的时候只更新这个旁路。

为什么这么做有效？因为大量研究表明，预训练模型的权重空间里，真正需要针对下游任务调整的部分其实集中在一个很低的秩子空间中。"低秩"意味着你不需要动几B甚至几十B的参数，只需要学一个很小的增量矩阵就够了。我用大白话解释过很多次：原模型是个博览群书的天才，LoRA不是让他重新读书，而是给他一本"考试技巧小册子"。小册子很薄，但针对性极强。

具体到参数上，关键就两个：

• rank（秩）：决定了旁路矩阵的宽度。rank越大，模型能学的新东西越多，但训练参数量和显存也随之上升。我见过不少新手一上来就rank=64、128，结果一个7B模型在单张24G卡上跑得极其勉强，loss还乱飞。实际上针对大部分指令跟随、风格迁移类任务，rank=8~16已经足够了
• alpha（缩放系数）：一般设成rank的两倍（比如rank=16, alpha=32），这个比例在多数情况下表现稳定

但有一个边界要清楚：LoRA适合"调整行为"，不适合"灌输知识"。你的模型如果连基础的常识都不具备，微调是补不回来的。举个具体例子：你想让模型学会回答你公司内部的产品售后问题，如果这些问题涉及的背景知识在基座模型里完全不存在（比如你们内部系统的专有名词、私有流程），LoRA能学到的非常有限，它会强行"记住"一部分训练样本，但遇到没见过的表述方式就露馅。这种场景的正解是RAG——把背景知识放到检索库里，让模型在回答时先检索再生成。

所以我通常会给团队一个很朴素的判断标准：

• 想让模型改变语气、格式、输出结构，例如按固定JSON schema输出 → 微调
• 想让模型回答问题风格更像某个特定人物或品牌 → 微调
• 想让模型知道一个外部知识库的内容（文档、FAQ、内部手册）→ RAG
• 想让模型学会使用工具、按流程执行多步任务 → Agent + 微调结合

3.2 QLoRA实践：24G显存微调7B模型的完整配置

很多人看到"微调"俩字就以为需要8卡A100集群，其实2026年的今天，消费级显卡微调开源模型已经是很成熟的操作了。我自己在单张RTX 4090（24G显存）上微调7B模型的配置，可以直接分享给你：

from transformers import ( AutoModelForCausalLM, AutoTokenizer, TrainingArguments ) from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training from trl import SFTTrainer model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen2.5-7B-Instruct", load_in_4bit=True, # 4bit量化加载，这是QLoRA的关键 device_map="auto", torch_dtype="auto", ) tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-7B-Instruct") model = prepare_model_for_kbit_training(model) lora_config = LoraConfig( r=16, lora_alpha=32, target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_config) training_args = TrainingArguments( output_dir="./qwen-7b-lora", per_device_train_batch_size=1, gradient_accumulation_steps=16, # 等效batch_size=16 learning_rate=2e-4, num_train_epochs=3, logging_steps=10, save_steps=500, fp16=True, optim="paged_adamw_8bit", remove_unused_columns=False, ) trainer = SFTTrainer( model=model, train_dataset=dataset, tokenizer=tokenizer, args=training_args, ) trainer.train()

这里有几个配置背后的逻辑必须讲清楚，不然你换个模型、换个数据就抓瞎：

• load_in_4bit=True：这是QLoRA能跑在24G卡上的根本原因。7B模型FP16权重要14G，4bit量化后只要约3.5G，省出来的空间给梯度和KV Cache
• gradient_accumulation_steps=16：单卡batch_size设1是无奈之举，但梯度累积16步，等效batch size=16，既保证了训练稳定性，又没有真的提高显存占用
• optim="paged_adamw_8bit"：优化器状态（AdamW的动量项）其实比模型权重还吃显存，8bit分页优化器专门解决这个问题
• fp16=True：半精度训练，训练速度和显存都比FP32友好

这套配置在24G卡上跑7B模型，显存占用大概在16~18G左右，留了余量。如果模型换成13B/14B，就会很吃力了，那需要考虑更激进的量化或者多卡方案。

3.3 训练数据的坑：为什么你的模型loss掉得漂亮但效果一塌糊涂

这是微调环节最扎心的一个问题，我几乎每个带的新人都会踩一遍。

先说结论：loss下降只能说明模型在拟合训练数据，不能说明它学到了你想要的通用能力。最常见的翻车场景是——训练集里放了500条样例，模型把这些样例的"标准答案"背下来了，loss降到很低，但一换新的问法就答得不知所云。这就是过拟合到"死记硬背"了。

怎么避免？我的经验集中在数据层面：

1. 数据量不必贪多，但覆盖要广。500条高质量、多样化的对话，比5000条内容高度相似的对话效果好得多。多样性包括：提问方式的多样性（同一个问题用不同说法问）、场景的多样性、答案长度的多样性
2. 严格做训练集/验证集分离，而且验证集要和训练集"不像"。如果你把同一个人同一批文档改了改措辞就放进验证集，那验证loss参考价值很低
3. attention mask设置要正确。SFT训练时，要让模型只对答案部分计算loss，prompt部分不应该贡献loss。SFTTrainer默认会处理这个逻辑，但如果自己拼数据就要格外小心

另外必须强调一个训练过程中的判断技巧：不要只看loss曲线，定期把验证集里的真实case拿出来看生成效果。哪怕loss还没降到底，如果生成质量已经明显在往目标方向走，那就是对的。反之，loss降得再漂亮，生成效果不对，也要果断调整数据。

3.4 微调之后的评估：一拳打到自己脸上

微调结束不是终点，评估才是。但行业里对评估的重视程度，说实话远不如对训练的重视。

我见过太多团队花两周微调出一个模型，然后拿10条样例人工看了一下，觉得"还行"，就匆匆上线了。然后线上翻车。问题是有些退化是隐蔽的——微调完一个模型专门输出JSON格式，结果通用对话能力退化了；在某个垂直领域效果好，但把之前已经能处理好的通用问题答崩了。这被称为灾难性遗忘（Catastrophic Forgetting）。

所以微调之后的评估，至少要做两层：

第一层：任务指标评估。针对你微调的目标任务，准备一套评测集（尽量是模型没见过的），量化指标。比如做代码生成的，跑HumanEval；做数学推理的，跑GSM8K；做结构化输出的，算schema遵循率。

第二层：通用能力回归测试。准备一份通用能力测试集（比如百科问答、开放对话、基础推理），对比微调前后的效果，确认没有明显退化。这一步容易被省掉，但恰恰是生产环境翻车的主因。

如果你用的模型来自Qwen、Llama这些主流家族，HuggingFace的lm-evaluation-harness可以直接跑一套标准benchmark，成本不高，强烈推荐做。

4. Agent开发：从Demo到可用产品的关键一跃

4.1 Function Calling与ReAct：模型怎么学会"调工具"

如果说2025年AI应用的叙事核心是RAG，那2026年的核心就是Agent。而Agent的地基，就是让模型具备"调用外部工具"的能力。

目前实现工具调用有两条主流路线：

路线一：Function Calling（函数调用）

在请求里显式声明有哪些工具可用（工具名、参数schema、描述），模型经过训练后能输出一个结构化的调用结果，而不是一段自然语言解释。OpenAI兼容接口里的tools参数就是干这个的：

{ "tools": [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的当前天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名"} }, "required": ["city"] } } } ] }

模型返回的不是直接调用结果，而是一个"意图"——它告诉系统"我想调用get_weather，参数是city=北京"，然后由你的代码去真正执行这个函数，把结果拼回去再交给模型生成最终回复。

路线二：ReAct（Reasoning + Acting）

不用专门的函数声明，而是把工具描述写进prompt里，让模型自己推理"我现在需要调用什么工具"，然后把调用动作输出成特定格式文本，由程序解析执行。这是LangChain时代最主流的做法。

2026年的实际情况是：主流模型（包括开源的Qwen、GLM和闭源的GPT、Claude）都原生支持Function Calling，所以尽量用原生接口，少依赖复杂的agent框架。原生Function Calling是模型专门训练过的能力，准确率高、错误率低、解析稳定。ReAct那套用提示词硬控制的方式，模型偶尔会"发挥创意"输出一些解析不了的格式，让人很崩溃。

4.2 上下文管理的痛：Agent为什么总是"记不住事儿"

Agent做多轮任务时，最常见的翻车点是"前面几步执行得好好的，后面突然忘了自己在干嘛"。这背后是上下文管理的问题。

模型能看到的上下文是有限的（即使是128K、200K的模型，真正有效的注意力范围也没有那么神），而Agent每一轮的工具调用结果、中间推理过程都会不断累积到上下文里。等上下文被塞满，有两个后果：

1. 模型会开始"忽略"早期信息——尤其是中间夹杂着一大堆工具返回的无关细节时
2. 上下文越长，计算延迟越高、成本越贵、最终生成质量越不稳定

我自己做Agent开发时的经验是：不要一股脑把所有历史都塞给模型，要做"上下文压缩"。常见的做法有：

• 摘要压缩：当对话超过一定轮数，把之前的历史用模型本身压缩成一两段摘要，腾出空间
• 结构化状态管理：不要把"用户已经选好的城市"这类关键信息放在对话历史里，而是放到一个结构化的状态对象里，只在每一轮把必要的状态注入system prompt
• 工具结果截断：工具的返回常常很长（比如数据库查询结果、网页正文），只截取对当前决策有用的部分，需要更多细节时再让模型明确申请

这个听起来不复杂，但做得好不好，直接决定了你的Agent是"能演示"还是"能干活"。

4.3 从零搭一个Agent的参考架构

如果是为了学习或者快速验证，我习惯用一个极简架构，而不是一上来就上LangGraph、AutoGen这种重框架。极简架构的核心只有三块：

1. 一个LLM核心（负责规划与决策）
2. 一组工具定义（用Function Calling声明）
3. 一个执行循环（LLM输出调用意图 → 代码执行工具 → 结果回填 → 交给LLM继续，直到LLM认为任务完成）

def agent_loop(user_input: str, tools: list[dict], max_steps: int = 5): messages = [{"role": "user", "content": user_input}] for _ in range(max_steps): resp = client.chat.completions.create( model="qwen2.5-14b", messages=messages, tools=tools, tool_choice="auto" ) msg = resp.choices[0].message messages.append(msg) if not msg.tool_calls: # 模型认为不需要调用工具了 return msg.content for call in msg.tool_calls: result = execute_tool(call.function.name, call.function.arguments) messages.append({ "role": "tool", "tool_call_id": call.id, "content": str(result) }) return "达到最大步数，任务未完成"

这个二三十行的循环就已经具备了一个Agent的完整骨架。后面要往这个骨架上加能力，无非是：

• 加记忆（Memory）模块，把长期用户信息放进去
• 加规划（Planning）模块，让模型先拆解子任务再逐一执行
• 加人工审批（Human-in-the-loop）环节，关键操作（比如执行SQL、发邮件）前让用户确认

还有一个2026年绕不开的话题是MCP（Model Context Protocol）。越来越多的工具和平台支持MCP协议，它本质上是一个标准化的工具接入协议——工具方实现一个MCP server，模型侧就能自动发现、调用这些工具，不用像Function Calling那样每次手写结构定义。如果你准备重点发展Agent方向，MCP值得花时间了解一下。

5. RAG落地：为什么你的知识库问答"看起来聪明，实际不中用"

5.1 RAG链路拆解：检索质量比生成能力更关键

RAG（检索增强生成）现在几乎是企业私有知识库问答的标配方案了——把文档切块、向量化、存进向量库，用户提问时先召回相关片段，再让模型基于这些片段生成答案。流程简单，但做得好不好，差距全在细节。

我先说一个反直觉的经验：RAG系统的效果天花板，往往不取决于大模型的生成能力，而取决于检索质量。一个再聪明的模型，你喂给它的相关片段是错的、残缺的、混杂大量噪音的，它也不可能输出正确答案。反过来，只要检索能命中关键段落，哪怕模型弱一点，答案也差不到哪去。

所以做RAG，先把80%的精力花在检索链路上。

5.2 切分（chunk）策略：不要迷信固定长度

文档切分是RAG的第一个坑。很多人直接用固定token长度切，比如每512个token一段，结果把一个完整的概念从中间切断，检索出来的是半截话，模型自然答不全。

我的切分原则很简单：

1. 优先按语义边界切：Markdown标题、段落、列表项，这些天然是语义单元，优先作为切分边界
2. 设置重叠区间：相邻chunk之间保留少量重叠（比如50~100字），避免关键信息恰好落在边界上被截断
3. 结合文档结构做父子分块：父chunk大（比如一个章节），子chunk小（比如一个段落）。检索时先用子chunk做向量召回，命中后把对应的父chunk整体喂给模型，这样既保证了覆准率，又给了模型足够的上下文

如果你用的是LangChain/LlamaIndex这类框架，里面都内置了多种splitter，但我建议还是自己写一个针对你文档格式的解析器，效果通常好于通用方案。尤其是那些有复杂表格、图片说明、脚注的产品手册，通用splitter会切得乱七八糟。

5.3 混合检索 + 重排：2026年RAG的标配操作

过去很多RAG方案只做向量检索（embedding），也就是把query和chunk都转成向量，算相似度。但它有个天生盲区：对专有名词、缩写、精确数字、代码片段极其不敏感。比如用户搜"ABC-123这个订单号"，语义向量很难精确匹配到"ABC-123"这个字符串。

所以2026年生产级的RAG，普遍采用混合检索：向量检索 + 关键词检索（BM25）同时跑，再用一个重排（Rerank）模型对两路结果做融合排序。简单说，向量检索负责找"语义像的"，关键词检索负责找"字面完全匹配的"，重排负责把两路最靠谱的结果排到最前面。

BM25这种传统算法在Elasticsearch/OpenSearch里都是内置功能，不用额外部署；重排可以用专门的交叉编码器模型（Cross-Encoder），比向量检索的精度高一个档次，但速度慢，一般只对top20~50的结果做重排，不影响整体性能。

我踩过一个大坑是：向量化模型的选择不匹配。如果你喂给向量库的文档是中文为主，就不要用一个主要针对英文训练的embedding模型；如果你用的是BGE、M3E这类中文模型，query端和文档端都要用同一个模型切同一个输入格式，不然embedding空间不一致，召回效果会明显打折。

5.4 评估你的RAG：没有评测集的RAG等于盲人摸象

RAG系统上线后最容易被吐槽的一个问题就是"有时候答得很好，有时候答得离谱"。如果不建立一个评测体系，你根本不知道问题出在召回、排序还是生成环节。

我的做法是把RAG评估拆成两个独立指标：

• 召回命中率：针对一批测试问题，人工标注"正确答案出现在哪几个文档片段中"，然后看系统是否能把它们召回到top5/top10。这个指标和模型无关，只看检索链路
• 端到端答案准确率：针对同一批测试问题，看最终生成的答案是否准确。这个指标同时包含检索和生成的影响

一旦分开看，你就能定位瓶颈。如果召回率已经90%了但端到端准确率只有60%，问题大概率在生成环节（比如模型没有忠实引用检索片段）；如果召回率只有50%，那先别调prompt了，去优化切分和检索策略。

你敢信，我接手过好几个号称"上线了RAG但仍然不好用"的项目，最后排查下来都是没有评测集，全凭感觉调参，今天调一下chunk size明天换一下embedding模型，问题始终在原地打转。下决心花两天时间建评测集，是这类项目止血的第一步。

6. 一条可复制的学习路线：从零到能干活要闯过的几关

6.1 先会跑，再研究怎么跑得更快

如果你是从零开始准备进入大模型工程师这个方向，最大的风险不是学不会，而是被信息淹没。网上的资料太多了：从Attention is All You Need到FSDP、vLLM源码、各种框架的源码分析……如果不设边界，很容易在底层原理里绕不出来。

我建议的学习顺序是"先会跑，再研究怎么跑得更快"：

第一阶段：建立手感和全局观（2~4周）

• 熟练用Python调大模型API，理解system/user/assistant消息结构、温度系数、max tokens这些基本参数对输出效果的影响
• 用ollama在本地部署一个7B~14B模型，跑通OpenAI兼容接口
• 用LangChain/LlamaIndex做一个最简单的RAG demo，理解"检索 + 生成"的基本流程
• 看完一篇大模型综述，不要求理解每个公式，但要对Transformer、预训练、微调、RLHF这些核心概念有整体印象

第二阶段：深入工程细节（4~8周）

• 把vLLM部署起来，理解--max-model-len、--gpu-memory-utilization等参数的含义
• 用QLoRA在单卡上微调一个小模型（7B或更小），跑通数据准备、训练、评估全流程
• 做一个带Function Calling的Agent，至少让它能查天气、查数据库、做简单计算

第三阶段：进入真实项目（持续）

• 在GitHub上找开源项目（比如上海交大的"动手学大模型"、各种AI应用模板），选一个做二次开发
• 尝试解决一个真实问题：比如给团队内部做一个文档问答机器人，做公司官网AI客服接口，做一个小领域模型微调
• 把项目部署到云服务器上，设置监控，了解生产环境的基本运维

这个路线的核心思想是以项目驱动学习：你不需要先精通所有底层原理再动手，而是在动手过程中遇到问题、查资料、解决问题，印象反而更深。

6.2 硬件不够怎么办：云GPU是普通人的最优解

很多初学者被"本地部署大模型"这个词误导，以为非得买一张RTX 4090或者A100才能开始。事实是，2026年的云GPU租赁已经非常成熟和廉价了，按小时计费，跑完实验就释放，一个完整的微调实验可能只花几十元。

常用的几个方向：

• AutoDL、恒源云等国内平台：性价比高，适合学（用）生和个人开发者，按卡时计费，有现成的PyTorch镜像
• 阿里云/腾讯云GPU实例：适合需要数据合规、稳定网络的企业项目
• RunPod/Vast.ai（海外）：适合需要访问海外模型和数据的场景

我个人建议的思路是：日常调试、推理、跑demo用本地小模型 + 自己的显卡或Mac的统一内存，真正需要微调的大任务再上云。这样既控制了成本，又保证了开发效率。

如果你的设备足够好，比如有24G以上显存的显卡，那本地就是你的主要战场，云GPU只是偶尔来救急。如果设备一般，也不要焦虑，我见过用MacBook + 云GPU组合完成整个学习路线的人不在少数。

6.3 避坑清单：学习路上最常见的五个误区

最后必须给一份避坑清单，这些是我在带人过程中反复纠正的典型问题：

1. 死磕底层论文，不做工程实践：大模型技术栈更新极快，你花一个月精读的论文可能半年后就过时了，但你会做RAG、会微调、会部署的能力不会过时。原理要懂，但不要在原理里无限深挖。

2. 数据不检查就丢进训练：训练数据里的格式错误、空字段、标签噪声，轻则影响效果，重则让loss爆炸。每一次训练前，先抽样看50条数据。

3. 无脑追求大模型：不是所有场景都需要70B模型。一个7B模型如果量化后速度和成本都合适、效果达标，它就是最优解。工程师的价值是给出最匹配需求的方案，不是炫技。

4. 忽略评估环节：没有评估就没有迭代方向。哪怕只是20条测试用例的人工打标，也比完全没有强。

5. 只学框架不学原理：你用了LangChain、LlamaIndex，可以加速开发，但如果不知道它内部是怎么做检索的，出了问题你连日志都看不明白。框架淘汰很快，原理是通用的。

2026年做AI大模型工程师，最大的感受就是：这个领域变化太快，今天的热门工具半年后可能就被替代了。所以比起追逐每一个新名词，更重要的反而是把底层的那些稳定能力练扎实——部署一个模型的流程、微调数据的工程方法、评估模型的科学思维、排查问题的系统路径。这些能力，不会随着某个框架的过时而贬值。

如果你正走在这条路上，不用焦虑自己是不是学得慢、知道得不够多。我见过太多起点很低但踏踏实实做项目的人，一年之后已经能独立负责整套系统的落地。干这一行，动手做永远是唯一的路。