本地部署DeepSeek能守住数据边界、控制长期成本，但硬件、模型与推理链路都有门槛；本文按环境、选型、部署、使用四步给出可执行路径。
当团队把课程资料、学员问答和企业内部文档交给云端大模型时，真正卡住项目的往往不是模型能力，而是数据合规、调用成本和响应稳定性。DeepSeek系列提供了从蒸馏小模型到671B全量模型的完整谱系，本地部署的难点也不在“能不能跑”，而在“跑得稳、接得进、用得住”。对于AI指导老师而言，部署不是目的，把模型变成可教学的答疑工具、可审计的课程助手，才是落地标准。下面按实际项目顺序拆解环境、选型、引擎和使用四个环节，并给出可复用的参数与判断依据。
1. 部署前的硬件盘点与环境基线
本地部署DeepSeek的第一步不是下载模型，而是把硬件、驱动和运行环境盘点清楚。以常见的蒸馏版模型为例，7B参数模型采用Q4量化后权重大约占用4至5GB显存，14B约需9至11GB，32B约需18至22GB，70B则接近40GB；这还没有计算KV缓存和上下文开销。若把上下文拉到8K以上，显存还要预留20%至30%的余量。因此，单卡RTX 4090的24GB显存适合运行14B的Q4量化版本，32B模型则建议使用双卡或A6000级别的48GB显存。纯CPU推理并非不可行，但7B模型在普通服务器上的生成速度通常只有每秒几个token，只适合离线批处理，不适合课堂实时答疑。
软件环境建议以Ubuntu 22.04为基线，搭配NVIDIA驱动535以上版本和CUDA 12.1，Python固定在3.10或3.11，避免新版依赖冲突。部署前应确认nvidia-smi能正常识别显卡，磁盘至少预留模型体积两倍的空间，因为下载、转换和缓存会重复占用。若使用Docker运行Open WebUI或向量数据库，还要提前规划端口和数据卷，把模型权重、日志和知识库文件分开挂载。一个常见的教学项目案例是：培训团队在单台4090工作站上部署14B蒸馏模型，配合Docker版Open WebUI做课程答疑，模型目录放在NVMe盘，日志与学员会话写入独立数据卷，后续迁移和备份都不需要重新下载权重。这个阶段多花半天做基线检查，能省掉后面大量“显存溢出”和“端口冲突”的排查时间。
2. 模型选型与权重获取
DeepSeek本地部署最容易踩的坑，是把“DeepSeek-R1”理解成单一模型。实际上，面向本地场景的常见选择是DeepSeek-R1-Distill系列，它基于Qwen或Llama架构蒸馏而来，提供1.5B、7B、8B、14B、32B、70B等参数规模；671B全量模型则需要多机多卡，普通教学团队基本不具备运行条件。选型时要同时看任务复杂度和硬件上限：课程问答、文档摘要和基础代码解释，14B蒸馏模型已经能给出较完整的推理链；涉及多轮工具调用和长文档分析，32B更稳妥；如果只是做分类、抽取和固定话术回复，7B甚至1.5B就够用，响应速度也更快。不要盲目追求参数规模，教学场景更看重首token延迟和并发稳定性。
权重获取建议优先走ModelScope或Hugging Face的官方仓库，确认仓库名包含DeepSeek-R1-Distill，并核对许可证和模型卡中的量化说明。使用Ollama时可以直接执行ollama pull deepseek-r1:14b，平台会自动选择适合的量化版本；使用vLLM或Transformers则下载safetensors权重，并保留tokenizer和配置文件。若显存紧张，可选择GGUF格式的Q4_K_M量化文件，在llama.cpp或Ollama中加载，质量损失通常可接受，但数学推理和长链推理会有所下降，需要通过评测集验证。实际项目中建议先下载7B和14B两个版本做小样本对比，用同一批课程问题测试回答完整度、事实准确率和平均响应时间，再决定最终上线的模型规格。模型文件应记录来源、版本号和哈希值，便于后续复现和审计。
3. 推理引擎落地与接口联调
推理引擎的选择决定了部署效率和后续扩展能力。对快速验证和教学演示，Ollama是最省事的路径：安装后执行ollama run deepseek-r1:14b即可在终端对话，服务默认监听11434端口，并提供OpenAI兼容接口，路径为/v1，可以直接被LangChain、Dify或自研前端调用。若需要更高并发和更细的批处理控制，vLLM更合适，安装后通过vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-14B启动服务，默认端口8000，支持张量并行和PagedAttention，在多用户同时提问时吞吐明显优于裸Transformers。前端层可以用Docker部署Open WebUI，把Ollama地址填入管理后台，再配置账号体系和会话记录，半天内就能得到一个可用的内部答疑界面。
接口联调阶段要重点验证三件事：模型是否按预期返回结构化内容、流式输出是否稳定、异常请求是否可控。以OpenAI兼容接口为例，请求体中的model字段要填写本地实际注册的模型名，temperature对推理模型建议设在0.5至0.7，max_tokens根据课程答案长度设置，过长会拖慢响应。并发测试不要只看单次对话，应该用10至20个并发请求观察显存占用和排队情况，14B模型在24GB显存上通常只能稳定支撑个位数并发，超出后延迟会快速上升。教学中还要保留系统提示词和会话日志，但DeepSeek-R1蒸馏模型对系统提示的敏感度与通用模型不同，建议把角色设定、输出格式和知识边界写进用户消息，避免多层提示互相干扰。联调完成后，把接口地址、模型版本、并发上限和超时时间写入部署文档，后续换模型或扩容时才有对照基线。
4. 业务使用、效果调优与运维边界
模型跑通只是起点，真正决定教学效果的是使用和调优策略。AI指导老师场景下，建议把课程大纲、常见问题、评分标准和内部术语整理成知识库，通过RAG挂接到模型前面，检索层可以用Dify或AnythingLLM，向量库选择Chroma或Milvus，文档切分控制在500至800字并保留标题层级。这样模型回答课程细节时有据可查，减少凭空编造。提示词设计要围绕教学动作展开，例如要求模型先复述学员问题、再给出分步解释、最后标注引用来源；对代码类问题则要求给出可运行示例和常见错误。推理模型不需要过度堆砌“请一步步思考”，但需要明确输出结构和禁止项，否则答案容易过长，反而增加学员阅读负担。
效果调优应建立小规模评测集，至少覆盖事实问答、流程解释、代码纠错和边界拒答四类问题，每类20至30条，固定模型版本和参数后每周复跑一次，记录准确率、平均响应时间和人工评分。若发现模型在特定课程上频繁出错，优先补充知识库和检索策略，而不是反复调整temperature。运维层面要明确边界：本地部署不等于零风险，模型权重、会话日志和知识库都涉及内部资料，需要设置访问控制、操作审计和定期备份；GPU温度、显存占用和接口错误率应纳入监控，Ollama和vLLM都提供日志输出，可以接入Prometheus或简单的定时巡检脚本。版本升级前先在测试环境验证模型输出差异，保留旧版本权重以便回滚。教学团队还应制定使用规范，明确哪些问题必须转人工、哪些回答需要标注“模型生成”，让本地DeepSeek成为可控的辅助工具，而不是替代教师判断的黑箱。
