企业官网建设流程全解析

简介：这份资源是一份面向AI推理部署与深度学习开发者的DeepSeek模型本地化部署指南，适合具备一定软硬件基础、希望降低云服务成本并深入理解大语言模型底层机制的研究人员与工程师。内容围绕Ollama安装、按显存规模选择DeepSeek-R1参数量版本、Docker容器化与Open WebUI图形界面接入等环节展开，覆盖从命令行加载到浏览器登录验证的完整链路。资源包共1个docx文档，约15KB，以图文步骤与命令说明为主，便于按章节查阅和对照操作。目前已有5229人学习下载，说明该方案在本地LLM部署场景中具有较高参考价值。读者可借此掌握一套通用的大模型本地部署思路，理解不同硬件条件下的模型选型逻辑，并借助Docker与Open WebUI扩展服务形态，为后续科研或项目落地提供可复用的实践基础。

1. 本地跑大模型这件事，卡在哪一步的人最多

DeepSeek 模型本地部署教程里，搜索量最高的组合词是「Ollama 安装」和「模型运行」。这两个词放在一起，其实暴露了一个很具体的困境：大多数人不是不想在本地跑模型，而是卡在从「下载完安装包」到「终端里真的吐出第一段文字」之间那段没人讲清楚的路。Ollama 这个工具的价值就在于把这段路压到最短——它把模型权重、推理引擎、API 服务打包成一个命令行程序，你不需要配 CUDA、不需要写 Python 加载脚本、不需要理解量化格式，装完就能ollama run。但「最短」不等于「没有坑」，显存不够、模型拉取中断、量化版本选错、上下文长度设太大导致 OOM，这些翻车现场在本地部署里一个都不会少。这篇笔记面向的是手上有台机器、想在自己环境里把 DeepSeek 跑起来的人，不管你是做私有化推理验证，还是单纯想有个不依赖网络的本地对话入口，下面的步骤和参数都能直接抄。

2. Ollama 安装与 DeepSeek 模型拉取：从零到第一次对话

2.1 安装前先确认三件事，不然装了也跑不动

Ollama 本身对系统要求不高，但它要跑的模型对硬件有硬门槛。安装之前先花两分钟确认这三项，能省掉后面大量无效折腾。

第一是内存和显存。DeepSeek 系列里适合本地跑的主要是蒸馏版和轻量版，参数量从 1.5B 到 70B 不等。1.5B 和 7B 级别在 16GB 内存的机器上纯 CPU 也能跑，只是速度慢；14B 以上建议至少有 12GB 显存的独立显卡，否则推理速度会掉到每秒几个 token，体验很差。第二是磁盘空间，模型文件动辄几个 GB 到几十 GB，拉取前确认目标盘剩余空间是模型体积的两倍以上，因为拉取过程中会有临时文件。第三是系统版本，Linux 内核建议 5.15 以上，macOS 建议 13 以上，Windows 需要 WSL2 或者原生安装包，老版本系统上 Ollama 的服务注册会失败。

确认完这三项，再往下走。如果你不确定自己的显卡能不能跑某个尺寸，一个粗略的估算方法是：FP16 精度下每 10 亿参数约需 2GB 显存，4-bit 量化后约需 0.7GB。按这个比例反推，就能知道自己的卡适合哪个量级。

2.2 Linux 和 macOS 上的安装命令与验证

Linux 和 macOS 的安装方式基本一致，官方提供了一键脚本。下面这条命令会下载安装脚本并执行，安装完成后 Ollama 会注册为系统服务，开机自启。

# 下载并执行官方安装脚本 curl -fsSL https://ollama.com/install.sh | sh # 验证服务是否正常运行 ollama --version # 查看服务状态（Linux systemd 环境） systemctl status ollama

安装脚本做的事情包括：检测系统架构、下载对应二进制、创建 ollama 用户、注册 systemd 服务（Linux）或 launchd 服务（macOS）。执行完ollama --version能看到版本号，说明二进制已经就位。如果systemctl status ollama显示 active (running)，说明后台服务已经起来，后续ollama run会直接和这个服务通信。

macOS 上如果不想用脚本，也可以直接下载 dmg 安装包拖进 Applications，首次打开会提示安装命令行工具，点确认即可。安装完成后同样用ollama --version验证。

注意：安装脚本需要 sudo 权限来创建系统用户和注册服务，如果当前用户没有 sudo 权限，脚本会报错退出。这种情况下可以手动下载二进制放到用户目录，但服务管理需要自己处理，不推荐新手走这条路。

2.3 Windows 上的安装与 WSL2 环境准备

Windows 用户有两条路：原生安装包和 WSL2。原生安装包最简单，下载 exe 双击安装，装完在 PowerShell 里就能用ollama命令。但原生版本对显卡驱动的兼容性偶尔出问题，尤其是较新的显卡。如果你遇到ollama run报错说找不到 GPU，可以换 WSL2 方案。

WSL2 方案的前提是已经装好 WSL2 和一个 Linux 发行版（Ubuntu 最常见）。进入 WSL2 终端后，按照上一节的 Linux 安装命令操作即可。WSL2 的优势是 GPU 直通支持比较成熟，NVIDIA 显卡在 WSL2 里能被 Ollama 正常识别。

# 在 WSL2 的 Ubuntu 终端里执行 curl -fsSL https://ollama.com/install.sh | sh # 确认 GPU 是否被识别 ollama run deepseek-r1:7b --verbose

--verbose参数会在对话结束后打印推理速度等统计信息，如果看到 GPU 相关的显存占用数据，说明显卡已经被调用。如果只看到 CPU 信息，需要检查 WSL2 的 GPU 直通配置和显卡驱动版本。

2.4 拉取 DeepSeek 模型：标签怎么选，拉取中断怎么办

Ollama 的模型库用「模型名:标签」的格式区分不同版本。DeepSeek 相关的常用标签有几种，选错了要么跑不动，要么效果打折扣。

# 拉取 7B 蒸馏版，适合 8GB 显存左右的机器 ollama pull deepseek-r1:7b # 拉取 1.5B 轻量版，适合纯 CPU 或低显存环境 ollama pull deepseek-r1:1.5b # 拉取 14B 版本，需要 12GB 以上显存 ollama pull deepseek-r1:14b # 查看本地已拉取的模型列表 ollama list

标签里的数字代表参数量，b 是 billion 的缩写。参数量越大，模型能力越强，但对硬件要求越高。7B 是一个比较平衡的起点，大多数消费级显卡能跑。1.5B 适合验证流程，效果一般但速度快。14B 以上适合有明确推理质量要求的场景。

拉取过程中如果网络中断，Ollama 支持断点续传，重新执行ollama pull会从断点继续，不会从头下载。但如果中断次数太多导致临时文件损坏，需要先ollama rm 模型名删掉残留，再重新拉。判断是否损坏的方法是看ollama list里模型大小是否明显小于预期。

提示：拉取大模型时建议在稳定的网络环境下进行，并且不要同时拉多个模型，并发拉取会争抢带宽，反而更慢。

2.5 第一次运行：run 命令的参数与交互方式

模型拉取完成后，用ollama run启动对话。

# 启动交互式对话 ollama run deepseek-r1:7b # 单次提问，不进入交互模式 ollama run deepseek-r1:7b "用一句话解释什么是量化" # 指定上下文窗口大小（默认 2048，可调大到 8192） ollama run deepseek-r1:7b --context-size 8192

进入交互模式后，直接输入问题回车即可。退出用/bye或者 Ctrl+D。--context-size控制模型能记住的上下文长度，调大能处理更长的对话，但会占用更多显存。7B 模型在 8GB 显存下，上下文开到 4096 比较稳妥，8192 可能会 OOM。

单次提问模式适合脚本调用，输出完就退出，不占资源。如果你要把 Ollama 集成到自己的程序里，更推荐用它的 HTTP API，默认监听 11434 端口，/api/generate和/api/chat两个端点覆盖了大部分需求。

3. 模型选型与量化：为什么同一个 DeepSeek 跑出来效果差很多

3.1 参数量、量化精度和显存的三角关系

同一个 DeepSeek 模型，不同人跑出来的效果和速度可能差好几倍，核心变量是量化精度。量化是把模型权重从高精度浮点数压缩成低精度表示的过程，精度越低，模型体积越小、推理越快，但输出质量会下降。

Ollama 默认拉取的模型通常是 4-bit 量化版本（Q4_K_M 或类似），这是在体积和质量之间比较平衡的选择。如果你手动指定其他标签，可能会拉到 8-bit 甚至 FP16 版本，体积翻倍但质量提升有限。对于大多数本地部署场景，4-bit 量化是性价比最高的选择。

下面这张表可以帮助你快速判断自己的硬件适合哪个量级：

体积和显存建议是估算值，实际会因量化方法和上下文长度浮动。选型的原则是：先确定你能接受的推理速度下限，再反推能跑的最大参数量，最后在这个参数量下选 4-bit 量化。

3.2 用 ollama show 查看模型细节，避免拉错版本

拉完模型后，建议用ollama show确认一下实际拉到的版本信息。

# 查看模型详细信息 ollama show deepseek-r1:7b # 输出包含：模型架构、参数量、量化方式、上下文长度等

输出里会列出quantization字段，显示实际量化精度。如果显示 Q4_K_M，说明是 4-bit 量化；如果显示 F16，说明是完整精度，体积会大很多。parameters字段显示参数量，context length显示模型支持的最大上下文。

这个命令的实用价值在于：当你从不同来源拉取同名模型时，实际内容可能不同。确认量化方式和参数量，能避免「以为拉的是轻量版，结果跑不动」的情况。

3.3 自定义 Modelfile：把系统提示词和参数固化下来

Ollama 支持用 Modelfile 自定义模型行为，把系统提示词、温度、上下文长度等参数固化成一个新模型。这样每次运行不用重复传参，也方便分享给其他人。

# 创建一个 Modelfile cat > Modelfile << 'EOF' FROM deepseek-r1:7b # 设置系统提示词 SYSTEM "你是一个简洁的技术助手，回答控制在三句话以内。" # 设置温度参数，越低越确定，越高越有创造性 PARAMETER temperature 0.3 # 设置上下文窗口 PARAMETER num_ctx 4096 # 设置重复惩罚 PARAMETER repeat_penalty 1.1 EOF # 基于 Modelfile 创建新模型 ollama create my-deepseek -f Modelfile # 运行自定义模型 ollama run my-deepseek

FROM指定基础模型，必须是本地已拉取的。SYSTEM是系统提示词，会在每次对话前注入。PARAMETER后面跟推理参数，temperature 控制随机性，num_ctx 控制上下文长度，repeat_penalty 控制重复内容的惩罚力度。

这个做法的好处是把配置代码化，换机器时只要带上 Modelfile 就能复现同样的行为。对于需要固定输出风格的场景，比如客服问答、代码补全，把提示词固化进模型比每次手动输入可靠得多。

4. 避坑与排查：本地部署 DeepSeek 最常见的五个翻车现场

4.1 拉取到一半报错，模型列表里出现半成品

现象是ollama pull执行到某个百分比后报错退出，ollama list里能看到模型名但大小不对，运行时报「模型文件损坏」。

原因通常是网络中断导致临时文件不完整，或者磁盘空间不足导致写入失败。Ollama 的断点续传在大多数情况下有效，但如果临时文件本身损坏，续传会一直失败。

解决方法是先删除残留再重新拉取。ollama rm 模型名会清理掉不完整的文件，然后重新执行ollama pull。如果反复失败，检查磁盘剩余空间，并尝试在网络更稳定的时段操作。

4.2 运行时报显存不足，但显卡明明还有余量

现象是ollama run启动后报 CUDA out of memory，但用nvidia-smi看显存占用并不高。

原因是 Ollama 默认会尝试把整个模型加载到显存，如果模型体积加上上下文缓存超过显存上限，就会直接报错，而不是自动降级到 CPU。另外，如果之前有残留的 Ollama 进程没退出，也会占着显存不放。

解决方法是先确认没有残留进程，pkill ollama后重新启动服务。然后降低上下文长度，用--context-size 2048启动。如果还是不够，换更小参数量的模型，或者接受 CPU 推理的慢速度。

4.3 输出速度极慢，每秒不到一个 token

现象是模型能跑起来，但生成速度慢到无法接受，一句话要等几十秒。

原因可能是模型跑在 CPU 上而不是 GPU 上，也可能是显存不够导致部分层被卸载到内存。另外，如果机器同时跑着其他占显存的任务，也会拖慢推理。

解决方法是先用ollama run --verbose看推理时的设备信息，确认是否调用了 GPU。如果显示 CPU，检查显卡驱动和 Ollama 版本是否匹配。如果确认是 GPU 但速度仍然慢，降低模型参数量或量化精度，减少显存压力。

4.4 中文输出夹杂乱码或异常符号

现象是模型回答中文问题时，偶尔出现乱码、重复字符或者不完整的句子。

原因通常是量化精度太低导致模型输出分布偏移，或者上下文长度设置不当导致截断。某些低精度量化版本在中文任务上表现明显差于英文。

解决方法是换用更高精度的量化版本，比如从 Q4 换到 Q5 或 Q8。如果显存不允许，换更小参数量的高精度版本，比如 7B 的 Q8 代替 14B 的 Q4。另外检查num_ctx是否设得太小，导致对话历史被截断后模型失去上下文。

4.5 服务启动失败，端口被占用

现象是systemctl status ollama显示 failed，日志里报「address already in use」。

原因是 11434 端口被其他程序占用，可能是之前手动启动的 Ollama 进程没退出，或者其他服务碰巧用了这个端口。

解决方法是先找到占用端口的进程，lsof -i :11434查看 PID，确认是残留的 Ollama 进程后 kill 掉。如果是其他程序占用，可以修改 Ollama 的监听端口，通过环境变量OLLAMA_HOST=0.0.0.0:11435指定新端口，然后重启服务。

5. 把 Ollama 接进自己的工作流：API 调用与批量推理

5.1 用 HTTP API 替代命令行，方便集成

Ollama 默认在 11434 端口提供 HTTP API，这是把它接进自己程序最直接的方式。下面是一个 Python 调用示例，用 requests 库发送请求。

import requests import json # Ollama 的生成接口 url = "http://localhost:11434/api/generate" payload = { "model": "deepseek-r1:7b", "prompt": "用 Python 写一个快速排序函数", "stream": False, # 关闭流式输出，一次性返回 "options": { "temperature": 0.2, "num_ctx": 4096 } } response = requests.post(url, json=payload) result = response.json() print(result["response"])

stream设为 False 时，接口会等模型生成完毕后一次性返回完整结果，适合脚本处理。设为 True 时，返回的是逐块输出的流，适合做打字机效果的前端。options里的参数和 Modelfile 里的 PARAMETER 对应，可以在这里覆盖默认值。

5.2 批量推理：用 chat 接口处理多轮对话

如果需要处理多轮对话，用/api/chat接口更合适，它接受消息列表格式。

import requests url = "http://localhost:11434/api/chat" messages = [ {"role": "system", "content": "你是一个技术助手。"}, {"role": "user", "content": "什么是量化？"}, {"role": "assistant", "content": "量化是把模型权重从高精度压缩到低精度的过程。"}, {"role": "user", "content": "那 4-bit 量化会损失多少精度？"} ] payload = { "model": "deepseek-r1:7b", "messages": messages, "stream": False } response = requests.post(url, json=payload) print(response.json()["message"]["content"])

messages 列表按角色区分，system 是系统提示，user 是用户输入，assistant 是模型之前的回复。把历史消息按顺序传入，模型就能基于完整上下文回答。这个接口适合做多轮问答的批处理，比如把一批客服对话记录逐条送入模型做意图分类。

5.3 一个容易忽略的细节：模型加载与卸载的时机

Ollama 在第一次收到请求时会加载模型到显存，之后一段时间内保持加载状态以加速后续请求。默认的保持时间是 5 分钟，超过后自动卸载释放显存。

这个机制在交互式使用时没问题，但在批量脚本里可能造成困扰：如果两条请求间隔超过 5 分钟，第二条请求会触发重新加载，增加延迟。可以通过环境变量OLLAMA_KEEP_ALIVE调整保持时间，设为-1表示永不卸载，设为0表示请求完立即卸载。

# 设置模型保持加载 30 分钟 export OLLAMA_KEEP_ALIVE=30m # 或者在 API 请求里指定 payload = { "model": "deepseek-r1:7b", "prompt": "你好", "keep_alive": "30m" }

对于需要频繁调用的场景，把 keep_alive 设长一点能减少加载开销。对于显存紧张、需要和其他任务共享显卡的场景，设短一点或者用0让模型用完即走。

5.4 验证部署是否成功的三个检查点

部署完成后，用这三个检查点确认一切正常。第一，ollama list能看到目标模型且大小合理。第二，ollama run 模型名 "测试"能在合理时间内返回有意义的回答。第三，用 curl 直接调 API 能拿到 JSON 响应。

# 检查点三：直接调 API curl http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:7b", "prompt": "回复 OK", "stream": false }'

如果这三个检查点都通过，说明本地部署已经可用。后续无论是接前端、写脚本还是做批量任务，都可以在这个基础上展开。我自己的习惯是每次换机器或升级 Ollama 版本后，先把这三个检查点跑一遍，确认基础链路没问题再动上层逻辑，这样出问题时排查范围能小很多。希望帮到你。

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