sanbuphy
3af119a598
- 新增 Vibe Coding 全栈相关演示组件 (DeveloperSkillShift, FrontendTriad, BackendCore 等) - 新增 RAG 相关组件 (RAGPipeline, ChunkingStrategy, Retrieval 等) - 新增 Embedding & Vector 相关组件 (EmbeddingConcept, VectorSimilarity 等) - 新增 AI Native App 设计组件 (AINativeArch, PromptDesign 等) - 新增 Infrastructure as Code 组件 (IaCConcept, TerraformWorkflow 等) - 新增 DNS & HTTPS 演示组件 (DnsResolution, HttpsHandshake 等) - 新增 Model Finetuning 组件 (FinetuningPipeline 等) - 更新多个章节的 markdown 内容，集成交互式演示
174 lines
9.2 KiB
Markdown
174 lines
9.2 KiB
Markdown
# 模型微调与部署
|
||
|
||
::: tip 前言
|
||
**大模型很强，但它不懂你的业务。** GPT-4 能写诗、能编程，但它不知道你公司的产品术语、不了解你行业的专业规范。微调（Fine-tuning）就是让通用大模型"学会"你的专业知识的过程——就像给一个博学的通才做岗前培训，让它变成你的领域专家。
|
||
:::
|
||
|
||
**这篇文章会带你学什么？**
|
||
|
||
学完这章后，你将获得：
|
||
|
||
- **流程认知**：掌握从数据准备到模型上线的完整微调流水线
|
||
- **数据工程**：了解微调数据的格式要求和质量标准
|
||
- **高效微调**：理解 LoRA 等参数高效微调技术的原理和优势
|
||
- **模型压缩**：掌握量化技术如何让大模型在消费级硬件上运行
|
||
- **部署实践**：了解模型服务的主流架构和选型策略
|
||
|
||
| 章节 | 内容 | 核心概念 |
|
||
|-----|------|---------|
|
||
| **第 1 章** | 微调流水线 | 数据→训练→评估→部署 |
|
||
| **第 2 章** | 训练数据 | 数据格式、质量控制 |
|
||
| **第 3 章** | LoRA 微调 | 低秩适配、参数高效 |
|
||
| **第 4 章** | 模型量化 | FP16、INT8、INT4 |
|
||
| **第 5 章** | 模型部署 | 推理服务、API 网关 |
|
||
|
||
---
|
||
|
||
## 0. 全景图：为什么需要微调？
|
||
|
||
大语言模型的训练分为两个阶段：**预训练**和**微调**。预训练是在海量通用数据上学习语言能力，微调是在特定任务数据上学习专业能力。
|
||
|
||
打个比方：预训练像是上大学——学习通识知识，什么都懂一点；微调像是入职培训——针对具体岗位学习专业技能。
|
||
|
||
::: tip 什么时候需要微调？
|
||
- **特定输出格式**：需要模型始终以固定 JSON 格式输出
|
||
- **专业领域知识**：医疗、法律、金融等领域的专业术语和规范
|
||
- **语言风格迁移**：让模型用特定的语气、风格回答（如客服话术）
|
||
- **小众语言支持**：提升模型在特定语言上的表现
|
||
- **成本优化**：用小模型微调替代大模型调用，降低推理成本
|
||
:::
|
||
|
||
---
|
||
|
||
## 1. 微调流水线：从数据到上线的完整旅程
|
||
|
||
微调不是"把数据丢给模型就完事"。它是一个严谨的工程流程，每个环节都会影响最终效果。
|
||
|
||
<FinetuningPipelineDemo />
|
||
|
||
::: tip 微调的五个阶段
|
||
1. **数据准备**：收集、清洗、标注训练数据，这是最耗时也最关键的环节
|
||
2. **模型选择**：选择合适的基座模型（Base Model），如 Llama 3、Qwen、Mistral
|
||
3. **训练配置**：设置学习率、batch size、epoch 数等超参数
|
||
4. **训练执行**：在 GPU 上运行训练，监控 loss 曲线和评估指标
|
||
5. **评估上线**：在测试集上评估效果，通过后部署为 API 服务
|
||
:::
|
||
|
||
| 阶段 | 关键动作 | 常见陷阱 |
|
||
|------|---------|---------|
|
||
| 数据准备 | 清洗、去重、格式化 | 数据质量差导致模型"学坏" |
|
||
| 模型选择 | 评估基座模型能力 | 模型太大训练不动，太小效果差 |
|
||
| 训练配置 | 调整超参数 | 学习率过高导致灾难性遗忘 |
|
||
| 训练执行 | 监控 loss 和指标 | 过拟合、训练不收敛 |
|
||
| 评估上线 | A/B 测试、灰度发布 | 测试集泄漏导致评估虚高 |
|
||
|
||
---
|
||
|
||
## 2. 训练数据：微调效果的天花板
|
||
|
||
在微调中有一句老话：**"Garbage in, garbage out"**。训练数据的质量直接决定了微调效果的上限。100 条高质量数据的效果，往往好过 10000 条低质量数据。
|
||
|
||
<TrainingDataDemo />
|
||
|
||
::: tip 微调数据的三种常见格式
|
||
1. **指令格式（Instruction）**：最常用的格式，包含 instruction（指令）、input（输入）、output（期望输出）三个字段。适合训练模型遵循指令。
|
||
2. **对话格式（Chat）**：多轮对话形式，包含 system、user、assistant 角色的消息列表。适合训练聊天机器人。
|
||
3. **补全格式（Completion）**：简单的 prompt-completion 对，适合文本生成、代码补全等场景。
|
||
:::
|
||
|
||
| 数据质量维度 | 说明 | 检查方法 |
|
||
|------------|------|---------|
|
||
| 准确性 | 答案必须正确无误 | 人工审核、专家校验 |
|
||
| 一致性 | 相似问题的回答风格一致 | 抽样对比检查 |
|
||
| 多样性 | 覆盖足够多的场景和变体 | 统计问题类型分布 |
|
||
| 去重 | 避免重复样本导致过拟合 | 文本去重、语义去重 |
|
||
| 数据量 | 通常 500~5000 条高质量数据即可 | 从少量开始，逐步增加 |
|
||
|
||
---
|
||
|
||
## 3. LoRA：用 1% 的参数实现 90% 的效果
|
||
|
||
全量微调（Full Fine-tuning）需要更新模型的所有参数——对于一个 70B 参数的模型，这意味着需要数百 GB 的显存和大量的 GPU 算力。对大多数团队来说，这不现实。
|
||
|
||
LoRA（Low-Rank Adaptation）提供了一个优雅的解决方案：**冻结原始模型参数，只训练一小组新增的低秩矩阵**。这些矩阵的参数量通常只有原模型的 0.1%~1%，但能达到接近全量微调的效果。
|
||
|
||
<LoRADemo />
|
||
|
||
::: tip LoRA 的核心思想
|
||
原始模型的权重矩阵 W 是一个巨大的矩阵（如 4096×4096）。LoRA 不直接修改 W，而是在旁边加一个"旁路"：W' = W + BA，其中 B 和 A 是两个小矩阵（如 4096×8 和 8×4096）。训练时只更新 B 和 A，原始 W 保持不变。
|
||
- **秩（Rank）**：r 值越大，表达能力越强，但参数量也越多。通常 r=8~64 就够用
|
||
- **合并部署**：训练完成后，可以把 BA 合并回 W，推理时零额外开销
|
||
:::
|
||
|
||
| 微调方式 | 可训练参数 | 显存需求 | 训练速度 | 效果 |
|
||
|---------|-----------|---------|---------|------|
|
||
| 全量微调 | 100% | 极高 | 慢 | 最好 |
|
||
| LoRA | 0.1%~1% | 低 | 快 | 接近全量 |
|
||
| QLoRA | 0.1%~1% | 更低 | 中等 | 略低于 LoRA |
|
||
| Prompt Tuning | < 0.01% | 极低 | 很快 | 有限 |
|
||
|
||
---
|
||
|
||
## 4. 模型量化：让大模型"瘦身"
|
||
|
||
一个 70B 参数的模型，如果用 FP32（32 位浮点数）存储，需要 280GB 显存——没有几块顶级 GPU 根本跑不起来。量化（Quantization）技术通过降低数值精度来压缩模型体积，让大模型能在消费级硬件上运行。
|
||
|
||
<ModelQuantizationDemo />
|
||
|
||
::: tip 量化的核心权衡
|
||
量化本质上是**精度换空间**的权衡。FP32 → FP16 几乎无损，INT8 有轻微损失，INT4 会有明显但通常可接受的质量下降。关键是找到你场景下的最佳平衡点。
|
||
- **FP16（半精度）**：体积减半，质量几乎无损，是训练和推理的默认选择
|
||
- **INT8（8 位整数）**：体积再减半，质量损失很小，适合大多数推理场景
|
||
- **INT4（4 位整数）**：体积仅为 FP32 的 1/8，质量有一定损失，适合资源受限场景
|
||
:::
|
||
|
||
| 精度 | 每参数字节 | 70B 模型体积 | 质量损失 | 适用场景 |
|
||
|------|-----------|-------------|---------|---------|
|
||
| FP32 | 4 字节 | ~280 GB | 无 | 训练基准 |
|
||
| FP16 | 2 字节 | ~140 GB | 几乎无 | 标准训练和推理 |
|
||
| INT8 | 1 字节 | ~70 GB | 很小 | 生产推理 |
|
||
| INT4 | 0.5 字节 | ~35 GB | 可接受 | 边缘设备、本地部署 |
|
||
|
||
---
|
||
|
||
## 5. 模型部署：从实验室到生产环境
|
||
|
||
模型训练好了，量化压缩了，最后一步是把它部署成可供调用的服务。模型部署不只是"把模型跑起来"，还涉及并发处理、负载均衡、成本控制等工程问题。
|
||
|
||
<ModelServingDemo />
|
||
|
||
::: tip 三种主流部署方案
|
||
1. **API 服务商**：直接使用 OpenAI、Anthropic 等厂商的 API。零运维，按 token 付费，适合快速验证和中小规模使用。
|
||
2. **自托管推理服务**：用 vLLM、TGI 等框架在自己的 GPU 服务器上部署。成本可控，数据不出域，适合有隐私要求或大规模调用的场景。
|
||
3. **Serverless 推理**：使用 AWS SageMaker、Replicate 等平台，按请求付费，自动扩缩容。适合流量波动大的场景。
|
||
:::
|
||
|
||
| 部署方案 | 成本模型 | 延迟 | 运维复杂度 | 适用场景 |
|
||
|---------|---------|------|-----------|---------|
|
||
| API 服务商 | 按 token 计费 | 中等 | 零 | 快速原型、中小规模 |
|
||
| vLLM 自部署 | GPU 租赁费用 | 低 | 高 | 大规模、隐私敏感 |
|
||
| Serverless | 按请求计费 | 冷启动较高 | 低 | 流量波动大 |
|
||
| 边缘部署 | 硬件一次性投入 | 极低 | 中 | 离线场景、IoT |
|
||
|
||
---
|
||
|
||
## 总结
|
||
|
||
模型微调与部署是让大模型从"通用工具"变成"专业助手"的关键环节。从数据准备到模型上线，每一步都需要工程化的思维和实践。
|
||
|
||
回顾本章的关键要点：
|
||
|
||
1. **微调是岗前培训**：让通用模型学会特定领域的知识和行为模式
|
||
2. **数据质量决定上限**：100 条高质量数据胜过 10000 条低质量数据
|
||
3. **LoRA 是效率之王**：用不到 1% 的参数实现接近全量微调的效果
|
||
4. **量化是部署利器**：INT4 量化让 70B 模型在单卡上运行成为可能
|
||
5. **部署方案因地制宜**：快速验证用 API，大规模用自部署，波动大用 Serverless
|
||
|
||
## 延伸阅读
|
||
|
||
- [Hugging Face PEFT 文档](https://huggingface.co/docs/peft) - 参数高效微调库官方文档
|
||
- [vLLM 文档](https://docs.vllm.ai/) - 高性能 LLM 推理引擎
|
||
- [Unsloth](https://github.com/unslothai/unsloth) - 2x 加速的 LoRA 微调框架
|
||
- [GGUF 格式说明](https://github.com/ggerganov/ggml/blob/master/docs/gguf.md) - llama.cpp 使用的量化模型格式
|
||
- [OpenAI Fine-tuning Guide](https://platform.openai.com/docs/guides/fine-tuning) - OpenAI 官方微调指南
|