Ertas 助力 ML 工程师与微调从业者

The Challenge

开源微调生态系统功能强大但严重碎片化。Unsloth 优化了训练速度但没有部署方案。Axolotl 提供灵活的配置但需要手动编写 YAML 且不提供实验跟踪。LLaMA-Factory 提供 Web UI 但将您锁定在其特定抽象中。每个工具都出色地解决了拼图的一块而忽略了其余部分，使 ML 工程师不得不用 shell 脚本、笔记本单元格和命名规范将工作流粘合在一起——当有团队成员加入或项目在两周后恢复时，这些必然会崩溃。GPU 内存约束增加了另一层摩擦——工程师可能花一整天时间找出量化、批大小、梯度累积和序列长度的正确组合，使训练运行适合其可用硬件。

部署差距是大多数微调项目死亡的地方。ML 工程师在笔记本中产生了一组漂亮的适配器权重，达到了强劲的评估指标，然后面临问题：然后呢？转换为 GGUF 需要找到支持该模型架构的正确 llama.cpp 提交。量化到正确的位深需要在 Q4_K_M、Q5_K_M 和 Q6_K 变体之间反复试验。没有标准方法来跟踪哪个实验产生了哪个适配器、使用了哪个数据集版本，或如何跨运行比较评估指标。当利益相关者问「你能复现三周前的模型吗？」诚实的回答通常是「大概可以，如果我能找到正确的笔记本而且训练数据没有被覆盖的话。」这种缺乏可复现性和血统跟踪不是工具上的不便——它是在生产中部署微调模型的根本阻碍。

The Solution

Ertas 提供了 ML 工程师一直在用开源工具拼凑的统一流水线。Studio 的可视化画布让您通过组合模块化块来设计训练流水线——数据加载、预处理、LoRA/QLoRA 配置、训练、评估和导出——同时暴露经验丰富的从业者期望的完整配置面。每个参数都可编辑，每个块都可以用自定义代码替换，整个流水线定义可导出为可复现的配置文件。这不是一个简化的 UI 螺栓拧在训练库上——它是一个真正的工作流编排器，碰巧有可视化界面。

实验跟踪和比较功能完全弥合了可复现性差距。Ertas 中的每次训练运行都自动带有完整血统版本化：使用了 Vault 中的哪个数据集版本、Hub 中的哪个基础模型、设置了什么超参数，以及达到了什么评估指标。并排比较视图让工程师在单一屏幕中评估多个 QLoRA 实验的损失曲线、基准分数和生成质量。当最佳实验被确定后，一键 GGUF 导出处理转换和量化流水线——包括架构感知转换，自动选择正确的 llama.cpp 代码路径。导出的 GGUF 可以部署到 Ollama、llama.cpp、vLLM 或任何其他推理运行时，无需手动转换步骤。从原始数据集到部署生产模型的整个旅程都在一个平台上完成，具有完整的审计追踪。

Key Features

Example Workflow

一位中期创业公司的 ML 工程师被要求将 GPT-4o 的推理能力蒸馏到用于设备端部署的紧凑模型中。他们首先整理了 50,000 个示例的 GPT-4o 输出数据集，覆盖公司的核心用例——客户查询分类、产品推荐和摘要——将版本化的数据集上传到 Vault。在 Hub 中，他们评估三个候选基础模型：Qwen 2.5 14B、Mistral Nemo 12B 和 LLaMA 3.1 8B，在公司的内部基准套件上进行比较。Qwen 2.5 14B 显示最强的基线性能，因此他们继续使用它。在 Studio 中，工程师配置 5 个 QLoRA 实验，不同的 rank（8、16、32）、学习率调度和序列长度，在 Cloud 上并行启动全部五个。训练完成后，并排比较视图显示 rank-16 配合余弦退火和 4096 序列长度在评估分数（内部基准 91.3%）和适配器大小（48MB）之间产生最佳权衡。工程师深入生成质量标签，抽查所有三个任务类别的输出，确认蒸馏模型在 94% 的测试案例上匹配 GPT-4o 的输出质量。一键将获胜实验导出为 Q5_K_M GGUF 文件，Ertas 自动为 Qwen 架构选择正确的 llama.cpp 转换路径。导出的模型部署到公司 API 网关后面的 vLLM 实例，以 180ms p95 延迟每分钟处理 2,000 个请求。完整的实验历史——全部 5 次运行、其数据集、配置和指标——保存在 Vault 中供将来参考和审计。