当一个跑了一年多的基于 LLM 自动化流程积累了超过万条真实数据后我产生一个想法能不能用这些数据训练一个专用小模型然后把 API 调用替换成本地推理这样能够显著减少数据外出风险同时也能学习到模型微调相关的知识我承认这是一个主要目的因此有了本文记录了从动机到落地的完整思路。一、背景一个已经跑了很久的基于 LLM 的自动化流程过去一年多我维护着一个银行结单自动识别归档的自动化工作流工程[基于飞书集成平台利用AI和多维表格的一个自动化工作案例](邮件/系统拉取结单 PDF → OCR 转文本 → LLM 提取 {账号, 报告期} → 标准化重命名 → 按约定目录存入 SharePoint这个流程在一年半时间内处理了超过 16000 多份文档提取准确率达到 99.95% 以上而且我通过智能对文档分割只取有效的单页还能将 token 消耗控制在 600 - 1300 tokens/文档同时避免整个文档数据泄露。从业务角度看它已经是相当成熟稳定。但维护久了两个问题越来越明显数据外出风险每份文档都要发到云端 API从 GPT-4 到 DeepSeek-V4 都试过虽然做了文档分割只暴露单页数据但金融文档天然敏感数据能被外网获取始终是个心理负担。固定任务用大模型是浪费这个任务极其固定——就是从固定格式的结单里找两个字段。让一个千亿参数的通用模型来做好比用飞机送外卖。于是问题变成了能不能用已经积累的数据训练参数量非常小的模型把这些工作全部收回到本地甚至可以用 CPU 推理就完成任务二、可行性分析为什么这件事可以做成不是所有任务都适合用小模型替代。我逐项评估了这个任务的特性评估维度判断说明任务是否固定✅ 极其固定就是找账号和日期格式可枚举是否有高质量标注数据✅ 超万条经过多种方式验证过的正确结果等于免费标注是否需要复杂推理❌ 不需要定位 格式化输出不是推理题是否能接受偶尔出错✅ 可容错归档系统有人工处理兜底方案是否有训练硬件✅ Arc B570千元级消费显卡10GB 显存结论这是一个理想的小模型微调场景。任务固定、数据充足、不需要复杂推理、有硬件——所有条件都满足。为什么不选择已有的专门用于数据提取的模型呢千元级消费显卡也能跑 AIIntel Arc B570 本地部署 四模型对比实战三、基座模型选择不是越大越好3.1 选择逻辑因为是替换 API 调用目标是争取能在 CPU 上也能跑得快。所以参数量的上限是能在普通服务器上用纯 CPU 推理平均响应时间不超过 3 秒。这个约束天然排除了 7B 以上的模型。在 0.5B-3B 的范围内我评估了三个候选模型参数量中文理解指令遵循在 Arc B570 上训练NuExtract-2.0-4B4B⭐⭐⭐⭐⭐QLoRA 可Qwen2.5-3B-Instruct3B⭐⭐⭐⭐⭐⭐⭐⭐LoRA 可Qwen3-0.6B0.6B⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐LoRA 轻松3.2 为什么是 Qwen3-0.6B三个关键理由第一中文是母语。结单文档绝大多数是中文含繁体NuExtract 系列虽然专攻抽取但在中文场景水土不服。Qwen 系列对中文金融术语的理解天然更准确。第二指令遵循能力突出。Qwen3 在 instruction following 上的提升是代际性的。对于必须输出严格 JSON 格式这个约束它几乎不会出错——这对后面的自动化流程至关重要解析失败 整个归档链条中断。第三体量刚好。0.6B 在 Arc B570 上用 LoRA 训练只需约 1 小时推理时 379MB 的 Q4_K_M 量化版在 CPU 上单次推理平均不到 3 秒。3.3 为什么不选更大的1.7B 也试了准确率相同但训练慢一倍推理慢一倍量化后体积大 3 倍。任务复杂度决定了所需参数量超过阈值的参数都是浪费从 0.6B 开始是个更优选择。四、数据集最好的标注来自生产验证4.1 数据来源的特殊性跟通常的微调项目最大的不同是没有做额外的数据标注。过去一年多的 API 调用每次都有指令、输入OCR 文本和输出LLM 提取的 JSON。这些结果在归档流程中天然地存储下来了自动化处理正确率在 99.95% 以上而且失败的案例也经过人工调整后被记录下来。也就是说超万条已经验证过的问答对天然就是训练数据。4.2 从原始记录到可用数据集不是所有生产数据都适合直接拿来训练。清洗过程花了最多的精力去重同一份结单可能因为流程重跑产生多条相同记录从完整结果中抽取约四分之一去重后得到 4,200 条样本即使再多数据其实也是形式上的重复效果并不会提升太多标签冲突检测发现了 13 组相同文本不同日期的样本经排查是同一张报表的不同月份版本日期不同但账号相同的合法情况予以保留但记录在案最终得到4,200 多条高质量训练样本。4.3 为什么不追求更多数据4,000 条对信息抽取来说已经足够。继续增加数据的边际收益很低3,000 条之后每增加 1,000 条提升不到 0.5%且大量样本高度相似同一银行不同月份格式相同冗余数据只会增加训练时间。五、训练Unsloth Studio 消费级显卡5.1 硬件和平台训练的硬件是一块Intel Arc B57010GB 显存2025 年发布的千元级消费显卡。选 Unsloth Studio 而非直接手写训练代码的原因很实际Intel Arc 显卡 Unsloth Studio 安装配置指南它提供了开箱即用的 LoRA/QLoRA 支持Qwen3 系列有专门的优化训练过程的 checkpoint 管理、评估日志都是自动的对新手足够友好对老手足够灵活5.2 训练配置实际使用的配置Qwen3-0.6B_lora_dataset_2026-08-10.yamltraining: max_seq_length: 4096 num_epochs: 3 learning_rate: 0.0002 batch_size: 2 gradient_accumulation_steps: 8 warmup_steps: 30 max_steps: 670 save_steps: 170 eval_steps: 170 # ...lora: lora_r: 16 lora_alpha: 32 lora_dropout: 0.05 target_modules: [k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj, q_proj]参数推导过程训练样本: 3,575 条 (85%)batch_size: 2 (Arc B570 10GB 的安全值)gradient_accumulation: 8有效 batch: 2 × 8 16每轮步数: ceil(3575 / 16) 224总步数: 224 × 3 轮 672 → 取整 670save_steps: 170 (约每轮 4 个 checkpoint)这套参数在 Arc B570 上大约 70 分钟跑完 3 轮显存占用约 6GB。说明原始数据集通过分拆脚本按照二拆模式 85:15 拆分为训练集和评估集。split_data.py也支持三拆模式70:15:15额外产出独立 test.jsonl支持更规范的数据管理。但测试用的 289 条测试用例是后来单独手工精选的与训练数据零重叠。5.3 Unsloth Studio 训练过程六、工程化构建可复用的流水线这是本文的重点。训练一个模型不难难的是让整个流程可复现、可迁移。6.1 设计思路整套工具链遵循三个核心原则一切皆文件脚本之间通过文件交换数据xlsx → jsonl → yaml → gguf → report不通过函数调用。每个脚本独立可运行、独立可测试。一切皆参数路径、比例、种子、量化格式全部通过命令行参数或环境变量控制。换一个任务、换一台机器只需改参数不用改代码。一切皆可恢复导出脚本检测产物是否存在自动跳过测试脚本每完成一条即写入 checkpoint中断后从断点继续。6.2 工作流总览┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐│ 原始数据 │ → │ 数据拆分 │ → │ 训练配置 │ → │ 模型训练 │ → │ 模型导出 │ → │ 效果测试 ││ xlsx │ │ jsonl │ │ yaml │ │ LoRA │ │ GGUF │ │ 报告 │└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ split_data.py split_data.py gen_config.py train.py export_gguf.sh run_test.py六个脚本覆盖从原始数据到测试报告的全流程。其中train.py是最新加入的一环——它通过 unsloth 库直接调用训练 API让训练也纳入了自动化工具链不再依赖 Unsloth Studio 的 Web 界面手动操作。6.3 项目目录结构与脚本说明model-fine-tuning/ # 项目根目录│├── data/ # 数据层 │ ├── raw/ # 原始训练数据只读│ │ ├── dataset.xlsx # 输入手工维护的 4,200 条标注数据│ │ └── dataset.csv # 输入CSV 格式副本│ ├── split/ # 拆分产物 → split_data.py 输出│ │ ├── train.jsonl # 训练集二拆 85% / 三拆 70%│ │ ├── eval.jsonl # 评估集二拆 15% / 三拆 15%│ │ └── test.jsonl # 测试集仅三拆模式15%│ └── test/ # 独立测试用例│ └── test_cases.xlsx # 289 条手工精选测试用例│├── configs/ # Unsloth Studio 训练 YAML│ ├── Qwen3-0.6B_lora_*.yaml # 0.6B 训练配置│ └── Qwen3-1.7B_lora_*.yaml # 1.7B 训练配置实验用│├── scripts/ # 工具脚本 │ ├── split_data.py # 输入: data/raw/*.xlsx → 输出: data/split/*.jsonl│ │ # 支持 --mode three (70:15:15) / --mode two (85:15)│ ├── gen_config.py # 输入: data/split/train.jsonl → 输出: configs/*.yaml│ │ # 读取样本数 显存大小自动推导训练超参数│ ├── train.py # 输入: config YAML jsonl → 输出: outputs/training/* (checkpoint)│ │ # 通过 unsloth 库直接执行 LoRA/QLoRA 训练无需 Web 界面│ │ # 支持 --config YAML 加载 --mode lora/qlora 切换│ ├── export_gguf.sh # 输入: HF缓存 LoRA adapter → 输出: ${MODELS_DIR}/export/model-*/*.gguf│ │ # merge → convert → quantize 四步流水线│ ├── run_test.py # 输入: GGUF模型 测试用例 → 输出: outputs/results/* outputs/logs/*│ │ # 自动发现模型、模糊匹配、断点续跑、双格式(xlsx/jsonl)测试│ └── utils/ # 共享工具模块│ ├── data_io.py # xlsx / jsonl 统一读取自动识别格式│ ├── model_discovery.py # 扫描导出目录自动注册模型零硬编码│ └── eval_metrics.py # 准确率计算、JSON Markdown 报告生成│├── outputs/ # 产物 │ ├── training/ # 训练输出 → train.py 输出│ │ └── {model}-{timestamp}/ # checkpoint-* 目录 训练日志│ ├── results/│ │ ├── result.json # JSON 格式完整测试结果│ │ └── report.md # Markdown 格式可读报告│ └── logs/ # 每次测试运行的 DEBUG 日志│├── docs/ # 文档 参考资料├── .claude/skills/ # Claude Code Skill 定义│ ├── fine-tuning-pipeline/ # 流水线编排Agent 自动执行│ └── unsloth-config-generator/ # 训练配置生成├── Makefile # 统一入口make split / config / export / test└── .gitignore输出目录项目外MODELS_DIR默认~/Models${MODELS_DIR}/├── hub/ # HF 缓存离线模式│ └── models--{org}--{model}/│ └── snapshots/{sha}/└── export/ # GGUF 导出产物 → export_gguf.sh 输出 └── model-qwen3-0.6b-bill-s670/ ├── *-f16.gguf # 原始精度 (1.1 GB) ├── *-Q4_K_M.gguf # 量化版 (379 MB推荐部署) ├── *-Q5_K_M.gguf # 量化版 (424 MB) ├── *-Q8_0.gguf # 量化版 (610 MB) └── *-export-meta.json # 溯源基座/步数/llama.cpp版本/时间戳6.4 命令行训练不再依赖 Web 界面Unsloth Studio 的 Web 界面适合初次实验但工程化流程中每次都手动上传数据、调整参数、点击启动效率太低。实际上Unsloth Studio 底层使用的是unslothPython 库v2026.7.5它提供了完整的编程接口——FastLanguageModel、UnslothTrainer、UnslothTrainingArguments——可以直接从命令行启动训练。train.py封装了这一能力核心设计YAML 驱动命令行覆盖# 直接用已有的训练配置python scripts/train.py --config configs/Qwen3-0.6B_lora_2026-08-10.yaml# QLoRA 模式4bit 量化训练4GB 显存就够python scripts/train.py --model unsloth/Qwen3-0.6B --mode qlora \ --train data/split/train.jsonl --eval data/split/eval.jsonl# 命令行覆盖 YAML 中的参数python scripts/train.py --config ... --epochs 4 --lr 1e-4参数优先级命令行 YAML 脚本默认值。这意味着可以用gen_config.py生成的 YAML 作为基础再按需调整。训练模式模式激活显存需求适用LoRA16bit--mode lora默认~8GB显存充足时精度最高QLoRA4bit--mode qlora~4GB显存受限或快速验证完整 Makefile 入口make train # LoRA 训练make train-qlora # QLoRA 训练显存友好训练产物输出到outputs/training/{model}-{timestamp}/包含 checkpoint 目录可直接被export_gguf.sh通过ADAPTER/path/to/checkpoint-xxx使用。至此六阶段流水线全部打通split → config → train → export → test每一步都有可独立运行的脚本也支持make一键串联。6.5 模型测试自动发现模糊匹配早期我的做法是每导出一个模型就在测试脚本里加一行配置。后来换了一个思路让脚本自己扫描目录发现模型。导出一个新模型后run_test.py自动感知它的存在。用户只需要一个模糊片段来指定--model 0.6b-bill → 扫描到 4 个变体 (Q4/Q5/Q8/f16) → 全部测试--model 0.6b-Q4 → 命中 1 个 → 只测这个--list → 列出所有可用模型测试结果自动生成 JSON机器可读和 Markdown人可读两种报告。6.6 让 AI 替你跑流程更进一步我为 Claude Code 编写了 Skill 文件让 Agent 能理解自然语言意图用户用 QLoRA 模式训练 Qwen3-0.6B → Agent 激活 venv → 执行 train.py --mode qlora --config configs/xxx.yaml用户把 step-670 导出为 Q4_K_M 和 Q8_0 → Agent 激活 venv → 组装参数 → 执行导出 → 报告结果用户测试所有 0.6b 的模型 → Agent 自动运行 run_test.py返回报告摘要工程的终点不是代码是让不熟悉代码的人也能操作。七、成果100% 准确率 CPU 反而比 GPU 更快7.1 测试结果用 289 条独立手工精选的测试用例包含各种边界情况15 位长账号、字母编码、繁体中文、英文报表覆盖三种量化格式 × 两种硬件GPU / CPU 推理共 7 组对比实验。测试环境GPU 推理使用 Intel Arc B570 (10GB)llama.cpp Vulkan 后端ngl99CPU 推理使用 AMD 5700X 纯 CPUngl0和 Intel i7-12700推理参数统一为 temperature0, max_tokens2048。Q4_K_M GPUQ4_K_M CPUQ5_K_M GPUQ5_K_M CPU (AMD)Q5_K_M CPU (i7)Q8_0 GPU硬件Arc B570AMD 5700XArc B570AMD 5700Xi7-12700Arc B570耗时1,615 ms1,326 ms1,632 ms1,400 ms2,739 ms1,632 msToken/s542661537626320537准确率100%100%100%100%100%100%7.2 分析准确率三种量化格式无损从 Q8_0 → Q5_K_M → Q4_K_M模型体积从 610 MB 压缩到 379 MB压缩比 1.6:1而 289 个测试用例的准确率始终是100%。说明对于这类信息抽取任务量化带来的精度损失几乎可以忽略不计。推荐部署 Q4_K_M——体积最小、速度最快、准确率保持优秀。CPU vs GPUAMD 5700X 反而更快三组 CPU vs GPU 对比中AMD 5700X 的纯 CPU 推理全部赢过 Arc B570 的 Vulkan 推理量化格式GPU (Arc B570)CPU (AMD 5700X)CPU 优势Q4_K_M1,615 ms1,326 ms快 18%Q5_K_M1,632 ms1,400 ms快 14%AMD vs Intel缓存和架构的差距同为纯 CPU 推理的 Q5_K_MAMD 5700X (DDR4) 比 i7-12700 (DDR4) 快 **96%**1,400 ms vs 2,739 msL3 缓存5700X 的 32 MB 比 12700 的 25 MB 多 28%对 memory-bound 的推理任务更多权重热区命中缓存意味着少走 DDR 延迟L3 ~10ns vs DDR4 ~70ns同构核心5700X 全 8 核性能均等而 12700 的 8P4E 中 E-core 成了线程池的短板单 CCD 低延迟5700X 核间通信在片内完成12700 跨簇需走 Ring Bus启示选 llama.cpp 推理 CPU 时大缓存 同构核心比多核 大小核更重要。7.3 实践意义在 289 条多场景测试中CPU 推理 1,326 ms 的平均耗时完全满足业务需求单份文档 OCR 推理 5 秒。相比 API 方案维度之前API现在本地模型数据安全文档出网全程本地成本按量付费零边际成本延迟网络推理 5-10s本地推理 3sCPU可控性模型不可调可按需重训准确率~99.95%100%在目标格式上甚至还可以利用之前的 API 调用方式为本地推理结果错误的情况兜底——这么一统计每年实际需要调用 API 的也就不到 5 份文档数据外出风险降到几乎为零。7.4 从 GPU 训练到 CPU 部署训练的模型导出为 GGUF 格式后可以在任意有 CPU 的机器上运行llama-cli -m model-qwen3-0.6b-bill-s670-Q4_K_M.gguf \ -ngl 0 -no-cnv \ -p 从下列账单中抽取账号和日期... -n 128379 MB 的模型文件不需要 GPU不需要 Python 环境一个 C 编译的二进制就能跑。八、可迁移性这套方案不只适用于银行结单8.1 迁移步骤整套流水线设计之初就考虑了可迁移性迁移到新任务只需四步步骤操作示例合同抽取1. 数据准备准备相同格式的 xlsxinstruction/input/output 三列合同文本 → {甲方, 乙方, 签署日期}2. 数据拆分python scripts/split_data.py --input data/raw/contracts.xlsx自动按 85:15 拆分3. 生成配置python scripts/gen_config.py --model-size 0.6B --vram 10根据样本数自动推导训练步数4. 执行流水线make split → make train → make export → make test一键训练 导出 测试8.2 迁移实例假设场景假设要训练一个从购销合同中提取甲乙方和签署日期的模型# 1. 准备数据# contracts.xlsx 包含 instruction / input / output 三列# 示例 output: {party_a: 北京科技公司, party_b: 上海贸易公司, date: 2026-08-10}# 2. 拆分python scripts/split_data.py --input data/raw/contracts.xlsx# 3. 生成配置仍用 Arc B570 10GBpython scripts/gen_config.py --model-size 0.6B --vram 10 --output configs/contract_extraction.yaml# 4. 训练python scripts/train.py --config configs/contract_extraction.yaml# 5. 导出 测试MODEL_REPOunsloth/Qwen3-0.6B bash scripts/export_gguf.shpython scripts/run_test.py --model contract --input data/test/contract_cases.xlsx预计训练时间1-2 小时取决于样本数。8.3 适用场景判断并非所有任务都适合这套方案判断项✅ 适合❌ 不适合任务类型信息抽取、分类、格式化输出开放式生成、复杂推理数据量1,000 条高质量标注 500 条或标注质量差输出格式结构化JSON/CSV自然语言段落部署环境有 CPU/GPU 服务器纯浏览器或移动端反例“生成营销文案”、回答开放性问题这类任务仍需要大模型。九、总结与展望9.1 核心收获这次实践回答了三个问题小模型能不能替代大模型 API能但前提是任务足够固定、有足够的高质量训练数据。通用能力交给大模型固定能力交给专用小模型——这是务实的工程思路。消费级硬件能不能做微调能。Arc B570 10GB 显存完全胜任 0.6B 模型的 LoRA 训练。而且模型导出后可以用纯 CPU 推理部署门槛为零。工程化的投入值不值得值得。脚本参数化、幂等性、自动发现这些工作每次迭代从半小时降到一行命令。而且整套工具链可以直接复制到下一个微调任务。9.2 局限性与未来方向当前局限领域专用性强当前模型针对中文银行结单跨领域需重新训练测试覆盖有限289 条测试用例虽经精选但边界 case 覆盖可能不完整离线依赖工具链依赖 HF 模型缓存首次需联网下载基座模型可能的改进方向模型蒸馏尝试将 0.6B 蒸馏到 0.3B进一步降低推理延迟增量学习新格式结单出现时少量样本即可快速适配多任务微调同一模型上训练多个相关任务结单 发票 合同提升泛化能力量化感知训练训练阶段引入量化可能进一步提升 Q4_K_M 准确率学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】