DeepSeek + Dify + Ollama 三剑客：从理论到实战的分层架构与代码落地

“三剑客”最容易陷入的误区，是把它当作三个可互相替代的模型工具来堆叠。三者的工程关系是分层：Ollama 是模型运行时，负责把 DeepSeek 权重加载进显存并提供 HTTP API；DeepSeek 是推理引擎，提供语言理解与生成能力；Dify 是编排层，负责工作流、Prompt 管理、知识库检索和模型路由。缺少任何一层，系统要么没有智能，要么不可运维。

Ollama：本地模型运行时的工程配置

Ollama 的部署本身只是一条命令，但生产可用性取决于几个默认值是否被显式覆盖。最常见的问题是模型推理完即卸载，下一轮对话重新加载导致延迟暴涨；解法是设置 OLLAMA_KEEP_ALIVE 让模型常驻。另一个高频坑是输出长度被截断——num_predict 默认值偏保守，长文任务必须显式调大。以下 Docker Compose 片段将 Ollama 与 GPU 直通、模型常驻、上下文窗口绑定在一起：

services:
  ollama:
    image: ollama/ollama:0.6.5
    ports: ["11434:11434"]
    volumes: [ollama_data:/root/.ollama]
    environment:
      - OLLAMA_KEEP_ALIVE=30m
      - OLLAMA_NUM_CTX=8192
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
volumes:
  ollama_data:

启动后拉取模型并验证推理链是否可见：docker exec -it <container> ollama pull deepseek-r1:7b，然后运行一个需要多步推理的提示，确认输出中包含 <think> 标签。量化选择上，Q4_K_M 在显存减半的同时 perplexity 劣化通常在 2 个点以内，是大多数本地部署的合理默认。

DeepSeek 在 Dify 中的两种接入路径

Dify 接入 DeepSeek 有两条路径，对应不同的部署形态。纯本地路径：模型由 Ollama 加载，Dify 的模型供应商选择 Ollama，基础 URL 填 http://host.docker.internal:11434（Dify 容器内访问宿主机 Ollama 的专用地址）。云端兜底路径：Dify 自定义模型选择 OpenAI 兼容接口，base_url 必须填 https://api.deepseek.com/v1，结尾的 /v1 不可省略，否则 Dify 会拼出错误路径；模型名填 deepseek-chat 或对应版本号。

两条路径可以共存于同一套 Dify 编排中。阿里云那篇复盘给出的分流原则是：简单任务（日常问答、文本整理、格式化）走本地 Ollama，复杂推理（深度分析、多步规划、代码生成）走 DeepSeek API，90% 的日常请求成本归零，API 费只花在刀刃上。

Dify 代码节点：把“分流”和“校验”写成可执行的逻辑

Dify 的 Code 节点允许在可视化工作流中嵌入 Python 或 JavaScript，用于处理内置节点无法完成的数据变换和条件判断。以下代码节点实现一个按任务复杂度分流的函数：输入用户问题和预判的复杂度标签，返回应调用的模型标识。它运行在 Dify 的 sandbox 容器中，不能访问文件系统或发起网络请求，因此返回值必须是纯粹的字符串或结构化字典：

def main(query: str, complexity: str) -> dict:
    """
    输入变量：query（用户问题），complexity（上游分类结果：simple / complex）
    输出：model_route（本地或云端模型标识）
    """
    if complexity == "complex":
        return {"model_route": "deepseek-chat", "reason": "多步推理，走云端"}
    return {"model_route": "deepseek-r1:7b", "reason": "日常任务，本地执行"}

如果需要在代码节点内部完成一次本地模型调用，可以使用 Python 标准库向 Ollama 的 /api/generate 发送请求，但必须将 sandbox 的网络访问配置为允许（SANDBOX_ENABLE_NETWORK=true 并通过 SSRF 代理路由）。以下是最小调用示例：

import json, urllib.request

def main(prompt: str) -> dict:
    req = urllib.request.Request(
        "http://ollama:11434/api/generate",
        data=json.dumps({"model": "deepseek-r1:7b", "prompt": prompt,
                         "stream": False}).encode(),
        headers={"Content-Type": "application/json"}
    )
    with urllib.request.urlopen(req, timeout=120) as resp:
        body = json.loads(resp.read())
    return {"response": body["response"], "done": body["done"]}

注意 stream: False 在代码节点中是必要的：sandbox 的输出有长度限制，流式响应无法被可靠消费。如果响应可能超长，应在提示词侧约束输出长度，或在 num_predict 中显式设置上限。

实战校准：三个必须显式处理的默认值

三剑客跑通之后，系统能否稳定取决于三个“默认值是否被主动覆盖”。第一，OLLAMA_KEEP_ALIVE 不设置，模型频繁冷加载；第二，num_predict 不设置，长回答中途截断；第三，Dify 容器的启动顺序——Dify 全家桶依赖数据库、Redis、sandbox 等多个中间件，未用 depends_on 理清依赖时容器可能因启动顺序错乱而失败。台州信保以“Dify + Ollama + DeepSeek”为核心架构完成 DeepSeek-R1:32b 私有化部署，验证了这套分层在真实企业环境中的可运行性。

三剑客的工程本质，是用 Ollama 解决“模型在哪里跑”，用 DeepSeek 解决“推理有多强”，用 Dify 解决“谁来编排和放行”。三者之间的连接点不是品牌兼容性，而是地址、端口、超时、输出上限、网络策略这些可配置项是否被显式管理。把这些默认值校准到位，本地优先的私有 AI 平台才从 Demo 变成可运维的系统。