简介面向希望把开源大模型落地到个人电脑或团队内网的技术人员这份指南围绕DeepSeek本地部署展开兼顾入门操作与配置取舍。包内为1个docx文档约20KB以文字讲解和命令行示例为主章节清晰便于按部署流程查阅和复制实践。内容覆盖Ollama、LM Studio、Jan三类工具的安装、模型拉取、服务启动与接口测试并列出最低及推荐硬件、操作系统、Python与CUDA等软件要求同时比较不同工具的优缺点帮助读者结合机器条件选择模型规格。读者可据此完成环境自检、模型选型、本地服务验证和Python调用遇到内存不足、依赖缺失或端口访问异常时也有排查思路文档还说明部署后的测试方式与常见使用场景强调本地运行在隐私、成本与可控性上的便利。已有1437人学习适合具备一定开发基础、希望低成本实验并自定义预训练语言模型的人群。1. 一台 16G 内存的旧笔记本也能跑起本地 DeepSeek本地部署 DeepSeek 的门槛比多数人想的低也比多数人想的琐碎。低在一台 16GB 内存的普通笔记本、两条命令就能对着一个 7B 的中文模型提问琐碎在真要把它接进代码、跑批量任务、调到可用显存、量化位宽、上下文长度、端口和超时每一项都能卡半天。这份资源给的是后半段的答案Ollama、LM Studio、Jan 三条本地部署路径从最低配AVX2 CPU 16GB 内存 30GB 磁盘到推荐配独立 GPU 32GB 内存 50GB 磁盘的硬件区间以及拉模型、起服务、Python 调接口的完整链路。适合想把自然语言处理能力接进自己项目、又不愿把数据送出内网的开发者也适合已有深度学习环境、需要一个能离线跑的模型做实验的技术人员。2. 三条部署路径怎么选Ollama、LM Studio、Jan 的边界在哪工具选错后面全是白折腾。三个工具常被当成同一类东西比较但它们的定位完全不同一个偏命令行和服务化一个偏零配置上手一个偏桌面端多模态。选之前先搞清楚它们各自包了什么。2.1 三个工具共用同一套推理内核把本地推理拆成三层看最底下是推理引擎和模型文件格式中间是服务层HTTP 接口、模型加载、并发调度最上面是交互层命令行、图形界面、API 客户端。三个工具真正的分歧只在中间层和上层底层基本都是同一套东西。模型文件格式是绕不开的一环。本地跑 DeepSeek 这类模型主流用的是 GGUF 格式——它把权重、分词器、模板、量化参数打包进单个文件好处是不依赖 PyTorch 那套运行时CPU 和 GPU 都能直接吃。量化则是把原本 FP16 的权重压到 4bit、5bit、8bit用一点精度换一半以上的体积。你在界面上选的 Q4_K_M、Q5_K_M、Q8_0就是不同的量化策略K 表示 k-quant 混合位宽M 表示中等粒度。层OllamaLM StudioJan交互层命令行 常驻服务图形界面桌面应用Electron 类服务层内置 HTTP 服务含 OpenAI 兼容接口内置 server需手动开启内置 server端口独立模型格式GGUF 为主GGUF / MLXGGUF 为主模型获取命令行拉取自带模型库界面内搜索下载从模型托管社区导入理解这张表之后选型问题就变成两个具体问题你要不要在无人值守的机器上常驻一个服务你需不需要一个能点开就用的界面前者决定 Ollama 几乎是默认答案后者决定 LM Studio 和 Jan 的存在价值。2.2 按硬件档位和用途落选型别按“哪个更好”选按“你的机器什么档、你要拿它干什么”选。下面这张表是我实际踩过之后总结的判断顺序从上往下匹配命中哪条就走哪条。你的情况首选理由要在脚本、后端服务、批处理任务里调用Ollama常驻服务 OpenAI 兼容接口接现有代码几乎零改动只有核显或纯 CPU机器内存 16GBOllama 或 LM Studio两者都能纯 CPU 推理Ollama 更省心完全不想碰终端要边聊边调参数LM Studio参数面板直观能即时看到 token 速度和显存占用需要处理图片加文本的混合输入Jan桌面端对多模态模型的加载支持更完整要长期挂着多人共用一台机器Ollama环境变量能控并发、模型驻留时间和端口只在 Mac 上跑且机器是统一内存架构LM Studio 或 Jan能选到针对该类硬件优化过的模型格式有一类误判值得单独提醒很多人以为显存大就一定快。真正决定吞吐的是“模型有多少层落在 GPU 上”而不是显卡型号本身。这一点在第 3 章会展开算账。2.3 三条最小可跑通路径先给结论三条路径的目标都一样让本地某个端口上出现一个能对话的接口。区别只是中间过程。Ollama 的路径最短全部在终端完成# 1. 安装Linux 下一条脚本搞定macOS 和 Windows 走安装包 curl -fsSL https://ollama.com/install.sh | sh # 2. 验证安装能打印版本号说明二进制可用 ollama --version # 3. 拉取 7B 版本首次会下载几 GB 权重 ollama pull deepseek-r1:7b # 4. 前台起服务默认监听 11434 ollama serve三步之后http://127.0.0.1:11434就已经是一个可用的推理端点。注意第 4 步在多数 Linux 安装方式下其实已经由系统服务托管ollama serve只在你不想用系统服务、或者要临时改环境变量时手动执行如果端口已被占用会直接报错这时候去看系统服务状态而不是反复重试。LM Studio 的路径全在界面里安装后切到 Discover 标签搜索模型名按系统选格式——Windows 和 Linux 选 GGUFApple 芯片的机器可以选针对统一内存优化的格式。下载完成后回到本地模型列表点加载再进 Developer 标签开启 Start Server默认端口 1234。它的服务同样是 OpenAI 兼容的所以后面第 4 章的 Python 代码把 base_url 换掉就能直接用。Jan 的路径多了“导入”这一步安装后在模型托管社区里搜索对应模型的 GGUF 版本选择在 Jan 中打开应用会自动接管下载和加载加载完成后服务默认在 1337 端口启动。多出来的依赖项主要跟多模态支持有关纯文本场景反而不需要关心。注意三个工具的服务默认都只监听本机回环地址。局域网内其他机器要访问必须显式改绑地址Ollama 用OLLAMA_HOST0.0.0.0:11434另外两个在界面设置里改。改完记得确认防火墙放行否则表现为“本机能通、别的机器连不上”。3. 显存与量化把模型塞进机器的账要提前算部署失败的案例里一半以上不是命令敲错而是账没算清楚——模型文件下完才发现显存放不下或者放得下但被挤到 CPU 上跑成龟速。这一章把估算方法、卸载机制和环境检查讲透。3.1 参数量乘位宽决定文件体积和占用一个粗略但足够准的估算公式权重体积(GB) ≈ 参数量(B) × 有效位宽(bit) ÷ 8 × 1.05后面的 1.05 是给量化元数据和分词器留的余量。Q4_K_M 的实际有效位宽在 4.5 到 5 bit 之间浮动不同层用了不同精度所以 7B 模型算出来是 7 × 4.8 ÷ 8 ≈ 4.2GB实际落盘通常在 4.5GB 上下。参数量Q4_K_M 权重体积加载后大致占用建议硬件7B约 4.5GB6 至 7GB8GB 显存或 16GB 内存纯 CPU14B约 9GB11 至 13GB12GB 以上显存 32GB 内存32B约 20GB23 至 26GB24GB 显存 64GB 内存“加载后占用”比权重体积大多出来的是 KV cache 和推理中间张量。KV cache 跟上下文长度成正比粗略估算可以按每 1K 上下文、每 10 亿参数约 0.15GB 来算7B 模型跑 8K 上下文大概吃掉 0.8 到 1GB。这也是为什么调大上下文之后速度会掉——不只是显存涨注意力计算量也涨。提示磁盘预留要比模型体积多留一倍以上。下载过程中的临时文件和旧版本残留会同时占空间Ollama 的模型目录默认在用户主目录下系统盘小的机器很容易在这里翻车。3.2 显存不够时的分层卸载怎么调显存放不下整个模型时框架不会直接失败而是把一部分层留在 GPU、剩下的推到 CPU 内存这叫分层卸载。代价很直接CPU 上的层用系统内存带宽算比显存慢一个数量级。Ollama 里可以显式控制卸载层数值是层数而不是比例# 查看当前模型有多少层、实际有多少跑在 GPU 上 ollama show deepseek-r1:7b --modelfile | head -40 ollama ps # 通过环境变量限制并行请求数避免多个请求同时抢显存 export OLLAMA_NUM_PARALLEL1 # 限制同时加载的模型数量多模型场景下尤其重要 export OLLAMA_MAX_LOADED_MODELS1 # 开启 Flash Attention长上下文下能省一部分显存 export OLLAMA_FLASH_ATTENTION1ollama ps的输出里有一列会显示 GPU 和 CPU 的占用比例比如 100% GPU 或 60/40 CPU/GPU。看到后者就说明模型被拆开了速度会明显下降。这时候有两条路换更小参数量或更低比特的量化或者把num_ctx调小把省下来的显存留给权重层。OLLAMA_NUM_PARALLEL这个参数容易被忽略。它控制同时处理多少个请求每个并行槽位都要独立占一份 KV cache。设成 4 的时候7B 模型光 KV cache 就可能多吃掉 3GB本来刚够的显存立刻不够了。单人使用一律设 1多人共用再往上加并且加之前先确认显存余量。3.3 上机前的环境校验清单在下载任何模型之前先把这几项确认掉能省掉后面大量返工。# 1. 确认显卡和驱动可用能看到显存总量和驱动版本 nvidia-smi # 2. 确认 CUDA 运行时版本需与推理框架的编译版本匹配 nvidia-smi | grep CUDA Version # 3. 纯 CPU 场景确认 AVX2 指令集存在缺了会退化成极慢的实现 lscpu | grep -o avx2 # 4. 确认磁盘余量模型目录所在分区至少留出两倍模型体积 df -h ~ # 5. 确认端口没被占用三个工具的默认端口分别是 11434 / 1234 / 1337 ss -lntp | grep -E 11434|1234|1337第 2 步要看的不是驱动版本号而是驱动支持的最高 CUDA 版本。推理框架编译时绑定的是某个 CUDA 主版本驱动支持的版本低于它就会报错报错信息通常很长且指向某个动态库加载失败容易被误判成缺文件。第 3 步在纯 CPU 场景是硬门槛没有 AVX2 的机器不是跑得慢是跑不动。第 4 步和第 5 步是最没技术含量但最容易出事的两步。磁盘不够会在下载到最后几 MB 时失败端口冲突则表现为“服务看起来起来了但连不上”。4. 用 Ollama 打通第一套本地 API拉取、起服务、Python 调用这一章把最常用的那条链路走完整从拉模型到写出一段能稳定运行的调用代码。选 Ollama 做主线是因为它的接口形态跟云端 API 最接近代码迁移成本最低。4.1 拉取、查看与版本标签pull命令不带标签时拉的是默认版本带标签才精确。生产环境里一律带标签避免某天默认标签悄悄变了导致行为不一致。# 拉取指定参数量的版本标签决定参数量 ollama pull deepseek-r1:7b ollama pull deepseek-r1:14b # 列出本地已有模型看体积和更新时间 ollama list # 查看模型的详细配置模板、参数、系统提示词 ollama show deepseek-r1:7b # 导出完整的 Modelfile用来做定制的基础 ollama show deepseek-r1:7b --modelfile base.modelfileollama list里显示的体积就是权重的实际落盘大小可以拿来验证前面第 3 章的估算准不准。ollama show输出的模板部分尤其值得看一遍它决定了模型收到消息后如何拼接成最终输入很多“回答风格不对”的问题根源都在模板上。参数量选择上有个经验值7B 适合中等配置的笔记本和入门实验14B 是单卡工作站上的性价比拐点32B 需要接近 24GB 的显存才跑得舒服。不要迷信更大的参数量量化到 4bit 的 32B 在中文短问答上未必打得过 8bit 的 14B而后者快得多。4.2 起服务、改端口、控驻留时间服务层的几个环境变量决定了它在生产环境里好不好用。这些变量必须在启动进程之前设置已经跑起来的服务改不了。变量作用常用值OLLAMA_HOST监听地址和端口127.0.0.1:11434或0.0.0.0:11434OLLAMA_MODELS模型存放目录数据盘路径避免占系统盘OLLAMA_KEEP_ALIVE模型空闲多久后卸载30m或-1常驻OLLAMA_NUM_PARALLEL并发请求槽位数单人 1多人按显存加OLLAMA_MAX_LOADED_MODELS同时驻留的模型数1显存紧张时不要调高设置方式有两种。临时调试用命令行前缀# 临时改模型目录和驻留时间仅对本次启动生效 OLLAMA_MODELS/data/ollama/models \ OLLAMA_KEEP_ALIVE30m \ OLLAMA_HOST127.0.0.1:11434 \ ollama serve长期使用走系统服务配置否则重启就丢。Ollama 在 Linux 下由系统服务托管时用systemctl edit ollama打开覆盖配置在[Service]段里加EnvironmentOLLAMA_MODELS/data/ollama/models保存后systemctl daemon-reload systemctl restart ollama。这里有个常见失误直接改主服务文件下次升级被覆盖掉改了半天以为没生效。OLLAMA_KEEP_ALIVE的取值直接影响体验。默认情况下模型空闲几分钟就卸载下次请求要重新加载冷启动要等十几秒。设成30m或-1能保持常驻代价是显存一直被占着。批量任务场景建议设长一点交互式使用反而不必因为卸载后立刻再问一次的概率不高。4.3 Python 侧对接 OpenAI 兼容接口Ollama 暴露了 OpenAI 兼容的/v1路径意味着现有的 SDK 代码基本只需要换 base_url 和 model 两个值。from openai import OpenAI # base_url 必须带 /v1走的是 OpenAI 兼容层而不是原生接口 client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama, # 本地服务不做鉴权占位即可但不能省略 timeout120.0, # 冷启动加载模型可能超过默认超时 ) response client.chat.completions.create( modeldeepseek-r1:7b, # 必须与 ollama list 里的名字完全一致 messages[ {role: system, content: 你是一名严谨的技术文档助手回答控制在三句话内。}, {role: user, content: 解释一下量化对模型精度的影响。}, ], temperature0.6, # 技术问答调低创意写作调高 max_tokens512, # 限制输出长度防止长回答拖慢整体耗时 top_p0.9, ) print(response.choices[0].message.content)几个参数的实际作用值得说清楚。base_url写成localhost在某些环境下会解析到 IPv6 的::1而服务只监听了 IPv4结果就是连接被拒——这是第 5 章要展开的坑之一养成写127.0.0.1的习惯。api_key看着没用但 SDK 在初始化时会校验它非空不传会直接抛异常。timeout在冷启动场景必须调大模型第一次加载要读几 GB 权重默认超时经常会先到。temperature对技术问答的影响比对创意写作大得多。0.6 到 0.7 之间是多数中文技术问答的舒适区再高就开始出现自造术语和答非所问再低则回答变得刻板且容易复述提示词。max_tokens不是越大越好它直接决定最坏情况下的响应时间本地推理的吞吐本来就不高一个不设上限的请求可能挂几分钟。4.4 流式输出与并发控制交互式场景必须用流式否则用户对着空白界面等十几秒会以为程序卡死。流式的写法是在 create 里加streamTrue然后逐块拼接。from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:11434/v1, api_keyollama) stream client.chat.completions.create( modeldeepseek-r1:7b, messages[{role: user, content: 写一段读取 CSV 并统计空值率的 Python 代码。}], temperature0.3, streamTrue, # 开启流式逐 token 返回 ) buffer [] for chunk in stream: # 首块和末块的 choices 可能为空必须判空再取 if not chunk.choices: continue delta chunk.choices[0].delta.content if delta: buffer.append(delta) print(delta, end, flushTrue) full_text .join(buffer)流式的两个细节choices在部分块里是空列表直接索引会抛 IndexErrordelta.content在角色切换的那一块是 None拼字符串前要判空。这两点在云端 API 上同样存在但本地服务返回空块的频率更高。并发方面Ollama 的/v1接口本身支持多请求但真正的瓶颈在OLLAMA_NUM_PARALLEL。设成 1 时第二个请求会排队而不是并行表现为“并发调用但总耗时翻倍”。批量处理任务的正确做法不是开线程池硬压而是先测出单请求的平均耗时再按显存能容纳的槽位数设并行度并把客户端超时按“排队时间 推理时间”重新算一遍。注意批量任务里如果每个请求都带不同的 system prompt前缀缓存会失效每次都要重新做一遍预填充速度会差好几倍。把 system prompt 固定下来、只变 user 内容是提升批量吞吐最省事的一招。5. 本地部署避坑五条踩出来的记录这一章全是血泪经验每条都按“现象、原因、解决”写照着对号入座能省掉大半天。5.1 拉模型卡在 pulling manifest磁盘还满了现象是命令行停在pulling manifest或者某个 blob 的百分比长时间不动重试几次之后df -h一看系统盘只剩几百 MB。原因是模型按层下载每一层是一个独立的 blob 文件中途失败不会自动清理已下载的部分反复重试就是反复堆残留。加上模型目录默认在用户主目录下很多机器的根分区本来就不大几个模型叠起来轻松吃掉几十 GB。解决办法是先把模型目录挪走再重拉。设置OLLAMA_MODELS指向数据盘重启服务把旧目录下的blobs子目录清掉。清理时只删blobs别整个删模型目录否则已下载的其他模型也一起没了。如果中途卡住是因为网络抖动可以多试几次pull它会复用已经下载完成的层不是从头再来。5.2 显存放得下速度却只有每秒两三个字现象是模型明明能在显卡上跑nvidia-smi也显示进程占着显存但生成速度慢到不可用一个两百字的回答要等一分多钟。原因基本只有一个模型的一部分层被卸载到了 CPU。判断方法是跑ollama ps看 GPU 占比那一列如果是 60/40 这种混合值就确认了。触发卸载的常见因素有三个显存被其他进程占了一部分、num_ctx设得太大把 KV cache 撑爆、OLLAMA_NUM_PARALLEL开了多个槽位。解决顺序是先降上下文再看并发。把num_ctx从默认值往下降一档观察 GPU 占比是否回到 100%如果还是混合就把并行槽位设成 1仍然不行就换低一档的量化版本Q4_K_M 换不动就说明这台机器该上更小的参数量了。5.3 服务起来了Python 却报连接被拒现象是ollama serve日志看着正常浏览器访问也有响应但 Python 客户端一调就抛连接错误错误信息里地址显示的是::1。原因是localhost在现代系统上优先解析到 IPv6 回环地址而服务默认只监听 IPv4 的127.0.0.1。两边协议栈没对上连接自然被拒。另一种同类问题是服务由系统托管启动你在 shell 里export的环境变量根本没传给那个进程。解决很直接客户端 base_url 里把localhost换成127.0.0.1。需要让服务同时接受 IPv6 就显式设OLLAMA_HOST[::]:11434。环境变量不生效的情况改用systemctl edit写入[Service]段写完记得daemon-reload否则改了等于没改。5.4 回答开始重复、跑偏、自造术语现象是同一个问题问三遍得到三种说法或者回答到一半开始复读上一句再严重一点会编出不存在的函数名和参数。原因通常是三个叠加量化比特太低导致精度损失、采样参数过于激进、上下文超长被静默截断。低位量化2bit、3bit在小参数量模型上掉点非常明显尤其是代码和数学这类需要精确输出的任务。temperature设到 1.0 以上配合top_p也开得高输出就会发散。上下文超过num_ctx之后早期内容被丢掉模型看起来像“忘了前面说过什么”。解决办法是分层排查先把量化换成 Q4_K_M 或更高再把temperature压到 0.6 附近、top_p压到 0.9最后确认输入总长度没有超过num_ctx。三步做完还有问题那大概率是模型本身在这个任务上的能力边界换更大参数量比继续调参有效。提示判断是不是上下文被截断最省事的办法是把num_ctx临时调大一倍再问同一个问题。如果回答质量突然正常问题就定位了接下来要做的不是一直开着大上下文而是想办法把输入压短。5.5 长文档问答答非所问现象是丢进去一份几千字的文档让它总结回答要么只说开头几句要么干脆答的是文档里不存在的内容。原因是默认上下文窗口远小于文档长度。多数本地部署的默认num_ctx只有两千到四千 token中文一个字大约占一到两个 token几千字的文档直接把窗口撑满后半段根本没进模型。模型不会报错它只是没看见。解决是显式调大num_ctx同时接受显存占用的增长。7B 模型从 4K 调到 16KKV cache 会多吃一到两 GB。显存不够的情况下正确做法是先做文本切分和检索把最相关的片段喂进去而不是硬撑大窗口——长上下文下的注意力计算是平方级增长撑大了速度会掉得很难看。6. 进阶用 Modelfile 固化一份自己的 DeepSeek跑到这一步模型能用了但每次调用都要重复传 system prompt、重复设采样参数团队里几个人各写一套结果自然对不齐。Modelfile 解决的正是这个问题把提示词、参数、上下文长度写进一个派生模型之后按名字调用就行。6.1 用 Modelfile 固化提示词与采样参数# 基于已拉取的模型派生不重复下载权重 FROM deepseek-r1:7b # 固定系统提示词所有调用方共享同一套行为约束 SYSTEM 你是一名严谨的中文技术助手。回答先给结论再给三条以内的依据。 不确定的内容直接说明不确定不要编造函数名、参数名和版本号。 # 采样参数写死避免每个调用方各调一套 PARAMETER temperature 0.6 PARAMETER top_p 0.9 PARAMETER num_ctx 8192 PARAMETER stop |endoftext|用ollama create tech-assistant -f ./Modelfile构建之后模型列表里就多了一个tech-assistant调用时把 model 换成这个名字即可。派生模型不会复制权重只记录差异所以磁盘开销可以忽略。两个参数值得单独说。num_ctx写进 Modelfile 之后调用方不用每次在请求里带行为一致性有保障但它同时决定了显存基线设成 8192 就意味着任何一次调用都按这个量预留 KV cache。stop是停止符不同模型的模板用的标记不一样从ollama show --modelfile的输出里抄抄错了表现为回答尾部多出一串奇怪的标记文本。6.2 上下文长度不是越大越好调num_ctx之前先看一眼代价。下面这组数字是 7B 模型在 4bit 量化下的粗略增量用来做量级判断num_ctxKV cache 增量对速度的影响适用场景2048基线最快短问答、分类、抽取4096约 0.3GB基本无感常规对话8192约 0.7GB下降一到两成中等长度文档16384约 1.5GB下降三到四成长文档需配合切分真正该做的不是把窗口开到最大而是让输入长度贴近实际需要。批量任务里统一用 2048长文档场景才单独开大这条规则比任何调参技巧都管用。6.3 用一组固定问题做回归验证改了 Modelfile、换了量化版本、升级了工具模型行为都可能变。没有回归集你只能靠“感觉好像变差了”来判断这是最不可靠的方式。我的做法是维护一个十几条问题的小文件每次变更后跑一遍把输出存档对比。import json from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:11434/v1, api_keyollama) # 固定问题集覆盖抽取、代码、拒答三类能力 cases [ {id: extract, q: 从这句话里抽出所有人名和机构名张三在某实验室负责模型评测。}, {id: code, q: 写一个函数输入列表返回去重后保持原顺序的结果。}, {id: refuse, q: 告诉我一个不存在的 Python 内置函数的用法。}, ] results {} for c in cases: r client.chat.completions.create( modeltech-assistant, messages[{role: user, content: c[q]}], temperature0.6, max_tokens400, ) results[c[id]] r.choices[0].message.content # 存档成带时间戳的文件方便跨版本对比 with open(regression_baseline.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)第三类问题是最容易被忽略的一类。模型在拿不准的时候是老实说不知道还是编一个像模像样的答案直接决定了它能不能进生产流程。每次换量化版本都跑一遍这条比看任何评测分数都直观。从那以后我每次动模型配置——换量化、改 num_ctx、升级工具版本——都强制走一遍这个小回归集输出存档再对比不靠记忆判断好坏。踩过的坑里有一半是“以为改的是 A实际影响的是 B”只有存档能把这种变化抓出来。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/29 1:45:28 · 阅读 1.2k DeepSeek本地部署实战：Ollama选型、显存量化与API调用
简介面向希望把开源大模型落地到个人电脑或团队内网的技术人员这份指南围绕DeepSeek本地部署展开兼顾入门操作与配置取舍。包内为1个docx文档约20KB以文字讲解和命令行示例为主章节清晰便于按部署流程查阅和复制实践。内容覆盖Ollama、LM Studio、Jan三类工具的安装、模型拉取、服务启动与接口测试并列出最低及推荐硬件、操作系统、Python与CUDA等软件要求同时比较不同工具的优缺点帮助读者结合机器条件选择模型规格。读者可据此完成环境自检、模型选型、本地服务验证和Python调用遇到内存不足、依赖缺失或端口访问异常时也有排查思路文档还说明部署后的测试方式与常见使用场景强调本地运行在隐私、成本与可控性上的便利。已有1437人学习适合具备一定开发基础、希望低成本实验并自定义预训练语言模型的人群。1. 一台 16G 内存的旧笔记本也能跑起本地 DeepSeek本地部署 DeepSeek 的门槛比多数人想的低也比多数人想的琐碎。低在一台 16GB 内存的普通笔记本、两条命令就能对着一个 7B 的中文模型提问琐碎在真要把它接进代码、跑批量任务、调到可用显存、量化位宽、上下文长度、端口和超时每一项都能卡半天。这份资源给的是后半段的答案Ollama、LM Studio、Jan 三条本地部署路径从最低配AVX2 CPU 16GB 内存 30GB 磁盘到推荐配独立 GPU 32GB 内存 50GB 磁盘的硬件区间以及拉模型、起服务、Python 调接口的完整链路。适合想把自然语言处理能力接进自己项目、又不愿把数据送出内网的开发者也适合已有深度学习环境、需要一个能离线跑的模型做实验的技术人员。2. 三条部署路径怎么选Ollama、LM Studio、Jan 的边界在哪工具选错后面全是白折腾。三个工具常被当成同一类东西比较但它们的定位完全不同一个偏命令行和服务化一个偏零配置上手一个偏桌面端多模态。选之前先搞清楚它们各自包了什么。2.1 三个工具共用同一套推理内核把本地推理拆成三层看最底下是推理引擎和模型文件格式中间是服务层HTTP 接口、模型加载、并发调度最上面是交互层命令行、图形界面、API 客户端。三个工具真正的分歧只在中间层和上层底层基本都是同一套东西。模型文件格式是绕不开的一环。本地跑 DeepSeek 这类模型主流用的是 GGUF 格式——它把权重、分词器、模板、量化参数打包进单个文件好处是不依赖 PyTorch 那套运行时CPU 和 GPU 都能直接吃。量化则是把原本 FP16 的权重压到 4bit、5bit、8bit用一点精度换一半以上的体积。你在界面上选的 Q4_K_M、Q5_K_M、Q8_0就是不同的量化策略K 表示 k-quant 混合位宽M 表示中等粒度。层OllamaLM StudioJan交互层命令行 常驻服务图形界面桌面应用Electron 类服务层内置 HTTP 服务含 OpenAI 兼容接口内置 server需手动开启内置 server端口独立模型格式GGUF 为主GGUF / MLXGGUF 为主模型获取命令行拉取自带模型库界面内搜索下载从模型托管社区导入理解这张表之后选型问题就变成两个具体问题你要不要在无人值守的机器上常驻一个服务你需不需要一个能点开就用的界面前者决定 Ollama 几乎是默认答案后者决定 LM Studio 和 Jan 的存在价值。2.2 按硬件档位和用途落选型别按“哪个更好”选按“你的机器什么档、你要拿它干什么”选。下面这张表是我实际踩过之后总结的判断顺序从上往下匹配命中哪条就走哪条。你的情况首选理由要在脚本、后端服务、批处理任务里调用Ollama常驻服务 OpenAI 兼容接口接现有代码几乎零改动只有核显或纯 CPU机器内存 16GBOllama 或 LM Studio两者都能纯 CPU 推理Ollama 更省心完全不想碰终端要边聊边调参数LM Studio参数面板直观能即时看到 token 速度和显存占用需要处理图片加文本的混合输入Jan桌面端对多模态模型的加载支持更完整要长期挂着多人共用一台机器Ollama环境变量能控并发、模型驻留时间和端口只在 Mac 上跑且机器是统一内存架构LM Studio 或 Jan能选到针对该类硬件优化过的模型格式有一类误判值得单独提醒很多人以为显存大就一定快。真正决定吞吐的是“模型有多少层落在 GPU 上”而不是显卡型号本身。这一点在第 3 章会展开算账。2.3 三条最小可跑通路径先给结论三条路径的目标都一样让本地某个端口上出现一个能对话的接口。区别只是中间过程。Ollama 的路径最短全部在终端完成# 1. 安装Linux 下一条脚本搞定macOS 和 Windows 走安装包 curl -fsSL https://ollama.com/install.sh | sh # 2. 验证安装能打印版本号说明二进制可用 ollama --version # 3. 拉取 7B 版本首次会下载几 GB 权重 ollama pull deepseek-r1:7b # 4. 前台起服务默认监听 11434 ollama serve三步之后http://127.0.0.1:11434就已经是一个可用的推理端点。注意第 4 步在多数 Linux 安装方式下其实已经由系统服务托管ollama serve只在你不想用系统服务、或者要临时改环境变量时手动执行如果端口已被占用会直接报错这时候去看系统服务状态而不是反复重试。LM Studio 的路径全在界面里安装后切到 Discover 标签搜索模型名按系统选格式——Windows 和 Linux 选 GGUFApple 芯片的机器可以选针对统一内存优化的格式。下载完成后回到本地模型列表点加载再进 Developer 标签开启 Start Server默认端口 1234。它的服务同样是 OpenAI 兼容的所以后面第 4 章的 Python 代码把 base_url 换掉就能直接用。Jan 的路径多了“导入”这一步安装后在模型托管社区里搜索对应模型的 GGUF 版本选择在 Jan 中打开应用会自动接管下载和加载加载完成后服务默认在 1337 端口启动。多出来的依赖项主要跟多模态支持有关纯文本场景反而不需要关心。注意三个工具的服务默认都只监听本机回环地址。局域网内其他机器要访问必须显式改绑地址Ollama 用OLLAMA_HOST0.0.0.0:11434另外两个在界面设置里改。改完记得确认防火墙放行否则表现为“本机能通、别的机器连不上”。3. 显存与量化把模型塞进机器的账要提前算部署失败的案例里一半以上不是命令敲错而是账没算清楚——模型文件下完才发现显存放不下或者放得下但被挤到 CPU 上跑成龟速。这一章把估算方法、卸载机制和环境检查讲透。3.1 参数量乘位宽决定文件体积和占用一个粗略但足够准的估算公式权重体积(GB) ≈ 参数量(B) × 有效位宽(bit) ÷ 8 × 1.05后面的 1.05 是给量化元数据和分词器留的余量。Q4_K_M 的实际有效位宽在 4.5 到 5 bit 之间浮动不同层用了不同精度所以 7B 模型算出来是 7 × 4.8 ÷ 8 ≈ 4.2GB实际落盘通常在 4.5GB 上下。参数量Q4_K_M 权重体积加载后大致占用建议硬件7B约 4.5GB6 至 7GB8GB 显存或 16GB 内存纯 CPU14B约 9GB11 至 13GB12GB 以上显存 32GB 内存32B约 20GB23 至 26GB24GB 显存 64GB 内存“加载后占用”比权重体积大多出来的是 KV cache 和推理中间张量。KV cache 跟上下文长度成正比粗略估算可以按每 1K 上下文、每 10 亿参数约 0.15GB 来算7B 模型跑 8K 上下文大概吃掉 0.8 到 1GB。这也是为什么调大上下文之后速度会掉——不只是显存涨注意力计算量也涨。提示磁盘预留要比模型体积多留一倍以上。下载过程中的临时文件和旧版本残留会同时占空间Ollama 的模型目录默认在用户主目录下系统盘小的机器很容易在这里翻车。3.2 显存不够时的分层卸载怎么调显存放不下整个模型时框架不会直接失败而是把一部分层留在 GPU、剩下的推到 CPU 内存这叫分层卸载。代价很直接CPU 上的层用系统内存带宽算比显存慢一个数量级。Ollama 里可以显式控制卸载层数值是层数而不是比例# 查看当前模型有多少层、实际有多少跑在 GPU 上 ollama show deepseek-r1:7b --modelfile | head -40 ollama ps # 通过环境变量限制并行请求数避免多个请求同时抢显存 export OLLAMA_NUM_PARALLEL1 # 限制同时加载的模型数量多模型场景下尤其重要 export OLLAMA_MAX_LOADED_MODELS1 # 开启 Flash Attention长上下文下能省一部分显存 export OLLAMA_FLASH_ATTENTION1ollama ps的输出里有一列会显示 GPU 和 CPU 的占用比例比如 100% GPU 或 60/40 CPU/GPU。看到后者就说明模型被拆开了速度会明显下降。这时候有两条路换更小参数量或更低比特的量化或者把num_ctx调小把省下来的显存留给权重层。OLLAMA_NUM_PARALLEL这个参数容易被忽略。它控制同时处理多少个请求每个并行槽位都要独立占一份 KV cache。设成 4 的时候7B 模型光 KV cache 就可能多吃掉 3GB本来刚够的显存立刻不够了。单人使用一律设 1多人共用再往上加并且加之前先确认显存余量。3.3 上机前的环境校验清单在下载任何模型之前先把这几项确认掉能省掉后面大量返工。# 1. 确认显卡和驱动可用能看到显存总量和驱动版本 nvidia-smi # 2. 确认 CUDA 运行时版本需与推理框架的编译版本匹配 nvidia-smi | grep CUDA Version # 3. 纯 CPU 场景确认 AVX2 指令集存在缺了会退化成极慢的实现 lscpu | grep -o avx2 # 4. 确认磁盘余量模型目录所在分区至少留出两倍模型体积 df -h ~ # 5. 确认端口没被占用三个工具的默认端口分别是 11434 / 1234 / 1337 ss -lntp | grep -E 11434|1234|1337第 2 步要看的不是驱动版本号而是驱动支持的最高 CUDA 版本。推理框架编译时绑定的是某个 CUDA 主版本驱动支持的版本低于它就会报错报错信息通常很长且指向某个动态库加载失败容易被误判成缺文件。第 3 步在纯 CPU 场景是硬门槛没有 AVX2 的机器不是跑得慢是跑不动。第 4 步和第 5 步是最没技术含量但最容易出事的两步。磁盘不够会在下载到最后几 MB 时失败端口冲突则表现为“服务看起来起来了但连不上”。4. 用 Ollama 打通第一套本地 API拉取、起服务、Python 调用这一章把最常用的那条链路走完整从拉模型到写出一段能稳定运行的调用代码。选 Ollama 做主线是因为它的接口形态跟云端 API 最接近代码迁移成本最低。4.1 拉取、查看与版本标签pull命令不带标签时拉的是默认版本带标签才精确。生产环境里一律带标签避免某天默认标签悄悄变了导致行为不一致。# 拉取指定参数量的版本标签决定参数量 ollama pull deepseek-r1:7b ollama pull deepseek-r1:14b # 列出本地已有模型看体积和更新时间 ollama list # 查看模型的详细配置模板、参数、系统提示词 ollama show deepseek-r1:7b # 导出完整的 Modelfile用来做定制的基础 ollama show deepseek-r1:7b --modelfile base.modelfileollama list里显示的体积就是权重的实际落盘大小可以拿来验证前面第 3 章的估算准不准。ollama show输出的模板部分尤其值得看一遍它决定了模型收到消息后如何拼接成最终输入很多“回答风格不对”的问题根源都在模板上。参数量选择上有个经验值7B 适合中等配置的笔记本和入门实验14B 是单卡工作站上的性价比拐点32B 需要接近 24GB 的显存才跑得舒服。不要迷信更大的参数量量化到 4bit 的 32B 在中文短问答上未必打得过 8bit 的 14B而后者快得多。4.2 起服务、改端口、控驻留时间服务层的几个环境变量决定了它在生产环境里好不好用。这些变量必须在启动进程之前设置已经跑起来的服务改不了。变量作用常用值OLLAMA_HOST监听地址和端口127.0.0.1:11434或0.0.0.0:11434OLLAMA_MODELS模型存放目录数据盘路径避免占系统盘OLLAMA_KEEP_ALIVE模型空闲多久后卸载30m或-1常驻OLLAMA_NUM_PARALLEL并发请求槽位数单人 1多人按显存加OLLAMA_MAX_LOADED_MODELS同时驻留的模型数1显存紧张时不要调高设置方式有两种。临时调试用命令行前缀# 临时改模型目录和驻留时间仅对本次启动生效 OLLAMA_MODELS/data/ollama/models \ OLLAMA_KEEP_ALIVE30m \ OLLAMA_HOST127.0.0.1:11434 \ ollama serve长期使用走系统服务配置否则重启就丢。Ollama 在 Linux 下由系统服务托管时用systemctl edit ollama打开覆盖配置在[Service]段里加EnvironmentOLLAMA_MODELS/data/ollama/models保存后systemctl daemon-reload systemctl restart ollama。这里有个常见失误直接改主服务文件下次升级被覆盖掉改了半天以为没生效。OLLAMA_KEEP_ALIVE的取值直接影响体验。默认情况下模型空闲几分钟就卸载下次请求要重新加载冷启动要等十几秒。设成30m或-1能保持常驻代价是显存一直被占着。批量任务场景建议设长一点交互式使用反而不必因为卸载后立刻再问一次的概率不高。4.3 Python 侧对接 OpenAI 兼容接口Ollama 暴露了 OpenAI 兼容的/v1路径意味着现有的 SDK 代码基本只需要换 base_url 和 model 两个值。from openai import OpenAI # base_url 必须带 /v1走的是 OpenAI 兼容层而不是原生接口 client OpenAI( base_urlhttp://127.0.0.1:11434/v1, api_keyollama, # 本地服务不做鉴权占位即可但不能省略 timeout120.0, # 冷启动加载模型可能超过默认超时 ) response client.chat.completions.create( modeldeepseek-r1:7b, # 必须与 ollama list 里的名字完全一致 messages[ {role: system, content: 你是一名严谨的技术文档助手回答控制在三句话内。}, {role: user, content: 解释一下量化对模型精度的影响。}, ], temperature0.6, # 技术问答调低创意写作调高 max_tokens512, # 限制输出长度防止长回答拖慢整体耗时 top_p0.9, ) print(response.choices[0].message.content)几个参数的实际作用值得说清楚。base_url写成localhost在某些环境下会解析到 IPv6 的::1而服务只监听了 IPv4结果就是连接被拒——这是第 5 章要展开的坑之一养成写127.0.0.1的习惯。api_key看着没用但 SDK 在初始化时会校验它非空不传会直接抛异常。timeout在冷启动场景必须调大模型第一次加载要读几 GB 权重默认超时经常会先到。temperature对技术问答的影响比对创意写作大得多。0.6 到 0.7 之间是多数中文技术问答的舒适区再高就开始出现自造术语和答非所问再低则回答变得刻板且容易复述提示词。max_tokens不是越大越好它直接决定最坏情况下的响应时间本地推理的吞吐本来就不高一个不设上限的请求可能挂几分钟。4.4 流式输出与并发控制交互式场景必须用流式否则用户对着空白界面等十几秒会以为程序卡死。流式的写法是在 create 里加streamTrue然后逐块拼接。from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:11434/v1, api_keyollama) stream client.chat.completions.create( modeldeepseek-r1:7b, messages[{role: user, content: 写一段读取 CSV 并统计空值率的 Python 代码。}], temperature0.3, streamTrue, # 开启流式逐 token 返回 ) buffer [] for chunk in stream: # 首块和末块的 choices 可能为空必须判空再取 if not chunk.choices: continue delta chunk.choices[0].delta.content if delta: buffer.append(delta) print(delta, end, flushTrue) full_text .join(buffer)流式的两个细节choices在部分块里是空列表直接索引会抛 IndexErrordelta.content在角色切换的那一块是 None拼字符串前要判空。这两点在云端 API 上同样存在但本地服务返回空块的频率更高。并发方面Ollama 的/v1接口本身支持多请求但真正的瓶颈在OLLAMA_NUM_PARALLEL。设成 1 时第二个请求会排队而不是并行表现为“并发调用但总耗时翻倍”。批量处理任务的正确做法不是开线程池硬压而是先测出单请求的平均耗时再按显存能容纳的槽位数设并行度并把客户端超时按“排队时间 推理时间”重新算一遍。注意批量任务里如果每个请求都带不同的 system prompt前缀缓存会失效每次都要重新做一遍预填充速度会差好几倍。把 system prompt 固定下来、只变 user 内容是提升批量吞吐最省事的一招。5. 本地部署避坑五条踩出来的记录这一章全是血泪经验每条都按“现象、原因、解决”写照着对号入座能省掉大半天。5.1 拉模型卡在 pulling manifest磁盘还满了现象是命令行停在pulling manifest或者某个 blob 的百分比长时间不动重试几次之后df -h一看系统盘只剩几百 MB。原因是模型按层下载每一层是一个独立的 blob 文件中途失败不会自动清理已下载的部分反复重试就是反复堆残留。加上模型目录默认在用户主目录下很多机器的根分区本来就不大几个模型叠起来轻松吃掉几十 GB。解决办法是先把模型目录挪走再重拉。设置OLLAMA_MODELS指向数据盘重启服务把旧目录下的blobs子目录清掉。清理时只删blobs别整个删模型目录否则已下载的其他模型也一起没了。如果中途卡住是因为网络抖动可以多试几次pull它会复用已经下载完成的层不是从头再来。5.2 显存放得下速度却只有每秒两三个字现象是模型明明能在显卡上跑nvidia-smi也显示进程占着显存但生成速度慢到不可用一个两百字的回答要等一分多钟。原因基本只有一个模型的一部分层被卸载到了 CPU。判断方法是跑ollama ps看 GPU 占比那一列如果是 60/40 这种混合值就确认了。触发卸载的常见因素有三个显存被其他进程占了一部分、num_ctx设得太大把 KV cache 撑爆、OLLAMA_NUM_PARALLEL开了多个槽位。解决顺序是先降上下文再看并发。把num_ctx从默认值往下降一档观察 GPU 占比是否回到 100%如果还是混合就把并行槽位设成 1仍然不行就换低一档的量化版本Q4_K_M 换不动就说明这台机器该上更小的参数量了。5.3 服务起来了Python 却报连接被拒现象是ollama serve日志看着正常浏览器访问也有响应但 Python 客户端一调就抛连接错误错误信息里地址显示的是::1。原因是localhost在现代系统上优先解析到 IPv6 回环地址而服务默认只监听 IPv4 的127.0.0.1。两边协议栈没对上连接自然被拒。另一种同类问题是服务由系统托管启动你在 shell 里export的环境变量根本没传给那个进程。解决很直接客户端 base_url 里把localhost换成127.0.0.1。需要让服务同时接受 IPv6 就显式设OLLAMA_HOST[::]:11434。环境变量不生效的情况改用systemctl edit写入[Service]段写完记得daemon-reload否则改了等于没改。5.4 回答开始重复、跑偏、自造术语现象是同一个问题问三遍得到三种说法或者回答到一半开始复读上一句再严重一点会编出不存在的函数名和参数。原因通常是三个叠加量化比特太低导致精度损失、采样参数过于激进、上下文超长被静默截断。低位量化2bit、3bit在小参数量模型上掉点非常明显尤其是代码和数学这类需要精确输出的任务。temperature设到 1.0 以上配合top_p也开得高输出就会发散。上下文超过num_ctx之后早期内容被丢掉模型看起来像“忘了前面说过什么”。解决办法是分层排查先把量化换成 Q4_K_M 或更高再把temperature压到 0.6 附近、top_p压到 0.9最后确认输入总长度没有超过num_ctx。三步做完还有问题那大概率是模型本身在这个任务上的能力边界换更大参数量比继续调参有效。提示判断是不是上下文被截断最省事的办法是把num_ctx临时调大一倍再问同一个问题。如果回答质量突然正常问题就定位了接下来要做的不是一直开着大上下文而是想办法把输入压短。5.5 长文档问答答非所问现象是丢进去一份几千字的文档让它总结回答要么只说开头几句要么干脆答的是文档里不存在的内容。原因是默认上下文窗口远小于文档长度。多数本地部署的默认num_ctx只有两千到四千 token中文一个字大约占一到两个 token几千字的文档直接把窗口撑满后半段根本没进模型。模型不会报错它只是没看见。解决是显式调大num_ctx同时接受显存占用的增长。7B 模型从 4K 调到 16KKV cache 会多吃一到两 GB。显存不够的情况下正确做法是先做文本切分和检索把最相关的片段喂进去而不是硬撑大窗口——长上下文下的注意力计算是平方级增长撑大了速度会掉得很难看。6. 进阶用 Modelfile 固化一份自己的 DeepSeek跑到这一步模型能用了但每次调用都要重复传 system prompt、重复设采样参数团队里几个人各写一套结果自然对不齐。Modelfile 解决的正是这个问题把提示词、参数、上下文长度写进一个派生模型之后按名字调用就行。6.1 用 Modelfile 固化提示词与采样参数# 基于已拉取的模型派生不重复下载权重 FROM deepseek-r1:7b # 固定系统提示词所有调用方共享同一套行为约束 SYSTEM 你是一名严谨的中文技术助手。回答先给结论再给三条以内的依据。 不确定的内容直接说明不确定不要编造函数名、参数名和版本号。 # 采样参数写死避免每个调用方各调一套 PARAMETER temperature 0.6 PARAMETER top_p 0.9 PARAMETER num_ctx 8192 PARAMETER stop |endoftext|用ollama create tech-assistant -f ./Modelfile构建之后模型列表里就多了一个tech-assistant调用时把 model 换成这个名字即可。派生模型不会复制权重只记录差异所以磁盘开销可以忽略。两个参数值得单独说。num_ctx写进 Modelfile 之后调用方不用每次在请求里带行为一致性有保障但它同时决定了显存基线设成 8192 就意味着任何一次调用都按这个量预留 KV cache。stop是停止符不同模型的模板用的标记不一样从ollama show --modelfile的输出里抄抄错了表现为回答尾部多出一串奇怪的标记文本。6.2 上下文长度不是越大越好调num_ctx之前先看一眼代价。下面这组数字是 7B 模型在 4bit 量化下的粗略增量用来做量级判断num_ctxKV cache 增量对速度的影响适用场景2048基线最快短问答、分类、抽取4096约 0.3GB基本无感常规对话8192约 0.7GB下降一到两成中等长度文档16384约 1.5GB下降三到四成长文档需配合切分真正该做的不是把窗口开到最大而是让输入长度贴近实际需要。批量任务里统一用 2048长文档场景才单独开大这条规则比任何调参技巧都管用。6.3 用一组固定问题做回归验证改了 Modelfile、换了量化版本、升级了工具模型行为都可能变。没有回归集你只能靠“感觉好像变差了”来判断这是最不可靠的方式。我的做法是维护一个十几条问题的小文件每次变更后跑一遍把输出存档对比。import json from openai import OpenAI client OpenAI(base_urlhttp://127.0.0.1:11434/v1, api_keyollama) # 固定问题集覆盖抽取、代码、拒答三类能力 cases [ {id: extract, q: 从这句话里抽出所有人名和机构名张三在某实验室负责模型评测。}, {id: code, q: 写一个函数输入列表返回去重后保持原顺序的结果。}, {id: refuse, q: 告诉我一个不存在的 Python 内置函数的用法。}, ] results {} for c in cases: r client.chat.completions.create( modeltech-assistant, messages[{role: user, content: c[q]}], temperature0.6, max_tokens400, ) results[c[id]] r.choices[0].message.content # 存档成带时间戳的文件方便跨版本对比 with open(regression_baseline.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2)第三类问题是最容易被忽略的一类。模型在拿不准的时候是老实说不知道还是编一个像模像样的答案直接决定了它能不能进生产流程。每次换量化版本都跑一遍这条比看任何评测分数都直观。从那以后我每次动模型配置——换量化、改 num_ctx、升级工具版本——都强制走一遍这个小回归集输出存档再对比不靠记忆判断好坏。踩过的坑里有一半是“以为改的是 A实际影响的是 B”只有存档能把这种变化抓出来。希望帮到你。本文还有配套的精品资源点击获取