企业官网建设流程全解析

最近这大半年，身边做业务、做产品的朋友问我最多的问题，已经从“大模型能不能落地”变成了“我想做个AI助手，到底该不该微调，该用哪个平台和框架起步”。这个问题听起来具体，实际上非常难回答，因为市面上叫“微调框架”的东西实在太多了，而且各自解决的问题完全不同。有的人拿着Hugging Face Trainer就开始全参微调，结果一张A100都不够用；有的人上来就买托管API的按token计费，业务还没跑通先烧掉几万块；还有人花两周时间折腾部署框架，最后发现自己的LoRA权重压根没被正确加载。这篇文章我想从自己实际用过、带团队踩过坑的12个框架和平台出发，按“训练侧、推理侧、托管平台、应用层”四层拆开讲，最后给一份可以直接对着勾选的选型指南。无论你是手里只有一张消费级显卡的独立开发者，还是准备上云做企业级AI助手的团队，都可以按图索骥。

1. 2026年还要不要自己做微调？先把三个前置问题想清楚

1.1 提示工程、RAG、微调的分界线到底在哪

我见过太多的项目，在“是否需要微调”这个问题上判断失误，导致整个技术路线跑偏。一个非常典型的场景是：有人想做一个某个垂直领域的客服助手，第一反应就是把领域知识灌进模型，让模型“学得更懂行”。但实际上，大部分文档问答类需求，用RAG（检索增强生成）在外部挂一个知识库，就能解决得非常好。RAG的本质是给已经会说话的模型配一本可以随时查阅的参考书，它不需要改变模型本身的说话能力。

真正到了需要“微调”这一步，通常会出现几个RAG和提示工程解决不了的问题：

• 语气和风格必须极度稳定，不允许出现“根据资料显示”这类模板化措辞，而是要整个团队统一的商业口吻。
• 输出格式有强约束，例如必须输出特定结构的JSON、特定长度的摘要，且不能容忍任何跑偏。
• 专有术语的准确率要求很高，例如私有的芯片型号命名规则、医疗检查项目缩写，RAG检索不到或检索到了模型也读不懂。
• 模型需要学会一个“新行为”，比如按照固定的多轮对话策略引导用户，而不仅仅是从知识库里找答案。

如果只是想让助手回答得更准确，先检查RAG；如果想让助手回答得更像“你自己”，才轮到微调登场。微调不是万能的，它改变的是模型的风格、行为和特定格式能力，而不是给模型硬塞新知识——塞进去也容易忘，这正是很多团队把几千条文档直接拿去微调之后效果反而变差的原因。

1.2 搞清楚你要做的微调属于哪一类

对大多数AI助手项目来说，微调其实有三种完全不同的子类型，它们的数据格式、训练方式和计算成本都不一样。

增量预训练（继续预训练）是在通用模型的基础上继续灌入大量领域语料，让模型学到领域词汇和专业表达。这需要几十GB甚至更多的数据，成本很高，通常只有需要真正“领域大模型”的机构才会做。

指令微调（SFT）是最常见的一类，也就是“问题-答案”式的监督训练，让模型学会在收到什么样的指令时给出什么样的回复。大多数AI助手风格的统一、回答格式的对齐，都是靠这一层完成的。

偏好对齐（DPO/RLHF）是在SFT之后进一步让模型的回答向“更受欢迎”的方向优化，典型做法是准备一些好/坏回答的对比数据。DPO是目前中小团队最容易上手的对齐方式，因为它训练稳定，资源开销也比经典RLHF低很多。

个人AI助手项目和绝大多数企业内部助手，实际上只需要做SFT，顶多再补一层DPO。如果谁一上来就跟你讲“要做增量预训练”，你先问问他准备了多少数据。没有几十GB精洗过的领域语料，这条路就是花钱买个心理安慰。

1.3 先算明白这笔账再动手

动手之前，先回答三个问题：你有多少条高质量数据？你手里有什么级别的算力？你希望这个模型用多久？

数据条数在几千条以下，微调收益通常不如提示工程。数据在1到5万条之间，LoRA/QLoRA 这条轻量微调路线性价比最高。数据到了几十万条，才需要考虑全参微调或更复杂的训练方案。算力也是一样的逻辑：只有一张RTX 3090/4090级别的显卡，就别想着做8B模型的全参微调了，QLoRA在这个量级下已经能跑得很漂亮。若是模型要长期对外服务、承担核心业务，那部署和监控的成本也得提前算进去，这些往往比训练本身更贵。

2. 训练侧第一梯队：Hugging Face生态、PEFT、Unsloth、Axolotl怎么选

2.1 Hugging Face Transformers + PEFT的搭配逻辑

这里要说的第一个“框架”，其实是Hugging Face生态里的组合拳：Transformers作为模型加载和训练的基础库，PEFT（Parameter-Efficient Fine-Tuning）作为轻量微调的核心组件，里面最知名的就是LoRA和QLoRA。

PEFT的核心思想非常直接：冻结住预训练模型绝大部分权重，只训练一小部分新增的参数。LoRA的做法是在Attention层的权重旁边插入低秩矩阵，用这两个小矩阵的乘积去近似原权重的变化量。打个比方，整本教科书不用重写，只需要在几个关键章节夹几张便签纸，写上新批注，最终阅读的时候把原书内容和便签内容叠加在一起看。训练完以后，这几张便签纸就是LoRA权重，可能只有几十到几百MB，而基座模型十几GB的权重完全不用动。

用Transformers + PEFT做SFT的关键代码并不复杂，大致长这样：

from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training import torch model_id = "meta-llama/Llama-3.1-8B-Instruct" tokenizer = AutoTokenizer.from_pretrained(model_id) model = AutoModelForCausalLM.from_pretrained( model_id, load_in_4bit=True, # QLoRA的入口：先把基座量化到4bit torch_dtype=torch.bfloat16, device_map="auto" ) model = prepare_model_for_kbit_training(model) lora_config = LoraConfig( r=64, # 低秩矩阵的秩 lora_alpha=128, # 缩放系数，通常取r的2倍 target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], lora_dropout=0.05, bias="none", task_type="CAUSAL_LM" ) model = get_peft_model(model, lora_config)

训练时用Hugging Face的Trainer，设置好学习率、批次大小、梯度累积步数，跑就完了。整套流程下来，单张24GB显存的显卡可以训练8B模型，如果是7B级别则RTX 4070 Ti Super这类16GB显卡也能跑。

2.2 LoRA和QLoRA节省显存的核心原理

很多同学不明白为什么QLoRA能用消费级显卡训大模型。拆开看就清楚：LoRA本身解决的是“可训练参数量”的问题，原本需要更新几十亿参数，现在只需要更新几百万参数，优化器状态的内存占用大幅缩小。但基座模型本身还是要加载到显存里，7B模型就算用16bit加载也要14GB显存。QLoRA进一步把基座模型量化到4bit，也就是约4GB左右，训练时计算也尽量在低精度下完成，整体显存占用就降到了单张卡能扛住的范围。

以7B模型为例，纯LoRA训练通常需要20GB以上显存，QLoRA则能压到12-16GB。13B模型QLoRA大约需要20GB左右。这套组合拳下来，普通人手里的游戏显卡也能体验一把“训大模型”的快乐。

不过代价也不是没有。QLoRA低精度量化带来的数值精度损失，在大多数业务场景里几乎无感，但如果你的任务本身对精度极其敏感，比如数学推理或严格的代码生成，建议至少用LoRA甚至全参微调。实测下来，数学类任务中FP16的LoRA比4bit QLoRA准确率高那么一两个点，这个差距有时候会决定业务是否能用。

2.3 Unsloth：把训练速度题重新做的开源库

如果你觉得Transformers + PEFT已经是“标准答案”，那么Unsloth就是试图把答案的分数从80分提到98分的东西。它不是一个独立的训练范式，而是对LoRA/QLoRA训练过程的内核进行了重写优化，包括手动优化算子、改进KV cache实现、减少不必要的显存碎片化。

我的实测感受是：用同一张RTX 3090微调Llama 3.1 8B，Unsloth比原生HF Trainer大概快2到3倍，显存占用还能省三到四成。对于“每天都要迭代一版模型”的节奏来说，这个差距意味着下班前能不能跑完实验，非常关键。代码上手成本也低，API几乎照抄HF的流程，但它默认就做了很多优化，不需要你手动开gradient checkpointing之类的东西，导入它自己的版本即可。

pip install unsloth

Unsloth适配的模型范围在快速扩大，主流的Llama 3系列、Mistral、Qwen系列都支持得很好。它的局限在于，如果你要做的不是标准的因果语言模型微调，而是某些特殊改造，那就不一定有对应的优化内核，这时候老老实实回到Transformers + PEFT。

2.4 Axolotl：适合团队标准化和实验复现的配置驱动框架

Axolotl是另一个我越用越顺手的开源框架，尤其适合团队协作场景。它的核心理念是“一切皆配置”，把模型定义、数据集路径、训练超参数、LoRA配置、是否用Flash Attention、是否用DeepSpeed等等全部塞进一个YAML文件里。只要这个文件写好了，一条命令就能开始训练：

axolotl train config.yml

这个设计带来了一个在团队里非常宝贵的特性：可复现性。团队成员A跑了一版效果不错的模型，把config.yml丢到群里，成员B在自己的机器上就能跑出一模一样的配置，不会出现“我这边能训你那边崩了”的玄学问题。Axolotl还整合了DPO、Flash Attention、DeepSpeed、多卡分布式训练等能力，很多开源模型的官方复现教程用的就是它。

它的缺点也比较明显：配置项非常多，刚上手容易被上百个字段吓到；文档虽然齐全，但很多字段要真正踩过坑才知道是干嘛的。建议在单卡个人项目里先用Unsloth跑通实验，等团队协作或需要严格管理实验配置时，再迁移到Axolotl。

2.5 训练框架选择的本质：先跑通流程，再谈优化

我把话说直白一点：对大多数做AI助手的团队，训练框架的选择远没有你想的那么重要。数据质量决定效果的下限，训练框架只影响你的迭代效率。先用Unsloth或PEFT把一个几十条样本的迷你实验跑通，确认数据格式正确、训练曲线正常、部署能跑，再去扩展数据规模、调整训练时长，这才是最稳的路径。

3. 模型训完后的现实问题：推理部署侧必须考虑的vLLM、TGI与LocalAI

3.1 为什么说推理侧才是真正检验微调成果的分水岭

我见过很多团队在微调阶段非常顺利，loss降得很漂亮，生成的样例看着也像模像样，结果一到上线部署阶段就卡壳。模型推理速度和并发吞吐完全拉胯，一个8B模型用最朴素的Transformers接口做服务，单并发响应慢不说，一旦有五六个人同时访问，GPU直接被打满，请求排队排到天荒地老。

这就是部署框架存在的意义。微调只是把模型变成了一个“有潜力”的大脑，推理框架才是让它真正能被人流畅使用的中枢神经系统。在这一层，我会优先推荐三个选择：vLLM、Hugging Face TGI、LocalAI。

3.2 vLLM：高吞吐与工程生态的当前最优解

vLLM最核心的武器是PagedAttention。它的原理是把KV Cache拆分成固定大小的“页”，像操作系统管理内存一样管理显存，避免了KV Cache碎片化带来的浪费。直观感受就是：同样的显存，vLLM能支撑的并发数和吞吐量要比朴素推理高出一大截，通常单张A100跑7B模型可以轻松支撑几十甚至上百路并发请求。

启动一个OpenAI兼容的服务非常简单：

vllm serve /path/to/merged_model \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --dtype bfloat16

vLLM还支持LoRA Adapter的动态加载，也就是说如果你不想把LoRA权重合并进基座模型，可以直接在服务启动时指定 --enable-lora 和相关参数，运行时按请求切换不同的LoRA插件。这在做多租户场景时非常有用——同一个基座模型，每个客户挂一个自己的LoRA，成本和运维压力都会显著下降。

不过vLLM也确实偏向“高性能服务器”定位，对个别冷门模型架构的兼容性偶尔会出问题。所以我通常建议：正式使用前先跑一遍启动测试，确认你的模型架构在当前vLLM版本里被正确支持。

3.3 TGI：Hugging Face生态内的稳妥选择

TGI（Text Generation Inference）是Hugging Face官方的推理服务器，支持连续批处理、张量并行、流式输出、OpenAI兼容API等主流特性。它和Hugging Face生态的契合度是最高的，如果你整个流程都深度依赖HF Hub，用TGI会非常顺手。

与vLLM相比，在中低并发场景下两者差距不明显，但高并发下vLLM的吞吐优势更明显，社区活跃度和新模型适配速度也更快。TGI的优势在于开箱即用的模板和多卡并行配置相对简单，而且官方支持稳定，不容易出现“版本追上不模型”的问题。我的经验是：如果你已经重度使用HF全家桶且不太想折腾，TGI是真省心；如果对性能有极致要求，或者需要很多社区新特性，vLLM值得优先。

3.4 LocalAI：不堆GPU也能跑的本地化方案

LocalAI完全站在另一个维度思考问题。它不追求极致性能，而是主打“本地化、无GPU也能跑、兼容OpenAI API”。它能在纯CPU环境或者普通家用机里运行量化后的模型，把本地模型包装成一个OpenAI兼容接口，让上面所有应用层代码完全不用改，只需要把API Base地址从api.openai.com换成LocalAI的地址。

适合它发挥的场景很明确：原型验证、边缘设备、内网隔离环境、数据不能外流的保密项目。甚至在一些边缘计算盒子上跑个小模型做离线辅助，LocalAI也是有效的方案。代价当然是速度，CPU推理一枚7B量化模型，每秒只能出几个token，体验远不如GPU部署，所以只适合对实时性要求不高的场景。

4. 不想碰GPU的人怎么办：OpenAI、Vertex AI、Azure三大托管微调平台

4.1 OpenAI Fine-tuning API：最适合先把业务流程跑通的选择

如果说前面的训练体系都需要你拥有至少一块像样的显卡，那么托管平台就是交付给云厂商去处理算力问题。OpenAI Fine-tuning API是门槛最低的一个。

准备数据的格式是JSONL，每一条对应一组多轮对话：

{"messages": [{"role": "system", "content": "你是一个资深的咖啡品鉴助手，回答简洁专业。"}, {"role": "user", "content": "什么是日晒处理法？"}, {"role": "assistant", "content": "日晒处理法是把采摘后的咖啡樱桃直接摊晒干燥，再脱壳取豆。它往往会带来更强的发酵感和更丰富的果香。"}]}

把足够规模的这类数据整理好，用一行Python脚本就能发起训练任务：

from openai import OpenAI client = OpenAI() job = client.fine_tuning.jobs.create( training_file="file-xxx", model="gpt-4o-mini", suffix="coffee-assistant-v1" ) print(job.id)

训练完成后你会得到一个专属的模型名称，通过标准API直接调用。整个过程不需要关心CUDA、显存、分布式训练，甚至连训练曲线的解读都不需要太操心，OpenAI会在训练结束时把评估指标发给你。

但这个平台的适用边界也很明显。第一，你的业务数据会给到第三方厂商，很多对数据隐私有严格要求的企业直接排除；第二，你只能以OpenAI提供的基座模型作为起点，无法选择Llama或Qwen做底层；第三，按token计费的模式在大规模训练和反复调参时会非常昂贵。我的观点很明确：OpenAI Fine-tuning API适合产品早期快速验证“微调路线是否有效”，一旦确认有效且业务量开始增长，就要考虑自建训练和部署的降本方案了。

4.2 Vertex AI：企业级数据治理与Google生态的结合

如果团队已经深度使用Google Cloud，Vertex AI在模型微调和部署上的完整度非常高。它支持Gemini系列模型的有监督微调，也支持对部分开源模型进行LoRA调优；在平台侧集成了数据处理、实验追踪、模型评估、端点部署、模型监控一条龙能力。

对于真正意义上的企业用户，Vertex AI最值钱的是它的数据治理和安全体系：权限管理细粒度到数据集级别，训练用的数据可以放在自己的存储桶里，审计日志齐全。如果你面对的是“必须通过合规审计才能上线”的业务，这些能力比单纯跑通一个模型重要得多。缺点也很现实：进入门槛高，控制台的各种概念对新手极不友好；国内访问不便；账单复杂，稍微配置不当就可能出现成本失控。

4.3 Azure Machine Learning：把微调能力嵌入现有IT体系

Azure ML在企业用户那里的受欢迎程度，很大程度上是因为微软把AI能力和企业IT体系绑得很深。如果你的业务已经在用Azure Active Directory、Power Platform、甚至Windows生态，那么Azure ML完全可以把模型微调包装成企业内部的一个标准流程。

Azure ML支持微调包括Llama、Phi等在内的多个开源模型，也支持Azure OpenAI Service的整体托管。训练完成后可以把模型注册到模型仓库里，一键部署成托管端点，自动获得负载均衡、弹性扩缩容版本灰度等能力。对很多运维能力薄弱的团队来说，这确实是最省心的企业级方案。和Vertex AI一样，它的核心适用前提是你已经接受了微软云生态，谈不上跨云通吃。

4.4 三个托管平台怎么选，我总结成一张表

5. 微调之后还要建“AI助手”：Dify与LangChain的应用层衔接

5.1 Dify：可视化编排AI助手的最佳起点

模型微调好、部署好，离“AI助手”其实还差一层。用户不会直接对着模型的API说话，他面对的是一个带对话框、知识库、工具调用、会话管理的完整应用。这正是应用层框架要解决的问题，也是我推荐的第十一个框架——Dify的用武之地。

Dify是开源的LLMOps平台，把Prompt管理、知识库检索、工具调用、Agent工作流、日志追踪都做成了可视化界面。你可以在一个页面里配置“当用户提问时，先从知识库检索相关资料，再交给微调模型生成回答”，整个过程不需要写代码。这种可视化的价值不仅在于开发快，还在于业务人员也能参与调试和优化Prompt。微调模型和Dify的对接方式非常简单：只要你的模型服务提供了OpenAI兼容的API地址，在Dify设置里填上Base URL和API Key就能用。

5.2 LangChain：灵活但需要自控力

LangChain是这个生态里绕不开的名字，但它的口碑一直比较分裂。喜欢它的人认为它把所有Agent组件都抽象成了统一接口，搭积木一样就能实现复杂的调用链；讨厌它的人抱怨它版本升级太过频繁、抽象层级太多，一个小改动就可能牵扯一片。

我的态度是：LangChain适合那些已经明确自己要做的AI助手流程比较复杂、需要深度定制代码的团队。比如你要一个Agent自主决定调用哪些工具、根据中间结果不断更新执行计划，LangChain的框架和社区样例能少走很多弯路。但如果你只需要一个“输入问题→检索资料→模型回答”的固定流程，强行上LangChain只会增加维护成本，Dify的可视化编排已经绰绰有余。

5.3 微调模型接入应用层的三个高频坑

微调模型和应用层之间的衔接，看起来只是一个API对接，实际踩坑点不少。

第一个坑是“系统提示词与微调行为打架”。有些团队把大量精力花在微调阶段，希望模型自动使用某种语气，结果在应用层的提示词编排里又专门写了一大段严格限制语气的system prompt。微调学到的行为和系统提示词互相干扰，最终效果往往不如单独依赖其中一种。

第二个坑是“期望模型记住知识”。不少团队在应用层把微调模型当数据库用，提问时不做检索，直接让模型“回忆”训练时见过的业务资料，效果可想而知。微调模型是行为专家，不是数据库，知识部分还是应该交给RAG来处理。

第三个坑是日志与监控缺失。上线AI助手之后，如果没有记录每一次请求的输入、输出、延迟、Token消耗，你的优化就只能靠猜。一旦用户反馈变差，连问题出在检索、模型还是提示词都不清楚。Dify这类平台自带日志能力，自己在LangChain上做开发时务必提前考虑。

6. 直接照着抄的2026年选型清单

6.1 四个判断维度，先给自己画个像

把上面这些框架和技术路线梳理完后，我认为做选型决策只需要盯住四个维度：算力、数据规模、团队技能栈、合规约束。

算力决定了你是否有资格走开源自建路线，手里没有一块16GB以上显存的显卡，也没有云GPU预算，那就直接考虑托管平台。数据规模决定了你是做LoRA还是全参微调，起步阶段永远从LoRA开始。团队技能栈决定了你用Dify还是LangChain——没有正经后端工程能力的人，先选Dify；有强工程团队且需要深度定制，再碰LangChain。合规约束则是一票否决项，数据不能出域，就别上OpenAI托管平台，老老实实自建LocalAI或vLLM。

6.2 按场景组合的推荐配置

我整理了四个最常见的画像，你们可以直接对号入座。

个人开发者，只有单张消费级显卡，做自己的AI助手产品原型，推荐组合是Unsloth训练、vLLM部署、Dify搭应用。这个组合迭代快、成本可控、踩坑资料也最多。

小型创业团队，有一定GPU资源，需要把AI助手做成稳定的产品线，推荐Axolotl做训练配置管理、vLLM为主部署、LangChain做深度应用定制。这套组合适合流程复杂、需要快速试错和沉淀工程资产的场景。

企业内部工具或客服助手，不追求极致定制，只想快速用上AI能力，推荐OpenAI Fine-tuning API或Azure ML做微调，配合Dify快速上线。记住把数据安全边界先确认好。

边缘或内网部署场景，模型需要本地跑，不依赖外部API，那么train用Unsloth，推理用LocalAI或TGI，应用层如果资源有限甚至可以不用框架，直接用轻量API封装。

6.3 我踩过坑之后最想提醒你的一件事

最后说一个我自己的真实体会：不要在项目第一天就在“选哪个微调框架”上花太多时间。先用一套你眼前最顺手、文档最全的方案——无论是Hugging Face生态还是OpenAI托管API——把一条最小路径跑通，让AI助手能回答三个你预设的问题。这个最小闭环一旦成立，你会立刻知道瓶颈在数据、在模型、还是在外层流程。很多AI助手项目最终失败，并不是因为框架选错了，而是卡在“永远在准备、永远没上线”的循环里。先交付一个能用的东西，再逐步把训练和部署迁移到更优的方案，这才是我所见过所有成功项目的共同路径。