把自有模型导入 Ollama：先分清完整权重、适配器与基础模型

先确认拿到的究竟是什么 下载目录中出现 Safetensors，不足以判断它是完整模型还是适配器。导入前应从模型发布说明确认架构、基础模型、文件角色以及是否已经把微调结果合并进完整权重。把这些信息与文件校验记录保存在一起，后续发现输出异常时才有可追溯的起点。 两条导入路径 官方导入指南中，完整 Safetensors 模型由 Modelfile 的 FROM 指向权重目录；完整 GGUF 模型则让 FROM 指向对应文件。适配器采用另一种组合：FROM 指定基础模型，ADAPTER 指向适配器目录或 GGUF 适配器文件。准备好 Modelfile 后，使用 ollama create 创建命名模型，再运行该模型验证。 这里最容易混淆的是文件位置与模型身份。路径正确只说明文件能被找到，并不能证明适配器与基础模型相容。官方特别要求适配器使用与训练时相同的基础模型，否则可能出现异常结果。 完整 GGUF 的最小操作例子 假设已经确认 ./weights/model.gguf 是当前版本支持的完整模型，在独立目录创建名为 Modelfile 的文本文件，只写一行： FROM ./weights/model.gguf 在该目录运行 ollama create import-check，再运行 ollama run import-check。import-check 是自拟测试名称，文件路径要换成自己的实际位置。成功创建但对话异常时，保留创建输出和文件来源，不要先覆盖原有可用模型。 如果拿到的只是适配器，这一份 Modelfile 就不适用。应将 FROM 指向训练时的基础模型，另加一行 ADAPTER 指向适配器。已经合并微调结果的完整权重则走完整模型路径，不应为了“补上微调”再把同一适配器叠加一次。文件扩展名无法替你判断是否已合并，要以训练和发布记录为准。 先做最小验证，再接业务 建议用新名称创建测试模型，保留原有可用模型。准备几条普通问答以及能体现微调目标的样例，记录输入、输出、模型身份和配置。若基础能力正常但目标行为异常，优先核对基础模型版本、适配器来源和是否已经合并权重，不要直接用更复杂的提示掩盖问题。 架构支持也要单独核对。文档列出了可导入的若干架构，并不意味着任意名称的 Safetensors 文件都能运行。准备较大的转换任务前，先确认目标架构属于当前版本支持范围。 样例也要分成基础能力与微调目标。例如，客服格式微调可以检查普通问答是否仍通顺，再检查“资料里没有保修日期”时是否按约定返回缺失，而不是强行给出日期。仅仅看到目标格式，不足以证明基础模型和适配器匹配正确；记录目标行为之外的退化，才便于比较导入前后的差异。 量化作为第二次变更 Ollama 支持在创建模型时将 FP16 或 FP32 权重量化。官方解释了内存占用与精度之间的取舍，因此量化应与初次导入分开验收。先确认未量化导入的结果，再用同一组样例比较量化后的输出，同时记录实际资源占用；不要仅凭文件变小判定成功。 适配器的量化方式还可能随训练框架而异。所核对指南更推荐非量化适配器，原因是不同框架采用的方法可能不同。遇到不一致时，应回到训练产物和导出方式，而不是随意替换基础模型尝试碰运气。 完成标准 一个可复现的导入记录应包含权重来源、基础模型身份、Modelfile、创建命令与样例结果。速度与任务效果应在目标机器上用真实样例验证，导入成功只是运行链路的第一步。

本篇涉及的工具1

Ollama

通过 Modelfile 导入已有模型与适配器

适合场景

手上已有 Safetensors 或 GGUF 文件，准备通过 Ollama 运行的开发者。

需要留意

架构、基础模型身份和适配器格式均需匹配。

了解项目 访问官网