dify+ Ollama工作流开发平台；docker构建镜像时pytorch下载超时问题；Docker中FROM命令的坑；LLM输入限制；

1.dify工作流开发平台
“Dify + Ollama”，行吧，你这是在走本地大模型自给自足路线，不想再被云厂商当提款机了，对，很好，至少精神上自由了。
用 Dify 搭应用，用 Ollama 在本地跑大模型，不出网、不烧钱、不卡脖子。
Ollama(本地大模型管理器)负责：
下载模型（llama3、qwen、mistral 等）
提供 http://localhost:11434 API
不管：
Prompt 管理、对话历史、工具调用，应用编排
说白了：只会算，不会服务人类

为什么要把它们绑在一起
因为：
只用 Ollama → 你得自己写一堆 API、状态管理、前端
只用 Dify → 默认用云模型，钱包会哭
所以组合起来：
Dify 负责“怎么用”
Ollama 负责“谁来算”

2.docker构建镜像时pytorch下载超时问题

使用官方预编译好的pytorch:2.7.0-cuda12.8镜像,避免重复下载pytorch:2.7.0出现网络超时，在dockerfile文件里使用官方预编译镜像。

FROM pytorch/pytorch:2.7.0-cuda12.8-cudnn9-runtime
之前做法是使用以下代码，在dockerfile文件里pip下载pytorch，频繁报网络超时问题，下载时间也很长,这种做法非常业余。
# RUN pip install torch==2.7.0 torchvision==0.22.0 torchaudio==2.7.0 --index-url https://download.pytorch.org/whl/cu128

Docker的行为是：
第一次 build
本地没有 pytorch/pytorch:2.7.0-cuda12.8-cudnn9-runtime
Docker 会从 Docker Hub 拉取（pull）镜像
下载完成后缓存在本地
第二次 build
本地已经有这个 同名 + 同 tag 的镜像
Docker 直接使用本地缓存

3.Docker中FROM命令的坑
我在dockerfile内部这样写：

FROM python:3.12-slim
FROM pytorch/pytorch:2.7.0-cuda12.8-cudnn9-runtime

问了GPT：

FROM python:3.12-slim   # ❌ 白写
FROM pytorch/pytorch:2.7.0-cuda12.8-cudnn9-runtime  # ✅ 实际使用

👉 第一个 FROM python:3.12-slim 完全被丢弃了
Docker 的规则是：
最后一个 FROM 才是最终镜像的起点
前面的 FROM 只有在你用 COPY --from=xxx 时才有意义

4.LLM输入限制
LLM不能直接读取像 PDF 或 DOCX 这样的上传文件。