简介这份文档面向希望将开源大模型落地到个人项目或团队工作中的技术人员系统讲解在本地环境部署DeepSeek的完整路径。内容围绕Ollama、LM Studio与Jan三款主流工具展开从最低与推荐硬件配置、操作系统与Python、CUDA等软件依赖到模型拉取、服务启动与接口调用均给出可跟随的命令行示例并对比各工具优缺点帮助读者按自身设备条件做出选择。资源包为1个docx文档约20KB以文字指南形式承载部署流程、环境要求与测试方法便于离线查阅与逐步实践。目前已有1436人学习。读者可据此掌握本地运行DeepSeek的完整思路理解不同模型规格对硬件的要求学会通过本地端口调用模型接口并借助Python示例将模型接入实际应用从而以较低成本获得可自定义、可离线使用的AI能力降低实验门槛为后续研究与开发提供可复用的部署参考。1. 本地跑 DeepSeek 这件事版本选错比显卡不够更让人头疼上周帮一个做 NLP 的朋友排查本地推理环境他机器是 RTX 3090 64GB 内存按理说跑个 7B 模型绰绰有余结果折腾了一下午连模型都没加载起来。最后发现是 Ollama 版本太老不支持 DeepSeek-R1 的 GGUF 量化格式终端里只报了一句含糊的Error: model requires more system memory实际上内存还剩一大半。这种坑在本地部署里太常见了——硬件够、软件版本不对照样翻车。DeepSeek 本地部署现在主流就三条路Ollama、LM Studio、Jan。Ollama 适合习惯命令行的开发者LM Studio 适合想快速上手图形界面的Jan 适合需要多模态能力的场景。三条路我都走过各有各的版本坑。这篇笔记按「装什么 → 怎么装 → 坏了怎么救」的顺序把三个工具的安装、配置、验证和排错一次讲透。如果你正在找 DeepSeek 本地部署的完整流程或者已经装了一半卡在某个报错上下面的内容应该能帮你省下不少时间。2. 环境先列清硬件底线、系统版本和依赖对照2.1 硬件配置的底线和推荐值本地跑 DeepSeek 这件事硬件决定了你能跑多大的模型软件决定了你能不能跑起来。先看硬件底线这是绕不过去的硬门槛。配置项最低要求推荐配置说明CPU支持 AVX2 指令集支持 AVX2 的现代多核 CPU老 CPU 不支持 AVX2 会直接报 illegal instruction内存16GB32GB 及以上7B 模型推理时内存占用约 8-12GB存储30GB 可用空间50GB 以上 SSD模型文件本身 4-8GB加上缓存和系统占用GPU非必须NVIDIA RTX 3090 或更高有 GPU 时推理速度提升明显显存 8GB 起步这里有个容易忽略的点内存和显存是两回事。Ollama 默认会优先用 GPU但如果显存不够它会回退到 CPU 内存模式。很多人看到「16GB 内存」以为够了结果跑 14B 模型时系统直接卡死因为 14B 的 GGUF 量化版加载后内存占用轻松超过 20GB。我一般建议7B 模型配 16GB 内存14B 模型配 32GB32B 模型至少 64GB。别信「最低配置能跑」这种话能跑和能用是两码事。2.2 操作系统和 Python 环境操作系统这块Ubuntu 20.04 和 Windows 10/11 都没问题macOS 需要 12 以上。Linux 下 Ollama 的安装最省心一条脚本搞定Windows 需要手动下载安装包macOS 用 Homebrew 或者直接下 dmg 都行。Python 环境不是必须的但如果你打算用代码调用模型接口建议装 3.8 以上版本。CUDA 这块要注意只有用 GPU 加速推理时才需要版本要求 11.7并且必须和 PyTorch 版本匹配。我见过有人 CUDA 装的是 12.x结果 Ollama 编译时用的还是 11.8 的运行时导致 GPU 调用失败。如果你不确定先不装 CUDA用 CPU 模式跑通流程再说。# 检查 CPU 是否支持 AVX2Linux grep -o avx2 /proc/cpuinfo | head -1 # 输出 avx2 说明支持无输出则不支持 # 检查内存和存储 free -h df -h /home # 检查 Python 版本 python3 --version上面这几条命令是我拿到新机器后必跑的尤其是 AVX2 那条。有些云服务商的便宜实例用的是老款 Xeon不支持 AVX2Ollama 装上去直接跑不起来报错信息还不明显。提前查一下能省很多事。2.3 三个部署工具的版本选择建议Ollama、LM Studio、Jan 这三个工具我按使用场景给个版本建议Ollama选 0.5.x 及以上版本。0.4.x 对 DeepSeek-R1 的支持不完整拉模型时可能报unsupported architecture。0.5.6 是我实测比较稳的版本。LM Studio选 0.3.x 以上。老版本对 GGUF 格式的兼容性有问题加载 DeepSeek 模型时容易卡在 99%。Jan选 0.5.x 以上。Jan 的更新频率高老版本可能缺少对 DeepSeek 新量化格式的支持。提示三个工具不要同时装在同一台机器上跑端口会冲突。Ollama 默认 11434LM Studio 默认 1234Jan 默认 1337同时启动时如果端口被占用后启动的会静默失败。3. Ollama 部署 DeepSeek从安装到拉模型3.1 安装 Ollama 并验证版本Ollama 是我最常用的本地部署工具命令行操作干净利落适合习惯终端的人。安装方式按系统分# Linux 一键安装 curl -fsSL https://ollama.com/install.sh | sh # macOS 用 Homebrew brew install ollama # Windows 去官网下载安装包双击安装安装完成后第一件事是验证版本ollama --version # 期望输出ollama version is 0.5.6如果版本低于 0.5.0建议先升级。Linux 下重新跑一遍安装脚本就会覆盖升级macOS 用brew upgrade ollama。Windows 需要卸载后重新安装直接覆盖安装有时会残留旧版本的服务进程。安装脚本做的事情其实不复杂下载对应平台的二进制文件放到/usr/local/bin/然后注册一个 systemd 服务Linux或 launchd 服务macOS。Windows 下则是安装成一个后台服务。理解这一点很重要因为后面排错时经常需要检查服务状态。3.2 拉取 DeepSeek-R1 模型并选择合适的大小Ollama 安装好之后拉模型就一条命令# 拉取默认版本通常是 7B 量化版 ollama pull deepseek-r1 # 指定模型大小 ollama pull deepseek-r1:7b ollama pull deepseek-r1:14b ollama pull deepseek-r1:32b模型大小的选择直接决定硬件压力。7B 模型文件大约 4.7GB加载后内存占用 8-10GB14B 大约 9GB内存占用 16-20GB32B 大约 20GB内存占用 32GB 以上。如果你只有 16GB 内存老老实实跑 7B别想着「试试看能不能跑 14B」系统卡死的时候连 kill 进程都费劲。拉取过程中如果中断Ollama 支持断点续传重新执行ollama pull会从断点继续。但有一种情况需要注意如果磁盘空间不足拉取会失败并留下不完整的 blob 文件这时候需要先ollama rm deepseek-r1删掉残留再重新拉。# 查看已下载的模型列表 ollama list # 删除不完整的模型 ollama rm deepseek-r1:7b3.3 启动服务并配置监听地址模型拉下来之后启动 Ollama 服务# 前台启动方便看日志 ollama serve # 后台启动Linux systemd sudo systemctl start ollama sudo systemctl enable ollama # 开机自启默认情况下 Ollama 监听127.0.0.1:11434只允许本机访问。如果你需要在局域网内其他机器上调用需要设置环境变量# Linux/macOS export OLLAMA_HOST0.0.0.0:11434 ollama serve # Windows PowerShell $env:OLLAMA_HOST0.0.0.0:11434 ollama serve这里有个参数取舍绑定0.0.0.0意味着同一网络下任何设备都能访问你的模型接口如果没有认证机制相当于把模型暴露出去了。我一般只在调试时临时开用完就改回127.0.0.1。另外OLLAMA_MODELS环境变量可以指定模型存储路径默认在~/.ollama/models如果系统盘空间紧张可以改到大容量数据盘。# 指定模型存储路径 export OLLAMA_MODELS/data/ollama/models设置完环境变量后需要重启 Ollama 服务才能生效。Linux 下用systemctl restart ollamamacOS 下需要退出 Ollama 应用再重新打开。4. LM Studio 和 Jan图形界面下的安装与配置4.1 LM Studio 安装与模型加载LM Studio 适合不想碰命令行的人图形界面操作直观但有几个配置项容易踩坑。安装很简单官网下载对应系统的安装包双击安装即可。首次启动后界面会引导你下载模型。在「Discover」标签页搜索「DeepSeek R1」会看到多个版本。这里要注意格式选择Windows 和 Linux 选 GGUF 格式Apple 芯片的 Mac 选 MLX 格式。选错格式的后果是模型能下载但加载时报unsupported format。下载完成后切换到「Local Models」标签页找到刚下载的模型点击「Load」。加载过程中可以在右侧看到内存占用和推理速度。如果加载失败最常见的原因是内存不足LM Studio 会在日志里提示insufficient memory。加载成功后进入「Developer」标签页开启「Start Server」。默认监听http://localhost:1234。LM Studio 的服务器兼容 OpenAI API 格式可以直接用 OpenAI 的 Python SDK 调用。import openai client openai.Client( base_urlhttp://localhost:1234/v1, api_keylm-studio # LM Studio 不校验 key随便填 ) response client.chat.completions.create( modeldeepseek-r1, # 模型名称要和 LM Studio 里显示的一致 messages[{role: user, content: 你好}], temperature0.7 ) print(response.choices[0].message.content)这段代码里base_url指向 LM Studio 的本地端口api_key随便填一个非空字符串就行。model参数必须和 LM Studio 中加载的模型名称完全一致否则会报model not found。4.2 Jan 安装与多模态配置Jan 的定位和 LM Studio 类似但更强调多模态能力。安装同样是从官网下载安装包。Jan 的模型下载走的是 Hugging Face 渠道在 Hugging Face 上搜索「unsloth gguf deepseek r1」找到模型后点击「Use this model」选择 Jan模型会自动在 Jan 中打开并开始下载。Jan 的服务器默认监听http://localhost:1337。加载模型后选中模型点击「Load」Jan 会自动启动服务器。Jan 的配置项比 LM Studio 多一些尤其是多模态相关的设置。如果你只做文本推理保持默认即可如果需要处理图像需要在设置里开启对应的多模态支持。Jan 的一个坑是依赖项问题。某些 Linux 发行版下Jan 需要额外的系统库才能正常运行比如libwebkit2gtk。如果启动时报error while loading shared libraries用包管理器装上对应的库就行。# Ubuntu/Debian 下安装 Jan 的依赖 sudo apt install libwebkit2gtk-4.0-37 libgtk-3-04.3 三个工具的端口和 API 兼容性对照三个工具都兼容 OpenAI API 格式但端口和默认模型名称不同混用的时候容易搞混。整理成表格方便查阅工具默认端口API 路径默认模型名认证方式Ollama11434/v1/chat/completionsdeepseek-r1:7b任意非空字符串LM Studio1234/v1/chat/completions加载时的模型名任意非空字符串Jan1337/v1/chat/completions加载时的模型名任意非空字符串三个工具的 API 路径都是/v1/chat/completions这意味着你可以写一套代码只改base_url就能在三个工具之间切换。我一般会在代码里把base_url做成配置项方便对比不同工具的推理效果。5. 避坑与排查五个真实踩过的坑5.1 坑一Ollama 拉模型报 unsupported architecture现象执行ollama pull deepseek-r1后下载完成但加载时报Error: unsupported architecture。原因Ollama 版本低于 0.5.0不支持 DeepSeek-R1 的模型架构。DeepSeek-R1 用的是较新的 GGUF 元数据格式老版本 Ollama 解析不了。解决升级 Ollama 到 0.5.x 以上。Linux 下重新跑安装脚本macOS 用brew upgrade ollamaWindows 卸载后重新安装。升级后先ollama rm deepseek-r1删掉旧模型再重新拉取。5.2 坑二模型加载后推理速度极慢现象模型能加载但每次生成回复要等几十秒CPU 占用 100%GPU 占用 0%。原因Ollama 没有正确识别到 GPU回退到了 CPU 推理。常见原因是 CUDA 版本不匹配或显卡驱动太老。解决先确认 Ollama 是否检测到 GPU# 查看 Ollama 日志中的 GPU 检测信息 journalctl -u ollama | grep -i gpu如果日志里没有 GPU 相关信息说明 Ollama 没找到可用的 GPU。检查 NVIDIA 驱动版本nvidia-smi确保 CUDA 运行时版本和 Ollama 编译时用的版本一致。实在搞不定就先接受 CPU 推理7B 模型在 CPU 上虽然慢但至少能跑。5.3 坑三LM Studio 加载模型卡在 99%现象LM Studio 下载完模型后点击 Load 一直卡在 99%进度条不动。原因模型文件下载不完整或者 GGUF 格式和 LM Studio 版本不兼容。LM Studio 0.2.x 对某些新量化格式支持不好。解决先删除已下载的模型文件升级 LM Studio 到 0.3.x 以上重新下载。如果还是卡住换一个量化版本试试比如从 Q4_K_M 换成 Q4_0。5.4 坑四端口被占用导致服务启动失败现象Ollama 启动时报bind: address already in use或者 LM Studio 的服务器开关打不开。原因默认端口被其他进程占用。11434 端口可能被之前的 Ollama 进程占着1234 端口可能被其他开发工具占用。解决先查端口占用# Linux/macOS lsof -i :11434 # Windows netstat -ano | findstr 11434找到占用进程后要么 kill 掉要么改 Ollama 的监听端口export OLLAMA_HOST127.0.0.1:11435 ollama serve5.5 坑五Python 调用时报 Connection refused现象Python 代码调用http://localhost:11434/v1时报Connection refused。原因Ollama 服务没启动或者监听地址不是localhost。有些情况下 Ollama 只监听了 IPv6 的::1而 Python 的 requests 库默认走 IPv4。解决先确认服务在跑ollama list能正常输出说明服务活着然后检查监听地址# 查看 Ollama 实际监听的地址 ss -tlnp | grep 11434如果显示的是::1:11434而不是127.0.0.1:11434把代码里的localhost改成127.0.0.1试试。或者设置OLLAMA_HOST127.0.0.1:11434强制走 IPv4。6. 装完怎么验证三条命令确认环境真的能跑装完不代表能用我一般会走一遍完整的验证流程确认模型真的能推理、API 真的能调通。下面三条命令按顺序执行任何一条失败都说明环境还有问题。第一步确认模型已加载ollama list # 期望输出包含 deepseek-r1:7b 及其大小如果列表为空说明模型没拉下来回到第 3 章重新拉取。第二步命令行直接推理ollama run deepseek-r1:7b 用一句话解释什么是深度学习 # 期望输出一段合理的中文回复这一步验证的是模型本身能不能跑。如果卡住不动大概率是内存不够检查free -h的可用内存。如果报错退出看终端输出的错误信息对照第 5 章的排查方法处理。第三步API 接口调用curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:7b, messages: [{role: user, content: 你好}], temperature: 0.7 }期望返回一个 JSON包含choices数组和模型生成的回复。如果返回Connection refused说明 Ollama 服务没启动或者端口不对。如果返回model not found检查model字段的值是否和ollama list里的名称完全一致。三条都通过之后再用 Python 跑一遍第 4 章那段代码确认 SDK 调用也没问题。我习惯把这三步写成一个 shell 脚本每次换机器或者升级版本后跑一遍省得手动敲。#!/bin/bash # verify_deepseek.sh - 本地 DeepSeek 环境验证脚本 set -e echo 检查模型列表 ollama list | grep deepseek-r1 || { echo 模型未找到; exit 1; } echo 命令行推理测试 ollama run deepseek-r1:7b 回复OK || { echo 推理失败; exit 1; } echo API 接口测试 curl -s http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model:deepseek-r1:7b,messages:[{role:user,content:回复OK}]} \ | grep -q choices || { echo API 调用失败; exit 1; } echo 全部通过 这个脚本里set -e让任何一步失败就退出grep -q只检查关键词是否存在不输出内容。我一般把它放在项目根目录每次环境变动后跑一次。从那以后我每次部署完本地模型都强制走一遍这三步验证不再凭「终端没报错」就认为装好了。很多问题是在实际调用时才暴露的提前验证能省下大量排查时间。希望帮到你。本文还有配套的精品资源点击获取