小白本地部署微调耍起

为什么写这篇

我们都知道思维链能反映大模型如何思考和处理问题。所以我在想能不能的东西，算是动手学大模型课程之外的一次延伸探索。其实，

痛点：硬件受限导致模型性能不足。想让低配模型具备高阶推理能力。

方向在 / 定下来：

数据策略当时是怎么定的？其实我当时脑子里想的是：一个模型就 15G，光是一个大方向的一个还没处理的原始数据集就 52G——这个训练成本太大了吧？跑完先不说最终效果，光是训练周期都遭不住。

痛点：海量原始数据导致存储和计算成本爆炸，难以在个人设备上完成全量训练。

就选择把方向更具体和清晰：聚焦自己需要的几个方向。

事后证明这个决定是对的。这两千多条训练，AI 告诉我预计跑五个小时我笔记本实际跑了十四个小时——还好当时制止了从零处理 52G。

痛点：即使是几千条数据，也可能因为硬件性能导致训练时间远超预期。老实说，

就这样走了一周。收官那天我是这么说的：

最终 V4 部署到了 Ollama：能解题、会讲概念。

痛点：微调后模型仍受限于底层容量与算力，多任务处理仍表现平平。

说句公道话，这本来就是个入门模型。那些公司、配了正经台式的人，都能搞能力更强的模型、做更大规模的训练；我这是一台 8G 显存的笔记本。模型上限就摆在这——拉高权重、再怎么微调，突破不了多少。微调的意义，是在我需要的方面提供定向帮助不是让它超越上限。

痛点：硬件显存瓶颈限制了模型规模。即使微调也无法突破根本上限，只能做垂直定制。

但在展开之前，我得先交代一件事——这不是一个人干的。我和我的 AI 助手基本五五开。

后面每一步，我都会标出来：这一步是谁做的。按理说，

一、数据：不是「量」说了算

Pain Point：#1 环境先行 - 环境搭建错误会导致整个流程卡死；#2 数据清洗繁琐 - 自动化工具帮忙，但标准只能自己定义； #3 数据量与质量平衡 - 大量低质数据反而拖累模型表现。话说回来，

处理到什么程度。这个尺度是你定的

」，这个标准只有我知道也只能我来规定。

Pain Point：缺乏统一的数据清洗标准导致噪声残留，引发后续训练不稳定。

数据量多少。跟着方向走

Pain Point：盲目追求数量会浪费硬盘空间和计算时间，需要依据业务方向精准采样。

I 最终定的是三个方向：数学、算法、桥接概念。三个方向基本五五开，所以数据量也相差不大——最终合并 # 条

地基 = 力扣代码随想录 + 蒸馏代码 + 考研数学真题
P4 = 数学扩充 + 代码扩充
桥接 = 概率→CS + CS基础 + 线代→CS + 离散→CS + 微积分→CS

Pain Point：如果方向分散。会导致每类样本不足，从而影响特化能力。

质量 vs 数量：几百条可能就够。也可能不够

This is my biggest takeaway.

• V1 用 # 条,loss 从 X 降到 Y；V2 加到 # 条,效果却下降——根源在于六大质量问题。
• 从K1来看，高质量少量数据往往胜过海量低质数据；K2: 加量不加质会让模型偏离预期轨道。

Pain Point： 盲目增量导致过拟合或知识漂移。

协作分工表

二、环境：显卡在「空转」

一上来就栽在环境上

Pain Point #1：装错依赖导致 PyTorch 从 GPU 切换成 CPU；Pain Point #2：版本冲突让 torchaudio 安装失败，却又不是主要需求。

GPU 在空转：Blackwell 的坑

• LLaMA‑Factory 安装时 Pip install -e . `把 cu128 覆盖成 cpu。结果 GPU 看似满载，却实则 CPU 在忙。
• BITSANDBYTES 对 RTX Blackwell 没有 4bit kernel → 全部回退 CPU 运算 → 步骤耗时十倍以上。
• SOLUTION：切换到 unsloth 框架。它自带适配 Blackwell 的量化引擎，使步长从 X 秒降至 Y 秒，加速约 Z 倍。

Pain Point： 框架兼容性检查不足导致长时间无效排查。

复盘这方面，三小时浪费在哪儿？

• LLaMA‑Factory 在 Windows+RTX Blackwell 上兼容性极差——YAML 不支持、Python/CUDA/transformers 敏感等多重因素叠加；
• Pip 安装过程意外覆盖 GPU 驱动版本——未提前预警即投入使用；不过，
• Lack of pre‑check on wher chosen framework supports specific GPU architecture.