围绕硬件评估、模型选型、运行工具、量化启动与API接入，给出DeepSeek本地部署的可执行步骤和常见问题处理思路。
DeepSeek本地部署常被包装成“一条命令跑起来”，但真正影响体验的是硬件边界、模型版本、量化格式、上下文长度和推理后端之间的匹配。对AI指导老师而言，教程的价值不只在给出安装命令，更在于让学员理解为什么某台机器只能跑7B或14B蒸馏模型，为什么满血版R1需要多卡服务器，以及什么时候该选Ollama、什么时候该转向vLLM。下面按可复现的落地顺序展开，把容易踩坑的环节讲清楚。
1. 硬件门槛与模型选型。
本地部署DeepSeek的第一件事不是装软件，而是判断硬件能承载哪一类模型。DeepSeek-V3和DeepSeek-R1满血版采用671B MoE架构，即使做4-bit量化也需要数百GB显存或多卡服务器，普通工作站和教学笔记本并不适合直接挑战；面向个人和课堂的通常是DeepSeek-R1蒸馏版，包括1.5B、7B、8B、14B、32B和70B等规格，它们分别基于Qwen或Llama系列，部署难度和硬件门槛逐级上升。显存估算可以用一个粗略基准：7B模型FP16约需14GB显存，4-bit GGUF通常落在5GB到6GB；14B的4-bit版本约需9GB到11GB；32B的4-bit版本约需20GB到24GB；70B的4-bit版本往往需要40GB以上，并且上下文一长就会进一步挤占显存。
模型选型要回到教学场景本身。如果只是课堂演示、离线答疑和学员单人练习，14B的4-bit量化模型在RTX 4090 24GB这类显卡上已经能覆盖多数问答和文本处理任务，设置8K上下文也比较从容；如果涉及较复杂的代码解释、长文分析和推理链展示，32B模型的质量更稳，但对显存和加载时间的要求明显提高；70B模型适合有A100或双卡高显存设备的实验室，普通单卡用户不宜把它当作入门目标。满血版R1更适合有服务器资源的团队，通过vLLM或SGLang做多卡推理，而不是在个人电脑上反复尝试。
存储和系统内存同样不能忽略。一个14B模型的量化文件通常在数GB到十余GB，32B和70B模型的下载体积更大，Hugging Face或ModelScope的缓存目录要预留充足空间；CPU内存建议至少达到模型文件体积的1.2倍到1.5倍，使用GGUF的mmap加载时可以适当降低内存压力，但并发一高仍会回到显存和内存的硬约束。教学实验室还要考虑多人轮流使用和并发请求，单卡24GB部署14B 4-bit适合小组演示，若要让20人同时问答，就需要vLLM配合请求队列、限制上下文和输出长度，或者增加显卡，否则体验会快速下降。
2. 运行环境与部署工具链。
操作系统和驱动决定了后续工具链是否顺畅。Linux环境优先选择Ubuntu 22.04，NVIDIA驱动、CUDA运行时和容器工具链的兼容性更好；Windows用户可以用原生Ollama或LM Studio快速起步，也可以用WSL2获得接近Linux的体验，但要注意WSL2的显存分配、文件系统性能和GPU直通配置。安装完成后先用nvidia-smi确认驱动能识别显卡，再核对CUDA版本与推理框架要求，驱动过旧或CUDA不匹配是模型加载失败、算子报错和显存识别异常的常见原因。使用Docker部署时要确认NVIDIA Container Toolkit已经生效，否则容器内看不到GPU。
工具链的选择要围绕使用目标而不是盲目追新。Ollama适合入门、单机问答和快速提供API，安装后通过ollama run deepseek-r1:7b就能验证模型能否运行，模型管理、端口和上下文参数也相对直观；LM Studio提供图形界面，适合不熟悉命令行的教师做课堂演示；llama.cpp适合CPU与GPU混合推理、GGUF量化和资源受限环境；vLLM和SGLang更偏向GPU吞吐与OpenAI兼容服务，适合多人并发、接口压测和系统集成。教学场景如果只是让学员观察模型回答过程，Ollama加Open WebUI的路径最短；如果要模拟企业应用或做并发测试，vLLM更合适，但需要接受更高的环境配置成本。
安装细节往往决定第一次部署能否成功。Linux下Ollama可以用官方脚本安装，Windows下使用安装包，安装后通过ollama --version确认版本，再把OLLAMA_MODELS指向空间充足的磁盘，避免模型默认落在系统盘；如果要把服务开放给局域网内的教学终端，需要谨慎设置OLLAMA_HOST，并配合防火墙和反向代理，不能直接把11434端口暴露到公网。vLLM通常要求Python 3.10以上环境，安装前确认CUDA版本与PyTorch匹配，首次启动会下载权重并编译部分算子，磁盘空间、网络代理和权限问题都可能让启动卡住。实际部署时建议先在一台样机上跑通单模型、单请求，再复制到实验室其他机器，减少重复踩坑。
3. 模型获取、量化与启动服务。
模型来源要优先选择官方模型卡、Hugging Face、ModelScope或Ollama模型库，下载前核对模型名称、参数规模、许可条款和文件完整性。GGUF是Ollama和llama.cpp常用格式，Q4_K_M通常在质量和体积之间比较平衡，Q5_K_M质量更高但显存和加载时间增加，Q8_0接近FP16的精度但占用明显变大；AWQ和GPTQ更适合vLLM等GPU推理框架，选择时要确认框架支持对应量化和模型结构。量化不是万能药，它能降低显存占用，却不能把671B满血模型塞进单张24GB显卡，教学材料里应明确这一点，避免学员误以为换一个量化等级就能突破硬件上限。
用Ollama启动模型时，可以先执行ollama pull deepseek-r1:14b拉取模型，再用ollama run deepseek-r1:14b做单轮验证；需要调整上下文时，通过Modelfile设置PARAMETER num_ctx 8192，需要控制GPU层数时设置PARAMETER num_gpu，修改后重新创建模型并观察加载日志。Ollama默认在11434端口提供接口，OpenAI兼容端点为/v1/chat/completions，适合快速接入聊天界面或教学脚本。用vLLM启动时，可以使用python -m vllm.entrypoints.openai.api_server --model deepseek-ai/DeepSeek-R1-Distill-Qwen-14B --max-model-len 8192 --gpu-memory-utilization 0.9这类命令，模型ID要换成实际下载的本地路径或仓库名称，显存利用率不要长期顶到极限，否则并发请求容易触发OOM。
上下文长度和并发数是启动阶段最容易被低估的变量。num_ctx或--max-model-len增大后，KV Cache会随之增长，14B模型在8K上下文和32K上下文下的显存表现差异明显，多个请求同时进入时还会叠加占用；因此教学演示可以把上下文限制在8K，长文任务再单独调整，不要一开始就设置超大上下文。启动后先用nvidia-smi观察显存、GPU利用率和温度，再查看推理框架日志中的加载时间、首 token 延迟和吞吐数据，完成单轮测试后再做小并发压测。模型文件、Modelfile、启动命令和量化版本都应记录在部署文档中，方便学员复现和后续回滚。
4. API接入、界面集成与稳定运行。
模型跑起来之后，下一步是把推理服务接入教学系统和日常工具。Ollama提供/api/generate和OpenAI兼容的/v1/chat/completions，vLLM原生提供OpenAI风格接口，Python端可以把OpenAI SDK的base_url指向本地服务地址，再设置模型名、超时时间和流式输出；教学平台接入时要处理重试、超时和错误提示，避免模型加载慢时前端一直等待。对课堂问答、作业批改辅助和离线知识库演示来说，API层要保持简单稳定，先验证单请求的返回结构，再接入Open WebUI、Chatbox、LobeChat或Dify这类界面，减少前端与推理服务之间的耦合。
界面集成要兼顾课堂演示和权限边界。Open WebUI适合做本地聊天入口，可以接入Ollama或vLLM的OpenAI兼容接口，为不同学员建立账号并隔离会话；如果只是教师演示，使用桌面客户端更轻量。只要服务需要被局域网内其他设备访问，就应通过Nginx或其他反向代理增加HTTPS、认证和访问日志，防火墙只放行教学网段，不要把11434或8000端口直接映射到公网。日志中可能包含学员提问和模型回答，涉及课程资料时要做脱敏和保留周期管理，模型许可和数据集许可也要在部署前核对清楚。
稳定运行依赖服务化和监控，而不是每次上课手动开终端。Linux下可以把Ollama或vLLM写成systemd服务，设置自动重启、工作目录和环境变量；用nvidia-smi、框架日志和系统监控观察显存泄漏、温度过高和请求堆积，给并发数设置上限，给单次输出长度设置上限，避免一个长文本请求拖垮整张卡。模型更新前保留旧版本目录和启动脚本，驱动升级先在样机验证，再推广到实验室机器；教学团队可以把部署脚本、Modelfile、端口配置和回滚步骤放进同一份文档，让每次调整都有据可查。
