简介这份文档面向希望在不同计算平台上运行DeepSeek大模型的开发者与AI技术爱好者系统梳理了多种部署路径。内容覆盖基于Ollama的本地部署流程、iPhone快捷指令与安卓Termux的手机端搭建方法以及结合Open WebUI与Docker Desktop的图形化部署方案帮助读者根据硬件资源与个人偏好选择合适途径兼顾性能与成本。资源包为1个docx文件约15KB以文字指导为主结构清晰、步骤完整便于按章节查阅与对照操作。目前已有766人学习下载适合需要将大模型迁移到不同终端、希望获得可落地操作参考的技术人群可作为部署选型与配置排错的实用手册。1. 从一张显卡到一台旧笔记本DeepSeek 多平台部署到底在解决什么很多团队第一次动 DeepSeek 部署的念头都是被同一件事逼出来的调用云端 API 时数据要出内网或者并发一上来账单就失控。于是问题从「模型效果好不好」变成了「我手上这台机器能不能把它跑起来」。DeepSeek 系列里既有面向消费级硬件的蒸馏小模型也有需要多卡并行的满血版本部署方案横跨 NVIDIA 显卡、Apple Silicon、纯 CPU 服务器甚至国产加速卡。这意味着同一套权重在不同平台上的加载方式、量化策略、推理后端完全不是一回事。这篇笔记面向三类人手里只有一张 24G 显卡想跑量化版的个人开发者、要在内网服务器上做私有化推理的运维、以及想用旧笔记本做离线验证的算法同学。我会把每个平台的选型理由、可复现的命令、必调参数和翻车点讲清楚让你看完能直接挑一条路径动手而不是停在「听说能本地跑」。2. 部署前的三个决策模型规格、量化精度、推理后端在敲任何命令之前有三件事必须先定下来否则后面每一步都会返工。这三件事互相牵制模型规格决定显存下限量化精度决定你能省多少推理后端决定你能否吃满硬件。很多人一上来就pip install然后报 OOM本质是顺序反了。2.1 先按显存反推模型规格而不是按模型挑机器DeepSeek 的蒸馏系列常见规格有 1.5B、7B、8B、14B、32B 等满血版则是数百 B 参数的 MoE 结构。显存占用有个粗略公式FP16 下每 B 参数约 2GBINT8 约 1GBINT4 约 0.5GB再叠加 KV Cache 和框架开销。所以一张 24G 卡跑 7B 的 INT4 很轻松跑 32B 的 INT4 就接近极限满血版基本别想单卡。模型规格FP16 显存INT8 显存INT4 显存典型硬件1.5B~3GB~2GB~1.5GB任意 4G 以上显卡7B/8B~16GB~9GB~5GBRTX 3060 12G 起14B~28GB~15GB~9GBRTX 4090 24G32B~64GB~34GB~20GB双卡 24G 或 A100满血 MoE数百 GB上百 GB数十 GB多卡服务器这张表是选型起点。如果你只有一张 12G 卡目标就锁定在 7B/8B 的 INT4如果有 24G可以上 14B INT4 或 32B INT4 但要把上下文压到 4K 以内。别信「小模型效果差」的说法蒸馏版在多数问答和摘要任务上够用真正吃参数的是复杂推理和长文档。2.2 量化精度的取舍INT4 不是万能药量化能省显存但代价是精度损失而且不同量化方案差异很大。常见的有 GPTQ、AWQ、GGUF 的 Q4_K_M 等。经验上Q4_K_M 在 7B 级别几乎无损Q3 开始明显掉点Q2 基本只能做演示。AWQ 对激活值更友好推理速度通常比 GPTQ 快一点但生态支持略窄。选量化的原则是先保证能跑起来再谈精度。如果 INT4 能让你从「跑不动」变成「跑得动」那就用 INT4别纠结那零点几个点的评测分。反过来如果硬件充裕优先 FP16 或 INT8省下的调试时间比省下的显存值钱。2.3 推理后端的选型vLLM、llama.cpp、Ollama 各管一段后端选择直接决定你的使用体验。vLLM 主打高吞吐和 PagedAttention适合多并发服务化llama.cpp 主打 CPU 和混合推理GGUF 格式的娘家适合没有独显的机器Ollama 是 llama.cpp 的封装胜在一键拉取和 API 兼容适合快速验证。三者不是替代关系而是场景分工。提示如果你的目标是「内网多人用」直接上 vLLM如果只是「我自己电脑上问几句」Ollama 最省事如果是「旧笔记本没独显」只有 llama.cpp 这条路。3. NVIDIA 显卡平台用 vLLM 跑通 OpenAI 兼容服务NVIDIA 是部署 DeepSeek 最顺的平台CUDA 生态成熟vLLM 对它的支持也最完整。这一章给出一条从零到能对外提供 API 的完整路径命令都可以直接抄。3.1 环境准备与依赖安装先确认驱动和 CUDA 版本。vLLM 对 CUDA 版本敏感装错版本会在编译算子时炸掉。建议用 conda 隔离环境避免污染系统 Python。# 查看驱动支持的 CUDA 上限 nvidia-smi # 创建独立环境python 用 3.10 或 3.11 conda create -n deepseek-vllm python3.11 -y conda activate deepseek-vllm # 安装 vLLM它会自动拉取匹配的 torch pip install vllm # 验证安装能打印版本即成功 python -c import vllm; print(vllm.__version__)这里的关键是nvidia-smi右上角显示的 CUDA Version 是驱动支持的上限不是你实际装的版本。vLLM 安装时会根据你的 torch 版本决定编译哪个 CUDA 算子所以不要手动去装一个和 torch 不匹配的 CUDA toolkit。如果pip install vllm卡在编译多半是 gcc 版本太低升级到 9 以上即可。3.2 启动推理服务与关键参数vLLM 的启动命令参数很多但真正影响能不能跑起来和跑得好不好的就那么几个。下面这条命令以 7B 的 AWQ 量化模型为例。python -m vllm.entrypoints.openai.api_server \ --model /data/models/deepseek-7b-awq \ --quantization awq \ --dtype float16 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --tensor-parallel-size 1 \ --port 8000逐项说明--quantization awq告诉 vLLM 用 AWQ 反量化如果你下的是 GPTQ 就改成 gptq下的是 FP16 原版就删掉这行。--max-model-len是上下文上限设太大 KV Cache 会吃掉大量显存8K 是 24G 卡跑 7B 的稳妥值。--gpu-memory-utilization 0.9表示允许 vLLM 占用 90% 显存留 10% 给系统设成 0.95 有时会 OOM。--tensor-parallel-size是多卡并行数单卡填 1双卡填 2且必须能整除注意力头数。启动后访问http://localhost:8000/v1/models能看到模型列表就说明服务起来了。调用方式和 OpenAI 完全一致from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) resp client.chat.completions.create( model/data/models/deepseek-7b-awq, messages[{role: user, content: 用一句话解释什么是量化}], temperature0.7, max_tokens256, ) print(resp.choices[0].message.content)api_key填任意非空字符串即可vLLM 默认不校验。model字段要和服务启动时的路径一致否则会报模型不存在。这套接口的好处是现有基于 OpenAI SDK 的代码几乎零改动就能切过来。3.3 多卡并行的注意事项当单卡放不下时用--tensor-parallel-size 2做张量并行。但要注意两点一是张量并行要求卡间通信快PCIe 4.0 x16 勉强够NVLink 更好二是并行数必须是注意力头数的约数7B 模型通常 32 个头所以 2、4、8 都行3 不行。如果启动时报 shape mismatch先检查这个整除关系。4. Apple Silicon 与纯 CPU 平台llama.cpp 的 GGUF 路线不是所有人都有独显。Mac 的 M 系列芯片统一内存架构或者一台纯 CPU 的旧服务器都能靠 llama.cpp 跑起来。这条路的核心是 GGUF 格式和量化等级的选择。4.1 在 Mac 上用 Metal 加速编译 llama.cppMac 上 llama.cpp 能调用 Metal速度比纯 CPU 快数倍。推荐从源码编译确保开启 Metal 支持。git clone https://github.com/ggerganov/llama.cpp cd llama.cpp # 编译Mac 上会自动开启 Metal make LLAMA_METAL1 -j8 # 编译完成后确认可执行文件存在 ls -lh mainLLAMA_METAL1是 Mac 上的关键开关不开的话就退化成纯 CPU。-j8是并行编译核数按你机器的核心数调整。编译产物main就是推理入口。如果你用的是较新的版本入口可能叫llama-cli以实际编译输出为准。4.2 用 GGUF 量化模型跑推理GGUF 模型可以从社区下载也可以自己用convert脚本从原始权重转换。假设你已经有一个 Q4_K_M 的 GGUF 文件./main \ -m /data/models/deepseek-7b-q4_k_m.gguf \ -p 写一段 Python 快速排序 \ -n 256 \ -t 8 \ -c 4096 \ --temp 0.7参数含义-m指定模型文件-p是提示词-n是最大生成 token 数-t是线程数Mac 上建议设为性能核数量设太多反而因调度开销变慢-c是上下文长度4096 对多数对话够用设太大会吃内存--temp是温度。在 M2 16G 的机器上7B Q4_K_M 大概能跑到每秒十几到二十几个 token日常问答可接受。4.3 纯 CPU 服务器的线程与内存调优纯 CPU 环境下瓶颈从显存变成内存带宽和线程调度。经验是线程数设为物理核心数而非超线程数比如 16 核 32 线程的机器设-t 16。内存方面7B Q4 大约需要 5-6GB加上上下文缓存16G 内存的机器跑 4K 上下文没问题。如果机器支持 AVX2 或 AVX512编译时会自动启用速度差距明显可以用lscpu确认指令集。注意CPU 推理的 token 速度通常只有个位数到十几别指望做实时交互。它更适合离线批处理、文档摘要这类不要求低延迟的场景。5. 避坑与排查部署 DeepSeek 最常见的五类翻车这一章是我和身边人踩过的坑合集每条都按「现象 → 原因 → 解决」写遇到问题先来这里对号入座。5.1 启动即 OOM但显存看起来够现象--gpu-memory-utilization设 0.9模型加载到一半报 CUDA out of memory但nvidia-smi显示空闲显存明明够。原因vLLM 会预分配 KV Cache预分配量按max-model-len和并发数估算实际占用可能远超模型权重本身。另外如果之前有残留进程没退干净显存被占着。解决先把--max-model-len降到 4096 试再把--gpu-memory-utilization降到 0.85。同时用nvidia-smi确认没有僵尸进程必要时kill -9清掉。别一上来就设 0.95那是给自己找麻烦。5.2 量化模型加载报 unsupported quantization现象下载了 GPTQ 模型启动时却报不支持的量化类型。原因vLLM 不同版本对量化格式的支持范围不同AWQ 和 GPTQ 需要显式指定--quantization而且某些旧版本不支持特定量化后端。解决先确认模型目录里的config.json写了什么quantization_config再对照 vLLM 版本文档。最稳的办法是升级 vLLM 到较新版本或者换用 AWQ 格式兼容性通常更好。5.3 中文输出乱码或断句奇怪现象模型能跑但中文回答里夹杂乱码或者一句话说到一半断掉。原因多半是 tokenizer 加载不对或者 GGUF 转换时词表处理有问题。也有可能是max_tokens设太小导致截断。解决确认模型目录里 tokenizer 文件完整GGUF 转换时用官方脚本而非第三方魔改版。如果是截断把-n或max_tokens调大。中文场景下建议温度别设太高0.6-0.8 比较稳。5.4 多卡并行启动失败或速度反而变慢现象双卡设--tensor-parallel-size 2要么启动报错要么跑起来比单卡还慢。原因卡间通信带宽不足或者并行数不整除注意力头数。PCIe 带宽不够时通信开销会吃掉并行收益。解决先确认并行数能整除头数再确认两张卡在同一 NUMA 节点下。如果主板 PCIe 通道是 x8 x8 而非 x16 x16双卡收益有限不如单卡跑小模型。用nvidia-smi topo -m看卡间连接方式。5.5 API 服务并发一高就超时现象单请求正常几个并发一起打过来就大量超时。原因vLLM 默认的调度策略和max-num-seqs限制了同时处理的序列数超出部分排队。另外如果max-model-len设得很大每个请求占的 KV Cache 多能并发的数量就少。解决适当调大--max-num-seqs同时把max-model-len压到实际需要的最小值。如果还是不够考虑加卡做张量并行或者用两个实例做负载均衡。别指望单卡无限并发物理上限摆在那。6. 进阶技巧用 Docker 固化环境并做一次可复现验证部署最烦的不是第一次跑通而是换台机器就复现不了。这一章讲怎么用 Docker 把环境固化并给一套验证方法确保你的部署不是「在我机器上能跑」的玄学。6.1 写一个可复用的 Dockerfile把 vLLM 和模型路径都固化进镜像换机器只需docker run。下面是一个精简版FROM nvidia/cuda:12.1.0-runtime-ubuntu22.04 RUN apt-get update apt-get install -y python3.11 python3-pip rm -rf /var/lib/apt/lists/* RUN pip install vllm0.4.0 # 模型通过挂载卷传入不打进镜像避免镜像过大 VOLUME /models EXPOSE 8000 ENTRYPOINT [python3, -m, vllm.entrypoints.openai.api_server, \ --model, /models/deepseek-7b-awq, \ --quantization, awq, \ --max-model-len, 8192, \ --gpu-memory-utilization, 0.9]基础镜像选runtime而非devel体积小很多vLLM 运行不需要编译工具链。模型用VOLUME挂载而不是COPY这样镜像只有几 GB模型更新也不用重建镜像。ENTRYPOINT里把参数写死保证每次启动行为一致。构建和运行docker build -t deepseek-vllm:local . docker run --gpus all -p 8000:8000 -v /data/models:/models deepseek-vllm:local--gpus all需要宿主机装好 nvidia-container-toolkit否则容器看不到显卡。挂载路径两边要对应容器里读的是/models。6.2 用固定 prompt 做回归验证环境固化后还需要一套验证方法确认部署没退化。我的习惯是准备一组固定 prompt每次部署完跑一遍对比输出长度和关键内容。import time from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) # 固定测试集覆盖问答、代码、摘要三类 cases [ 用一句话解释什么是 KV Cache, 写一个 Python 函数判断回文, 把下面这段话压缩成 20 字以内深度学习模型的部署需要考虑硬件、量化、后端等多个因素。, ] for i, q in enumerate(cases): t0 time.time() resp client.chat.completions.create( model/models/deepseek-7b-awq, messages[{role: user, content: q}], temperature0, # 固定温度保证可复现 max_tokens128, ) dt time.time() - t0 text resp.choices[0].message.content print(f[case {i}] {dt:.2f}s | {len(text)} chars | {text[:40]}...)temperature0是关键保证同样输入得到同样输出否则每次结果不同就没法对比。记录每个 case 的耗时和输出长度如果某次部署后耗时突然翻倍或输出明显变短说明环境或参数出了问题。这套方法不依赖任何评测框架几十行代码就能跑适合每次上线前过一遍。6.3 一个我常犯的错最后说个血泪教训。我早期部署时总喜欢把max-model-len往大了设觉得「反正显存够」结果并发一上来就 OOM排查半天才发现是 KV Cache 预分配把显存吃光了。后来我养成习惯先按实际业务的最长输入设一个最小值跑稳了再逐步往上加每次加完压测一轮。部署这件事保守的参数比激进的参数活得久。希望帮到你。本文还有配套的精品资源点击获取