Ollama 可复现性指南3 个变量钉住模型输出【免费下载链接】MLOps-Basics项目地址: https://gitcode.com/GitHub_Trending/ml/MLOps-Basics同一个 prompt 连跑两次两段输出对不上一个词。想让 LLM 实验结果稳定下来Ollama 可复现性其实只取决于三件事模型版本、生成参数、运行时环境。三件都锁死输出就固定漏掉任何一件之前的实验全部作废。一次翻车现场同一个 prompt两种输出同事甩来一句这模型很稳定你重跑同一个 prompt输出差出很远。怀疑代码改了git status 却是干净的。终端历史里翻出来的旧输出每一次看都不一样。LLM 的生成过程本身就是采样。随机源不锁死输出一致就只靠运气。说模型不稳定是偷懒的说法真正该做的是把随机源一个个钉死。悄悄破坏 LLM 实验一致性的 3 个变量别把不一致全归给模型随机。可复现性由三个独立变量决定任何一个单独都能让实验失真模型版本:latest指向的是活动靶。今天和上个月拉到的同名模型权重可能已经不同。更新对你不可见输出却悄悄漂移。生成参数seed、temperature、top_k 是三个采样旋钮。seed 默认是 0即每次运行随机temperature 默认大于 0。任何一项不固定输出分布就是移动靶。运行时环境Ollama 版本、GPU 还是 CPU、并行请求数、量化精度都会影响 logits 和浮点累加顺序。换一次版本、换一张卡同一个模型就是另一批结果。变量破坏一致性的方式锁定手段模型版本:latest漂移不同时间拉取权重不同钉住具体 tag并记录 digest生成参数seed / temperature / top_k 不固定每次采样结果不同写入 Modelfile运行时不再经 API 传参运行时环境版本、硬件、并行度改变批处理组成固定 Ollama 版本用 Docker 冻结锁定链路从参数到环境三个动作按锁参数 → 锁环境 → 记元数据的顺序做全做完才算一次成立实验。 把 seed 和 temperature 钉进 Modelfile参数全部写进 ModelfileOllama seed 参数与 Modelfile temperature 设置就不再依赖调用者的心情FROM llama3.2 PARAMETER seed 42 PARAMETER temperature 0 PARAMETER top_k 1 PARAMETER num_ctx 4096 PARAMETER num_predict 512 SYSTEM 你是固定格式的评估模型严格按指令作答。用ollama create llm-baseline -f Modelfile创建之后统一ollama run llm-baseline prompt。三个要点seed 取固定值temperature0 且 top_k1解码确定性num_predict 必须固定否则生成到多长停本身就是随机的。为什么写进 Modelfile 而不是命令行命令行参数容易忘Modelfile 随代码进版本库。还有个坑API 请求的 options 会覆盖 Modelfile 参数测试脚本里随手传一个 temperature锁就白上了。用ollama show llm-baseline随时核对生效参数。 用 Docker 冻结运行环境参数一致不等于环境一致。用 Docker 锁定 Ollama 实验环境钉死 Ollama 版本把并行度和加载模型数冻结为 1模型权重放挂载卷里docker run -d --name ollama-baseline \ -e OLLAMA_NUM_PARALLEL1 \ -e OLLAMA_MAX_LOADED_MODELS1 \ -e OLLAMA_DEBUG1 \ -v ./models:/root/.ollama/models \ ollama/ollama:0.5.2并行度为什么必须是 1多个请求并发时batch 组成变化浮点累加顺序跟着变同一 seed 也会跑出不同结果。OLLAMA_DEBUG1 留着日志出问题时才有东西可查。推理服务如果也要容器化本仓库里的 Dockerfile 与 docker-compose.yml 的容器化组织方式可以直接借鉴。把每次运行的元数据写进文件输出哈希没有上下文就只是一个数字。每次实验随手附上三个文件ollama show llm-baseline --modelfile run/modelfile.txt ollama list | grep llm-baseline run/digest.txt ollama --version run/env.txt模型 digest、Ollama 版本、参数快照三样齐了。团队协作时按实验名建子目录放进版本库日后有人质疑某个结果直接甩这个目录。 验证闭环让哈希替你做 Ollama 输出一致性验证一致性是否成立只看一件事同一输入多次运行输出哈希是否相同。设计 3–5 个固定测试 prompt覆盖你真正关心的题型每个跑 5 次用 SHA-256 对比import subprocess, hashlib PROMPTS [用一句话解释随机数种子, 列举 JSON 的三个用途每行一个, 给出 REST 的一个优点和一个缺点] def run(p): out subprocess.run([ollama, run, llm-baseline, p], capture_outputTrue, textTrue) return hashlib.sha256(out.stdout.encode()).hexdigest() for p in PROMPTS: hashes {run(p) for _ in range(5)} print(PASS if len(hashes) 1 else FAIL, p)全部 PASS说明这套配置是可复现的。把这一批哈希记为本次实验的基线下次改动任何参数重跑同一个脚本有没有回归一眼可见。如果部分 prompt PASS、部分 FAIL先查失败的那条是不是文本更长。长输出的累计浮点差异窗口更大往往是最先漂移的。对比结果要落表不要靠肉眼哪些 prompt 一致、哪些漂移、差在哪个位置全部量化记录下来。长期维护升级之后闭环怎么保版本升级是可复现性最容易断裂的时刻。升级 Ollama 或更换模型版本前先跑一遍验证脚本把当前基线哈希存档升级后再跑一遍。哈希变了不是 bug是信号——版本变了输出分布本来就可能变。正确动作是重新定基线而不是强行要求新输出等于旧输出。换模型版本时旧基线不要迁移每个版本单独保留自己的 Modelfile 和哈希基线目录直接用模型版本号命名。跨版本比哈希没有意义比的是新版本在自己基线内是否稳定。自检清单□ seed 固定为确定值没有留默认□ temperature0 或 top_k1解码是确定的□ num_predict 与 num_ctx 显式固定□ 模型钉在具体 tag 上未使用 :latest□ 模型 digest 与 Ollama 版本已记录在案□ 并行度与加载模型数均为 1□ 每次运行附元数据快照参数 版本 digest□ 任何升级后至少重跑一次验证脚本【免费下载链接】MLOps-Basics项目地址: https://gitcode.com/GitHub_Trending/ml/MLOps-Basics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考