企业官网建设流程全解析

简介：这份文档面向希望在不同计算平台上运行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 参数约 2GB，INT8 约 1GB，INT4 约 0.5GB，再叠加 KV Cache 和框架开销。所以一张 24G 卡跑 7B 的 INT4 很轻松，跑 32B 的 INT4 就接近极限，满血版基本别想单卡。

这张表是选型起点。如果你只有一张 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 python=3.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_url="http://localhost:8000/v1", api_key="EMPTY") resp = client.chat.completions.create( model="/data/models/deepseek-7b-awq", messages=[{"role": "user", "content": "用一句话解释什么是量化"}], temperature=0.7, max_tokens=256, ) 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.cpp

Mac 上 llama.cpp 能调用 Metal，速度比纯 CPU 快数倍。推荐从源码编译，确保开启 Metal 支持。

git clone https://github.com/ggerganov/llama.cpp cd llama.cpp # 编译，Mac 上会自动开启 Metal make LLAMA_METAL=1 -j8 # 编译完成后确认可执行文件存在 ls -lh main

LLAMA_METAL=1是 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 vllm==0.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_url="http://localhost:8000/v1", api_key="EMPTY") # 固定测试集，覆盖问答、代码、摘要三类 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}], temperature=0, # 固定温度，保证可复现 max_tokens=128, ) dt = time.time() - t0 text = resp.choices[0].message.content print(f"[case {i}] {dt:.2f}s | {len(text)} chars | {text[:40]}...")

temperature=0是关键，保证同样输入得到同样输出，否则每次结果不同就没法对比。记录每个 case 的耗时和输出长度，如果某次部署后耗时突然翻倍或输出明显变短，说明环境或参数出了问题。这套方法不依赖任何评测框架，几十行代码就能跑，适合每次上线前过一遍。

6.3 一个我常犯的错

最后说个血泪教训。我早期部署时总喜欢把max-model-len往大了设，觉得「反正显存够」，结果并发一上来就 OOM，排查半天才发现是 KV Cache 预分配把显存吃光了。后来我养成习惯：先按实际业务的最长输入设一个最小值，跑稳了再逐步往上加，每次加完压测一轮。部署这件事，保守的参数比激进的参数活得久。希望帮到你。

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