引言：为什么要在本地部署 DeepSeek

过去一年，大模型的能力边界被不断刷新，但“调用 API”始终隔着一层：数据要出网、成本随调用量线性增长、延迟受网络波动影响、模型行为也难以深度定制。对于开发者而言，真正的掌控感来自把模型握在自己手里——这正是本地部署的价值所在。

DeepSeek 系列开源模型的出现，让这件事的门槛显著降低。其模型权重开放、社区工具链成熟，配合量化技术与推理框架的进步，一台配备消费级显卡的工作站甚至一台高内存的笔记本，都能跑起可用的推理服务。本文面向有一定工程基础的开发者，系统梳理从环境准备、模型获取、推理部署到微调与趣味源码实验的完整路径，并给出可复现的操作要点与常见坑位提示。

需要说明的是，本文聚焦方法论与工程实践，不鼓励盲目追求“最大参数”。选择与硬件匹配的模型规格，往往比堆砌算力更能带来实际收益。

一、部署前的认知准备：模型规格与硬件匹配

DeepSeek 开源模型覆盖多个参数规模与架构变体，部署前首先要明确三件事：模型参数量、精度格式、以及推理框架的支持情况。

参数规模与显存的关系。一个粗略但实用的估算：FP16 精度下，每 10 亿参数约需 2GB 显存用于权重加载；INT8 量化约减半；INT4 量化再减半。但显存占用不止权重，还包括 KV Cache（随上下文长度和并发数增长）与框架开销。因此，7B 级模型在 INT4 量化下，8GB 显存可跑单路推理；14B 级建议 12GB 以上；32B 级在 INT4 下通常需要 24GB 显存；更大规模则要考虑多卡或 CPU 卸载方案。

精度格式的选择。GGUF 格式适合 llama.cpp 系推理，对 CPU 与混合卸载友好，量化档位丰富（Q4_K_M、Q5_K_M 等），是本地部署的“万金油”；GPTQ/AWQ 适合 GPU 上的 vLLM 或 Transformers 加载，吞吐更高；原生 safetensors 权重则便于微调与二次开发。建议根据用途分流：纯推理优先 GGUF 或 AWQ，微调则保留原始权重。

推理框架的取舍。llama.cpp 生态轻量、跨平台、CPU 可用；Ollama 在其上封装了模型管理与服务接口，上手最快；vLLM 面向高吞吐服务场景，支持 PagedAttention 与连续批处理；Transformers 则是研究与微调的标准入口。本文后续会分别给出 Ollama 与 vLLM 两条部署路线。

二、环境准备：从驱动到依赖

无论选择哪条路线，基础环境都需要先就位。

GPU 驱动与 CUDA。NVIDIA 用户应确认驱动版本与 CUDA Toolkit 匹配，nvidia-smi 能正常输出且显存未被异常占用。CUDA 版本并非越新越好，需与推理框架的预编译包对齐；若使用 vLLM，建议按其文档选择经过验证的 CUDA 版本，避免自行编译带来的兼容性问题。AMD 用户可关注 ROCm 支持情况，但生态成熟度仍有差距，需预留更多调试时间。

Python 环境隔离。强烈建议使用 conda 或 venv 创建独立环境，避免与系统 Python 包冲突。以 conda 为例，创建 Python 3.10 环境后，先升级 pip，再安装框架依赖。注意 PyTorch 版本与 CUDA 版本的对应关系，安装命令应来自官方索引而非随意 pip install torch。

磁盘与内存。模型文件动辄数 GB 到数十 GB，需预留充足磁盘空间，SSD 能显著缩短加载时间。若采用 CPU 卸载或纯 CPU 推理，系统内存应至少为模型文件大小的 1.5 倍，并为操作系统留出余量。

常见坑位。一是多版本 CUDA 共存导致库加载错误，可用 LD_LIBRARY_PATH 显式指定；二是容器环境中 GPU 未透传，需检查 --gpus all 与 nvidia-container-toolkit 配置；三是权限问题导致模型目录不可读，尤其在以服务方式运行时。

三、路线一：Ollama 快速部署

Ollama 是目前上手成本最低的本地推理方案，适合快速验证与个人使用。

安装与拉取模型。安装 Ollama 后，通过命令行拉取模型即可。以 DeepSeek 蒸馏或轻量版本为例，执行拉取命令后，Ollama 会自动下载权重并完成格式适配。拉取完成后，ollama run 即可进入交互式对话，ollama list 查看本地模型，ollama ps 观察运行状态。

服务化与 API 调用。Ollama 默认在本地端口提供兼容 OpenAI 风格的接口，开发者可直接用 HTTP 请求调用，也可接入 LangChain、LlamaIndex 等框架。对于需要自定义系统提示词与参数（temperature、top_p、上下文长度）的场景，可通过 Modelfile 定义模型配置，再 ollama create 生成定制模型。这一机制实际上是一种轻量级的“提示词工程固化”，适合把稳定的角色设定沉淀为可复用资产。

性能调优要点。Ollama 会自动判断 GPU 可用性并分配层数，但自动策略未必最优。可通过环境变量控制 GPU 层卸载数量、并发数与上下文长度。上下文长度是显存占用的隐形杀手，默认值往往偏大，按实际需求下调可显著降低显存压力。此外，开启 flash attention（若框架与硬件支持）对长上下文场景有明显收益。

适用边界。Ollama 适合单用户、低并发、快速验证；若需要多路并发与高吞吐，应转向 vLLM 等方案。它也不适合作为微调入口，权重格式与训练框架的衔接需要额外转换。

四、路线二：vLLM 高性能推理服务

当部署目标从“能跑”升级为“能服务”，vLLM 是更合适的选择。

安装与模型加载。在独立环境中安装 vLLM 后，可通过命令行启动 OpenAI 兼容服务，指定模型路径、张量并行度、显存利用率上限与最大上下文长度。首次加载会进行权重格式转换与显存预分配，耗时较长属正常现象。若模型为 AWQ 或 GPTQ 量化版本，需在启动参数中声明量化方式，否则可能加载失败或精度异常。

关键参数解读。--gpu-memory-utilization 控制显存占用比例，默认值较高，多卡或与其他进程共存时应下调；--max-model-len 决定最大上下文，直接影响 KV Cache 预留；--tensor-parallel-size 用于多卡切分，需与卡数匹配；--enforce-eager 可关闭 CUDA Graph 以节省显存，代价是吞吐略降。这些参数之间存在联动，调优时应一次只改一个变量并观察吞吐与延迟变化。

压测与容量规划。部署完成后，建议用并发请求做基础压测，观察首 token 延迟与每秒生成 token 数。vLLM 的连续批处理在高并发下优势明显，但显存不足时会触发抢占与重算，表现为延迟抖动。容量规划的核心是找到“显存上限—上下文长度—并发数”三者的平衡点，而非一味追求单请求速度。

生产化注意事项。对外提供服务时应加认证与限流，避免裸奔；日志需记录请求量、延迟分位与显存水位，便于定位问题；模型更新采用灰度切换，保留回滚路径。若部署在容器中，注意模型目录挂载与健康检查探针的配置。

五、微调入门：让模型适配你的领域

本地部署的另一层价值是微调。对于垂直领域任务，少量高质量数据的 LoRA 微调往往比更换更大模型更有效。

数据准备。指令微调数据通常为“指令—输入—输出”三元组，格式需与训练框架对齐（如 JSONL）。数据质量远比数量重要：去重、清洗、统一格式、控制长度分布，都是必要步骤。建议先构造 500 至 2000 条高质量样本跑通流程，再考虑扩量。

LoRA 微调流程。使用 PEFT 与 Transformers 生态，加载基础模型后挂载 LoRA 适配器，冻结主干参数，仅训练低秩矩阵。关键超参包括秩（r）、学习率、批次大小与训练轮数；显存不足时可启用梯度检查点与 4bit 量化加载。训练过程中监控 loss 曲线，过拟合迹象出现时应早停。

评估与合并。微调后需在留出集上对比基线与适配器效果，避免只看训练 loss。评估应覆盖目标任务指标与通用能力回归，防止灾难性遗忘。确认有效后，可将 LoRA 权重合并回主干，或保留适配器动态加载。合并后的模型可再走一遍量化流程，用于推理部署