企业官网建设流程全解析

简介：面向AI开发者与技术爱好者的DeepSeek模型多平台部署实操指南，聚焦从本地到移动端再到Web端的完整落地路径。内容以Ollama为核心，覆盖macOS、Linux、Windows下环境安装、模型拉取与终端交互；针对手机用户给出iPhone快捷指令调用与Android Termux编译运行的特定方案，同时讲解借助Open WebUI与Docker容器化实现浏览器访问的集成部署。资源为单个docx文档，压缩包大小约15KB，结构紧凑，适合快速查阅。目前已有3766人学习浏览。文档中提供了明确的命令行操作、官方下载链接、环境配置与验证步骤，读者可对照完成DeepSeek-R1系列模型的部署与对话测试，减少踩坑成本；同时也能理解多设备协同使用大模型的基本思路，适合将AI能力快速融入个人设备或业务实验环境。

1. 多平台部署 DeepSeek 没有唯一路径，但 Ollama 是最好的起点

如果你手上已经有一份 DeepSeek 的模型权重，或者只是想在笔记本上跑通一次对话，最快的方式不是去读 Hugging Face 上的推理脚本，而是先装一个 Ollama。它把模型下载、量化、显存调度和 OpenAI 兼容 API 全部收敛进一个本地守护进程，之后无论接手机 App 还是 Open WebUI，本质上都是往这个进程上挂客户端。本篇就按「本地 Ollama → API 暴露 → 移动端接入 → WebUI 容器化」的顺序推进，覆盖从零部署到联调排错的完整链路。适合正在选型本地大模型方案的后端工程师，也适合想在局域网里给团队搭一个私有对话服务的运维同学。读完你应该能回答三个问题：模型下不动怎么办，手机怎么连上局域网里的 DeepSeek，以及 Open WebUI 和 Ollama 之间到底怎么建立关联。

2. Ollama 安装与 DeepSeek 模型拉取，先解决下载慢的问题

2.1 安装 Ollama 的三种方式与国内镜像加速

Linux 服务器上最常见的做法是执行官方安装脚本，它会自动识别 CUDA、ROCm 或纯 CPU 环境并安装对应运行时。macOS 和 Windows 直接下载安装包即可，Windows 版安装后会常驻后台，并默认暴露127.0.0.1:11434。安装完成后先确认守护进程状态：

curl -fsSL https://ollama.com/install.sh | sh systemctl status ollama ollama --version

第一条命令通过管道把远端脚本交给 sh 执行，装完后 systemd 会自动拉起ollama serve。ollama --version用来确认 CLI 与守护进程版本一致。如果服务器在国内且拉取脚本超时，可以改用离线安装包，或者直接到镜像站下载对应架构的二进制文件解压到/usr/local/bin。

下载模型慢是本地部署里最常被卡住的一步。Ollama 默认从registry.ollama.ai拉取模型层，国内网络下经常只有几十 KB/s。常见的绕行方案是设置镜像环境变量后重启服务：

export OLLAMA_HOST=0.0.0.0 export OLLAMA_MODELS=/data/ollama/models export OLLAMA_NUM_PARALLEL=4

OLLAMA_HOST设为0.0.0.0是让局域网内其他设备能访问 API，默认只监听回环地址。OLLAMA_MODELS把模型存储目录从系统盘迁到大容量数据盘，避免~/.ollama/models塞满根分区。OLLAMA_NUM_PARALLEL控制并发请求数，显存充足时可适当调大。如果下载仍然不稳定，还有一个可靠兜底：从 ModelScope 下载 GGUF 格式权重，再用本地 Modelfile 导入 Ollama。

2.2 用 ModelScope 下载 GGUF 后导入 Ollama

ModelScope 上有社区维护好的 DeepSeek 量化版本，下载速度远快于官方 registry。先安装modelscopePython SDK，然后指定模型仓库和缓存目录拉取文件：

pip install modelscope modelscope download --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B-GGUF --local_dir /data/models/deepseek

参数说明：--model指定仓库 ID，--local_dir决定文件落盘位置。下载完成后写一份Modelfile指向 GGUF 文件并声明对话模板：

FROM /data/models/deepseek/deepseek-r1-distill-qwen-7b-q4_k_m.gguf TEMPLATE """{{- if .System }}system: {{ .System }}{{ end }} user: {{ .Prompt }} assistant: """ PARAMETER temperature 0.7 PARAMETER top_p 0.9 PARAMETER stop "<|im_end|>"

在 Modelfile 所在目录执行ollama create deepseek-r1:7b-q4 -f Modelfile，Ollama 会读取 GGUF 头信息生成模型，版本名自定义为7b-q4。之后ollama run deepseek-r1:7b-q4就能正常对话。这个导入流程的意义在于：它把模型获取与模型运行解耦，凡是能拿到 GGUF 的渠道都能变成 OLLAMA_MODELS 的合法来源，不需要动 Ollama 本身的 registry 配置。

2.3 显存选型：不同量化级别怎么选

本机资源不同，能跑的模型大小完全不同。DeepSeek 系列蒸馏模型在 Ollama 里有多个 tag，选择依据只有一个：你的 GPU 显存和内存带宽。下面这张表按经验值列出常见规格，量化等级统一为 Q4_K_M：

有独立显卡但显存不足时，Ollama 会把部分层 offload 到 CPU，但性能会断崖式下降。纯 CPU 环境跑 7B 模型速度约 5 token/s，只适合验证流程。Q8 量化比 Q4 更接近原模型效果，但显存占用几乎翻倍。移动端接入场景下，建议直接使用 Q4 量化版本，因为最终瓶颈在局域网传输和手机内存。

3. Open AI 兼容 API 与模型管理，移动端和 WebUI 都靠它

3.1 Ollama 的 API 端点与请求结构

Ollama 的值钱之处在于它内置了 OpenAI 兼容接口，监听在11434端口。移动端 App、Open WebUI、甚至codex这类开发工具，都只需要配置一个base_url就能接入，不需要各自实现一套模型加载逻辑。先看最常用的两个端点。

对话补全端点POST /api/chat：

curl http://localhost:11434/api/chat -d '{ "model": "deepseek-r1:7b-q4", "messages": [ {"role": "user", "content": "用 SWIG 包装一个 C++ 类"} ], "stream": false }'

返回 JSON 里的message.content就是最终回答。stream: false表示完整结果一次返回，适合脚本调用；移动端交互场景建议设true走 SSE 流式输出，用户等待时间会变短。生成参数端点POST /api/generate则更接近纯文本补全，适合做单轮提示词模板实验。

OpenAI 兼容端点位于v1/chat/completions，base_url写作http://<host>:11434/v1。这也是 codex 等工具接入 Ollama 的入口，配置model_provider指向本地地址即可。它的 body 结构和 OpenAI 保持一致，Ollama 会负责把temperature、top_p等参数映射到内部采样器。

3.2 模型生命周期：拉取、热切换与内存释放

运行时经常需要同时管理多个模型，比如deepseek-r1:7b负责对话，nomic-embed-text负责 WebUI 里的向量检索。Ollama 默认把最近使用的模型保持在显存中，长时间不调用会按 LRU 策略自动卸载。手动干预用三条命令：

ollama pull deepseek-r1:7b ollama rm deepseek-r1:7b-old ollama show deepseek-r1:7b --modelfile

pull是增量下载，已存在且 hash 一致的层会跳过；rm同时删除对应的层文件，释放磁盘；show能查看模型架构、参数量、嵌入长度和量化信息，排查奇偶层问题时会用。若多个模型并发占用导致显存溢出，可以在请求体里加"keep_alive": "5m"，让模型在 5 分钟无请求后主动退出显存。

3.3 与 codex / OpenAI SDK 对接的参数联调

向量化地讲，Ollama 暴露的 OpenAI 兼容层没有完全实现 OpenAI 的全部字段，但核心的messages、temperature、max_tokens、stream都已覆盖。用 Python 的openaiSDK 对接时，只需要替换base_url和api_key：

from openai import OpenAI client = OpenAI(base_url="http://192.168.1.20:11434/v1", api_key="ollama") resp = client.chat.completions.create( model="deepseek-r1:7b-q4", messages=[{"role": "user", "content": "解释一下 num_ctx 的作用"}], max_tokens=512, temperature=0.6 ) print(resp.choices[0].message.content)

不要怀疑api_key为什么写ollama，这个字段在本地模式下会被忽略，但 SDK 要求非空。num_ctx是 Ollama 特有参数，控制上下文窗口长度，默认 2048，调高到 8192 会显著增加显存占用。temperature在代码生成任务里建议设低（0.2～0.4），对话任务设 0.7 左右平衡创造性。

4. 移动端接入：局域网暴露、App 选型与性能优化

4.1 通过局域网 API 让手机访问本地 DeepSeek

移动端要连的是 Ollama 的 API 端口，而不是 SSH 或文件共享。先确保服务端绑定了非回环地址，然后从手机侧用浏览器或 curl 验证连通性：

# 服务端查看监听地址 ss -tlnp | grep 11434 # 手机端或者局域网另一台机器验证 curl http://192.168.1.20:11434/api/tags

/api/tags返回当前已下载的模型列表，连得通就说明网络层没有隔离问题。注意OLLAMA_HOST改完后必须重启 Ollama 进程，systemd 模式下执行systemctl restart ollama。手机和服务器最好在同一广播域，如果跨 VLAN 要放行 TCP 11434 端口。不建议直接把端口映射到公网，因为 API 默认无鉴权，任何人都能调用你的算力。

4.2 移动端常用的三套客户端方案

移动端大体有三类接入方式，各适合不同需求：

• 原生 App 类（如 Maid、Enchanted）：内置 Ollama 连接配置，填入http://<局域网IP>:11434即可，适合快速体验。
• 通用 AI 对话 App（如 Chatbox 移动版）：在设置里选择自定义 API 类型，填 base_url 与模型名，适合同时接多家服务。
• 自研 H5 / React Native 应用：通过 WebSocket 或 fetch 调用 OpenAI 兼容端点，适合集成进业务系统。

自研场景下有个浏览器兼容问题：手机上非 HTTPS 页面访问局域网 HTTP 接口会被混合内容拦截。开发环境可以用 iOS 的 ATS 例外或 Android 的usesCleartextTraffic放行，但正式环境建议用 PWA 或原生壳包装。其次是 CORS 问题，Ollama 默认允许跨域，但生产环境建议在前面加一层 Nginx 反向代理，统一处理 CORS、限流和 HTTPS 证书。

4.3 React Native 与 H5 调用的最小请求示例

下面是一个基于 fetch 的最小对话实现，兼容 React Native 和浏览器 H5：

async function chat(question) { const resp = await fetch("http://192.168.1.20:11434/v1/chat/completions", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ model: "deepseek-r1:7b-q4", messages: [{ role: "user", content: question }], max_tokens: 256, stream: false }) }); const data = await resp.json(); return data.choices[0].message.content; }

代码里有两个关键点：一是模型名必须与服务器上的ollama list结果完全一致，否则返回 404；二是stream: false在弱网环境下体验较差，建议改成 SSE 流式并解析data:前缀事件。React Native 如果遇到网络请求失败，优先检查 Android 的网络安全配置和 iOS 的本地网络权限，这两个是移动端连局域网服务最典型的坑。

移动端性能优化的核心不在端上，而在服务端。手机渲染一个 token 一次网络往返，7B 模型在 1050Ti 级别的 GPU 上生成速度可能只有 20 token/s，体验会比较拖沓。换个思路：用 1.5B 模型做摘要或意图提取，再用 7B 模型做精细回答，把耗时的推理放在 Wi-Fi 环境，移动端只负责展示。

5. Open WebUI 部署：Docker 容器化与 Ollama 关联配置

5.1 用 Docker 拉起 Open WebUI 并连接已有 Ollama

Open WebUI 是目前 Ollama 生态里最流行的自托管对话界面，提供用户注册、多会话管理、Markdown 渲染、RAG 等功能。官方镜像托管在ghcr.io，用 Docker 部署时建议用 named volume 持久化数据。先看最小可用配置：

docker run -d --name open-webui \ -p 3000:8080 \ -v open-webui:/app/backend/data \ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \ -e WEBUI_AUTH=False \ --restart always \ ghcr.io/open-webui/open-webui:main

参数拆开讲：-p 3000:8080把宿主机 3000 端口映射到容器内 8080；-v open-webui:/app/backend/data用 Docker volume 存 SQLite 数据库和上传文件，重启容器不丢；OLLAMA_BASE_URL是连接 Ollama 的关键，Docker Desktop 环境下用host.docker.internal指代宿主机，Linux 原生 Docker 需要改成--network=host或用宿主机 IP。WEBUI_AUTH=False表示跳过登录页，适合内网家庭环境；若多人使用，删掉这个环境变量即可开启邮箱注册和密码登录。

启动后用宿主机浏览器访问http://localhost:3000，首次进入会看到模型选择下拉框，里面应该已经出现 Ollama 里的模型列表。如果列表为空，先检查OLLAMA_BASE_URL能否在容器内访问：

docker exec -it open-webui curl http://host.docker.internal:11434/api/tags

5.2 模型管理与 RAG 知识库的依赖关系

Open WebUI 浏览 Ollama 模型，走的是它内置的模型发现逻辑。它不仅能把 Ollama 现有模型展示出来，还能在界面上直接拉取新模型，相当于调用了 Ollama 的/api/pull接口。管理员面板里可以设置模型权限：哪些模型对普通用户可见，哪些作为管理员专属。

开启 RAG 对话时，Open WebUI 需要两个额外组件：一个嵌入模型和一个向量数据库。嵌入模型默认从 Ollama 拉取nomic-embed-text或bge-m3；向量数据库在 Docker 单机模式下自动切换到内置的 Chroma，不需要额外部署。若数据量大或者要跨容器共享，才考虑接 Qdrant。Windows 用户常见的问题是docker run卡在 pulling layers，这通常与镜像 ghcr.io 拉取速度有关，可通过配置镜像加速器或设置 Docker 代理环境变量解决。

5.3 用户权限与多模型隔离的落地配置

当多人共用一台 GPU 服务器时，推荐开启用户注册，并关掉匿名访问。在容器启动参数中不设置WEBUI_AUTH，首次访问会让你创建管理员账户。之后每个用户都能创建自己的会话，但模型仍由所有物理设备共享。如果你希望 A 组只能用 7B 模型、B 组只能用 32B，就需要在 Open WebUI 的管理后台里建立分组并限制可访问模型。这个功能本质上是让 Open WebUI 在生成请求时做模型名白名单校验，而不是真正的显存隔离，因此不能让用户独自占用模型资源。

6. 把 Ollama 注册成系统服务并用 curl 验证全链路

模型和界面都部署好后，最后一步是把 Ollama 的启动从手动ollama serve变成开机自启，并用一次完整的 HTTP 请求验证「手机/浏览器 → Open WebUI → Ollama → 模型」的链路是否通畅。Linux 上安装脚本已经注册好 systemd，但手动编译安装的需要自己写 unit 文件：

[Unit] Description=Ollama Service After=network-online.target [Service] Environment="OLLAMA_HOST=0.0.0.0" Environment="OLLAMA_MODELS=/data/ollama/models" ExecStart=/usr/local/bin/ollama serve Restart=always RestartSec=3 [Install] WantedBy=multi-user.target

把文件放到/etc/systemd/system/ollama.service，然后执行systemctl daemon-reload && systemctl enable --now ollama。注意ExecStart的二进制路径要和which ollama一致，OLLAMA_MODELS路径要提前建好并且给运行用户写权限。配置完成后用curl -i检查响应头，确认 WebUI 能正常转发请求：

curl -s http://localhost:3000/api/health

返回true表示 Open WebUI 本身健康。接着访问http://localhost:3000/api/models，看模型列表是否完整。即便走的是 GUI，这两条 curl 也能在排查问题时分清是界面层还是模型服务层出错。部署完成后有一个实测技巧：在 WebUI 里新建聊天，反复发送同样的问题，同时用ollama ps观察模型是否常驻在显存中——如果频繁加载，说明keep_alive设得太短，建议在环境变量中设置OLLAMA_KEEP_ALIVE=30m拉长热驻留时间，减少首次回答延迟。

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