从 Notebook 到生产：弥合微调部署鸿沟

你微调了一个模型。它在评估集上表现良好。你的 Jupyter notebook 显示了令人印象深刻的指标。然后什么都没发生。

模型留在某个 VM 上的检查点目录中，你最终会忘记关闭它。它从未服务过一个真实用户。你并不孤单——行业估计表明大多数微调模型从未到达生产环境。不是因为它们不工作，而是因为从"在 notebook 中工作「到」在生产中运行"的路径充满了与机器学习无关的运维问题。

这就是部署鸿沟，它是当今应用 AI 工程中最大的瓶颈。

鸿沟为何存在

部署鸿沟不是单一问题。它是五个相互复合的独立问题，每一个都足以独自让项目停滞。

没有标准导出路径

你用 Hugging Face Transformers、Unsloth 或 Axolotl 训练了模型。你的检查点是分散在目录中的适配器权重、配置文件和分词器资源的集合。要部署它，你需要将适配器合并到基础模型中、转换为推理优化格式、为目标硬件量化，并验证转换没有降低质量。

没有 model.export("production") 命令。应该有，但没有。

手动 GGUF 转换

GGUF 已成为本地推理的标准格式，但转换仍是手动过程。

没有实验跟踪

大多数微调在一次性 notebook 中进行。超参数硬编码。结果目测。

没有模型版本控制

代码有 Git。模型没有等价物。

没有生产监控

在评估集上有效的模型在真实数据上可能失败。

从 Notebook 到生产的五个步骤

步骤 1：实验跟踪

训练前设置跟踪。记录每个超参数、每个数据集版本、每个评估指标。

步骤 2：模型评估

评估不是单个数字。构建覆盖核心任务性能、边缘案例处理、预期负载下延迟、输出格式一致性和分布外输入行为的评估流水线。

步骤 3：格式转换

标准化导出流水线。从训练检查点到生产就绪产物应该是一条命令。

步骤 4：推理优化

生产模型不仅要准确——还要快、内存高效和可靠。

步骤 5：生产监控

模型服务真实流量后，你需要可见性。至少跟踪：请求量和延迟、输出质量指标、错误率和资源利用率。

Ertas 如何弥合每个鸿沟

Ertas 围绕这个具体问题而设计。平台将从训练到生产的路径视为一等工作流，而非事后考虑。

Studio 处理实验跟踪和评估。

GGUF 导出 内置于平台中。导出流水线自动验证质量。

Cloud 为已部署模型提供生产监控。