企业官网建设流程全解析

简介：围绕多平台环境下 DeepSeek 模型的落地部署，这份 docx 文档面向希望把大模型能力接入个人设备或业务流程的开发者、研究人员与技术爱好者，重点解决不同硬件与系统下环境配置、模型拉取和交互入口不统一的问题。内容按平台组织：桌面端覆盖 macOS、Linux、Windows 上的 Ollama 本地部署与终端交互；移动端分别说明 iPhone 快捷指令和 Android Termux 的可行路径；Web 端则借助 Open WebUI 与 Docker 容器化环境完成模型集成与管理。全文强调步骤简明，并附有操作命令和官方网址，便于读者核对版本、查询最新资料和排查配置问题，也方便根据自身设备选择合适路线并理解模型运行机制。资源包共 1 个 docx 文件，大小约 15KB，轻量却涵盖多端部署思路；目前已有 3772 人学习，适合需要快速建立跨平台部署认知的中级读者参考。

1. 三台设备跑同一个 DeepSeek：先选部署路径，再谈模型大小

一台 16GB 内存的笔记本、一部旧安卓机、一台只开浏览器的办公电脑，想把同一个 DeepSeek 模型都用起来，最先卡住的往往不是模型本身，而是部署路径。多平台环境下 DeepSeek 模型部署可以拆成三条线：Ollama 本地跑通命令行与 HTTP 接口，移动端用快捷指令或 Termux 做轻量接入，Open WebUI 加 Docker 把浏览器变成控制台。三条线面向的人不一样：想快速验证效果的新手先走 Ollama，手上只有手机的人看移动端，要把模型接进团队流程或 NLP 应用的人再上 WebUI。后面按“先本地、再移动、后容器”的顺序拆，每一步都给可抄的命令和参数边界。

2. Ollama 本地部署：从安装到 11434 端口跑通 7B 模型

2.1 为什么先选 Ollama：模型分发、量化文件和本地 HTTP 服务

本地部署 DeepSeek 的第一道坎不是写代码，而是模型文件怎么来、运行时怎么管。Ollama 把这两件事收在一个命令行工具里：ollama pull负责按标签拉取模型，ollama run负责加载并进入交互，后台还会起一个默认监听11434的 HTTP 服务。对刚接触 AI 模型部署的人来说，这比手动找权重、配 Python 环境、处理依赖冲突要省事得多。它的边界也要提前说清：Ollama 不是推理加速框架，模型能不能跑、跑得多快，取决于参数量、量化方式和机器内存。7B、8B 这类尺寸在 16GB 内存的笔记本上通常能跑，但上下文一长、并发一多，响应就会明显变慢。把 Ollama 当成“本地模型的最小可用入口”更合适，先跑通，再谈调优。

选型上还有一个实际理由：Ollama 的接口是 HTTP，后面接 Open WebUI、接自己的 NLP 应用、甚至用手机快捷指令发请求，都能复用同一个地址。也就是说，第 2 章跑通的11434，是后面移动端和 WebUI 的共同底座。先把它跑通，后面排错时就能少一层变量。

2.2 macOS、Linux、Windows 的安装与模型拉取

安装方式按系统走，但检查动作一致：先确认命令存在，再拉模型。macOS 和 Linux 常见做法是从 Ollama 官方发布页获取安装包或安装脚本，Windows 则下载安装程序后打开 PowerShell。下面这段先做版本检查和服务启动检查，不涉及具体版本号，避免照着旧版本号硬套。

# macOS / Linux：确认命令可用 ollama --version # 如果桌面版没有自动拉起服务，手动启动 ollama serve # 另开一个终端，拉取并运行 7B 模型 ollama pull deepseek-r1:7b ollama run deepseek-r1:7b

ollama --version只验证可执行文件是否在 PATH 里；ollama serve是手动启动服务，桌面版通常已经常驻，重复启动会提示端口占用；ollama pull只下载不进入对话，适合先检查磁盘和网络；ollama run会加载模型并进入交互，第一次执行时如果本地没有对应标签，也会触发下载。模型标签里的7b是参数量级，不是文件体积，实际占用要看量化格式和模型卡说明。Windows 下把终端换成 PowerShell，命令主体不变：

# Windows PowerShell：检查并拉取模型 ollama --version ollama pull deepseek-r1:7b ollama run deepseek-r1:7b

这段的关键不是命令多，而是顺序：先确认ollama能执行，再确认服务在跑，最后才拉模型。很多人一上来就run，结果卡在下载或端口冲突上，误以为是模型坏了。另一个常见动作是拉完模型后忘了看本地列表，后面 WebUI 里选不到模型就开始怀疑容器。用ollama list看一眼标签，能省很多排查时间。

# 查看本地已下载模型，确认标签和大小 ollama list # 查看服务是否在 11434 监听 curl http://localhost:11434

ollama list输出的是本地模型标签，后面在 Open WebUI 或 API 请求里填的model字段必须和这里一致；curl http://localhost:11434返回一句话说明服务在响应，如果这里就拒绝连接，后面的手机端和容器都不用继续试。这个检查动作很土，但它是后面所有跨端问题的分界线。

2.3 模型标签、内存和量化：7B 与 8B 怎么选

模型标签不是越大越好。7B 和 8B 在普通笔记本上的差别，往往体现在内存占用和首 token 延迟上，而不是“回答质量立刻上一个台阶”。如果机器只有 8GB 内存，还要开浏览器和 IDE，7B 的量化版本更现实；16GB 内存可以尝试 8B，但要把上下文长度控制住。下面这张表是经验区间，不是硬指标，实际以模型卡和ollama list显示的体积为准。

参数怎么设：先不要急着改温度、top_p 这些采样参数，先把num_ctx控制住。Ollama 的请求里可以带options，上下文越长，占用越高。做本地验证时，把上下文压到 2048 或 4096，确认能跑通，再往上加。这个顺序比一上来追求长上下文更稳，也更不容易把机器拖死。

2.4 用 API 验证：不要只会在终端里聊天

终端交互只能证明模型能说话，不能证明它能被应用调用。把 DeepSeek 接进自己的 NLP 应用之前，先用curl打一次/api/generate，看返回结构。下面这段请求把stream设为false，方便一次性看到完整 JSON。

# 调用本地 Ollama 的生成接口 curl http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "用三句话解释本地模型服务和应用调用之间的关系", "stream": false, "options": { "num_ctx": 4096 } }'

model必须和ollama list里的标签一致；prompt是输入；stream: false表示等完整结果返回，调试时比流式输出好读；options.num_ctx控制上下文窗口，先给 4096，跑不通再降。返回 JSON 里的response字段就是模型输出，done表示本次生成结束。如果返回 404，先查模型标签；如果连接被拒绝，先查ollama serve；如果返回很慢，先看内存和上下文，不要先怀疑模型。

再补一个/api/chat的调用，后面手机端和 WebUI 都更常用这种消息数组结构：

# 用 chat 接口模拟多轮消息 curl http://localhost:11434/api/chat -d '{ "model": "deepseek-r1:7b", "messages": [ {"role": "system", "content": "你是一个部署助手，回答尽量短。"}, {"role": "user", "content": "Ollama 默认端口是多少？"} ], "stream": false }'

messages里role可以是system、user、assistant，这比单段prompt更适合接聊天界面；system用来约束回答风格，不要写太长，否则会挤占上下文。这个接口跑通之后，iPhone 快捷指令、Android Termux 里的本地调用、Open WebUI 的连接配置，都是同一套地址和模型标签的变体。

3. 移动端两条路线：iPhone 快捷指令调 API 与 Android Termux 编译 Ollama

3.1 iPhone 快捷指令路线：手机不跑模型，只做请求端

iPhone 的算力不适合直接扛 7B 模型，常见做法是把手机当请求端：快捷指令发 HTTP 请求到一台已经跑起 Ollama 的电脑或内网服务，手机只负责输入和展示。这条路线适合临时演示、外出时查资料，不适合把大模型塞进手机本地。配置分三步：新建快捷指令，加入“获取 URL 内容”动作，方法选 POST，请求体用 JSON；然后把请求地址改成电脑的局域网地址，例如http://192.168.1.20:11434/api/chat。如果中间加了鉴权网关，再补一个Authorization头。先在电脑上把下面这段curl跑通，再去手机上填，能排除大半问题。

# 在电脑上验证局域网地址是否可被手机访问 curl http://192.168.1.20:11434/api/chat \ -H "Content-Type: application/json" \ -d '{ "model": "deepseek-r1:7b", "messages": [ {"role": "user", "content": "把这段需求拆成三个步骤：整理会议纪要"} ], "stream": false }'

这里的192.168.1.20只是示例，要换成运行 Ollama 那台机器的局域网 IP；Content-Type: application/json不能少，否则服务端可能不解析请求体；messages的结构和上一节一致。如果服务端加了网关鉴权，再加-H "Authorization: Bearer <你的密钥>"，但不要把密钥写进公开分享的快捷指令里。iPhone 第一次运行时可能弹出本地网络权限，拒绝后请求会直接失败，表现像“地址填错了”，实际是权限没给。

快捷指令里的 JSON 可以这样组织，字段名不要改错：

{ "model": "deepseek-r1:7b", "messages": [ { "role": "user", "content": "用一句话说明当前模型的部署位置" } ], "stream": false }

model仍然要和电脑上的ollama list对齐；stream: false让快捷指令一次拿到完整文本，处理起来简单；messages里只放一条用户消息也能跑。想做成多轮，就在快捷指令里维护一个消息数组，把上一轮 assistant 的内容追加进去。这里最容易翻车的是把 API Key 写死在快捷指令的文本里，然后分享出去；更稳妥的做法是把 Key 放在服务端网关做校验，手机端只带短期凭证，或者只在内网使用。

3.2 Android Termux 路线：在手机上编译一个 Ollama

Android 上想本地跑，Termux 是常见入口。思路是装依赖、克隆 Ollama 仓库、编译、启动服务、拉模型。这条路能走通，但对手机内存和散热要求高，8B 模型不是每台机器都能扛。先装 Termux，打开后更新包索引并装编译依赖。安装包要从 Termux 官方发布渠道获取，不要用来路不明的 APK，否则后面缺库很难排查。

# Termux 内更新并安装编译依赖 pkg update && pkg upgrade -y pkg install git cmake golang libjpeg-turbo -y # 给 Termux 存储权限，便于后面放模型和日志 termux-setup-storage

pkg update和pkg upgrade先把包索引和已装包对齐；git用来克隆仓库，cmake和golang是编译依赖，libjpeg-turbo处理图像相关依赖；termux-setup-storage会弹系统权限，允许后 Termux 才能访问共享存储。依赖装不齐时，go build往往报链接错误，而不是直接说缺哪个包，所以这一步不要跳。

接着克隆并编译。--depth 1只取最近一次提交，减少下载量；go generate ./...生成编译需要的资源；go build .在当前目录产出可执行文件。编译阶段最容易遇到内存不足，手机会直接杀进程。

# 克隆 Ollama 仓库并编译 git clone --depth 1 https://github.com/ollama/ollama.git cd ollama go generate ./... go build .

如果go build被系统杀掉，先把并行度降下来，再重试：

# 降低编译并发，减少内存峰值 GOMAXPROCS=2 GOFLAGS=-p=1 go build .

GOMAXPROCS=2限制运行时使用的 CPU 核心数，GOFLAGS=-p=1让构建一次只处理一个包，代价是编译更慢，但比直接失败好。编译成功后启动服务并验证端口：

# 启动本地服务并检查 11434 ./ollama serve & curl http://localhost:11434 # 拉取并运行模型 ./ollama pull deepseek-r1:8b ./ollama run deepseek-r1:8b

&把服务放到后台，curl返回版本信息说明服务在跑；pull和run的模型标签要按实际仓库里的写法来，原文里出现过deepseekr1:8b这种连写形式，实际执行时以ollama list和拉取结果为准，标签对不上就会报找不到模型。手机端跑 8B 的边界很明确：内存不够会频繁换出，发热后降频，长时间对话体验会明显下降。如果只是想在手机上用 DeepSeek，优先考虑 3.1 的请求端路线；Termux 编译更适合做本地验证和离线演示。

3.3 移动端两条路线的选择边界

iPhone 快捷指令路线和 Android Termux 路线不是替代关系。前者把计算放在电脑或内网服务上，手机只负责交互，适合“我只有手机，但身边有电脑”的场景；后者把模型放在手机本地，适合断网演示、临时验证，但受内存和散热限制。移动端开发（Mobile Development）里接 AI 模型，常见做法也是把重计算放服务端，客户端只做请求和缓存，这样版本更新、模型切换、鉴权都更容易统一管理。把这条边界想清楚，后面就不会在手机上反复重装依赖。

4. Open WebUI 加 Docker：把浏览器变成模型控制台

4.1 为什么用 Open WebUI：多会话、模型切换和团队共用

Ollama 的终端交互适合验证，不适合多人共用。Open WebUI 的价值在于把模型包装成浏览器界面：多会话、模型切换、提示词管理、用户体系都能在一个页面里完成。用 Docker 跑 Open WebUI 的好处是依赖隔离，不用在本机装一堆 Python 包；坏处是网络配置多一层，容器里的localhost和宿主机的localhost不是一回事。这一章的重点不是“装一个界面”，而是把容器到 Ollama 的链路打通。

选型上，Docker Desktop 适合 macOS 和 Windows，Linux 上直接用 Docker Engine 也行。Open WebUI 的容器默认监听容器内的8080，映射到宿主机的3000是常见做法。模型仍然由 Ollama 提供，WebUI 只负责界面和会话管理，所以第 2 章的11434必须先跑通。

4.2 启动 Open WebUI 容器：端口、卷和宿主机网络

先确认 Docker 可用，再启动容器。下面这条命令把宿主机的3000映射到容器8080，把/app/backend/data挂到命名卷，容器重启后会话和配置不会丢；--add-host=host.docker.internal:host-gateway让 Linux 容器也能用host.docker.internal访问宿主机。

# 检查 Docker docker --version # 启动 Open WebUI docker run -d \ -p 3000:8080 \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ --add-host=host.docker.internal:host-gateway \ ghcr.io/open-webui/open-webui:main

-p 3000:8080左边是浏览器访问端口，右边是容器内端口，改左边可以避开本机已占用端口；-v open-webui:/app/backend/data是持久化卷，删容器不删数据；--restart always让容器随 Docker 启动；--add-host在 Linux 上补宿主机名解析。macOS 和 Windows 的 Docker Desktop 通常自带host.docker.internal，加上也不冲突。启动后看日志，确认没有反复重启：

# 查看容器日志，确认服务已启动 docker logs -f open-webui

日志里出现监听端口的提示后，浏览器打开http://localhost:3000。如果页面打不开，先看容器是否在运行，再看端口是否被占用，不要直接去改 WebUI 配置。

4.3 让 WebUI 连上 Ollama：地址填错是最常见的翻车点

容器里的localhost指向容器自己，不是宿主机。WebUI 设置里的 Ollama 地址要填http://host.docker.internal:11434，或者填宿主机的局域网 IP。前提是 Ollama 不能只监听127.0.0.1，否则容器过不来。Linux 上可以用环境变量让 Ollama 监听所有网卡：

# 让 Ollama 接受来自容器的请求 OLLAMA_HOST=0.0.0.0 ollama serve

OLLAMA_HOST=0.0.0.0表示监听所有网卡，只建议在内网使用，并且用防火墙限制来源；如果机器直接暴露在公网，不要这么开。启动后在容器里验证能不能访问宿主机：

# 进入 WebUI 容器，测试到 Ollama 的连通性 docker exec -it open-webui sh -c "curl http://host.docker.internal:11434"

返回版本信息说明链路通了；如果拒绝连接，回到宿主机看curl http://localhost:11434是否正常，再看OLLAMA_HOST和防火墙。WebUI 里在设置页填好地址后，模型列表应该能读到ollama list里的标签；读不到就先在 WebUI 里手动拉取，或者用命令行ollama pull拉完再刷新。下面这张表把几个参数的作用列清楚，改配置时对着看。

4.4 在 WebUI 里完成一次最小验证

配置完成后不要只看首页，做一次最小验证：新建对话，选deepseek-r1:7b，发一句短问题，确认能返回；再刷新页面，确认会话还在，说明卷挂载生效；最后重启容器，再发一句，确认模型地址没有丢。这个三步验证能覆盖端口、模型标签、持久化三个最容易出问题的点。团队共用时，再考虑在 WebUI 里开用户和权限，不要把所有东西都堆在默认管理员账号上。

5. 跨端部署避坑排查：五个高频翻车点与定位命令

5.1 模型标签对不上：model not found不一定是模型没下载

现象：ollama run deepseek-r1:7b报找不到模型，或者 WebUI 里模型列表是空的。原因通常不是下载失败，而是标签写错：deepseek-r1和deepseekr1不是同一个标签，7b和8b也不能混用；有的模型库标签带版本后缀，复制时漏掉一段就会 404。解决顺序是先看本地列表，再看拉取返回。

# 先确认本地到底有什么 ollama list # 再按实际标签拉取，不要凭记忆拼 ollama pull deepseek-r1:7b

ollama list的 NAME 列就是后面所有配置要填的值；ollama pull的返回如果明确说找不到标签，就去模型库页面核对，不要反复重装 Ollama。WebUI 里选不到模型时，先在宿主机用ollama list确认，再检查 WebUI 的 Ollama 地址是否指到了另一个实例。这个坑很常见，尤其是跟着旧命令复制的时候。

5.2 11434 拒绝连接：服务没起、只监听本机、还是防火墙拦了

现象：curl http://localhost:11434直接拒绝连接，或者手机、容器访问不到。原因分三层：Ollama 没启动；启动了但只监听127.0.0.1；监听正确但防火墙没放行。先在宿主机上分层查：

# 看端口有没有在监听 ss -lntp | grep 11434 # 本机自测 curl http://localhost:11434 # 用局域网 IP 自测，确认是否只监听本机 curl http://192.168.1.20:11434

ss能看到监听地址，如果是127.0.0.1:11434，手机和容器都过不来；localhost通、局域网 IP 不通，说明监听范围不够；两个都不通，先回到ollama serve看前台报错。需要跨设备访问时用OLLAMA_HOST=0.0.0.0 ollama serve，同时用防火墙限制来源。这个排查顺序比反复重启有效。

5.3 Termux 编译被杀：内存峰值和依赖缺失要分开处理

现象：go build .跑到一半进程消失，或者报链接错误。原因一是手机内存不够，编译并行度太高；二是依赖没装全，尤其是图像相关库；三是 Termux 包版本太旧。先降并发，再补依赖，不要一上来换手机。

# 降低编译并发，减少内存峰值 GOMAXPROCS=2 GOFLAGS=-p=1 go build . # 依赖缺失时补装后再试 pkg install git cmake golang libjpeg-turbo -y

GOMAXPROCS和GOFLAGS=-p=1是编译期的资源限制，不是模型运行参数；补依赖后要重新执行go generate ./...再编译。如果仍然失败，先确认手机剩余存储和内存，再考虑改用请求端路线。手机本地编译适合验证，不适合硬扛大模型长期跑。

5.4 Docker 里连不上 Ollama：容器内的 localhost 不是宿主机

现象：浏览器能打开 Open WebUI，但模型列表为空，日志里出现连接失败。原因通常是 Ollama 地址填了http://localhost:11434，容器跑到自己内部去了；或者宿主机 Ollama 只监听127.0.0.1；Linux 上还可能是缺少host-gateway解析。解决分两步：让 Ollama 监听网卡，让容器能解析宿主机。

# 宿主机：让 Ollama 接受容器请求 OLLAMA_HOST=0.0.0.0 ollama serve # 容器内：验证到宿主机的链路 docker exec -it open-webui sh -c "curl http://host.docker.internal:11434"

如果容器内curl不通，先看启动命令有没有--add-host=host.docker.internal:host-gateway，再看宿主机防火墙。地址填host.docker.internal比填局域网 IP 更不容易随网络变化失效，但在 Linux 上要确认解析生效。这个坑的典型表现是“页面正常、模型全空”，不要被前端误导。

5.5 手机端 401 或权限失败：密钥、请求体和本地网络权限

现象：iPhone 快捷指令返回 401、403，或者一直提示网络错误。原因可能是 Key 没带、带错位置、请求体字段写错，或者 iOS 本地网络权限被拒绝。排查时先在电脑上用同一条curl打通，再把地址和请求体搬到手机；Key 不要写死在分享版快捷指令里，能放服务端校验就放服务端。请求体里model、messages、stream三个字段最常错，尤其是把messages写成字符串。手机端只做请求时，优先走内网地址，不要把 Ollama 直接暴露到公网；需要远程访问时，在网关层做鉴权和访问控制，别把 11434 裸奔出去。

6. 进阶调优与验证：量化、上下文和并发怎么设

6.1 先定上下文，再谈并发

本地跑 DeepSeek，调参顺序建议是：先定模型尺寸，再定上下文，最后才碰并发。上下文从 2048 或 4096 起步，确认机器能扛，再往上加；并发不要一上来开多路，Ollama 在单机上更容易被内存拖慢。下面这张表可以作为起步参数，不是绝对标准。

上下文越长，KV 缓存占用越高；并发越高，内存峰值越明显。机器开始频繁卡顿的时候，先降上下文，再降并发，不要先换模型。

6.2 用固定请求做回归验证

每次改完端口、模型标签或容器配置，用同一条固定请求做回归，比手动聊天更容易发现链路问题。下面这段把请求跑三次，记录耗时和返回是否包含response字段，适合在改配置后快速验证。

# 固定请求回归：改完配置后跑三次 for i in 1 2 3; do echo "--- run $i ---" time curl -s http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "只回答：部署链路正常", "stream": false, "options": {"num_ctx": 2048} }' | grep -o '"response":"[^"]*"' done

time看总耗时，grep只抓返回里的response字段，避免被大段 JSON 干扰；三次结果差异很大时，先看机器是不是在跑别的重任务，再看模型是否被反复加载。这个习惯看着笨，但排错时比“再聊一句试试”可靠得多。

从那以后我每次改完 Ollama 地址或 Docker 端口，都强制走一遍“ollama list、curl 11434、容器内curl、手机同网段请求”这四步，不跳步。多平台部署最容易翻车的不是模型，而是地址和标签在不同设备上各说各话。如果你准备把这套方案落地，先把 Ollama、Docker 和 Open WebUI 的安装包归到一个目录，再按第 2 到第 4 章的顺序跑通，命令和参数表可以直接对照资源清单改。希望帮到你。

本文还有配套的精品资源，点击获取