企业官网建设流程全解析

简介：多平台环境下DeepSeek模型的部署指南，面向希望在个人设备或业务流程中落地大模型的开发者、研究者与技术爱好者。内容系统讲解三条部署路径：基于Ollama的本地部署方案，覆盖macOS、Linux、Windows从安装环境到使用ollama run deepseek-r1:7b拉取模型并进入终端交互；移动端部署分别通过iPhone快捷指令配置API Key和Android Termux编译运行Ollama实现；Web端部署则借助Docker Desktop与Open WebUI完成容器化集成，方便以浏览器访问和管理模型。资源为单个docx文档，大小约15KB，内容精炼，命令明确，并附带官方链接、环境准备与运行验证提示；所有步骤均保持简单明了，便于初学者按图索骥。读者可参照指南快速将DeepSeek部署到不同设备，提升NLP服务能力，同时加深对模型运行机制的理解。已有3769人学习/下载，适合对私有化AI模型部署感兴趣的中高级技术人员。

1. 为什么都在折腾DeepSeek模型部署：一条命令到全平台覆盖

DeepSeek模型部署最近成了开发者工具链里的高频词。很多人以为跑大模型只能买云服务，实际上本地部署才是把模型真正握在手里的方式。这篇文章覆盖三条主流路径：用Ollama在桌面终端本地跑、在iPhone和Android上通过快捷指令或Termux实现移动端部署、再用Open WebUI配合Docker把模型封装成浏览器可访问的Web服务。适合三类人：想离线用模型的研究人员、要把AI聊天能力集成进业务流程的开发者、以及单纯想在自己设备上跑通大模型的爱好者。下面直接进入可复现的操作步骤。

2. 基于Ollama的本地部署：从安装到交互对话的完整链路

2.1 为什么选Ollama：本地部署的选型理由

Ollama是目前把“下载模型、跑起来、对外提供接口”压到最简的工具。它不是一个训练框架，而是推理部署工具，内部封装了llama.cpp及对应量化实现，默认用4bit量化加载模型，让消费级硬件也能跑7B甚至8B参数量的模型。我用它替换掉以前那套“Python环境加CUDA依赖再手工下载权重”的流程，三个词总结就是：零依赖、跨平台、标准化。

常见的本地部署选型还有llama.cpp原生编译、Hugging Face transformers以及vLLM。llama.cpp需要自己处理模型转换和编译参数，适合有定制需求的人；transformers更偏研究和微调，部署时要自己写服务封装；vLLM在高并发场景有优势，但对显存和CUDA版本的要求更苛刻。如果只是想在个人电脑上稳定跑一个模型，我一般会选Ollama，因为它把推理服务暴露成了REST API，后面无论接终端、脚本还是WebUI都很顺手。

下面用一张表把四个方案的边界说清楚，方便你判断Ollama是不是合适的那一个：

2.2 安装Ollama：macOS/Linux/Windows三平台差异

三个平台的安装方式各有入口，但核心都是把ollama二进制放进系统PATH。macOS端直接下载安装包然后拖进Applications，Windows端走exe安装器，这两个图形界面安装器都会自动处理PATH。Linux下通常是包管理或脚本方式，我用过curl脚本，也用过发行版仓库里的版本，二者差异不大，但仓库版可能滞后。

安装完成后，第一件事是验证命令是否存在：

# 验证安装结果，正常会打印版本号 ollama --version

Linux下如果不想用脚本，也可以手动下载二进制放到/usr/local/bin，但注意保持可执行权限。Windows用户如果在PowerShell里提示“无法识别”，大概率是PATH没有生效，重开一个终端窗口即可。macOS如果遇到“已损坏”的提示，需要到系统设置里允许Ollama运行，这是Gatekeeper的常见拦截。

安装之后我建议立刻确认模型存储路径。Ollama默认把模型放在~/.ollama/models，如果你习惯把系统盘空间留给软件，可以提前设置OLLAMA_MODELS环境变量指向大分区。这个变量在后续使用中不会频繁改动，所以最好写在 shell 配置里：

# 写入 ~/.zshrc 或 ~/.bashrc，Windows下作为系统环境变量 export OLLAMA_MODELS="/data/ollama/models"

设置之后重启终端再执行ollama list，如果提示No models found说明配置生效。这一步不做的话，7B模型动辄几GB的下载内容会直接占用系统盘。Windows下配置系统环境变量后，需要重新打开PowerShell才能读取新值，这是新手最容易迷糊的地方。

2.3 拉取并运行DeepSeek-R1：命令背后的参数逻辑

桌面端最常用的命令只有一条：

# 拉取模型并进入交互对话模式 ollama run deepseek-r1:7b

这条命令执行时，Ollama先检查本地是否已有deepseek-r1:7b，没有就从模型库拉取。下载完成后自动加载并进入终端交互模式，你可以直接输入问题，模型会以流式方式返回回答。退出交互模式输入/bye即可，模型会从内存卸载但保留在磁盘。

关于模型命名需要说明一下。deepseek-r1:7b中的7b是参数量，还有一个8b版本，对应Android编译章节中会用到的deepseek-r1:8b。对个人CPU运行来说，7b更轻量，8b的上下文理解稍好但更吃内存。如果你的机器内存低于16GB，建议先用7b；如果有一块6GB以上显存的显卡，8b也能流畅跑。Ollama对NVIDIA GPU有原生支持，AMD和Intel的GPU支持持续在完善，但我不建议一上来就折腾GPU直通，先用CPU把流程跑通，再优化加速。

如果你只想下载模型而不进入对话，可以用ollama pull：

# 单独拉取模型，之后可以用 ollama run 进入 ollama pull deepseek-r1:7b

拉取过程中终端会显示进度条。这里有个重要参数：Ollama拉取的默认是Q4_K_M量化版本，也就是4bit量化，所以7B模型实际下载大约4.7GB，而不是原始精度下的14GB左右。如果你需要更高精度，可以用deepseek-r1:7b:q8_0这种带量化标签的版本，但磁盘占用会翻倍，推理速度会明显下降。我在实际项目里默认选Q4_K_M，因为效果和体积的平衡最稳。

交互模式下还可以临时调整推理温度。比如要更保守的回答，输入/set parameter temperature 0.5，之后再提问，输出会更稳定。这些参数只对当前会话生效，重启Ollama后恢复默认值。要长期改变默认参数，可以在模型目录下建Modelfile并用ollama create重新生成一个自定义模型名，这是后话，但足以说明Ollama并不像看起来那么“黑匣子”。

如果想查看一个模型的详细参数，比如上下文长度、嵌入维度、量化类型，可以用ollama show：

# 查看模型元信息和参数配置 ollama show deepseek-r1:7b

输出里的parameters字段会列出num_ctx等关键值，num_ctx默认是4096。如果你的业务需要处理长文档，可以在运行模型时用OLLAMA_CONTEXT_LENGTH环境变量扩大上下文，但显存和内存会同步上涨，我一般建议从8192开始试，不要一次拉到128K。到这里，桌面端的本地部署已经完整跑通。需要强调一点：Ollama启动后会在localhost:11434监听REST API，这为后面Android的Termux方案和Open WebUI方案提供了统一的接口基础。

3. 移动端部署：iPhone快捷指令与Android Termux编译

3.1 手机跑模型的两条路：API转发与本地编译

手机端跑大模型有两个截然不同的方向。iPhone方案走的是“轻量API转发”：手机本身不承载模型，而是通过快捷指令把问题发给云端API，拿到结果后展示在通知栏或快捷指令输出页。这个方案的好处是几乎不占用手机性能，坏处是必须有网络并且依赖API服务商。Android方案走的是“本地编译”：用Termux在手机上编译Ollama，让模型真正跑在手机CPU里。这个方案的好处是完全离线、数据不出手机，坏处是编译时间长、内存占用高，而且只推荐骁龙8系或天玑9000以上的设备。

为什么要分开讲？因为两类人群的需求不同。如果只是要在手机上偶尔问问题，API转发完全够用；如果是隐私敏感场景或者没网络的环境，本地编译是更稳的选择。下面的操作步骤我会把两条路都走一遍，你可以按自己设备选择。

3.2 iPhone快捷指令配置流程

iPhone方案的核心是“快捷指令 + API Key”。整个过程不需要写代码，但有几个配置点容易踩坑。

首先在Safari里打开快捷指令安装页，会自动跳转到快捷指令App。如果系统提示“无法打开”，先到设置 -> 快捷指令 -> 允许不受信任的快捷指令，把它打开。这个开关默认关闭，是很多新手卡住的第一道门槛。安装完成后，从API服务商获取一个Key，建议选支持DeepSeek模型的兼容API服务，获取后先不要关页面，后面要填。

打开快捷指令App，找到刚安装的指令，点击右上角的设置按钮，把API Key粘贴到对应文本框中。有些版本还会要求填写模型名称和API Base URL，一般默认值就是deepseek-r1:7b。这一步务必确认没有多余空格，我见过多次因为复制时把换行符一起带进来导致请求失败。首次运行快捷指令时，系统会弹出“允许访问”提示，询问是否允许访问API地址和剪贴板，全部选“允许”即可。

为了确认API Key有效，建议先在终端里用curl试一次请求，别急着在快捷指令里排查：

# 用API Key测试连通性，地址换成你的服务商地址 curl https://your-api-provider.example/v1/chat/completions \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-r1:7b","messages":[{"role":"user","content":"测试"}],"stream":false}'

如果返回的JSON里有choices.response字段，说明Key和网络都正常。之后在快捷指令里运行，只要权限允许，基本不会再出问题。给一份常用的配置参数表，方便你对照：

这个表格里的温度参数不是所有快捷指令都能改，但建议保留0.6左右。这里要提醒的是，手机端API方案本质是网络请求，如果后续发现返回报错，先检查网络和API服务商的配额，不要一上来怀疑模型配置文件。

3.3 Android Termux编译Ollama的完整步骤

Android方案比iPhone复杂一个数量级，但走通之后非常有成就感。Termux是一个终端模拟器，可以在Android上提供Linux环境，Ollama的Android编译本质上就是把Linux版Ollama源码在手机本地编译成可执行文件。整个过程需要网络稳定，且建议连接电源。

先安装Termux，可以从GitHub Releases下载APK。安装完成后打开，第一件事是授权存储和更新软件源：

# 授予存储权限，访问手机文件需要 termux-setup-storage # 更新软件源和已装包 pkg update && pkg upgrade

termux-setup-storage会创建~/storage目录，用于访问手机内置存储。pkg update是同步软件源索引，pkg upgrade是升级已有包，这两个命令在Termux环境里是标配。网络慢的话需要等几分钟，千万不要中途杀掉进程。

编译前申请唤醒锁，防止屏幕熄灭后编译中断：

# 申请唤醒锁，保持CPU持续运行 termux-wake-lock

接下来安装编译依赖：

# 安装编译Ollama所需的工具链 pkg install git cmake golang libjpegturbo

这里解释一下每个包的作用：git用于克隆源码，cmake负责管理一些原生依赖的构建，golang是Ollama的主语言编译器，libjpegturbo是图像处理库，Ollama处理图片输入时会用到。如果你不打算跑多模态模型，这个依赖也可以先装，避免后续报错。

克隆仓库时注意参数写法：

# 浅克隆，只拉取最近的提交记录，减少下载量 git clone --depth 1 https://github.com/ollama/ollama.git cd ollama

这里的--depth 1会大幅度减少克隆体积和时间。很多教程里写git clone depth 1，少两个横线会直接报错，如果遇到unknown argument就检查这一行。进入目录后执行编译：

# 生成平台相关代码 go generate ./... # 编译主程序 go build .

go generate会调用内部工具生成一部分平台相关的胶水代码，不运行直接go build会报缺少文件。go build会在当前目录生成名为ollama的二进制文件。这一步耗时取决于手机CPU，旗舰级芯片大约10到20分钟，中端芯片可能到40分钟以上。编译期间屏幕不要熄灭，也建议在Termux设置里打开“保持唤醒”。

编译完成后先启动服务器，再验证接口：

# 后台启动Ollama服务器 ./ollama serve & # 验证服务器是否响应，出现版本信息即成功 curl http://localhost:11434

serve &中的&表示放入后台。Termux关闭后进程会退出，所以后续使用过程中要保证Termux在后台运行。curl返回的内容里能看到Ollama版本号。确认服务器在跑，就可以拉取模型了：

# 拉取DeepSeek R1 8B模型 ./ollama pull deepseek-r1:8b # 运行模型进入交互 ./ollama run deepseek-r1:8b

需要留意的是，手机内存小于8GB的话，8B模型很可能加载不完整，出现慢速或强行退出。可以改用deepseek-r1:7b，在Android上体积更友好。另外，模型拉取后存放在手机存储里，大约5GB，建议预留10GB空间。整个过程走完后，手机就变成了一台不插电的离线AI终端，信号不好的地方也能继续用。如果你想在Termux之外也能访问这个服务，可以用nohup ./ollama serve > /dev/null 2>&1 &，让进程在终端退出后继续存活，但前提是保持Termux处于后台运行状态。

这一章的操作密度比较大，iPhone方案偏配置、Android方案偏编译，但共同点是都需要注意权限和路径。每当有人问我“手机跑模型到底现不现实”，我都说看你的预期：接受API转发，5分钟搞定；坚持本地离线，请给手机充好电再动手。

4. 基于Open WebUI的容器化部署：用浏览器管理模型

4.1 Open WebUI与Docker的角色分工

Open WebUI是一个自托管的Web前端，它的历史版本曾叫Ollama WebUI，后来扩展成支持多后端。它解决的问题是：Ollama本身只有命令行和REST API，缺少一个可以让非技术用户直接打开的聊天界面。Open WebUI提供了类似ChatGPT的页面，支持对话历史、多会话、附件上传和模型切换。

Docker在这里的作用是环境隔离。Open WebUI需要Python后端和Node前端同时运行，手动配置容易冲突，而容器镜像把两者打包好了。部署后架构就是：浏览器访问Open WebUI的端口，Open WebUI再转发请求给Ollama的11434端口。因此电脑上必须有一个正在运行的Ollama服务，这里说的Ollama可以是桌面版，也可以是上一章在Termux里跑起来的那个。

4.2 Docker Desktop安装与端口映射

安装Docker Desktop前，先确认电脑支持虚拟化。Windows用户需要在BIOS里开启虚拟化，然后安装WSL2；macOS用户只要是Intel或Apple Silicon都可以；Linux用户不用Docker Desktop，直接装Docker Engine即可。安装完成后，运行docker version能看到客户端和服务端信息，就说明环境正常。如果Windows下docker version提示找不到命令，多半是WSL2没有设置为默认版本，可以在PowerShell里执行wsl --set-default-version 2。

接下来用一行命令启动Open WebUI：

# 运行Open WebUI容器，宿主机3000端口映射容器8080端口 docker run -d \ -p 3000:8080 \ --add-host=host.docker.internal:host-gateway \ -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main

参数逐一说：-d表示后台运行；-p 3000:8080把容器内部的8080端口映射到宿主机3000，这样浏览器访问localhost:3000就能进入WebUI；--add-host=host.docker.internal:host-gateway是Linux和Windows旧版Docker需要的，让容器能通过host.docker.internal这个别名访问宿主机；-e OLLAMA_BASE_URL指定Ollama的API地址，这里是宿主机的11434；--name open-webui给容器起名，方便后续停止或删除；--restart always让Docker守护进程启动时自动带起这个容器，避免机器重启后服务丢失；最后一项是镜像名，main对应最新主线版本。

如果你习惯用编排文件，也可以写一个最简docker-compose.yml：

services: ollama: image: ollama/ollama:latest ports: - "11434:11434" volumes: - ollama_data:/root/.ollama open-webui: image: ghcr.io/open-webui/open-webui:main ports: - "3000:8080" environment: OLLAMA_BASE_URL: http://ollama:11434 extra_hosts: - "host.docker.internal:host-gateway" volumes: ollama_data:

这个编排文件把Ollama和Open WebUI都放进了Docker，两个容器通过内部网络互相访问，Ollama的ollama_data卷用来持久化模型文件。如果已经用桌面版Ollama占用了11434端口，那就不要用这个编排，只跑Open WebUI容器并让它的OLLAMA_BASE_URL指向宿主机地址。启动后打开Docker Desktop，在Containers列表里能看到open-webui容器，点击端口号3000:8080会直接打开浏览器。如果在Linux上看到宿主机端口没有被监听，先检查防火墙是否放行了3000端口。

4.3 在WebUI中下载并切换DeepSeek模型

Open WebUI第一次访问时，会让你注册管理员账号。这个账号只存在于本地数据库，不会外发。登录后界面左侧是会话列表，右上角的模型选择器默认只显示Ollama里已有的模型。如果Ollama里还没有DeepSeek，先回到终端执行拉取命令：

# 确保模型存在后再回到WebUI刷新 ollama pull deepseek-r1:7b

拉取完成后，打开Open WebUI左下角的设置，进入“模型”标签页，点击刷新按钮，模型列表里就会出现deepseek-r1:7b。选择它并新建对话，就能像用商用聊天产品一样使用本地模型了。这里要注意的一点是，Open WebUI缓存了模型列表，刷新不起作用时，重启容器：

# 重启Open WebUI容器，让配置重新加载 docker restart open-webui

在WebUI的模型设置里，每个模型可以单独配置temperature、top_p等参数。我给一个比较稳的起步配置：temperature 0.6、top_p 0.9、max_tokens 2048。温度太高会让输出发散，太低会让回答像复读机；top_p控制采样的累积概率，0.9在多样性和稳定性之间比较均衡；max_tokens限制单次回复长度，如果你的业务需要长文本，可以提高到4096，但也会拖慢推理速度。

Open WebUI还自带一个“文档”功能，可以把本地TXT、PDF上传给它，它会自动做向量化检索，然后让模型基于文档内容回答。如果你的DeepSeek部署是为了对接内部知识库，这一步比单独写RAG代码要快得多。但前提是Ollama里的模型本身支持长上下文，DeepSeek R1系列在上下文128K下都能运行，所以这个组合在企业内部工具链里很常见。至此，浏览器访问本地大模型的链路已经完整搭好。下一章把我在几个项目里反复遇到的部署问题集中列出来，你会看到大部分报错其实都和网络、权限、端口这三个因素有关。

5. 部署避坑手册：五条高频踩坑记录

5.1 模型下载一直卡在0%或中断

现象：执行ollama run deepseek-r1:7b后，进度条长时间不动，或者下载到一半报错退出。

原因：Ollama默认从官方模型库下载，网络波动或DNS解析异常时，会一直卡在连接阶段。部分企业网络还会拦截大文件传输。

解决：先检查网络，再换源。常见做法是设置代理环境变量，但如果你的网络环境不允许代理，可以直接手动下载模型文件并放到~/.ollama/models对应目录。更省事的方案是让同网段另一台已下载的机器用ollama serve共享模型，或者用U盘拷贝。我通常先执行ollama pull --verbose看日志，如果卡在pulling manifest就说明是网络层问题。

5.2ollama run提示内存不足或加载缓慢

现象：终端报failed to load model或no space left on device，也有是加载后每个字要等好几秒。

原因：模型加载时需要把权重读入内存，7B模型量化后也需要4.7GB左右，如果内存不够，系统会频繁换页，速度极慢。磁盘空间不足则是模型解压时写不进去。

解决：用free -h看内存，用df -h看磁盘。如果模型存储路径在系统盘，按2.2节的OLLAMA_MODELS挪到空间更大的分区。内存不足时换成更小参数的模型，比如deepseek-r1:1.5b，或者减少并发数量。不要同时开多个模型，Ollama默认可以同时加载多个模型，但那是在内存充足的前提下才有意义。

5.3 iPhone快捷指令运行时报错“无法打开”

现象：在Safari里点击快捷指令链接，页面提示无法打开，或者运行指令时卡在权限请求。

原因：第一步是系统默认不允许安装非App Store的快捷指令，需要手动打开“允许不受信任的快捷指令”。第二步是快捷指令里的API请求没有勾选“允许重定向”，或者API Key包含隐藏字符。

解决：先到设置里打开允许开关，再重新安装。如果仍然无法打开，把快捷指令的“网络”权限切换为“询问每次”。对于Key隐藏字符的问题，建议在文本编辑器中显示不可见字符，把粘贴内容清成纯文本。我自己的习惯是先在备忘录里粘贴一次，再复制到快捷指令，能过滤掉大部分剪贴板残留。

5.4 Termux编译时go generate报错

现象：执行go generate ./...时提示go: cannot find main module或exec: "gcc": executable file not found。

原因：前者是当前目录不对，没有进入ollama目录；后者是缺少C编译器。Termux的基础包不包含完整编译链，Ollama的某些原生依赖需要gcc。

解决：先确认在cd ollama目录下，再检查工具链：pkg install clang make。Ollama在Termux环境下一般用clang代替gcc，安装后重新执行go generate。如果还报错，把GOPATH清理一下：go env查看路径，确保没有把手机内部存储当作工作目录。这里有个细节，Termux的$HOME默认在应用私有目录里，不要用cd ~/storage当工作目录，否则编译会非常慢。

5.5 Open WebUI始终提示“连接Ollama失败”

现象：打开WebUI后，界面显示无法连接到Ollama，日志里出现connection refused。

原因：OLLAMA_BASE_URL配置错误，或者Ollama服务没有启动，再或者防火墙拦截了11434端口。用Docker部署Open WebUI时，容器里的localhost不是宿主机，必须用host.docker.internal，很多人漏掉了这个细节。

解决：先在宿主机执行curl http://localhost:11434确认Ollama在跑。再检查docker run参数里的OLLAMA_BASE_URL是不是http://host.docker.internal:11434。如果还是不行，把--add-host=host.docker.internal:host-gateway加上。Windows上还可能是防火墙拦截，到“允许应用通过防火墙”里放行Docker。

这五条是我在模拟项目X的部署过程中反复遇到的，几乎每个问题都对应一次“翻车”。把这些记录下来不是要吓退你，而是告诉你：遇到报错先看网络、权限、端口三件套，多半能定位。接下来最后一章，说说部署完成后怎么验证效果，以及几个让日常使用更顺手的小技巧。

6. 部署完成的验证与进阶用法

6.1 怎么确认部署真的可用

部署完成后，不要急着关终端。先做一套最基本的验证清单：检查模型是否在列表中，检查API是否响应，最后跑一次真实对话。下面这个命令可以一步完成模型状态和API连通性检查：

# 查看模型是否就绪 ollama list # 测试API生成接口，-d后的JSON是请求体 curl http://localhost:11434/api/generate \ -d '{"model":"deepseek-r1:7b","prompt":"你好，请自我介绍","stream":false}'

ollama list输出里的SIZE列可以确认模型文件没有缺失。curl请求中的stream:false表示等待完整回复返回，这样能拿到整段JSON，而不是流式分片。如果返回的response字段有内容，说明从模型加载到推理输出整条链路都正常。WebUI场景则多一步：新建会话，确认模型选择器里有同名模型，发一句话看回复。

6.2 进阶：调整并发与后台驻留习惯

日常使用中，我最常调整的是Ollama的并发参数。默认情况下Ollama只串行处理请求，如果你要把这个服务暴露给团队用，可以考虑用环境变量提高并行度：

# 启动时设置并发请求数和保留模型数 OLLAMA_NUM_PARALLEL=2 OLLAMA_MAX_LOADED_MODELS=1 ollama serve

OLLAMA_NUM_PARALLEL=2允许同时处理两个请求，适合两个人同时用一个模型；OLLAMA_MAX_LOADED_MODELS=1让内存只保留一个模型，避免切换模型时把内存占满。如果机器内存不够，这两个参数都不要调高，否则会看到一条“内存不足”的报错，然后服务直接重启。另外，OLLAMA_KEEP_ALIVE可以控制模型在空闲后驻留多久，默认5分钟，如果你频繁使用，可以设成24h，减少重复加载的等待。

从那以后，我每次部署完模型，都会强制走一遍这套验证清单：先看模型列表，再发一次API请求，最后用WebUI或终端各跑一轮对话。过去因为跳过验证直接交差，出现过模型加载失败但界面看起来正常的情况，返工成本更高。这组方法虽然基础，却能筛掉八成隐患。希望帮到你。

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