企业官网建设流程全解析

1. 别急着学“算法”，先搞清楚2026年大模型岗位到底要什么

先说结论：2026年这个节点，大模型已经不是“研究型玩法”，而是“工程化落地”为主。我观察身边从各个方向转进来的开发者，做得好的反而不是那种能背下整篇论文的，而是能快速把模型用起来、调好、部署上线的人。

你如果是小白程序员，目标不该是“把大模型原理推导到我能手推”，而应该是“我从零汇出一条路：会用基础模型 → 会做Prompt → 会搭RAG → 会微调 → 能部署上线”。这条路线走完，你的简历上就有能讲的实战项目，面试时也有能聊的落地细节。

2026年的市场竞争也比前两年更成熟。只看过科普、只会调API的人已经没什么优势，需要有真实项目，最好是你亲手从数据准备、模型选择、训练调优到服务部署都走了一遍。这篇文章把路线拆成六个阶段，每个阶段都给你一个明确的目标、要学的内容、怎么检查自己学会了，以及我踩过的坑。不是让你一次性看完就顿悟，而是让你保存下来，照着走3到6个月。

文章很长，我尽量说人话。所有内容都是我这几年带项目爬坑攒下来的经验，不是文档复述。

1.1 先认清你自己的起点，再决定从哪一步切入

很多小白最大的问题不是不会学，而是不知道自己的起点在哪里。我建议你先做一个自我测评：

• 会不会Python基础语法，能不能读懂函数、类、装饰器？
• 有没有写过简单的PyTorch或TensorFlow代码？
• 知不知道什么是损失函数、梯度下降、神经网络？
• 用没用过API接口，知不知道HTTP请求、JSON格式？

这四类问题分别对应编程基础、深度学习基础、工程基础。如果你的答案大多是“不会”，就从第2章的预修阶段开始。如果编程没问题但没碰过深度学习，那可以直接跳到第3章。如果用过API但没碰过模型训练，那你其实可以从第4章开始，先补Prompt和工具链，再回头补原理和微调。

不搞清楚起点就按“全网最全路线”机械执行，是最容易放弃的。学习路线的意义不是让你从头咀嚼到尾，而是按自己的缺口去补。

1.2 2026年，学大模型的核心价值已经不是“会调包”

我见过太多人学了两个月，最后还是只会对着API写Prompt。这个能力当然有价值，但它没法形成壁垒。真正的价值链条现在越来越清晰：业务问题 → 数据 → 模型选型 → 增能力强 → 微调定型 → 部署上线 → 反馈迭代。

这个链条里，最挣钱的环节不是单点技术，而是把整个链路串起来的能力。你还是那个写业务的程序员，但你处理的对象从“写死规则”变成了“让模型按你预期输出”。

所以要避免几个典型的弯路：

• 花大量时间啃数学，把微积分、线性代数从头刷一遍，结果三个月后还在起步阶段。
• 沉迷刷论文，今天读这篇明天读那篇，就是不写代码。
• 在工具链上过度钻研，今天试试这个框架明天换那个框架，没有完整跑通过一个项目。
• 以为有了大模型就什么都能做，完全不做数据清洗和分析。

这篇文章的路线会刻意压缩这些容易沉迷的环节，把时间投到高频、高复用、能落地的能力上。

2. 六个阶段整体拆解：从预修到部署，每一步都要有“结束标志”

路线一定要设计得有阶段性。每个阶段都有一个明确的交付物，学完能验证自己是不是真的会了。很多人坚持不下来，是因为没有阶段目标，学完感觉“啥都看过、啥都不会”。

我给你的整体路线如下：

整个周期大概4到6个月，每天能投入3到4小时比较合理。如果你有基础，3个月能走完核心阶段，后面再花时间打磨项目细节。

2.1 阶段之间怎么衔接才不会“学了前面忘了后面”

这个路线不是线性的，而是螺旋上升。比如你阶段1学Transformer，阶段3微调又会用回这套知识，阶段4做RAG时还要理解embedding向量，阶段5部署时又和显存、量化相关。

所以我在每一阶段都会安排一个“回收旧知识”的动作。比如阶段2的Prompt工程，本质上是“用自然语言调用预训练能力”，它需要你对生成参数有一定认识。阶段3微调时，你又要回看Transformer的注意力结构，才能理解LoRA为什么要挂在注意力矩阵上。

我自己的习惯是：每个阶段结束，写一篇学习笔记，主题是“我上阶段学的什么，在这个阶段是怎么被用上的”。写不出来就说明没串起来，回头补。

2.2 每个阶段都要能回答三个问题

每个阶段结束时，你要能回答：

1. 这个技术解决的是什么现实问题？
2. 如果不用这个技术，会发生什么？
3. 缺点和局限是什么？

举例子：阶段4学RAG时，你要能说出为什么不用微调，而用向量检索，那就是“微调未必能保证时效性和事实溯源，RAG可以低成本注入最新知识”。同时你也要知道RAG有检索不准的问题，那就要设计重排和回退策略。

带着这三个问题去学，你才不会变成“调包侠”。面试时，这三个问题也几乎是必问的。

3. 阶段0：编程与数学基础，照着“够用就行”的标准来

这一阶段的目标非常明确：你不需要成为数学专家，你只需要能看懂带参数的公式、能写能跑深度学习的Python代码。

数学这块，优先级最高的是“矩阵形状”，也就是维度概念。你要习惯这样思考：一个词向量是[1, 768]，一批32个词就是[32, 768]，乘上权重矩阵[768, 4096]，输出就是[32, 4096]。大模型里大部分公式看不懂，都是因为不理解数据在变形的过程中“形状怎么变”。起初是矩阵乘法，后面是注意力，再到多头拼接，全是形状变换。

概率与统计，你只需要知道“分布”、“采样”、“期望”这几个概念，能理解为什么temperature=0时模型输出几乎固定、为什么top_p会截断低概率词。微积分，知道什么是梯度、为什么学习率太大容易发散就够了。不要陷入推导偏导数的泥潭，更不要为了学而学去啃习题集。

3.1 Python必会的五个技能点

你不需要精通所有Python高级技巧，但下面这些一定要会：

1. 面向对象和类型标注：你会经常看框架源码里的类定义，类型标注能帮你理清接口。
2. 装饰器：很多框架的注册机制、推理缓存、日志都基于装饰器，不会看代码会很吃力。
3. 异步与并发：部署推理服务时，并发请求处理是常事，至少知道async/await和线程池的区别。
4. 生成器与迭代器：处理大文本流式输出时，这是底层机制，比如流式LLM响应。
5. 上下文管理器with：资源管理、模型加载、数据库连接都要用，写错会泄漏资源。

检验办法：用Python写一个命令行多轮对话脚本，能从终端接收用户输入，用Request调用某个模型接口，并把结果流式打印出来。如果这个交作业能自己写出来，说明你已经具备第一阶段继续的条件。

3.2 PyTorch到底学多深够用？跑通一个最小训练循环就够了

很多教程会带你从张量、自动求导、DataLoader、神经网络模块一点点啃。但我的建议是：不用系统刷完官方教程，直接跑一个“最小训练循环”：

• 定义线性层和一个简单的MLP
• 定义损失函数，比如交叉熵
• 构造一份极小的文本映射数据
• 循环训练几步，观察loss变化
• 保存checkpoint并重新加载

当你能把这个循环跑通，你对模型训练的理解会建立起来。后面学微调时，你会发现微调本质上就是在这个循环里加一个“Adapter”，改一下“训练哪部分参数”，其他流程不变。

顺带一提，尽量不要一开始就在本地环境上折腾太久。先跑通代码再说，环境问题后面有的是机会踩。记住我们目标是验证理解，不是搭比赛环境。

4. 阶段1：大模型核心原理，重点拆解Transformer与生成机制

这一阶段是整个路线的地基。它不需要你看懂每一篇论文，但必须理解几个核心概念的实际含义。

Transformer本身，现在主流生成模型几乎都是Decoder-only结构。它的核心模块有几个：词嵌入（把词变成向量）、位置编码（把顺序信息加进去）、多头自注意力（让每个token和上下文建立关联）、前馈网络（对表征做非线性变换）、层归一化和残差连接（让深层网络训练更稳）。

你不需要从论文第一页推导到最后一页，但至少要能画出一个完整的Decoder模块数据流，并说清楚每个阶段的张量形状。

4.1 注意力机制：用代码把它“翻译”成人话

我总觉得注意力机制讲得再玄，都不如直接看代码。下面的代码是一个简化的注意力实现，它能让你理解QKV到底是什么：

import torch import torch.nn.functional as F def scaled_dot_product_attention(query, key, value): # query: [batch_size, heads, seq_len, head_dim] # key: [batch_size, heads, seq_len, head_dim] # value: [batch_size, heads, seq_len, head_dim] d_k = query.size(-1) scores = torch.matmul(query, key.transpose(-2, -1)) / torch.sqrt(torch.tensor(d_k, dtype=torch.float32)) weights = F.softmax(scores, dim=-1) output = torch.matmul(weights, value) return output # 模拟一个batch、2个头、4个token、每个头8维 batch_size, heads, seq_len, head_dim = 2, 2, 4, 8 query = torch.randn(batch_size, heads, seq_len, head_dim) key = torch.randn(batch_size, heads, seq_len, head_dim) value = torch.randn(batch_size, heads, seq_len, head_dim) output = scaled_dot_product_attention(query, key, value) print(output.shape)

核心逻辑就三步：点点乘算相似度、除以根号维度缩放、softmax变成权重再对value加权求和。除以根号维度的原因是防止点积过大导致softmax落入梯度饱和区。这个知识点面试经常问，你要能讲清楚。

多头注意力的含义就是不止算一组QKV，而是切成多组并行算，每个头关注不同子空间的关系。比如有的头关注语法上的主谓关系，有的头关注距离较远但语义相关的词。多头让模型表达能力更强。

4.2 生成机制：为什么同一个模型能输出不同的结果

生成模型是“自回归”的，也就是说，它每次预测的是“下一个token的概率分布”。给定已有的上下文，模型输出一个向量，这个向量经softmax变成词表上每个词的概率。然后你按某种策略从概率分布里采样一个词，接到输入后面继续预测，直到遇到结束符。

最重要的三个采样参数：

• temperature：控制概率分布的形状。温度越低分布越尖锐，倾向于选择高概率词；温度越高分布越平滑，更随机更有创造性。
• top_p（核采样）：从累计概率超过p的最小词集合里采样。比如top_p=0.9，则保留累计概率达90%的那波词，其余全部舍弃。
• repeat_penalty：对已经出现过的token做惩罚，降低重复率。

你如果直接调API，可以把这三个参数当成玩具随便调。但要做工程，就必须理解它们背后的含义：低temperature适合代码生成、翻译、结构化的输出；高temperature适合创意写作和头脑风暴。我做文档助手时，一般temperature设0.1到0.3，否则它太容易自由发挥，编造不存在的配置项。

4.3 Tokenizer和词表：中文里一个“词”到底怎么切

Tokenizer是把文本变成token序列的工具。不同模型用的词表大小不相同，大约在3万到25万之间。中文经常会把常见字和词直接编成token，所以同一个句子不同模型切出来的token数也不完全一样。

为什么要关心这个？因为token数直接决定成本和速度。很多API按token计费，Prompt和输出的总token是成本上限。同时模型上下文长度也是“token数”，不是“字符数”。1个中文字大概占1到2个token，你在设计Prompt的时候要有基本的长度意识。

实操建议：把模型的tokenizer下载下来，随便拿几段中英文跑一下。观察哪些词被拆细了，哪些词是整段保留的。这会帮你理解为什么同样是“深度学习”，在不同词表下token数量会有细微差异。

5. 阶段2：Prompt工程与API开发，先把模型“用对”再谈“调优”

进入这个阶段，你的身份从“学习者”变成了“开发者”。Prompt工程是大模型应用里门槛最低、但上限很高的能力。它的本质不是“措辞”，而是“通过结构化的输入，把复杂任务约束在模型能稳定执行的范围内”。

你先要养成一个习惯：把Prompt当代码工程来写，而不是聊天时随意打的几行字。

一个结构化Prompt至少包含这几部分：

• 角色：让模型从特定视角回答，比如“你是一名资深Linux运维”。
• 任务：明确你要模型做什么，比如“分析下面报错日志，按优先级列出可能原因”。
• 背景：补充必要的上下文，比如“这是某生产环境的错误日志”。
• 输出格式：规定XML、JSON、Markdown表格，或标注“不输出解释”。
• 示例：给一两个few-shot，让模型模仿输出风格。

我来举一个对比示例。差的Prompt是：“帮我分析一下这段日志”。好一点的则是：“你是运维专家，请分析下面这段应用日志，先按严重程度排序，输出JSON格式，字段包括level、message、suggestion，不要输出解释性文字”。

这两个Prompt得到的回复质量完全不是一个级别。第二个Prompt其实就是在给模型“规划一个子程序”。

5.1 多轮对话里的角色管理：System、上下文与记忆

通过API调用大模型时，请求里通常包含一个消息列表，每条消息有role和content。role通常包括system、user、assistant。System是“最高层的指令”，它会持续影响整段对话。很多新人会把System当成随便写写的背景，实际上System Prompt的权重很高，应该放稳定的策略性规则，比如“始终用中文回答”“禁止编造数据”“遇到不懂的明确说不确定”。

你要避免把所有内容都塞进System，那会让每轮对话都消耗大量token，还会稀释指令。更合理的做法是：只在System里放全局规则，把临时性的用户问题放User，把上一轮模型回答放Assistant。

上下文管理是最容易忽略的环节。当你把一个长对话不断往后拼接，超过模型上下文窗口后，早期的内容要么被截断，要么被模型遗忘。工程上解决这个问题的思路很多：滑动窗口式摘要、只保留最近N轮、把重要信息提取成“长期记忆”存库。这个朴素但实用的方案，在小项目里非常有效。

5.2 让模型输出可靠结构：JSON模式与函数调用

2026年，所有主流推理框架和模型API基本都支持“结构化输出”或“函数调用”。这解决了大模型输出不稳定、难以直接对接业务代码的问题。

函数调用的大体机制是：你预先定义一批“工具”，包括名称、描述、参数JSON Schema。当用户提的问题涉及执行操作时，模型不直接给出答案，而是返回一个“函数调用指令”，再由你的业务代码真正执行工具，把工具结果回填给模型，让模型整合成最终回答。

举个例子，我做一个文档问答助手时，定义了一个“查询知识库函数”，参数是查询关键词。用户问“帮我查一下部署遇到403错误怎么办”，模型先决定调用查询函数，我根据返回内容组织答案，而不是让模型凭空编。

这种方式好在三点：可控性强、可审计、能接真实系统。它的底层机理是模型被训练成“在需要外部信息时主动触发工具”，而不是强迫自己记忆所有知识。这也是后面Agent的基础。

5.3 黄金速率与工程健壮性：重试、缓存、限流一个都不能少

真正做产品，模型返回不稳定、被限流、网络抖动是常态。这一阶段一定要学习如何把一个API调用写得健壮。

我建议最低要求是：

• 加入指数退避重试，当服务端返回429或5xx时，按固定倍数递增等待时间重试。
• 对相同或相似请求做缓存，尤其当你的业务里用户会反复问近似问题时，缓存能省下大量成本和延迟。
• 用并发限制控制请求速率，避免某个循环瞬间把额度打满。
• 超时设置一定要有，避免一个模型调用卡住整个服务。

这些工程习惯，在后续部署自有模型时也一样重要。你甚至可以把它封装成一个统一的“模型调用客户端”，在客户端里统一处理重试、日志、tracing。这也是通往高级工程师的好习惯。

6. 阶段3：从“调用模型”到“微调模型”，用LoRA做领域适配

为什么2026年我们仍然需要微调？Prompt能做到的事很多，但有些场景是它做不到的：

• 你需要模型固定输出某种业务格式，比如“识别合同里的甲方、乙方、金额，并输出固定JSON结构，漏掉任何一项都算失败”。
• 你需要模型掌握某个领域的专业术语和规则，比如医疗报告、法律条文、机械参数。
• 你需要控制说话风格，比如公司的客服要求温和礼貌，任何情况都不允许和用户顶嘴。

微调就是对预训练模型做“二次训练”，让它在你的数据分布下更稳定地输出。但你要知道，微调不是“教模型新知识”的首选方式，它更适合“调整输出风格、格式、稳定性和领域偏好”。知识类的信息，更适合用RAG去补齐。

6.1 LoRA到底做了什么，为什么它是小白首选

LoRA，即低秩适应，思想非常优雅。它不修改原来的模型权重，而是在原权重旁边“并行增加一个可训练的低秩矩阵”。推理时，输出等于原始权重和低秩增量共同作用的结果。这样带来的好处是：显存占用小，训练参数少，可以针对同一基座模型同时挂多个不同方向的LoRA，按需切换。

具体到训练时，你要设置的几个关键参数：

• rank（秩）：决定新增矩阵的容量，越大表达能力越强，但训练成本也越高。常见的选择是8、16、32。不是越大越好，小规模数据下rank过大反而容易过拟合。
• alpha：缩放参数，实际影响是“增量矩阵的强度”。一般设置为rank的一半或等于rank，比如rank=16时alpha=16或32，需要微调。
• target_modules：决定LoRA要挂到哪些模块上，最常见的做法是挂到attention层中的q、k、v、o矩阵。不一定要全挂，挂在部分模块上也能有不错的效果，还能省显存。
• dropout：在LoRA的输入上加随机丢弃，能起到一定的正则作用。通常设0.05或0.1，如果数据量很少，可以适当加大。

训练流程和普通深度学习几乎一样：加载基座模型、加载数据集、定义LoRA配置、设置训练参数、训练保存。

6.2 训练数据怎么造，质量永远比数量重要

微调领域有一句老话：数据决定上限，模型决定下限。你花三天清洗数据，胜过用一万条垃圾数据跑十个epoch。

指令数据通常长这样：

{ "instruction": "请判断以下商品描述里是否包含价格信息，并输出JSON", "input": "这款手机采用6.1英寸屏幕，售价4999元。", "output": "{\"has_price\": true, \"price\": 4999}" }

构造这类数据时要注意几个问题：

• 覆盖面要广：你需要定义清楚这个模型上线后会被问什么样的请求，并为每种请求准备足够多的样本。
• 答案要稳定：如果同一个问题在数据里有两种矛盾答案，模型会学到随机。你必须先对答案做一致性校验。
• 负样本不能少：模型需要学会拒绝，比如“这个问题不在我职责范围内”或“这个信息我不确定”。没有负样本的微调模型容易在烂问题上也硬答。
• 不要有数据泄漏：训练集和验证集要按“业务场景”切分，不能是“同一批回答换个问法”，否则测试时看着指标很高，一上生产就崩。

我做某客服场景时，先用真实的历史问答做了500对种子数据，然后让模型自己按照既有风格生成了一批“改写问题”，最后人工一条条过滤。这个过程看着笨，但最终效果远比直接爬一堆通用问答要好。

6.3 微调之后的评估：别只看loss，要看真实业务指标

小白最容易犯的错误是只盯着训练loss，看着loss降了就以为成功了。实际上微调后的模型像一把新的刀具，你说好不好用，得看它在真实任务上的表现。

我推荐的评估方式是按“规则+人工”两级来做：

• 规则部分：对输出格式做自动检查，比如是否能被JSON解析、是否包含指定字段、是否有重复。
• 语义部分：抽一批固定的评测样例，让模型跑一遍，按“准确、部分正确、错误”打分，然后算一个准确率。
• 对比部分：同时用微调前和微调后的模型跑同一批输入，重点看“原来不稳定的地方是不是被修正了”。

如果在评估时发现模型开始“鹦鹉学舌”，把训练语料里的专有名词硬套到无关问题上，那就是过拟合了。这时候要调低epoch、加大数据多样性和正则化，同时把学习率适当降低。

7. 阶段4：RAG与Agent，让模型有能力“查资料再回答”

微调能调整模型的表达风格，但它没法保证所有知识的时效性。RAG就在这个时候出现：让模型在回答前先从外部知识库检索相关资料，基于资料再生成答案。它的最大优势是低成本更新知识、回答可溯源、能有效降低幻觉程度。

整个RAG流程包含五步：文档切分、向量化、存储与索引、检索、生成。每一步都有坑，但都不难。

7.1 RAG的关键不是模型，而是“切分和检索”

很多新人以为RAG就是把一堆PDF扔进向量数据库就完事。真正的麻烦在于“切分”。

文档切分决定了你的检索单元是什么。切得太粗，比如把整篇文章作为一个chunk，查询时匹配到一大段没用的内容；切得太细，比如按每句话切，相关信息可能被拆散到不同chunk里，检索不到完整上下文。

我总结出一个经验：先用“语义完整度”来决定切分点，而不是僵硬地按1000字符切。常见策略是“按标题、章节结构切分”，没有结构时再按固定长度切，并且设置overlap（重叠）区域。overlap的作用是防止一个完整的概念被硬切到两个chunk里。比如一段话在500字处刚好说到一半，如果切点向后挪50字，让下一块重复这50字，就能保证上下文连续可靠。

向量化模型的选择也很重要。中文场景下，建议用开源的embedding模型先跑起来，不要急着上最贵的商用方案。你需要关注的是“检索到的内容是否真的相关”，而不是“向量维度够不够大”。如果你发现检索结果差，先看文档切分是否有问题，再看是否要做混合检索。

混合检索是“关键词检索+向量检索”的组合。关键词检索负责精确匹配专有名词，向量检索负责语义相似匹配。把两类结果合并重排，效果往往比单用向量检索好不少。我在项目里直接用BM25（经典关键词检索算法）和向量检索并行工作，最后再用一个重排模型把Top K结果重新打分排序，实测准确率至少能提升10个百分点。

7.2 从RAG到Agent：让模型自己决定调用哪段知识、哪个工具

Agent相比RAG更进一步。RAG是一个静态流程：你提问，我检索，我回答。Agent则是一个动态循环：给模型一组工具，模型自己判断要不要查知识库、要不要调搜索引擎、要不要运行一段代码、如果发现结果不足，还可以换一种方式继续查。

最常见的Agent设计模式是ReAct：推理与行动交替进行。模型先分析用户意图，说明“我需要查询什么”，然后调工具，看到工具结果后再推理下一步。

举个例子，用户问“我最近在做的某跨平台系统部署时一直报403，帮我排查一下”。一个带Agent的助手会这么做：

1. 判断需要查询知识库，先搜“403”相关文章。
2. 如果知识库没有，决定调用另一个系统日志工具，查最近错误日志。
3. 两个结果都拿到后，综合判断给出可能原因，并给出下一步操作建议。

这个过程中，“是否调用工具”“调用哪个工具”“怎么处理结果”都由模型自己决策。它的可靠性取决于“工具描述的清晰度”和“模型决策的边界”。你在工程上要做的是给工具写足够明确的描述，并设定好安全限制，避免模型做危险操作。

到了Agent这一步，你的技术能力已经能覆盖大多数企业级AI应用的形态了。但别为了Agent而Agent，很多业务用简单的RAG加非常明确的“意图路由”就够了，硬上一套Agent反而不好维护。

7.3 RAG最常见的四个坑，提前帮你排掉

我在这上面踩过的坑列出来，每个都很有代表性：

• 检索不准但生成硬编：模型在检索结果里找不到答案，但又不肯说“不知道”，于是编了一个答案。解决方法是把“未检索到明确信息时必须拒绝回答”写进System，并且打开生成日志。
• chunk太多导致重复片段：多个chunk都命中同一段话，模型被重复信息带偏。做去重机制，只保留和常问问题相关性最高的结果。
• 重排后反而更差：某些重排模型在领域文档上并不比原始匹配好。不要迷信“加个Rerank一定更好”，跑一批评测再决定。
• 向量库索引和文档更新不同步：删掉旧文档后，旧的向量仍在库里，导致模型提到“已经不存在的配置项”。要建立“文档入库时间+来源”的元数据过滤。

这些坑几乎每个做RAG项目的人都会遇到。你在学习阶段就提前知道，可以省出一到两周的调错时间。

8. 阶段5：部署与性能优化，从“能跑”到“接得住并发”

前面所有阶段，模型都在笔记本或远程开发机上跑。等到上线，你得考虑响应速度、并发、显存、稳定性和成本。这一阶段的目标是：把一个微调好的模型部署成高可用的推理服务。

谈到部署，先讲一下硬指标——显存。模型显存占用主要看参数量和精度。以7B模型为例，FP16（半精度）下只是加载权重就约需14GB显存，再加上KV Cache和推理中间状态，实际部署建议准备20GB以上。INT4量化后，权重大约只要4GB，但精度有轻微损失，需要看业务能不能接受。

所以选型时要反向思考：你的显卡有多少显存，决定你能部署多大的模型。下表供你快速估计：

这是经验值，实际占用还受上下文长度、并发数和量化方案影响。你需要用nvidia-smi监控真实显存占用，而不是只看理论值。

8.1 量化：用一点精度换性能，INT4和INT8怎么选

部署阶段几乎离不开量化。量化的直观理解是，把模型的浮点权重从FP16或BF16压缩成更低的整数表示，比如INT8、INT4。这也让模型体积变小、推理速度变快，同时代价是精度略有下降。

具体方案里，最常见的两个是GPTQ和AWQ，通常用于离线量化。它们会在量化过程中基于一小批校准数据计算每层的缩放因子，尽量把量化误差降到最低。这个环节需要你准备一组有代表性的“校准数据”，一般是几十到几百条文本，贴近真实业务场景。

启动推理时要不要用量化？我的判断是：

• 显存很吃紧或要求高并发，上INT4。
• 对输出质量很敏感，且显存允许，就保持FP16或INT8。
• 推理框架本身已经做了算子融合，INT8在很多显卡上其实已经很够用。

实际操作时，永远先在你的业务评测集上跑一遍量化前后的对比。如果量化后错误率没有明显上升，那就可以放心用。

8.2 推理加速：vLLM与PagedAttention，把吞吐量跑上去

多个模型部署框架中，vLLM是目前绕不开的利器。它最核心的创新是PagedAttention，思路可以类比成操作系统里的虚拟内存分页：KV Cache不再为每个请求连续分配固定大小的显存，而是按块分配。这样一来显存利用率更高，更少的显存能承载更高的并发。

另外一个关键特性是continuous batching，它打破了传统“一个batch等最慢的那个请求结束后才释放”的模式，允许新请求随时加入当前批处理，提高整体吞吐。

实际使用非常直接，如果模型本身兼容vLLM，你可以这样起服务：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --dtype auto \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000

启动后你会得到一个和OpenAI格式兼容的API接口，开发体验非常顺畅。它会支持/tokenize、/v1/chat/completions这些常见路径，基本不用改上层代码。

如果你只是想在本地快速验证，而不需要高并发，也可以先用Ollama。它能一键拉模型、自己管理显存，对开发者很友好。到了生产环境，再上vLLM或对应的推理框架。

8.3 服务化上线：从模型文件到稳定的API，中间还有多少事

模型训练完、量化完，不等于“上线”。上线是一整套工程问题：

• 加载模型和LoRA权重，注意路径版本管理。
• 配置生成参数，比如max_tokens、temperature、top_p的默认值。
• 设计API层，包括鉴权、限流、请求日志、错误码统一。
• 处理并发下显存不足的回退策略，比如排队或降级。
• 设置健康检查，监控模型推理延迟、失败率、显存占用。

你可以在服务外面套一层常见的Web框架，把所有“调用模型”的逻辑封装成内部模块。前面阶段写的“模型调用客户端”此时就起作用了，重试、缓存、超时都能直接复用。

还有一个小细节，模型加载很慢，线上启动可能要花几分钟。你在做发布流程时，要考虑滚动发布，不要出现老服务还没就绪就去接新流量的情况。

9. 一个能写进简历的完整实战：把每个阶段的知识串起来

上面阶段都学完，你需要做一个“承上启下”的项目。这个项目最好不是网上查得到的那种“猫狗分类”，而是有点业务价值，能体现出全链路能力。

我建议你做一个“某领域智能助手”，领域可以是你目前的工作、你熟悉的兴趣方向，或者你实习项目中遇到的具体场景。无论哪个领域，最核心的是“你懂数据从哪来、模型怎么选、效果如何评估”。

项目骨架大致如下：

• 需求：选定一个细分场景，比如“某知识库问答”“代码报错排查助手”“某产品客服”。
• 数据：收集线上真实问答记录，清洗、去重、构造指令样本。至少200条答案可靠的种子数据。
• 基座选型：根据显存和业务复杂度选择开源底座模型，7B级别通常是性价比平衡点。
• RAG搭建：把领域相关文档切分入库，建立检索链路，让模型先查后答。
• 微调：用前一步构造的指令数据做LoRA微调，对齐输出格式和语气。
• 评测：建一份不参与训练的评测集，对比微调前与微调后效果。
• 部署：把RAG和微调模型集成到一个API服务里，对外提供统一接口。
• 迭代：上线后收集真实用户反馈，每周更新一次数据和评估结果。

9.1 我建议的时间线，以及每部分花多少时间

如果你每天有3到4小时学习时间，上面这个项目我建议这样切：

• 第1周：确定场景，收集原始数据，把文档整理成可入库的文本。
• 第2周：跑通RAG链路，用未微调模型先做一个粗糙版本。
• 第3周：构造并清洗指令数据，完成第一次LoRA训练。
• 第4周：评估、对比、调参，把服务部署到云端，写文档和展示页面。

到第5周，你手里就会有一个“完整产品”的雏形。剩下的就是打磨细节：提升检索准确率、优化推理速度、补充更复杂的交互场景。

这里有个容易犯的错误：一开始就追求完美数据。我见过很多人在“收集数据”和“清洗数据”上花了两个月，结果还没跑过完整链路。正确的做法是先跑通，再迭代。第一版数据糙一点没关系，只要链路通了，后面用反馈去修正数据，效率更高。

9.2 在简历上怎么讲这个项目，一句话就要让人听出重点

很多面试者把项目写得像功能列表：“用了某模型，用了RAG，用了LoRA”。这不够，你得分层输出：

• 第一步，讲业务背景：“某场景下人工解答问题成本高，需要做一个能引用内部文档并稳定输出格式的助手”。
• 第二步，讲方案权衡：“调研后发现预训练模型在专业术语上表现差，但训练数据量又不足以支撑全量微调，所以选用了LoRA来调对齐，同时保留RAG做实时知识检索”。
• 第三步，讲结果数据：“将评测准确率从xx%提升到xx%，答复中的幻觉问题降低xx%，单次请求平均延迟控制在xx秒内”。
• 第四步，讲你的反思：“发现某一个数据质量问题导致模型输出不稳定，之后加了数据一致性校验，让指标稳定了很多”。

这个表达方式能让面试官快速感知你的工程判断力，而不是只会调参数。毕竟企业招你不是为了看你写多少代码，而是看你面对不确定问题时能不能做一个合理决策。

10. 常见问题排查与避坑实录

我在带人或者自己做项目时，总会遇到一些高频问题。这里整理成一张速查表，你可以直接保存：

10.1 小白最该避开的学习陷阱

学习大模型的路上，我见过太多人踩进同一个坑：追求“原理上完全明白”才开始动手。真相是，你不可能在第一次就把注意力机制理解得通透，但你可以先把它当工具箱里的一个零件，用了很多次之后，某天突然就通了。

也不必非得买一块几十GB的大显存卡才能开始。前期用云服务或开放API完成Prompt工程和RAG阶段，完全没有问题。比如在本地用CPU跑1.5B的小模型，体验全套逻辑，也足够理解整个推理流程。等到了真正训练微调的时候，再考虑租卡，成本也完全可控。

还有一个建议是“不要囤课”。我看过很多人收藏了两百个视频、三四个大模型训练营，结果还是没动手。这个领域变化快，旧课程很可能讲了已经被淘汰的用法。最有效的学习材料始终是官方文档、模型卡、开源仓库里的示例代码，以及你亲手跑出来的报错日志。

10.2 关于学RLHF，要不要放到这个路线里

经常有人问我：“微调之后要不要再加一步RLHF，听说效果更好？”我的回答是：如果你不是做研究，不是在海量数据上打磨顶级模型，现阶段先不要碰。原因很简单：

• RLHF需要高质量的人类偏好数据，成本很高。
• RLHF调参难度大，不稳定，小白直接上手很容易把模型训坏。
• 对绝大多数业务场景来说，指令微调加RAG已经能解决90%的问题，剩下的瓶颈往往在数据质量而非训练范式。

你可以先知道RLHF大致在做什么，了解“奖励模型”“策略优化”这些名词。当你有足够资源和清晰需求时，再去深入研究，这个决定也不迟。

11. 写在最后：几个支撑我坚持下来的实际操作习惯

最后分享三个我个人经常用的习惯，不一定适合所有人，但至少帮我熬过了很多想放弃的时刻。

第一，任务小到“打开编辑器就能做”。不要给自己定“我要学完Transformer”这种大目标，要定“我今晚用代码实现一个缩放点积注意力”。目标越小，心理阻力越低，才更容易坚持。

第二，永远留一份“可复现基线”。不管做微调、RAG还是部署，我都习惯先把一个最笨、最简单的方案跑通，并存好笔记。之后任何新尝试，都拿这个基线去对比。遇到调参调不出来的时候，起码还有一条确定的退路。

第三，给自己做“项目周报”。每周记录我本周做了什么、卡在哪、下周做什么。这个习惯帮我避免“学了一周感觉啥都没干”的虚无感。等三个月后回头翻，你会发现自己已经走过了很长一段路。

大模型这条学习路很长，但方向比速度重要，动手比收藏重要。你不需要一开始什么都懂，只需要沿着路线，一段一段走完。走到部署上线那一刻，你会发现自己已经不自觉地完成了从“小白程序员”到“能独立做AI应用”的转变。到那时候记得回来，把这篇文章转给你身边同样需要路线的人。