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

关键词：大模型训练、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 → 量化部署；
• 从零训练基础模型：数据工程 → 大规模预训练 → 多阶段后训练。

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

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

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

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

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

测试细节

指标数据逻辑存储模型

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

单值模型是根据业务指标数据建模，按照单个指标的细粒度进行数据使用和逻辑存储，如下所示，一行数据只有一个指标值，即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

可以把两者理解为：

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

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

nginx给网站添加basic表单认证

很多大数据组件的adminUI 并没有设计授权认证，可以通过nginx 做一个简单的用户名密码认证：

1. 生成密码文件

1
2
3
4

yum install httpd-tools -y

#输入密码，就会生成加密的用户密码文件
htpasswd -c /etc/nginx/conf.d/.ngpasswd admin

2 nginx 加上 auth_basic信息

即席数据分析中的缓存机制和离线队列机制

每一次ad-hoc查询，均是会占用有限的计算资源，而OLAP 系统在现有技术下，并不能支撑很高的查询并发，为了有效改善这个问题，在查询时间范围内数据未发生变化或者变化量小，有效运用缓存可以有效提高查询效率和用户体验

缓存机制的实现：

对SQL的查询结果进行缓存，可以在 adhoc 层 或者 api 层进行处理

1. adhoc/api层可以对Query对象或者SQL进行Hash，hash值设定为缓存的key，计算完成后将查询结果存入 redis(同时需要保存最后计算时间）
2. 缓存原则是越底层做合适，但缓存跟业务场景关联性强，比如有的业务场景不允许缓存误差，那么缓存设定在底层就不合适，所以adhoc需要支持多个产品或者业务，可以由api层来做缓存
3. 对于已经配置好的看板，可以设置定时任务，每天凌晨可以有调度定时执行查询，查询后根据缓存机制进行缓存
4. 预判场景，有些不合适缓存的尽可能不缓存，比如单纯的查明细、结果数据大、数据导出等
5. 需要从界面端带一个参数：是否使用缓存，如果为true 表示可以走缓存逻辑，如果为false 则表明是用户强制刷新
6. 返回给界面端的response带一个 最后计算时间

领导说：

​ “目前各个项目分散在不同的仓库中，不利于管理，需要将多个项目仓库合并到一个工程仓库来进行开发，要求保留各个仓库迁移前的commits 记录，最好还能对命名不规范的项目进行重命名”

恕我直言，可以实现！

Git 多仓库合并

假设要合并ABC 不同的分支到新工程X，ABC 工程作为X工程的子目录

迁移A 工程的5.0分支到新工程X的A1目录

迁移B工程的dev分支 到新工程X的B1目录

迁移C 工程的6.0分支 到新工程X的C1目录

期望：合并后的目录结构

新工程X（master分支）
.
├── A1 (原A工程的某分支)
├── B1 (原B工程的某分支)
├── C1 (原C工程的某分支)
.git
README.md

OAuth2 Client在实际运用过程中遇到的问题

服务程序集成了OAuth2-Client，以便于用户能够方便集成到支持OAuth2第三方登录的自有业务系统中。开发完成后，本地测试、或者直连服务程序，都没有问题。但凡放到线上环境，经过了nginx 转发后，我们的服务程序OAuth登录永远是以失败告终。

现象如下：

访问需要授权的接口时 https://blog.95id.com:4005/user_attr，期望是跳转到授权服务器 github.com进行登录授权，但实际都是跳转到``http://blog.95id.com/login`

因为当时直接用服务程序的端口没问题，就将解决思路放在了nginx 转发过程上。

当时线上环境路由规则类似于：

第一层：nginx1 4005 （ssl、负载均配置在这）

第二层：nginx2 4005

第三层：oauth2-client 8082

再看nginx 的配置，第一层nginx 配置：

基于 Gitbook 制作电子书

安装gitbook 命令行工具

1

sudo npm install -g gitbook-cli

安装完之后，你可以检验下是否安装成功。

1

gitbook -V

常用命令

gitbook help 可以查看所有指令：

1
2
3
4
5
6
7
8

gitbook build #build a book
gitbook serve #serve the book as a website for testing
gitbook install # install all plugins dependencies
gitbook parse #parse and print debug information about a book
gitbook init #setup and create files for chapters
gitbook pdf #build a book into an ebook file
gitbook epub
gitbook mobi

Presto 主动Kill 机制

背景：用户界面中，为了改善用户使用体验，移除了 查询时点击按钮的操作，变更为只要检测到查询条件的修改都会自动触发计算。而实际使用过程中，用户在最终条件确定前，所有条件变更导致的查询计算均是计算资源的浪费

目的：为了避免自动触发的计算导致Presto 计算资源的浪费

如图所示，左侧指标、细分维度、公共过滤条件以及 日期范围、日期粒度、人群的变化都会导致分析查询的调用

方案:

数据分析中可视化图表缓存策略

每一次ad-hoc查询，均是会占用有限的计算资源，而OLAP 系统在现有技术下，并不能支撑很高的查询并发，为了有效改善这个问题，在查询时间范围内数据未发生变化或者变化量小，有效运用缓存可以有效提高查询效率和用户体验

1. 问题

单纯的N小时缓存失效的机制，会导致数据刷新不及时，造成数据理解上的偏差：

现象：在相同指标在不同图表数据不一致，尤其是在同一个DashBoard内时，让人难以理解；
原因：图表在不同时间创建和缓存的，在时间差内，相关的数据发生了变更