尧图网页设计 
简介一份面向企业技术人员与研究员的DeepSeek内网部署实战PDF指南聚焦基于Ollama的私有大模型落地兼顾安全加固与多客户端集成。内容覆盖Ollama在Windows、Linux、macOS上的安装与环境变量配置在线/离线模型下载方式并对比Lmstudio、Chatbox、Cherry-Studio、Lobe Chat四种客户端的接入特点同时给出个人及企业RAG知识库的搭建思路。安全部分从网络隔离、访问控制、模型安全、系统与数据防护多个维度展开并针对内网代理、性能调优和故障排除提供了具体排查思路。压缩包为单份PDF大小2.52MB已有308人学习下载适合具备一定IT基础、需要在金融、医疗等高敏感环境内部署大模型的开发者和运维人员快速上手。1. 内外网 DeepSeek 部署为什么选 Ollama 做中枢以及这套方案解决什么很多做内部工具链的团队第一步就卡在怎么让浏览器、桌面客户端和脚本都调同一个 DeepSeek。直接调在线 API 容易有数据出域顾虑自己写转发层又太费劲。Ollama 在这条路上是门槛最低的入口单进程、支持离线部署、对外提供 OpenAI 兼容接口Open WebUI、Cherry Studio 这些客户端都能直接连。难点在于内外网模型分发、下载慢、默认监听本机、没有内置鉴权导致多客户端接入和安全强化都需要额外补。这篇文章就是沿着这个标题把部署、接入、安全收口、避坑和验证串起来给内网落地一个能照抄的答案。2. 把 Ollama 与 DeepSeek 模型装进内外网离线包、下载慢与存储路径2.1 先判断网络形态三种常见环境的部署差异内网部署第一步不是敲命令而是先弄清这台机器能访问哪些网络。纯内网环境最常见于生产区和研发隔离区机器没有外网路由这时候只能靠离线安装包和模型文件分发。能访问外网的机器可以直接跑官方安装脚本但国内用户普遍会撞上ollama pull下载慢的问题而且模型文件动辄几个 GB反复重试很折磨人。还有一类混合网络部署机能上外网但客户端全在内网这种环境要同时考虑模型拉取和服务暴露范围。我一般先画一张小拓扑把三类角色标出来Ollama 服务节点、客户端网段、模型文件中转机。中转机的作用很关键它负责把模型包从外网搬进来之后再通过内网文件共享或 rsync 分发到目标机器。很多翻车是因为把中转和部署混在同一台机器上结果一边在拉模型一边在对外服务负载和路径全搅在一起。2.2 离线安装 Ollama安装包分发与模型目录搬迁Ollama 官方安装脚本本质上就是把二进制放到/usr/local/bin并注册 systemd 服务。内网环境不需要联网跑脚本直接分发二进制和 service 文件就行。我在交付时一般准备一个最小可用的 systemd 配置避免官方脚本里带的升级逻辑在内网环境添乱。# 内网部署机已经拷入 ollama 二进制 sudo install -o root -g root -m 0755 ollama /usr/local/bin/ollama sudo useradd -r -s /bin/false -m -d /usr/share/ollama ollama # 写入 systemd 服务最小可用版 sudo tee /etc/systemd/system/ollama.service /dev/null EOF [Unit] DescriptionOllama Service Afternetwork-online.target [Service] ExecStart/usr/local/bin/ollama serve Userollama Groupollama Restarton-failure RestartSec3 EnvironmentOLLAMA_HOST0.0.0.0:11434 [Install] WantedBydefault.target EOF sudo systemctl daemon-reload sudo systemctl enable --now ollamaUserollama是为了避免用 root 跑模型服务OLLAMA_HOST0.0.0.0:11434让它监听所有网卡稍后安全强化章节会再收敛。此时ollama list应该能看到空模型列表。关于ollama国内镜像源网上有很多说法但我不会去改源。Ollama 的模型仓库走的是 OCI 分发协议随便换源无法保证哈希一致内网交付一旦出问题很难追溯。更靠谱的做法是利用中转机把模型拉下来打包再用内网高速链路分发。如果是多台机器部署可以只维护一个共享目录作为模型源每台机器用tar解压而不是各自去外网重拉。模型迁移是离线部署最耗时的一步。我一般这样操作在能联网的机器上先ollama pull deepseek-r1:7b然后把~/.ollama/models目录整体打包通过内网文件分发传到目标机器。目标机器的 Ollama 用户家目录要一致否则服务找不到模型。# 在联网机器 ollama pull deepseek-r1:7b tar czf models-backup.tar.gz -C ~/.ollama models # 在内网机器 sudo systemctl stop ollama sudo mv /usr/share/ollama/.ollama/models /usr/share/ollama/.ollama/models.bak sudo tar xzf models-backup.tar.gz -C /usr/share/ollama/.ollama sudo chown -R ollama:ollama /usr/share/ollama/.ollama sudo systemctl start ollama这里有个很多人踩过的点Ollama 的模型仓库目录不是按模型名一层层放的里面包含 manifest、blobs、shards 等结构必须整体搬迁单独拷贝某个 GGUF 文件进去并不会被识别。如果只有 GGUF则要新建Modelfile并用ollama create导入这一步放到避坑章节展开。2.3 修改模型存储路径与监听地址OLLAMA_MODELS 与 OLLAMA_HOST生产环境不建议把模型放在系统盘。DeepSeek 7B 量化后接近 5GB32B 量化后超过 20GB系统盘被撑满会导致整个节点不可用。推荐用独立数据盘sudo mkdir -p /data/ollama/models sudo systemctl edit ollama在编辑窗口写入[Service] EnvironmentOLLAMA_MODELS/data/ollama/models EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_KEEP_ALIVE5m保存后执行sudo systemctl daemon-reload sudo systemctl restart ollamaOLLAMA_MODELS覆盖模型目录OLLAMA_HOST控制监听地址。默认 Ollama 只监听 127.0.0.1内网客户端怎么都连不上必须先改成0.0.0.0或者指定内网网卡 IP。OLLAMA_KEEP_ALIVE是很多人忽略的参数它决定了模型在完成一次请求后留在显存或内存里的时间。默认值是 5 分钟如果客户端频繁请求每次都要重新加载模型首 Token 时延会高得离谱。内网多客户端场景可以调到5m甚至更长后面并发调优再细说。2.4 用 Docker 跑 Ollama 的场景数据卷与端口映射有些团队习惯用 Docker 部署方便和监控、日志体系打通。镜像启动命令并不复杂docker run -d \ --name ollama \ --restartalways \ -v /data/ollama/models:/root/.ollama/models \ -p 127.0.0.1:11434:11434 \ ollama/ollama注意我这里把端口绑定到127.0.0.1然后让宿主机上的 Nginx 或 Open WebUI 通过宿主机地址访问。这样不会把 11434 直接暴露到内网安全强化更好做。数据卷挂载到/root/.ollama/models前提是容器内进程以 root 运行否则权限会有问题。如果用 Docker Compose可以在同一个网络里把 Ollama 和 Open WebUI 放一起避免容器间连接谜之失败。这里先给一个最小 composeservices: ollama: image: ollama/ollama volumes: - /data/ollama/models:/root/.ollama/models environment: OLLAMA_HOST: 0.0.0.0:11434 restart: always open-webui: image: ghcr.io/open-webui/open-webui:main ports: - 3000:8080 environment: OLLAMA_BASE_URL: http://ollama:11434 depends_on: - ollama restart: alwaysOLLAMA_BASE_URL里填的是 compose 服务名ollama不是localhost。这是 Docker 网络的一个经典坑容器内的 localhost 指向容器自己必须用服务名或宿主机网关地址。这一段配置可以直接套在内外网环境里只要把镜像提前拉到内网仓库。纯内网环境里Docker 镜像本身也需要提前准备。在一台能访问外网的机器上先docker pull ollama/ollama再导出镜像包docker save ollama/ollama -o ollama-image.tar内网机器导入docker load -i ollama-image.tar这样整条链路都不依赖外网适合内网交付场景。到这里Ollama 本体已经立住了下一章开始接客户端。3. 多客户端集成Open WebUI、Cherry Studio 与代码调用如何接到同一个 Ollama3.1 认准 Ollama 的两种 API 协议原生接口与 OpenAI 兼容接口DeepSeek 接入多客户端最核心的点是选对协议。Ollama 原生接口POST /api/generate也能用但 Open WebUI、Cherry Studio 以及大部分 AI 应用都更愿意兼容 OpenAI 接口所以统一走POST /v1/chat/completions会省很多适配工作。这样做还有一个好处以后想把底座从 Ollama 换成 vLLM 或其他推理服务客户端的 Base URL 和消息结构都不用动。curl http://192.168.10.5:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:7b, messages: [{role: user, content: 用三句话介绍 Ollama}] }返回的 JSON 结构里choices[0].message.content是最终回复usage给出 token 统计。DeepSeek R1 这类推理模型还会带思考过程不过 Ollama 的兼容接口在不同版本里对这个字段的处理不完全一样建议直接用返回的message.content作为展示文本不要自己拼字段。如果客户端要求填 Base URL 和 API KeyBase URL 填http://内网IP:11434/v1API Key 可以先随便填一个非空字符串因为 Ollama 原生不校验它。但安全强化后这个随便填的值就必须和网关校验逻辑对齐后面第 4 章会讲。3.2 Web 端接入Open WebUI 如何找到内网 OllamaOpen WebUI 是常见的中转层它提供账号体系、历史会话和文件上传前端请求先打到 Open WebUI再转给 Ollama。部署方式见 2.4 的 compose。关键参数就是OLLAMA_BASE_URLOpen WebUI 容器通过这个环境变量决定向哪里发请求。如果 Open WebUI 部署在宿主机、Ollama 也在宿主机OLLAMA_BASE_URL不能写http://localhost:11434因为容器内 localhost 不是宿主机。常见写法是docker run -d \ --name open-webui \ -p 3000:8080 \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ -v open-webui:/app/backend/data \ ghcr.io/open-webui/open-webui:mainWindows 和 macOS 的 Docker Desktop 默认支持host.docker.internalLinux 要在docker run加--add-hosthost.docker.internal:host-gateway。否则用 compose 服务名更干净。Open WebUI 自己的登录账号和 Ollama 无关它在启动后第一次注册的账号会成为管理员。内网交付时要确认这个端口只对局域网开放否则任何人都能注册账号并调用模型这也是安全强化的一部分。3.3 桌面端接入Cherry Studio 填写服务地址与密钥Cherry Studio 是目前比较常用的桌面客户端支持 OpenAI 兼容接口。新增模型服务商时选择 OpenAI 类型填三项API 地址、API Key、模型名。以 Ollama 为例API 地址http://192.168.10.5:11434/v1API Key可以先填ollama模型名deepseek-r1:7bCherry Studio 请求时会拼出http://192.168.10.5:11434/v1/chat/completions。这里有个细节如果地址写成http://192.168.10.5:11434不带/v1很多客户端会自动补但也有客户端的预检逻辑会先打GET /v1/modelsOllama 支持这个路径所以最好还是带上/v1。如果不做安全强化Cherry Studio 装的这个 API Key 就是摆设。做了第 4 章的 Nginx 网关后这个 Key 会变成真正的钥匙。Cherry Studio 每次请求会带Authorization: Bearer key由网关校验。3.4 代码接入用 Python 统一走 /v1/chat/completions团队内部写脚本或做自动化时推荐直接用requests发 HTTP不引入多余 SDK让接入逻辑在换服务时不用改。import requests url http://192.168.10.5:11434/v1/chat/completions payload { model: deepseek-r1:7b, messages: [{role: user, content: 写一段 Nginx 配置限制内网访问}], temperature: 0.2, stream: False } resp requests.post(url, jsonpayload, timeout120) resp.raise_for_status() data resp.json() print(data[choices][0][message][content])timeout建议给到 120 秒以上因为 R1 类模型首 Token 可能要思考很久默认 30 秒容易超时。temperature降到 0.2 左右适合代码生成类任务。流式场景把stream设为 True并迭代响应体中的data:行这里不展开。要是团队里有 Dify 这类应用编排工具也只需要把模型提供商配成 OpenAI 兼容并填同一个地址原理和 Cherry Studio 完全一致接入成本几乎为零。这样一套 Base URL 可以服务 Web、桌面、脚本、编排平台四条通路排查时只要盯住一条链路。4. 安全强化方案从防火墙到 API Key 鉴权再到内外网端口收口4.1 先收敛 11434 的暴露面防火墙与监听地址Ollama 默认不带鉴权因此第一道防线是网络层。如果 Ollama 监听0.0.0.0:11434内网所有机器都能直接调用非常危险。我用 ufw 限制来源网段sudo ufw allow from 192.168.10.0/24 to any port 11434 proto tcp sudo ufw deny 11434/tcp sudo ufw reload这里顺序很重要先放行可信网段再默认拒绝。如果反过来ufw 的规则顺序会导致任意来源都被拒。如果是云环境则在安全组里只放行需要访问 Ollama 的客户端 IP同时设置OLLAMA_HOST只绑定内网网卡 IP比如OLLAMA_HOST192.168.10.5:11434不要绑定0.0.0.0。还有一种常见误用把 Ollama 端口映射到公网主机再靠 API Key 防护。我不建议这么做Ollama 接口中有不少运维性质的路由暴露公网意味着攻击面过大。4.2 用 Nginx 做入口网关TLS 与 Basic Auth 落地内网环境可以不做 TLS但一旦涉及跨集群、跨地域或混合云明文传输模型输入输出容易成为审查问题。用 Nginx 把 11434 收口到 443是最常见的做法。server { listen 443 ssl; server_name llm.internal.example; ssl_certificate /etc/nginx/certs/llm.crt; ssl_certificate_key /etc/nginx/certs/llm.key; auth_basic Ollama API Access; auth_basic_user_file /etc/nginx/htpasswd; client_max_body_size 10m; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; } }auth_basic提供的是用户名密码Open WebUI、Cherry Studio 等客户端对 Basic Auth 的支持参差不齐所以只适合给管理端或内部简单工具用。如果客户端只能填 Bearer Token就要用下一节的方式。TLS 证书这里不展开内网交付可以用自建 CA 签发客户端装根证书公网场景则需要可被信任的证书。关键是 Nginx 只监听 443客户端一律通过https://llm.internal.example/v1访问Ollama 本体不再直接暴露。4.3 让 Cherry Studio 这类客户端带着 API Key 访问Ollama 本身不校验 API Key所以要在 Nginx 里做一层校验。最简单的是直接用map比较 Authorization 头。map $http_authorization $auth_result { default 0; Bearer sk-internal-deepseek-2024 1; } server { listen 443 ssl; server_name llm.internal.example; ssl_certificate /etc/nginx/certs/llm.crt; ssl_certificate_key /etc/nginx/certs/llm.key; if ($auth_result 0) { return 401; } client_max_body_size 10m; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; } }此时客户端配置API 地址https://llm.internal.example/v1API Keysk-internal-deepseek-2024Cherry Studio 发出的请求头是Authorization: Bearer sk-internal-deepseek-2024Nginx 校验通过后把请求转发给本地的 Ollama。Key 泄露时不用重启 Ollama只需要改map里的值并 reload Nginx。map和if的写法不算优雅但它没有额外依赖适合内网小规模部署。想做得更正规可以把校验逻辑提到auth_request指向一个独立鉴权服务但那要额外维护一个进程对团队人力不划算。内网场景先把 Key 校验挡住误用就够了。4.4 内外网隔离的完整端口规划做完安全强化后端口规划应该这样服务端口监听范围说明Ollama11434仅本机 127.0.0.1默认所有流量由 Nginx 转发Nginx443内网/外网按需TLS 终止和 API Key 校验Open WebUI3000仅内网提供账号体系和会话管理远程管理22仅运维网段用于内网维护Ollama 不直接暴露给客户端Nginx 是唯一入口。如果要彻底内外网隔离不要让 443 对公网开放而是要求用户先进入办公网再访问llm.internal.example。若公网也必须提供服务就把 Nginx 的 443 放入公网安全组但必须在 Nginx 之上再做来源 IP 白名单同时 TLS 证书使用内部 CA 或已备案证书。这两条不是二选一而是缺一不可。安全强化的核心是让所有客户端都看到同一个入口但入口背后只有一条可控链路。这样可以随时回收密钥、观察访问日志而不用逐个客户端去改配置。5. 避坑Ollama 部署 DeepSeek 最常见的 5 个翻车现场5.1 安装与导入相关的两个坑现象一在内网机器上执行ollama pull deepseek-r1:7b进度卡在 0%过一会儿报connection refused或tls handshake timeout。原因模型文件托管在海外对象存储纯内网机器没有外网路由。解决不要在目标机上直接拉。在能联网的机器上先拉好把~/.ollama/models目录打包传到内网放到和ollama服务用户匹配的家目录下然后sudo chown -R ollama:ollama。注意 tar 包解压后不要手动合并 blobs直接覆盖目录即可。现象二只有一份 GGUF 文件拷进 models 目录后ollama list看不到。原因Ollama 不直接识别裸 GGUF需要经过Modelfile创建。解决把 GGUF 放在固定目录写一个最小ModelfileFROM /data/gguf/deepseek-r1-7b.Q4_K_M.gguf然后执行ollama create deepseek-r1-local -f /data/gguf/ModelfileDeepSeek 官方的 GGUF 可能带多份文件FROM路径写主 GGUF 即可Ollama 会自动解析同目录下的分片。5.2 连接与容器相关的坑现象三Open WebUI 在容器里报Ollama isnt running或者connection refused。原因容器里的localhost指向容器自己而 Ollama 跑在宿主机也没有走 compose 网络。解决确认 Ollama 的监听地址为0.0.0.0:11434然后在 Open WebUI 容器里把OLLAMA_BASE_URL设为http://宿主机IP:11434。用 Docker Desktop 开发时可以设为http://host.docker.internal:11434Linux Docker 需要在启动参数加--add-hosthost.docker.internal:host-gateway。检查时用curl http://宿主机IP:11434/api/version从容器内先验证。现象四桌面客户端连接成功后模型列表能看到但发起对话一直转圈。原因常见为 API 地址写错比如多写了/api/generate或者把stream设成 false 后客户端没有正确等待。解决统一填http://内网IP:11434/v1而不是http://内网IP:11434模型名要和ollama list输出完全一致包含小数点和标签。可以先用 3.1 的 curl 命令验证一次非流式请求再切回客户端测试。如果 curl 正常而客户端不行把客户端日志打开看请求落到了哪个路径。5.3 运行与并发相关的坑现象五多客户端同时用模型反复加载卸载有时候响应间隔长达几十秒。原因Ollama 默认并发加载策略会按空闲情况卸载模型。多个客户端轮询时keep_alive太短导致模型被频繁卸载。解决按需调大OLLAMA_KEEP_ALIVE或者设置OLLAMA_NUM_PARALLEL。具体做法是在 systemd 环境变量里加EnvironmentOLLAMA_KEEP_ALIVE10m EnvironmentOLLAMA_NUM_PARALLEL1如果只有一块 GPU建议把并行数设为 1避免多个请求争显存导致 OOM如果显存能装下模型且还有余量可以调整大于 1。另外磁盘写入问题在 2.3 已经强调过这里再提醒一句检查OLLAMA_MODELS所在分区剩余空间ollama list不会预警磁盘满写满后模型加载会报blobs/... no such file or directory。5.4 安全校验相关的坑现象六Nginx 已经加了 API Key但 curl 不加 Key 也能拿到模型列表。原因location /里的auth_basic只对指定 location 生效某些客户端请求/api/version和/v1/models可能会绕过。解决把校验放到server块级别的if或者对 API Key 使用map方法确保/v1/下所有路径都经过统一判断。更简单的是在 Nginx 配置里设定location /api/version { return 404; }把不应公开的运维接口先藏掉。同时注意日志脱敏Nginx 的 access log 会记录完整 URL 和部分 Headers如果日志里有auth_basic密码或 Key需要设置log_format去掉这些字段。6. 进阶验证与调优用冒烟脚本收口多客户端链路并盯住三个指标6.1 写一个冒烟脚本验证接口、鉴权与模型是否可用部署完成之后不要急着让全组试用先跑一遍冒烟脚本把链路分成三层验证网络通不通、鉴权拦不拦、模型回不回。这个脚本可以作为交付前的验收依据。import requests base https://llm.internal.example/v1 headers_ok {Authorization: Bearer sk-internal-deepseek-2024} payload { model: deepseek-r1:7b, messages: [{role: user, content: ping}], stream: False } # 验证鉴权不加 key 应该被 401 拦下 r requests.post(f{base}/chat/completions, jsonpayload, timeout30) assert r.status_code 401, fexpected 401, got {r.status_code} # 验证模型链路加 key 应该正常返回 r requests.post(f{base}/chat/completions, jsonpayload, headersheaders_ok, timeout180) r.raise_for_status() answer r.json()[choices][0][message][content] print(answer[:50])一条脚本把 Nginx 的 Key 校验、Ollama 的模型加载和 OpenAI 兼容接口全串起来。任何一环坏了都能立刻定位。6.2 三个关键指标首 Token 时延、模型加载时间和请求排队数内网部署最怕的不是模型跑不动而是用户点完按钮之后不知道在等什么。我在运维时只看三个指标指标查看方式健康区间首 Token 时延脚本计时time.perf_counter()本地模型 3s模型加载时间ollama ps观察加载状态加载后保持驻留请求排队数Nginx 日志统计高峰 5ollama ps可以看到当前加载的模型和显存占用如果发现每次请求前后模型状态从空到 loaded说明 keep_alive 太短。Nginx 日志里upstream_response_time变长则说明排队或抢占开始出现。另外提一句关于 DeepSeek R1 的体验问题R1 会在正文前输出一大段思考过程Ollama 没有开关直接关闭。常见做法是在系统提示词里加一句“只输出最终答案”或者在前端展示时过滤reasoning字段。这个调优对多人同时使用的体验提升很明显。我第一次做内网部署时把OLLAMA_HOST忘改了三个客户端全连不上最后发现是本地回环地址在挡路后来又把keep_alive调太短模型反复加载被同事笑话说“上班先等两分钟”。从那以后我每次交付都先跑一遍上面的脚本再盯三个指标。希望帮到你。本文还有配套的精品资源点击获取 Ollama内网部署DeepSeek：多客户端接入与安全加固指南
简介一份面向企业技术人员与研究员的DeepSeek内网部署实战PDF指南聚焦基于Ollama的私有大模型落地兼顾安全加固与多客户端集成。内容覆盖Ollama在Windows、Linux、macOS上的安装与环境变量配置在线/离线模型下载方式并对比Lmstudio、Chatbox、Cherry-Studio、Lobe Chat四种客户端的接入特点同时给出个人及企业RAG知识库的搭建思路。安全部分从网络隔离、访问控制、模型安全、系统与数据防护多个维度展开并针对内网代理、性能调优和故障排除提供了具体排查思路。压缩包为单份PDF大小2.52MB已有308人学习下载适合具备一定IT基础、需要在金融、医疗等高敏感环境内部署大模型的开发者和运维人员快速上手。1. 内外网 DeepSeek 部署为什么选 Ollama 做中枢以及这套方案解决什么很多做内部工具链的团队第一步就卡在怎么让浏览器、桌面客户端和脚本都调同一个 DeepSeek。直接调在线 API 容易有数据出域顾虑自己写转发层又太费劲。Ollama 在这条路上是门槛最低的入口单进程、支持离线部署、对外提供 OpenAI 兼容接口Open WebUI、Cherry Studio 这些客户端都能直接连。难点在于内外网模型分发、下载慢、默认监听本机、没有内置鉴权导致多客户端接入和安全强化都需要额外补。这篇文章就是沿着这个标题把部署、接入、安全收口、避坑和验证串起来给内网落地一个能照抄的答案。2. 把 Ollama 与 DeepSeek 模型装进内外网离线包、下载慢与存储路径2.1 先判断网络形态三种常见环境的部署差异内网部署第一步不是敲命令而是先弄清这台机器能访问哪些网络。纯内网环境最常见于生产区和研发隔离区机器没有外网路由这时候只能靠离线安装包和模型文件分发。能访问外网的机器可以直接跑官方安装脚本但国内用户普遍会撞上ollama pull下载慢的问题而且模型文件动辄几个 GB反复重试很折磨人。还有一类混合网络部署机能上外网但客户端全在内网这种环境要同时考虑模型拉取和服务暴露范围。我一般先画一张小拓扑把三类角色标出来Ollama 服务节点、客户端网段、模型文件中转机。中转机的作用很关键它负责把模型包从外网搬进来之后再通过内网文件共享或 rsync 分发到目标机器。很多翻车是因为把中转和部署混在同一台机器上结果一边在拉模型一边在对外服务负载和路径全搅在一起。2.2 离线安装 Ollama安装包分发与模型目录搬迁Ollama 官方安装脚本本质上就是把二进制放到/usr/local/bin并注册 systemd 服务。内网环境不需要联网跑脚本直接分发二进制和 service 文件就行。我在交付时一般准备一个最小可用的 systemd 配置避免官方脚本里带的升级逻辑在内网环境添乱。# 内网部署机已经拷入 ollama 二进制 sudo install -o root -g root -m 0755 ollama /usr/local/bin/ollama sudo useradd -r -s /bin/false -m -d /usr/share/ollama ollama # 写入 systemd 服务最小可用版 sudo tee /etc/systemd/system/ollama.service /dev/null EOF [Unit] DescriptionOllama Service Afternetwork-online.target [Service] ExecStart/usr/local/bin/ollama serve Userollama Groupollama Restarton-failure RestartSec3 EnvironmentOLLAMA_HOST0.0.0.0:11434 [Install] WantedBydefault.target EOF sudo systemctl daemon-reload sudo systemctl enable --now ollamaUserollama是为了避免用 root 跑模型服务OLLAMA_HOST0.0.0.0:11434让它监听所有网卡稍后安全强化章节会再收敛。此时ollama list应该能看到空模型列表。关于ollama国内镜像源网上有很多说法但我不会去改源。Ollama 的模型仓库走的是 OCI 分发协议随便换源无法保证哈希一致内网交付一旦出问题很难追溯。更靠谱的做法是利用中转机把模型拉下来打包再用内网高速链路分发。如果是多台机器部署可以只维护一个共享目录作为模型源每台机器用tar解压而不是各自去外网重拉。模型迁移是离线部署最耗时的一步。我一般这样操作在能联网的机器上先ollama pull deepseek-r1:7b然后把~/.ollama/models目录整体打包通过内网文件分发传到目标机器。目标机器的 Ollama 用户家目录要一致否则服务找不到模型。# 在联网机器 ollama pull deepseek-r1:7b tar czf models-backup.tar.gz -C ~/.ollama models # 在内网机器 sudo systemctl stop ollama sudo mv /usr/share/ollama/.ollama/models /usr/share/ollama/.ollama/models.bak sudo tar xzf models-backup.tar.gz -C /usr/share/ollama/.ollama sudo chown -R ollama:ollama /usr/share/ollama/.ollama sudo systemctl start ollama这里有个很多人踩过的点Ollama 的模型仓库目录不是按模型名一层层放的里面包含 manifest、blobs、shards 等结构必须整体搬迁单独拷贝某个 GGUF 文件进去并不会被识别。如果只有 GGUF则要新建Modelfile并用ollama create导入这一步放到避坑章节展开。2.3 修改模型存储路径与监听地址OLLAMA_MODELS 与 OLLAMA_HOST生产环境不建议把模型放在系统盘。DeepSeek 7B 量化后接近 5GB32B 量化后超过 20GB系统盘被撑满会导致整个节点不可用。推荐用独立数据盘sudo mkdir -p /data/ollama/models sudo systemctl edit ollama在编辑窗口写入[Service] EnvironmentOLLAMA_MODELS/data/ollama/models EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_KEEP_ALIVE5m保存后执行sudo systemctl daemon-reload sudo systemctl restart ollamaOLLAMA_MODELS覆盖模型目录OLLAMA_HOST控制监听地址。默认 Ollama 只监听 127.0.0.1内网客户端怎么都连不上必须先改成0.0.0.0或者指定内网网卡 IP。OLLAMA_KEEP_ALIVE是很多人忽略的参数它决定了模型在完成一次请求后留在显存或内存里的时间。默认值是 5 分钟如果客户端频繁请求每次都要重新加载模型首 Token 时延会高得离谱。内网多客户端场景可以调到5m甚至更长后面并发调优再细说。2.4 用 Docker 跑 Ollama 的场景数据卷与端口映射有些团队习惯用 Docker 部署方便和监控、日志体系打通。镜像启动命令并不复杂docker run -d \ --name ollama \ --restartalways \ -v /data/ollama/models:/root/.ollama/models \ -p 127.0.0.1:11434:11434 \ ollama/ollama注意我这里把端口绑定到127.0.0.1然后让宿主机上的 Nginx 或 Open WebUI 通过宿主机地址访问。这样不会把 11434 直接暴露到内网安全强化更好做。数据卷挂载到/root/.ollama/models前提是容器内进程以 root 运行否则权限会有问题。如果用 Docker Compose可以在同一个网络里把 Ollama 和 Open WebUI 放一起避免容器间连接谜之失败。这里先给一个最小 composeservices: ollama: image: ollama/ollama volumes: - /data/ollama/models:/root/.ollama/models environment: OLLAMA_HOST: 0.0.0.0:11434 restart: always open-webui: image: ghcr.io/open-webui/open-webui:main ports: - 3000:8080 environment: OLLAMA_BASE_URL: http://ollama:11434 depends_on: - ollama restart: alwaysOLLAMA_BASE_URL里填的是 compose 服务名ollama不是localhost。这是 Docker 网络的一个经典坑容器内的 localhost 指向容器自己必须用服务名或宿主机网关地址。这一段配置可以直接套在内外网环境里只要把镜像提前拉到内网仓库。纯内网环境里Docker 镜像本身也需要提前准备。在一台能访问外网的机器上先docker pull ollama/ollama再导出镜像包docker save ollama/ollama -o ollama-image.tar内网机器导入docker load -i ollama-image.tar这样整条链路都不依赖外网适合内网交付场景。到这里Ollama 本体已经立住了下一章开始接客户端。3. 多客户端集成Open WebUI、Cherry Studio 与代码调用如何接到同一个 Ollama3.1 认准 Ollama 的两种 API 协议原生接口与 OpenAI 兼容接口DeepSeek 接入多客户端最核心的点是选对协议。Ollama 原生接口POST /api/generate也能用但 Open WebUI、Cherry Studio 以及大部分 AI 应用都更愿意兼容 OpenAI 接口所以统一走POST /v1/chat/completions会省很多适配工作。这样做还有一个好处以后想把底座从 Ollama 换成 vLLM 或其他推理服务客户端的 Base URL 和消息结构都不用动。curl http://192.168.10.5:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:7b, messages: [{role: user, content: 用三句话介绍 Ollama}] }返回的 JSON 结构里choices[0].message.content是最终回复usage给出 token 统计。DeepSeek R1 这类推理模型还会带思考过程不过 Ollama 的兼容接口在不同版本里对这个字段的处理不完全一样建议直接用返回的message.content作为展示文本不要自己拼字段。如果客户端要求填 Base URL 和 API KeyBase URL 填http://内网IP:11434/v1API Key 可以先随便填一个非空字符串因为 Ollama 原生不校验它。但安全强化后这个随便填的值就必须和网关校验逻辑对齐后面第 4 章会讲。3.2 Web 端接入Open WebUI 如何找到内网 OllamaOpen WebUI 是常见的中转层它提供账号体系、历史会话和文件上传前端请求先打到 Open WebUI再转给 Ollama。部署方式见 2.4 的 compose。关键参数就是OLLAMA_BASE_URLOpen WebUI 容器通过这个环境变量决定向哪里发请求。如果 Open WebUI 部署在宿主机、Ollama 也在宿主机OLLAMA_BASE_URL不能写http://localhost:11434因为容器内 localhost 不是宿主机。常见写法是docker run -d \ --name open-webui \ -p 3000:8080 \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ -v open-webui:/app/backend/data \ ghcr.io/open-webui/open-webui:mainWindows 和 macOS 的 Docker Desktop 默认支持host.docker.internalLinux 要在docker run加--add-hosthost.docker.internal:host-gateway。否则用 compose 服务名更干净。Open WebUI 自己的登录账号和 Ollama 无关它在启动后第一次注册的账号会成为管理员。内网交付时要确认这个端口只对局域网开放否则任何人都能注册账号并调用模型这也是安全强化的一部分。3.3 桌面端接入Cherry Studio 填写服务地址与密钥Cherry Studio 是目前比较常用的桌面客户端支持 OpenAI 兼容接口。新增模型服务商时选择 OpenAI 类型填三项API 地址、API Key、模型名。以 Ollama 为例API 地址http://192.168.10.5:11434/v1API Key可以先填ollama模型名deepseek-r1:7bCherry Studio 请求时会拼出http://192.168.10.5:11434/v1/chat/completions。这里有个细节如果地址写成http://192.168.10.5:11434不带/v1很多客户端会自动补但也有客户端的预检逻辑会先打GET /v1/modelsOllama 支持这个路径所以最好还是带上/v1。如果不做安全强化Cherry Studio 装的这个 API Key 就是摆设。做了第 4 章的 Nginx 网关后这个 Key 会变成真正的钥匙。Cherry Studio 每次请求会带Authorization: Bearer key由网关校验。3.4 代码接入用 Python 统一走 /v1/chat/completions团队内部写脚本或做自动化时推荐直接用requests发 HTTP不引入多余 SDK让接入逻辑在换服务时不用改。import requests url http://192.168.10.5:11434/v1/chat/completions payload { model: deepseek-r1:7b, messages: [{role: user, content: 写一段 Nginx 配置限制内网访问}], temperature: 0.2, stream: False } resp requests.post(url, jsonpayload, timeout120) resp.raise_for_status() data resp.json() print(data[choices][0][message][content])timeout建议给到 120 秒以上因为 R1 类模型首 Token 可能要思考很久默认 30 秒容易超时。temperature降到 0.2 左右适合代码生成类任务。流式场景把stream设为 True并迭代响应体中的data:行这里不展开。要是团队里有 Dify 这类应用编排工具也只需要把模型提供商配成 OpenAI 兼容并填同一个地址原理和 Cherry Studio 完全一致接入成本几乎为零。这样一套 Base URL 可以服务 Web、桌面、脚本、编排平台四条通路排查时只要盯住一条链路。4. 安全强化方案从防火墙到 API Key 鉴权再到内外网端口收口4.1 先收敛 11434 的暴露面防火墙与监听地址Ollama 默认不带鉴权因此第一道防线是网络层。如果 Ollama 监听0.0.0.0:11434内网所有机器都能直接调用非常危险。我用 ufw 限制来源网段sudo ufw allow from 192.168.10.0/24 to any port 11434 proto tcp sudo ufw deny 11434/tcp sudo ufw reload这里顺序很重要先放行可信网段再默认拒绝。如果反过来ufw 的规则顺序会导致任意来源都被拒。如果是云环境则在安全组里只放行需要访问 Ollama 的客户端 IP同时设置OLLAMA_HOST只绑定内网网卡 IP比如OLLAMA_HOST192.168.10.5:11434不要绑定0.0.0.0。还有一种常见误用把 Ollama 端口映射到公网主机再靠 API Key 防护。我不建议这么做Ollama 接口中有不少运维性质的路由暴露公网意味着攻击面过大。4.2 用 Nginx 做入口网关TLS 与 Basic Auth 落地内网环境可以不做 TLS但一旦涉及跨集群、跨地域或混合云明文传输模型输入输出容易成为审查问题。用 Nginx 把 11434 收口到 443是最常见的做法。server { listen 443 ssl; server_name llm.internal.example; ssl_certificate /etc/nginx/certs/llm.crt; ssl_certificate_key /etc/nginx/certs/llm.key; auth_basic Ollama API Access; auth_basic_user_file /etc/nginx/htpasswd; client_max_body_size 10m; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; } }auth_basic提供的是用户名密码Open WebUI、Cherry Studio 等客户端对 Basic Auth 的支持参差不齐所以只适合给管理端或内部简单工具用。如果客户端只能填 Bearer Token就要用下一节的方式。TLS 证书这里不展开内网交付可以用自建 CA 签发客户端装根证书公网场景则需要可被信任的证书。关键是 Nginx 只监听 443客户端一律通过https://llm.internal.example/v1访问Ollama 本体不再直接暴露。4.3 让 Cherry Studio 这类客户端带着 API Key 访问Ollama 本身不校验 API Key所以要在 Nginx 里做一层校验。最简单的是直接用map比较 Authorization 头。map $http_authorization $auth_result { default 0; Bearer sk-internal-deepseek-2024 1; } server { listen 443 ssl; server_name llm.internal.example; ssl_certificate /etc/nginx/certs/llm.crt; ssl_certificate_key /etc/nginx/certs/llm.key; if ($auth_result 0) { return 401; } client_max_body_size 10m; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; } }此时客户端配置API 地址https://llm.internal.example/v1API Keysk-internal-deepseek-2024Cherry Studio 发出的请求头是Authorization: Bearer sk-internal-deepseek-2024Nginx 校验通过后把请求转发给本地的 Ollama。Key 泄露时不用重启 Ollama只需要改map里的值并 reload Nginx。map和if的写法不算优雅但它没有额外依赖适合内网小规模部署。想做得更正规可以把校验逻辑提到auth_request指向一个独立鉴权服务但那要额外维护一个进程对团队人力不划算。内网场景先把 Key 校验挡住误用就够了。4.4 内外网隔离的完整端口规划做完安全强化后端口规划应该这样服务端口监听范围说明Ollama11434仅本机 127.0.0.1默认所有流量由 Nginx 转发Nginx443内网/外网按需TLS 终止和 API Key 校验Open WebUI3000仅内网提供账号体系和会话管理远程管理22仅运维网段用于内网维护Ollama 不直接暴露给客户端Nginx 是唯一入口。如果要彻底内外网隔离不要让 443 对公网开放而是要求用户先进入办公网再访问llm.internal.example。若公网也必须提供服务就把 Nginx 的 443 放入公网安全组但必须在 Nginx 之上再做来源 IP 白名单同时 TLS 证书使用内部 CA 或已备案证书。这两条不是二选一而是缺一不可。安全强化的核心是让所有客户端都看到同一个入口但入口背后只有一条可控链路。这样可以随时回收密钥、观察访问日志而不用逐个客户端去改配置。5. 避坑Ollama 部署 DeepSeek 最常见的 5 个翻车现场5.1 安装与导入相关的两个坑现象一在内网机器上执行ollama pull deepseek-r1:7b进度卡在 0%过一会儿报connection refused或tls handshake timeout。原因模型文件托管在海外对象存储纯内网机器没有外网路由。解决不要在目标机上直接拉。在能联网的机器上先拉好把~/.ollama/models目录打包传到内网放到和ollama服务用户匹配的家目录下然后sudo chown -R ollama:ollama。注意 tar 包解压后不要手动合并 blobs直接覆盖目录即可。现象二只有一份 GGUF 文件拷进 models 目录后ollama list看不到。原因Ollama 不直接识别裸 GGUF需要经过Modelfile创建。解决把 GGUF 放在固定目录写一个最小ModelfileFROM /data/gguf/deepseek-r1-7b.Q4_K_M.gguf然后执行ollama create deepseek-r1-local -f /data/gguf/ModelfileDeepSeek 官方的 GGUF 可能带多份文件FROM路径写主 GGUF 即可Ollama 会自动解析同目录下的分片。5.2 连接与容器相关的坑现象三Open WebUI 在容器里报Ollama isnt running或者connection refused。原因容器里的localhost指向容器自己而 Ollama 跑在宿主机也没有走 compose 网络。解决确认 Ollama 的监听地址为0.0.0.0:11434然后在 Open WebUI 容器里把OLLAMA_BASE_URL设为http://宿主机IP:11434。用 Docker Desktop 开发时可以设为http://host.docker.internal:11434Linux Docker 需要在启动参数加--add-hosthost.docker.internal:host-gateway。检查时用curl http://宿主机IP:11434/api/version从容器内先验证。现象四桌面客户端连接成功后模型列表能看到但发起对话一直转圈。原因常见为 API 地址写错比如多写了/api/generate或者把stream设成 false 后客户端没有正确等待。解决统一填http://内网IP:11434/v1而不是http://内网IP:11434模型名要和ollama list输出完全一致包含小数点和标签。可以先用 3.1 的 curl 命令验证一次非流式请求再切回客户端测试。如果 curl 正常而客户端不行把客户端日志打开看请求落到了哪个路径。5.3 运行与并发相关的坑现象五多客户端同时用模型反复加载卸载有时候响应间隔长达几十秒。原因Ollama 默认并发加载策略会按空闲情况卸载模型。多个客户端轮询时keep_alive太短导致模型被频繁卸载。解决按需调大OLLAMA_KEEP_ALIVE或者设置OLLAMA_NUM_PARALLEL。具体做法是在 systemd 环境变量里加EnvironmentOLLAMA_KEEP_ALIVE10m EnvironmentOLLAMA_NUM_PARALLEL1如果只有一块 GPU建议把并行数设为 1避免多个请求争显存导致 OOM如果显存能装下模型且还有余量可以调整大于 1。另外磁盘写入问题在 2.3 已经强调过这里再提醒一句检查OLLAMA_MODELS所在分区剩余空间ollama list不会预警磁盘满写满后模型加载会报blobs/... no such file or directory。5.4 安全校验相关的坑现象六Nginx 已经加了 API Key但 curl 不加 Key 也能拿到模型列表。原因location /里的auth_basic只对指定 location 生效某些客户端请求/api/version和/v1/models可能会绕过。解决把校验放到server块级别的if或者对 API Key 使用map方法确保/v1/下所有路径都经过统一判断。更简单的是在 Nginx 配置里设定location /api/version { return 404; }把不应公开的运维接口先藏掉。同时注意日志脱敏Nginx 的 access log 会记录完整 URL 和部分 Headers如果日志里有auth_basic密码或 Key需要设置log_format去掉这些字段。6. 进阶验证与调优用冒烟脚本收口多客户端链路并盯住三个指标6.1 写一个冒烟脚本验证接口、鉴权与模型是否可用部署完成之后不要急着让全组试用先跑一遍冒烟脚本把链路分成三层验证网络通不通、鉴权拦不拦、模型回不回。这个脚本可以作为交付前的验收依据。import requests base https://llm.internal.example/v1 headers_ok {Authorization: Bearer sk-internal-deepseek-2024} payload { model: deepseek-r1:7b, messages: [{role: user, content: ping}], stream: False } # 验证鉴权不加 key 应该被 401 拦下 r requests.post(f{base}/chat/completions, jsonpayload, timeout30) assert r.status_code 401, fexpected 401, got {r.status_code} # 验证模型链路加 key 应该正常返回 r requests.post(f{base}/chat/completions, jsonpayload, headersheaders_ok, timeout180) r.raise_for_status() answer r.json()[choices][0][message][content] print(answer[:50])一条脚本把 Nginx 的 Key 校验、Ollama 的模型加载和 OpenAI 兼容接口全串起来。任何一环坏了都能立刻定位。6.2 三个关键指标首 Token 时延、模型加载时间和请求排队数内网部署最怕的不是模型跑不动而是用户点完按钮之后不知道在等什么。我在运维时只看三个指标指标查看方式健康区间首 Token 时延脚本计时time.perf_counter()本地模型 3s模型加载时间ollama ps观察加载状态加载后保持驻留请求排队数Nginx 日志统计高峰 5ollama ps可以看到当前加载的模型和显存占用如果发现每次请求前后模型状态从空到 loaded说明 keep_alive 太短。Nginx 日志里upstream_response_time变长则说明排队或抢占开始出现。另外提一句关于 DeepSeek R1 的体验问题R1 会在正文前输出一大段思考过程Ollama 没有开关直接关闭。常见做法是在系统提示词里加一句“只输出最终答案”或者在前端展示时过滤reasoning字段。这个调优对多人同时使用的体验提升很明显。我第一次做内网部署时把OLLAMA_HOST忘改了三个客户端全连不上最后发现是本地回环地址在挡路后来又把keep_alive调太短模型反复加载被同事笑话说“上班先等两分钟”。从那以后我每次交付都先跑一遍上面的脚本再盯三个指标。希望帮到你。本文还有配套的精品资源点击获取