简介这份文档面向希望将开源大模型落地到个人项目或团队工作中的技术人员系统讲解在本地环境部署DeepSeek的完整路径。内容围绕Ollama、LM Studio与Jan三类主流工具展开从最低与推荐硬件配置、操作系统与Python、CUDA等软件依赖到模型拉取、服务启动与接口调用均给出可跟随的命令行示例并对比各工具优缺点帮助读者按自身设备条件做出选择。资源包为1个docx文件约20KB以图文与代码片段结合的方式组织便于边看边操作。文档还包含部署成功后的测试方法与实际调用示例如通过Python接口访问本地服务让读者能快速验证模型可用性并接入自有应用。目前已有1436人学习适合具备一定深度学习与NLP基础、希望低成本获取最新AI技术支持并降低实验门槛的开发者参考。1. 本地跑 DeepSeek为什么我宁愿折腾三小时也不碰在线 API上个月帮一个做医疗问答的团队看架构他们想把 DeepSeek 接进内部知识库但数据合规部门死活不批在线调用。这不是个例——我接触过的 NLP 项目里超过一半最终都走向了本地部署。原因很实在推理延迟可控、数据不出内网、没有 token 计费焦虑而且 DeepSeek 作为开源模型蒸馏版本在消费级硬件上就能跑出可用效果。但本地部署这件事坑比想象中多。Ollama、LM Studio、Jan 三个工具我都完整走过一遍流程有的场景下 Ollama 一条命令搞定有的场景下 LM Studio 的 GGUF 量化格式才是唯一解。这篇文章不跟你讲大道理就按我实际踩过的路线把选型逻辑、硬件底线、三个工具的完整操作链路、以及那些文档里不会写的翻车点全部拆开讲清楚。如果你手头有一台 16GB 内存以上的机器跟着走完至少能跑起来一个能用的本地推理服务。2. 部署工具选型Ollama、LM Studio、Jan 到底怎么选2.1 三个工具的核心差异不在界面在推理后端很多人选工具看的是「哪个好看」但真正决定体验的是底层推理引擎。Ollama 底层用的是 llama.cpp对 GGUF 格式支持最成熟命令行交互为主适合脚本化和服务化部署。LM Studio 同样基于 llama.cpp但封装了图形界面和模型市场下载模型不用记命令适合快速验证。Jan 则走的是另一条路——它更像一个桌面 AI 工作台支持多模态输入底层可以切换不同的推理后端但依赖项也最多。从实际使用感受来说Ollama 的冷启动速度最快服务化最干净LM Studio 的模型管理最省心但内存占用偏高Jan 的功能最全但首次配置最容易卡在依赖安装上。如果你是要把模型集成到现有 Python 项目里Ollama 的 OpenAI 兼容接口是首选如果只是想在本地聊天窗口里试试效果LM Studio 更顺手。2.2 选型决策表按你的场景对号入座维度OllamaLM StudioJan操作系统macOS/Linux/WindowsmacOS/Windows/LinuxmacOS/Windows/Linux交互方式命令行 API图形界面 API图形界面 API模型格式GGUFGGUF/MLXGGUF/多格式最低内存16GB16GB16GB服务端口1143412341337适合场景服务化/脚本集成快速验证/对话多模态/桌面助手依赖复杂度低中高这张表是我自己三台机器上实测后的总结。注意「最低内存」这一行——16GB 是跑 7B 量化模型的底线低于这个数模型加载阶段就会 OOM。如果你只有 8GB 内存建议直接放弃本地部署或者考虑更小的蒸馏版本。2.3 硬件底线别信「CPU 也能跑」的鬼话官方文档说 CPU 支持 AVX2 指令集就能跑这话没错但「能跑」和「能用」是两回事。我在一台 i7-10700 32GB 内存的无显卡机器上试过 DeepSeek-R1 7B 的 Q4 量化版推理速度大约 3-5 token/秒问一个问题等半分钟才出第一句话。这个速度做批量离线处理勉强可以做交互式对话就是折磨。推荐配置里写的 RTX 3090 32GB 内存是合理门槛。有 GPU 的情况下7B 模型能跑到 40-60 token/秒14B 模型也有 20-30 token/秒基本达到可用状态。如果你手头是 RTX 4060 8GB 显存跑 7B Q4 量化版没问题但 14B 就吃力了。显存不够时Ollama 会自动把部分层卸载到内存速度会明显下降这是正常现象。注意CUDA 版本必须和 PyTorch 版本匹配否则 Ollama 会静默回退到 CPU 推理。装完驱动后先用nvidia-smi确认 CUDA 版本再决定装哪个版本的推理后端。3. Ollama 部署 DeepSeek从安装到 API 调用的完整链路3.1 安装与版本验证Ollama 的安装是三个工具里最简单的。Linux 下一条命令Windows 和 macOS 直接下载安装包。装完之后第一件事不是急着拉模型而是确认版本和服务状态。# 检查 Ollama 是否安装成功 ollama --version # 预期输出类似ollama version is 0.5.6 # 查看当前已下载的模型列表 ollama list # 启动 Ollama 服务后台运行 ollama serve ollama --version返回版本号说明二进制文件没问题。ollama list在首次安装后是空的这是正常的。ollama serve启动的是 API 服务默认监听 11434 端口后面 Python 调用就是连这个端口。如果你在 Windows 上安装Ollama 会自动注册为系统服务不需要手动执行ollama serve。3.2 拉取模型版本标签决定一切ollama pull deepseek-r1这条命令会拉取默认标签的模型通常是 7B 版本。但如果你想要特定大小的模型必须显式指定标签。# 拉取默认版本通常是 7B ollama pull deepseek-r1 # 拉取 7B 版本适合 16GB 内存 8GB 显存 ollama pull deepseek-r1:7b # 拉取 14B 版本适合 32GB 内存 16GB 显存 ollama pull deepseek-r1:14b # 拉取 32B 版本适合 64GB 内存 24GB 显存 ollama pull deepseek-r1:32b模型标签里的数字代表参数量参数量越大效果越好但对硬件要求也越高。7B 模型文件大约 4-5GB14B 大约 9-10GB32B 大约 20GB。下载时间取决于网络国内拉取速度一般在 5-10MB/s7B 模型大概需要 10-15 分钟。拉取完成后用ollama list确认模型已就位。如果下载中断重新执行ollama pull会断点续传不需要删除重来。3.3 启动服务与 Python 调用模型拉取完成后Ollama 服务已经在运行了。直接用 Python 的 OpenAI SDK 就能调用因为 Ollama 提供了 OpenAI 兼容接口。import openai # 连接到本地 Ollama 服务 client openai.Client( base_urlhttp://localhost:11434/v1, api_keyollama # 本地服务无需真实密钥但必填 ) # 发起对话请求 response client.chat.completions.create( modeldeepseek-r1:7b, # 必须与 ollama list 中的名称一致 messages[ {role: system, content: 你是一个简洁的助手。}, {role: user, content: 用三句话解释什么是注意力机制。} ], temperature0.7, # 0-1越高越有创造力越低越确定 max_tokens512 # 限制回复长度防止无限生成 ) print(response.choices[0].message.content)base_url指向本地 11434 端口api_key填任意字符串即可Ollama 不做鉴权。model参数必须和ollama list里显示的名称完全一致写错会报 404。temperature控制随机性做知识问答建议 0.3-0.5做创意生成可以调到 0.8-1.0。max_tokens建议显式设置否则模型可能生成超长回复导致等待时间过长。如果调用返回连接错误先确认ollama serve是否在运行再检查端口是否被占用。Linux 下用ss -tlnp | grep 11434查看端口状态。4. LM Studio 与 Jan 部署图形界面下的模型管理与服务启动4.1 LM StudioGGUF 与 MLX 格式的选择逻辑LM Studio 的核心优势是模型市场搜索「DeepSeek R1」就能看到各种量化版本。但下载之前要搞清楚格式选择Windows 和 Linux 选 GGUFApple Silicon 的 MacBook 选 MLX。选错格式模型加载会直接失败。下载完成后在「Local Models」里找到模型点击「Load」加载。加载时注意右侧的配置面板GPU Offload 层数建议拉满Context Length 根据内存调整7B 模型建议 409614B 建议 2048。加载成功后进入「Developer」标签页点击「Start Server」服务默认监听 1234 端口。LM Studio 的 API 同样兼容 OpenAI 格式Python 调用只需把base_url改成http://localhost:1234/v1api_key填lm-studio即可。模型名称在「Local Models」列表里可以看到通常是模型文件夹名。4.2 Jan多模态场景下的依赖处理Jan 的安装包不大但首次启动会提示安装额外依赖。在 Windows 上主要是 Visual C 运行库在 Linux 上需要确认libfuse2已安装。如果启动后界面空白大概率是依赖没装全。模型下载走的是 Hugging Face 渠道搜索「unsloth gguf deepseek r1」能找到社区量化版本。点击「Use this model」后选择 Jan模型会自动下载并出现在模型列表中。加载模型后Jan 会自动在 1337 端口启动服务API 格式同样兼容 OpenAI。Jan 的特点是支持多模态输入如果你需要处理图片文本的混合任务Jan 是三个工具里唯一原生支持的。但代价是内存占用更高同样跑 7B 模型Jan 比 Ollama 多占 1-2GB 内存。4.3 三个工具的 API 调用对比工具Base URLAPI Key模型名称来源Ollamahttp://localhost:11434/v1ollamaollama listLM Studiohttp://localhost:1234/v1lm-studioLocal Models 列表Janhttp://localhost:1337/v1jan模型列表三个工具的调用代码结构完全一致只需要改base_url、api_key和model三个参数。这意味着你可以写一套代码通过环境变量切换后端不用为每个工具单独适配。5. 避坑指南本地部署 DeepSeek 的五个血泪教训5.1 模型加载成功但推理极慢现象ollama list显示模型已加载但每次提问要等 30 秒以上才出结果。原因Ollama 默认优先使用 GPU但如果 CUDA 版本不匹配或显存不足会静默回退到 CPU 推理。CPU 推理 7B 模型的速度就是 3-5 token/秒体感极慢。解决执行ollama ps查看模型实际运行在 GPU 还是 CPU 上。如果显示 100% CPU检查nvidia-smi确认驱动正常然后重新安装匹配 CUDA 版本的 Ollama。Linux 下可以用ollama serve启动时加OLLAMA_DEBUG1环境变量查看详细日志。5.2 端口冲突导致服务启动失败现象ollama serve报错「address already in use」或者 Python 调用返回连接拒绝。原因11434 端口被其他进程占用常见于之前启动的 Ollama 实例没有正常退出或者有其他服务占用了同一端口。解决Linux 下用lsof -i :11434找到占用进程并 kill 掉。Windows 下用netstat -ano | findstr 11434找到 PID然后在任务管理器里结束。如果不想杀进程可以设置OLLAMA_HOST0.0.0.0:11435环境变量换一个端口启动。5.3 模型名称写错导致 404现象Python 调用返回model not found错误。原因model参数必须和ollama list里显示的完整名称一致包括标签。比如拉取的是deepseek-r1:7b调用时写deepseek-r1就会报错。解决先执行ollama list复制完整名称再粘贴到代码里。LM Studio 和 Jan 同理模型名称以界面显示为准。5.4 内存不足导致模型加载中断现象拉取模型时进度条卡住或者加载时直接崩溃退出。原因7B 模型 Q4 量化版需要约 5GB 内存加上系统占用和推理时的 KV Cache16GB 内存是底线。如果同时开了浏览器和其他大型应用很容易触发 OOM。解决关闭不必要的应用或者换用更小的量化版本。Ollama 支持deepseek-r1:1.5b这种小模型虽然效果打折扣但 8GB 内存也能跑。LM Studio 下载时选择 Q3 或 Q2 量化级别文件更小内存占用更低。5.5 首次推理等待时间过长现象第一次提问等了很久才出结果后续提问速度正常。原因模型首次加载时需要把权重从磁盘读入内存并初始化推理引擎这个过程通常需要 10-30 秒取决于磁盘速度和模型大小。解决这是正常现象不是故障。如果觉得等待太久可以提前执行一次空推理「预热」模型。Ollama 下用ollama run deepseek-r1:7b hi触发加载之后再通过 API 调用就会很快。6. 进阶技巧用环境变量和批量脚本把本地推理压榨到极致6.1 环境变量调优让 Ollama 更听话Ollama 支持通过环境变量控制运行行为几个关键参数值得调整# 设置模型常驻内存避免反复加载 export OLLAMA_KEEP_ALIVE24h # 限制并行请求数防止内存溢出 export OLLAMA_NUM_PARALLEL2 # 指定 GPU 层数-1 表示全部卸载到 GPU export OLLAMA_GPU_LAYERS-1 # 启动服务 ollama serveOLLAMA_KEEP_ALIVE控制模型在内存中的驻留时间默认 5 分钟。设成 24h 后模型不会自动卸载后续调用零加载延迟代价是内存一直被占用。OLLAMA_NUM_PARALLEL控制并发请求数设太高会导致显存溢出设太低又浪费 GPU 算力一般 2-4 比较合适。OLLAMA_GPU_LAYERS设为 -1 表示所有层都跑在 GPU 上显存不够时可以设成具体数字比如 20 表示前 20 层跑 GPU剩余跑 CPU。6.2 批量推理脚本一次处理多个问题单次调用适合交互场景但如果你要批量处理数据逐条调用效率太低。下面这个脚本用并发方式批量提问速度能提升 3-5 倍import openai from concurrent.futures import ThreadPoolExecutor client openai.Client( base_urlhttp://localhost:11434/v1, api_keyollama ) def ask(question): 单次提问返回模型回复 response client.chat.completions.create( modeldeepseek-r1:7b, messages[{role: user, content: question}], temperature0.3, max_tokens256 ) return response.choices[0].message.content # 待处理的问题列表 questions [ 什么是梯度下降, 解释一下过拟合。, Transformer 和 RNN 的区别是什么, 如何评估一个分类模型, 什么是数据增强 ] # 并发执行最多同时 3 个请求 with ThreadPoolExecutor(max_workers3) as executor: results list(executor.map(ask, questions)) for q, a in zip(questions, results): print(fQ: {q}\nA: {a}\n{-*40})ThreadPoolExecutor的max_workers控制并发数建议不超过OLLAMA_NUM_PARALLEL的值。每个请求的max_tokens设小一点可以加快响应速度批量场景下不需要长篇大论。这个脚本跑 5 个问题大约 15-20 秒比逐条调用快一倍以上。6.3 验证部署是否真正可用部署完成后用下面这个检查清单确认服务状态检查项命令/操作预期结果服务进程ollama ps显示模型名称和运行状态端口监听ss -tlnp | grep 11434显示 LISTEN 状态API 连通curl http://localhost:11434/v1/models返回模型列表 JSON推理测试Python 调用示例返回合理回复GPU 占用nvidia-smi显示 Ollama 进程占用显存这五项全部通过说明部署链路完整可用。如果 API 连通但推理失败重点检查模型名称和max_tokens设置。6.4 我踩过最深的坑别在模型加载时改配置最后说一个我反复翻车的点。Ollama 在模型加载过程中会锁定配置文件如果你在加载时修改环境变量或切换模型会导致服务状态不一致表现为「模型列表里有但调用报错」。从那以后我每次调整配置都先ollama stop停掉所有模型改完环境变量再重新ollama serve这个习惯帮我省了至少十次重启排查的时间。本地部署 DeepSeek 这件事工具选对了能省一半力气参数调对了能再省一半。希望这些实操记录能帮你少走点弯路。本文还有配套的精品资源点击获取