摘要：大模型训练并不是选择一个框架就结束了。训练目标、参数更新方式、上层工作流、分布式执行和在线生成分别由不同技术负责。本文从学习视角梳理主流训练方法与框架分层，解释它们如何组合，并给出按任务、开发方式和硬件规模进行选型的思路。

关键词：大模型训练、SFT、DPO、PPO、GRPO、LoRA、QLoRA、TRL、LLaMA-Factory、Axolotl、Unsloth、Open-R1、verl、DeepSpeed、FSDP、Megatron-Core

本文基于 2026 年 8 月可查的官方资料整理。开源框架更新很快，具体参数和支持矩阵请以项目对应版本的官方文档为准。

一、先建立大模型训练的全景图

一个模型从“基础模型”走向“可用助手”，可能经历如下过程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

海量原始文本、代码、多模态数据
        ↓
预训练 Pre-training
        ↓
Base Model：会续写、有通用知识，但不一定会听指令
        ↓
继续预训练 Continued Pre-training（可选）
        ↓
吸收金融、法律、医疗、代码等领域分布
        ↓
监督微调 SFT
        ↓
学会对话格式、任务步骤、工具调用和标准回答
        ↓
偏好优化 DPO 等（可选）
        ↓
更偏好安全、清晰、有帮助的回答
        ↓
强化学习 PPO / GRPO 等（可选）
        ↓
针对可评分目标在线探索和优化
        ↓
评测、量化、部署、监控和数据回流

这不是每个项目都必须完整执行的流水线。实际情况可能是：

• 企业客服模型：基座模型 → SFT → DPO；
• 数学推理模型：基座模型 → 推理轨迹 SFT → GRPO；
• 行业知识模型：基座模型 → 继续预训练 → SFT；
• 小型本地模型：基座模型 → QLoRA SFT → 量化部署；
• 从零训练基础模型：数据工程 → 大规模预训练 → 多阶段后训练。

因此，第一原则是：先确定训练阶段，再选择框架。

大模型后训练路线

1
2
3
4
5
6
7
8
9
10
11

大模型后训练（Post-training）
│
├── 监督学习
│   └── SFT：学习“标准答案应该怎么写”
│
├── 偏好学习
│   └── DPO：学习“回答 A 比回答 B 更好”
│
└── 强化学习
    ├── PPO：根据奖励训练，通常需要 Value Model
    └── GRPO：根据同题多答案的相对奖励训练，通常不需要 Value Model

7. DPO：直接偏好优化

方法类型：直接偏好优化。通常使用提前准备好的离线偏好对，不需要在训练过程中运行完整的强化学习 rollout。

7.1 原理

DPO（Direct Preference Optimization）的核心思想是：直接拿“好回答”和“差回答”训练，让模型更倾向好回答，不再先训练一个阅卷老师，再做一轮 PPO。

训练时还会保留一个冻结的 reference model 作为参照，避免模型只顾拉开好坏答案的差距而偏离原模型太远。可以理解为：

1
2
3
4

对同一个问题：
  提高 chosen 的相对倾向
  降低 rejected 的相对倾向
  同时参考原模型，防止整体改变过猛

4. 预训练与继续预训练

4.1 预训练（Pre-training）

定义：在海量通用或混合语料上使用自监督目标训练模型，主要获取语言、知识和基础能力。

通俗解释：给模型阅读海量网页、书籍、代码等内容，让它反复做“猜下一个 token”的练习。原始数据不需要人工逐条写答案，文本的下一个 token 本身就是答案。

样例数据：预训练数据通常只是连续文本，而不是问答对。

1
2

{"text": "水在标准大气压下的沸点约为100摄氏度。温度继续升高时，液态水会逐渐转化为水蒸气。"}
{"text": "def fibonacci(n):\n    if n < 2:\n        return n\n    return fibonacci(n-1) + fibonacci(n-2)"}

模型会自动从每段文本中产生大量“根据前文预测下一个 token”的训练题。

适用场景：

• 从零构建基础模型；
• 有足够数据、算力和工程团队；
• 现有模型在语言、授权、架构或核心能力上不满足需求。

优势：能力上限和数据分布可控，可形成自主基座。

劣势：数据、算力、稳定性、分布式系统和评测成本极高；失败代价大。

4.2 继续预训练（Continued Pre-training / Domain-Adaptive Pre-training）

定义：从已有基座继续使用语言建模目标训练，而不是使用问答标签。

通俗解释：基座模型已经读完“通识课程”，现在让它集中阅读某个专业的原始材料。例如继续阅读证券研报、法律条文或公司代码库，使它熟悉该领域的术语、表达和知识分布。

金融领域样例数据：

1
2

{"text": "资产负债率是企业负债总额与资产总额的比率，常用于衡量企业的长期偿债能力……"}
{"text": "本报告期内，公司经营活动产生的现金流量净额同比增长18.6%，主要原因是应收账款周转改善……"}

一个典型大语言模型（LLM）的生命周期可以概括为：

1
2
3
4
5
6
7
8
9
10
11
12
13

原始数据
  ↓ 清洗、去重、过滤、配比、分词
预训练（Next-Token Prediction）
  ↓ 获得 Base Model：会续写、有知识，但未必会听指令
继续预训练（可选，领域知识/新语言/长上下文）
  ↓
监督微调 SFT
  ↓ 获得 Instruction Model：学会指令格式和示范行为
偏好或强化优化（DPO / PPO-RLHF / GRPO 等）
  ↓ 提升有用性、安全性、风格、推理或可验证任务能力
评测、压缩、量化、部署
  ↓
在线推理、监控、数据回流、迭代训练

预训练主要解决“能力和知识从哪里来”，SFT 解决“如何按指令表现”，偏好优化解决“多个看似合理的答案中更偏好哪个”，推理系统解决“如何以可接受的成本和延迟把能力交付出来”。

查看更多

因为有单机私有化部署业务需要，所以要选一款单机能hold、性能不差的模型，先看：

OpenAI Whisper：全球知名的多语言通用模型，基于海量音频数据训练，准确率高且支持多国语言与翻译

openAI Whisper 有不同大小的语音识别模型，真实场景到底用哪一个呢？我们来测试下：

openAi Whisper 实际模型加载过程耗时占大部分，所以最好做成服务

测试细节

VictoriaMetrics 是后出的一款面向可观测指标的时序数据存储和查询引擎， 传闻比prometheus 查询性能强，存储成本还低，我们也有做指标数据平台，特来学习下

以下分析基于 v1.45.x 版本

1. 核心结论

VictoriaMetrics 的存储设计可以概括为以下几点：

• 使用 vminsert、vmstorage 和 vmselect 分离写入、存储与查询职责；
• 采用 Prometheus 风格的单值时序模型，每个数据点由时间戳和浮点数值组成；
• 根据指标名和标签生成时间序列标识 TSID；
• 将标签索引与原始时序数据分开存储；
• 原始数据按 TSID 聚合，并将时间戳和值分别进行列式压缩；
• 数据先写入内存，刷盘后形成不可变的 Part，再通过后台 Merge 合并；
• 按月建立数据分区，通过 small 和 big 两级目录平衡近期数据的读取速度与历史数据的压缩率；
• 索引和数据均采用分层文件结构，通过元索引缩小读取范围；
• 不依赖传统 WAL，在异常退出时可能丢失尚未刷盘的数据。

2. 集群架构

VictoriaMetrics 集群由三个核心组件组成。

三个组件可以分别扩容。vmstorage 采用 Shared-Nothing 架构：节点之间不共享数据，也不需要互相通信。这种结构降低了节点间协调成本，使扩容和故障隔离更简单。

Vectoria Metrics 查询性能测试用例

原本是测试某款产品和 vm的对比， 某款产品没有对比意义，已经移除相关对比数据， 只看vm的查询性能即可

测试结果

测试方案

单次查询脚本

1. 双方准备测试用例sql
2. 用例均通过双方的query api接口进行查询，均通过response中的执行耗时进行用例耗时统计
3. 循环测试用例，每个用例连续执行3遍，新用例执行前清除系统cache
4. 收集所有用例执行时间
5. 分别统计 冷执行（用例第一次执行） 和 热执行（用例第二次和第三次执行）所耗时间
6. 进行对比

测试结果

benchmark 数据源配置

pod 4c6G

数据生成速率

1
2
3

3000*1230 active time series
scrapeInterval 10秒，1230*3K/10  369k samples/sec
每10分钟 更新10%  time series

数据协议，prometheus remote write

数据格式（转json 后）

1
2
3

{"metric":{"__name__":"node_scrape_collector_success","job":"node_exporter","instance":"host-2362","collector":"mdadm","replica":"0","revision":"r0","url_replica":"0"},"values":[1],"timestamps":[1724313603243]}
{"metric":{"__name__":"node_textfile_scrape_error","job":"node_exporter","instance":"host-1398","replica":"0","revision":"r5","url_replica":"0"},"values":[0],"timestamps":[1724313609919]}
{"metric":{"__name__":"node_textfile_scrape_error","job":"node_exporter","instance":"host-1902","replica":"0","revision":"r0","url_replica":"0"},"values":[0],"timestamps":[1724313604325]}

指标数据逻辑存储模型

常见的时序数据库的数据模型，主要分成单值模型和多值模型

单值模型是根据业务指标数据建模，按照单个指标的细粒度进行数据使用和逻辑存储，如下所示，一行数据只有一个指标值，即value列。目前采用单值模型的时序数据库，有OpenTSDB、 KairosDB、Prometheus等。

1
2
3
4

单值模型：
time                 host   metric     value
2026-08-08 10:00:00  web01  cpu_usage  72
2026-08-08 10:00:00  web01  io_usage   31

多值的模型则是针对数据源建模，我们每一行数据针对的是一个数据源，它的被测量的多个指标在同一列上，如下所示，一行数据有多个指标值，即有cpu和io两列。目前采用多值模型的时序数据库，有InfluxDB、TimescaleDB等。

1
2
3

多值模型：
time                 host   cpu_usage  io_usage
2026-08-08 10:00:00  web01  72         31

可以把两者理解为：

• 单值模型：一条时序记录只描述一个指标。
• 多值模型：一条时序记录同时描述同一数据源在同一时刻的多个指标。

严格来说，多值模型中的多个指标是放在同一行的不同列/字段中，而不是同一列。

指标体系的应用场景 - 动态阈值

在指标体系的应用场景中，基于指标的告警也是指标数据的一个重要应用。

基于指标的告警一般有以下几种类型：

• 静态阈值：大于/小于 某个具体的值则产生告警（对于明细数据，还可以用中位值/分位值进行阈值判断）
• 同环比： 同比/环比 变化率/变化值 上升/下降超过多少产生告警
• 动态阈值： 对比历史同时间段的基线值 产生告警
• 异常检测：基于历史数据检测度量的异常行为。异常检测会检测指标的行为何时与过去不同，并考虑趋势和季节性
• 离群点异常检测：离群点异常检测组内与其他成员相比异常的成员，主要用于判断指标的分组组合中哪些和其他组合差异过大
• 预测告警：预测指标在未来的表现。通过在超出阈值之前发出警报

本篇主要介绍动态阈值的实现方案：