★ FEATURED ARTICLE 1. 内网部署 DeepSeek 的真实困境与破局思路很多企业想把大模型用起来第一反应是调云端 API但真到落地阶段安全部门一句数据不能出内网就把方案打回去了。尤其是金融、医疗、制造业的研发团队代码、工单、客户资料这些内容一旦离开内网合规上根本过不去。我接触过几个团队他们的诉求非常一致模型要能跑在自己的服务器上接口要统一最好还能像调 OpenAI 那样一行代码切换模型。这就是企业专属 DeepSeek 智能中台要解决的问题。核心思路其实不复杂用 Ollama 在内网服务器上把 DeepSeek 跑起来再用 OneAPI 做一层统一网关把 Ollama 的本地模型、以及未来可能接入的其他模型全部包装成标准的 OpenAI 兼容接口。这样上层业务系统只需要认一个 Base URL 和一个 Key底层换模型、加模型都不用改业务代码。为什么选 DeepSeek因为它在中文推理、代码生成上的表现确实能打而且开源权重可以本地部署32B 量化版本在单张 24G 显存的卡上就能跑起来对中小企业来说门槛可控。为什么选 Ollama它把模型加载、显存管理、API 暴露这些脏活都封装好了一条ollama serve就能对外提供 HTTP 接口。为什么还要 OneAPI因为 Ollama 原生接口虽然能用但格式和 OpenAI 不完全一致而且多模型、多 Key、用量统计这些企业级需求它不管OneAPI 正好补上这块。整个链路是这样的业务系统 → OneAPI统一网关端口 3000→ Ollama本地推理端口 11434→ DeepSeek 模型。数据全程在内网流转不出网卡。下面我把这套中台的搭建过程拆成可复制的步骤包括离线环境下的模型导入、OneAPI 的渠道配置、以及连通性验证。2. 前置准备Ollama 离线安装与 DeepSeek 模型导入内网服务器最大的坑就是装不了东西。Ollama 官方的一键脚本curl -fsSL https://ollama.com/install.sh | sh在内网直接歇菜因为脚本本身要联网下载二进制包。所以必须走离线路线在有网的机器上下载好安装包和模型文件再通过 U 盘或跳板机传进内网。先说 Ollama 的离线安装。根据服务器架构一般是 linux-amd64在有网机器上执行curl -L https://ollama.com/download/ollama-linux-amd64.tgz -o ollama-linux-amd64.tgz下载完通过 scp 或堡垒机传到内网服务器比如放到/tmp目录。然后解压安装sudo tar -C /usr -xzf /tmp/ollama-linux-amd64.tgz解压后/usr/bin/ollama就有了直接执行ollama serve能跑起来。但为了让它开机自启、方便管理建议注册成 systemd 服务。先创建专用用户sudo useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama sudo usermod -a -G ollama $(whoami)然后在/etc/systemd/system/ollama.service写入[Unit] DescriptionOllama Service Afternetwork-online.target [Service] ExecStart/usr/bin/ollama serve Userollama Groupollama Restartalways RestartSec3 EnvironmentPATH$PATH EnvironmentOLLAMA_HOST0.0.0.0:11434 [Install] WantedBydefault.target注意这里加了OLLAMA_HOST0.0.0.0:11434否则 Ollama 默认只监听 127.0.0.1OneAPI 容器访问不到。改完执行sudo systemctl daemon-reload sudo systemctl enable --now ollama接下来是模型导入这是内网部署最绕的一步。内网没法ollama pull得先在本地机器上把模型拉下来找到模型文件再传进去。本地执行ollama pull deepseek-r1:32b ollama show deepseek-r1:32b --modelfile输出里会有一行FROM C:\Users\xxx\.ollama\models\blobs\sha256-96c415...这个路径就是模型权重文件。同时把 Modelfile 导出ollama show deepseek-r1:32b --modelfile Modelfile把权重文件和 Modelfile 一起传到内网服务器同一目录比如/opt/models/deepseek。进去后重命名权重文件方便识别mv sha256-96c415656d377afbff962f6cdb2394ab092ccbcbaab4b82525bc4ca800fe8a49 deepseek-r1_32b.gguf然后编辑 Modelfile把FROM那行改成相对路径FROM ./deepseek-r1_32b.gguf最后导入ollama create deepseek-r1:32b -f Modelfile ollama list看到deepseek-r1:32b出现在列表里模型这步就成了。这里有个细节Modelfile 里的 TEMPLATE 和 PARAMETER 不要动那是 DeepSeek 的对话模板改了会导致输出格式错乱。3. OneAPI 网关部署与渠道配置可复制片段模型跑起来只是第一步要让业务系统方便调用还得有 OneAPI 这层网关。OneAPI 是开源的 LLM API 管理与分发系统能把 Ollama、OpenAI、Claude 等各种后端统一成 OpenAI 格式。内网部署同样用 Docker先写docker-compose.yamlservices: db: image: mysql:8.1.0 container_name: mysql restart: always environment: MYSQL_ROOT_PASSWORD: mysql-password volumes: - ./data:/var/lib/mysql one-api: image: justsong/one-api container_name: one-api restart: always ports: - 3000:3000 depends_on: - db environment: - SQL_DSNroot:mysql-passwordtcp(db:3306)/one_api - TZAsia/Shanghai - TIKTOKEN_CACHE_DIR/TIKTOKEN_CACHE_DIR volumes: - ./data:/data - ./TIKTOKEN_CACHE_DIR:/TIKTOKEN_CACHE_DIR networks: default: name: one-api这里有个内网必踩的坑OneAPI 依赖 tiktoken 做 token 计数而 tiktoken 启动时会去openaipublic.blob.core.windows.net下载编码文件内网直接超时。报错长这样[FATAL] failed to get gpt-3.5-turbo token encoder: dial tcp ... i/o timeout, if you are using in offline environment, please set TIKTOKEN_CACHE_DIR to use exsited files解决办法是手动把编码文件放进去。tiktoken 认的是 URL 的 SHA-1 作为文件名先算哈希echo -n https://openaipublic.blob.core.windows.net/encodings/cl100k_base.tiktoken | sha1sum | head -c 40输出是9b5ad71b2ce5302211f9c61530b329a4922fc6a4。在有网机器上下载cl100k_base.tiktoken重命名为这个哈希值放进./TIKTOKEN_CACHE_DIR目录。如果日志里还报别的 encoder 缺失重复这个操作直到启动不再报错。启动服务docker compose up -d docker compose logs -f one-api看到监听 3000 端口就 OK。浏览器访问http://内网IP:3000默认账号root密码123456首次登录务必改掉。接下来配置 Ollama 渠道。进后台「渠道」→「添加新的渠道」关键字段这样填字段值说明类型Ollama下拉选择名称deepseek-local自定义分组default默认分组模型deepseek-r1:32b与 ollama list 一致代理留空内网直连密钥任意填Ollama 不校验最容易卡住的是「代理」地址。OneAPI 跑在容器里容器内的localhost指向容器自己不是宿主机。所以不能填http://localhost:11434。两种解法一是让 OneAPI 容器用 host 网络模式network_mode: host然后填http://127.0.0.1:11434二是保持 bridge 网络填http://host.docker.internal:11434但 Linux 下需要在 compose 里加extra_hosts: - host.docker.internal:host-gateway。我一般用第一种省事。渠道建好后去「令牌」页面新建一个令牌这就是业务系统要用的统一 Key。到这里网关层就通了。4. 内网调用验证与连通性排查动作配置完不验证等于没配。验证要分两层先确认 Ollama 本身能出结果再确认通过 OneAPI 能出结果。第一层直接在服务器上打 Ollama 原生接口curl http://127.0.0.1:11434/api/generate -d { model: deepseek-r1:32b, prompt: 用一句话解释什么是向量数据库, stream: false }如果返回 JSON 里有response字段且内容是中文说明模型加载正常。如果卡住不动多半是显存不够去看nvidia-smi或者journalctl -u ollama -f的日志。第二层走 OneAPI 的 OpenAI 兼容接口。假设 OneAPI 在内网 IP192.168.1.100令牌是sk-xxxxxxxxcurl http://192.168.1.100:3000/v1/chat/completions \ -H Authorization: Bearer sk-xxxxxxxx \ -H Content-Type: application/json \ -d { model: deepseek-r1:32b, messages: [{role: user, content: 写一个 Python 快速排序}], stream: false }返回结构里choices[0].message.content就是模型输出。这一步通了说明整条链路打通请求进 OneAPIOneAPI 转发给 OllamaOllama 推理后原路返回。Python 业务侧调用更简单用 openai 官方 SDK 改个 base_url 就行from openai import OpenAI client OpenAI( base_urlhttp://192.168.1.100:3000/v1, api_keysk-xxxxxxxx ) resp client.chat.completions.create( modeldeepseek-r1:32b, messages[{role: user, content: 帮我审查这段 SQL 有没有注入风险}] ) print(resp.choices[0].message.content)这样业务代码完全不用感知底层是 Ollama 还是别的未来要加模型只在 OneAPI 后台加渠道业务侧改个 model 名即可。连通性排查我整理了一个顺序先在服务器上curl 127.0.0.1:11434确认 Ollama 活着再curl 127.0.0.1:3000确认 OneAPI 活着然后从另一台内网机器curl 192.168.1.100:3000确认端口没被防火墙拦最后带上 Key 打完整请求。哪一步断问题就锁定在哪一层。5. 常见报错排查401、local proxy failed 与 reading choices内网搭这套东西报错基本集中在几个固定位置。我把踩过的坑按现象列出来对照着查能省不少时间。401 Unauthorized。这个最常见八成是 Key 的问题。先确认请求头里Authorization: Bearer sk-xxx格式对不对Bearer 后面有空格。再确认令牌在 OneAPI 后台是不是被禁用或额度耗尽。还有一种情况是令牌绑定的分组和渠道分组不匹配比如令牌是 default 分组渠道却建在 vip 分组请求就会 401。去「令牌」页面看分组设置和渠道保持一致。local proxy failed / dial tcp 127.0.0.1:11434 connection refused。这是 OneAPI 连不上 Ollama 的典型报错。原因就一个容器网络隔离。OneAPI 容器里的 127.0.0.1 不是宿主机。解决方式前面提过要么把 OneAPI 改成 host 网络要么用host.docker.internal并配extra_hosts。改完记得docker compose down docker compose up -d重建容器光 restart 不生效。reading choices: unexpected end of JSON input。这个报错说明 OneAPI 收到了 Ollama 的响应但解析失败。常见原因是 Ollama 返回了非标准格式或者模型名对不上。先确认渠道里填的模型名和ollama list输出完全一致大小写、冒号都不能差。再确认 Modelfile 导入时没改坏 TEMPLATE模板错了会导致输出结构异常。如果还不行去 OneAPI 日志里看原始响应docker compose logs -f one-api | grep -i choicesOAuth / 登录相关报错。如果你用的是 OneAPI 的 OAuth 登录比如接企业 SSO内网环境下回调地址配错会一直跳转失败。检查后台「系统设置」里的服务器地址必须填内网可访问的地址不能填 localhost。另外首次部署如果没改默认密码有些版本会强制要求改密按提示操作即可。模型加载超时或 OOM。这不是 OneAPI 的问题是 Ollama 侧显存不够。32B 模型量化后大概需要 20G 左右显存如果卡是 16G 就会加载失败。换 14B 或 7B 版本或者用ollama ps看当前加载状态。日志里出现CUDA out of memory就是显存爆了。排查这类问题有个通用心法先分层定位再逐层缩小。Ollama 层、网络层、OneAPI 层、业务层每层单独验证不要一上来就怀疑最上层。6. 从本地中台到统一接入长期编码场景的延伸内网中台搭好之后日常的模型调用就统一走 OneAPI 这一个入口了。但实际用起来你会发现团队里不同角色的需求差异挺大有人只是偶尔问问问题有人要长期跑 Agent 做代码审查还有人需要把模型接进 IDE 做补全。这时候光有一个内网网关还不够得考虑怎么把内网模型和外部能力做统一调度。我的做法是保留内网 OneAPI 作为主入口同时用 TaoToken 这类统一接入层来管理多来源的模型调用。它的价值在于把不同后端本地 Ollama、云端模型的 Key 和 Base URL 收敛成一套配置业务侧不用为每个来源写一套适配代码。对于需要长期跑编码任务的场景可以直接用 Coding Plan 把模型调用额度管起来避免某个 Agent 把额度跑爆。具体接入时Base URL 填https://taotoken.net/apiKey 在控制台的 API Keys 页面生成Model ID 按你实际要用的模型填。这三件套配好无论是 Cline、Codex 还是自己写的脚本都能用同一套凭证。如果你还在选模型阶段可以先去模型对话页面实测一下不同模型在代码任务上的表现再决定长期用哪个。需要说明的是内网中台和统一接入层不是替代关系。内网中台解决的是数据不出内网的合规底线统一接入层解决的是多模型调度和额度管理的效率问题。两者配合才能既守住安全又不牺牲开发体验。对于刚开始搭中台的团队建议先把 Ollama OneAPI 这条链路跑通验证模型效果和性能再考虑接入层的扩展。
阅读完成 · 觉得有帮助？
