尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

Puter 自托管如何配置 Ollama 本地 LLM 容器并拉取默认模型?

Puter 自托管如何配置 Ollama 本地 LLM 容器并拉取默认模型? Puter 自托管如何配置 Ollama 本地 LLM 容器并拉取默认模型【免费下载链接】puter The Internet Computer! Free, Open-Source, and Self-Hostable.项目地址: https://gitcode.com/GitHub_Trending/pu/puterPuter 自托管栈的 docker-compose.yml 内置了两个可选容器puter-ollamaollama/ollama镜像提供本地 LLM 推理和puter-ollama-init一次性任务负责拉取默认模型。它们藏在 compose profileai后面不显式指定就不会启动。这篇文章的任务是在已跑起来的 Puter 自托管栈上启用这两个容器让 Puter 通过 compose 内部网络访问 Ollama并完成默认模型tinyllama的拉取。前提条件与 Puter 自托管文档一致主机装有 Docker 及compose插件且你已经完成 doc/self-hosting.md 中的 Step 1写好.env和puter/config/config.json和 Step 4docker compose up -d正常启动。为什么默认配置里 Ollama 是关闭的默认生成的puter/config/config.json里是providers: { ollama: { enabled: false } }。这不是疏漏Puter 启动时会自动探测127.0.0.1:11434上的 Ollama如果本机没有 Ollama每次启动都会刷ECONNREFUSED。所以文档的策略是——不跑本地模型时保持enabled: false跳过探测要跑本地模型时把配置指向 compose 网络里的ollama服务地址见 doc/self-hosting.md 中providers.ollama.enabled: false的说明以及 config.template.jsonc 第 399 行附近的注释。第一步修改 config.json 指向容器内的 Ollama编辑puter/config/config.json把providers段替换为providers: { ollama: { apiBaseUrl: http://ollama:11434 } }http://ollama:11434是 compose 网络内的服务名只能在 Puter 容器内解析——这要求 Puter 与 Ollama 运行在同一个 compose 栈里。docker-compose.yml 中ollama服务的注释给出了同一结论启用时写apiBaseUrl不启用时写enabled: false否则 Puter 会在启动时反复报ECONNREFUSED 127.0.0.1:11434。改完配置后按 doc/self-hosting.md「Additional configuration」的约定执行docker compose restart puter让新配置生效。第二步在 .env 中选择默认模型可选ollama-init拉取哪个模型由.env中的OLLAMA_DEFAULT_MODEL决定缺省值是tinyllamaOLLAMA_DEFAULT_MODELtinyllama # default — 1.1B, ~640 MB on disk, ~700 MB RAM # Other tiny picks: qwen2.5:0.5b, llama3.2:1b # Larger / better: phi3.5, llama3.2, mistral文档明确给出的候选值只有上面注释里列出的这几个。tinyllama的体积约 640 MB 磁盘、约 700 MB 内存是文档标注的估算值选更大模型时磁盘和内存占用会相应增长这一点 docker-compose.yml 的注释也做了提示。不修改.env时直接使用默认值tinyllama即可。第三步用 ai profile 启动并验证模型拉取docker compose --profile ai up -d docker compose logs -f ollama-init--profile ai会额外拉起ollama和ollama-init两个服务。ollama-init的行为定义在 docker-compose.yml它等待ollama服务的 healthcheck 变为 healthy 后执行一次ollama pull $OLLAMA_DEFAULT_MODEL模型拉取完成后以退出码 0 结束。判断成功的依据就是文档给出的这一条ollama-initexits 0 once the model is pulled。之后每次重启都会再次触发这个 init 容器但ollama pull是幂等的——模型已存在时是一次快速的 no-op。Ollama 模型数据落在./puter/data/ollama挂载到容器内/root/.ollama与栈里其他服务的状态目录一样保留在宿主机上重启不会丢。可选分支把 Ollama 直接暴露到宿主机。默认情况下ollama只在 compose 内部网络可达。如果你想在本机用ollamaCLI 或 OpenAI 兼容工具访问它取消 docker-compose.yml 中ollama服务下ports: 11434:11434的注释即可。GPU 加速NVIDIA。取消ollama服务下的deploy:块注释把全部 NVIDIA GPU 设备直通给容器文档要求宿主机安装nvidia-container-toolkit。这是文档中唯一给出的 GPU 支持路径未做其他硬件的说明。限制与排错不带--profile ai启动时ollama相关容器保持关闭Puterenabled: false也不会尝试连接其余栈的行为不变。也就是说「没开 ai profile」和「开了但模型没拉下来」是两件事前者 Puter 根本不看 Ollama后者才会出现 Puter 侧的请求失败。Puter 侧的模型列表来自 Ollama 的/api/tags接口实现见 OllamaProvider.ts。该 provider 在调用方未指定模型时的兜底默认值是gpt-oss:20b——如果你只拉取了tinyllama发起补全时应显式指定已拉取的模型不要依赖这个兜底值。ollama服务的 healthcheck 是容器内执行ollama listollama-init的启动依赖它变为 healthy。若 init 日志长时间停在等待阶段先docker compose ps看puter-ollama是否 unhealthy再用docker compose logs ollama查看原因。与 doc/self-hosting.md Troubleshooting 一致的通用结论若改完配置后 Puter 行为不对先docker compose restart puter并确认config.json已落在./puter/config/下该目录是整体挂载进容器的/etc/puter。【免费下载链接】puter The Internet Computer! Free, Open-Source, and Self-Hostable.项目地址: https://gitcode.com/GitHub_Trending/pu/puter创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表