本文围绕Ollama本地部署DeepSeek，拆解硬件评估、模型选型、参数调优、知识库集成与运维排障，给出可复用的教学落地路径。
本地大模型正在从课堂演示走向教学日常，AI指导老师希望把答疑、备课和代码辅导留在自己的机器上，数据不出内网，响应也不受公网波动影响。Ollama把模型拉取、量化推理和接口封装做成了统一入口，让DeepSeek这类推理模型可以在笔记本、工作站或小型服务器上跑起来。真正的难点并不在第一条命令，而在于模型规模与显存是否匹配、上下文长度是否合理、知识库链路是否闭环，以及服务能否长期稳定运行。下面按环境基线、模型调优、工具链集成和运维排障四个环节展开。
1. 硬件评估与Ollama部署基线
本地运行DeepSeek的第一道门槛是硬件匹配，而不是软件安装。Ollama提供的DeepSeek-R1蒸馏版本覆盖1.5B、7B、8B、14B、32B、70B以及671B等规格，普通教学机更适合从7B、8B或14B切入。按Q4_K_M量化估算，7B与8B模型文件约4GB到5GB，14B约9GB到10GB，32B约20GB，70B约40GB，671B则需要多机或多卡环境。显存之外还要给KV缓存留空间，上下文从4K提高到16K会明显增加占用，因此16GB显存适合跑14B并控制上下文，24GB显存可以尝试32B Q4，但要把num_ctx压在8K附近观察是否完全驻留显存。CPU内存建议达到模型文件体积的1.5倍以上，系统盘使用SSD能缩短模型加载时间。
安装环节按操作系统选择官方路径即可。Linux常用curl -fsSL | sh完成安装，macOS使用安装包，Windows使用安装器，安装后用ollama --version确认版本。教学机房建议把模型目录迁到独立数据盘，通过OLLAMA_MODELS指定路径，避免系统盘被模型文件占满。服务监听地址用OLLAMA_HOST=127.0.0.1:11434保持本机访问，模型常驻时间用OLLAMA_KEEP_ALIVE=30m减少反复加载，并发数用OLLAMA_NUM_PARALLEL=2控制，同时加载模型数用OLLAMA_MAX_LOADED_MODELS=1限制，防止多模型争抢显存。NVIDIA显卡需要安装匹配的驱动，Ollama启动时会自动探测CUDA，Apple Silicon则走Metal后端。
部署完成后要建立可复现的基线记录。用ollama ps查看模型是否完全加载到GPU，用curl :11434/api/tags确认模型列表，用journalctl -u ollama查看Linux服务日志，macOS与Windows则查看用户目录下的Ollama日志文件。首次拉取模型后先跑一组固定问题，记录首 token 延迟、生成速度和显存峰值，再决定是否调整量化级别或上下文长度。教学场景中常见的问题是只验证了“能回答”，却没有记录模型版本和运行参数，后续换机器或换模型时无法复现效果。把Ollama版本、模型标签、量化格式、num_ctx和GPU占用写进部署说明，才算建立了可靠的本地基线。
2. DeepSeek模型选型与推理参数调优
模型选型要围绕任务复杂度和硬件上限做取舍。1.5B适合轻量问答和课堂演示，响应快但推理深度有限；7B与8B适合日常答疑、文本润色和简单代码解释；14B在16GB显存机器上性价比较高，能承担多轮教学对话和中等难度推理；32B适合需要更强逻辑链的课程设计、代码审查和复杂问答；70B及以上更适合有专业显卡或服务器的工作室。DeepSeek-R1不同规格采用不同蒸馏基座，实际表现不只看参数量，还要看中文理解、代码能力和长上下文稳定性。教学机优先选择Q4_K_M量化，它在体积、速度和输出质量之间比较均衡，显存紧张时再考虑更低比特量化，但要注意推理质量下降。
拉取与运行可以通过ollama pull deepseek-r1:14b和ollama run deepseek-r1:14b完成，长期使用则建议编写Modelfile固定参数。典型配置包括PARAMETER temperature 0.6、PARAMETER top_p 0.95、PARAMETER repeat_penalty 1.1、PARAMETER num_ctx 8192和PARAMETER num_predict 2048。DeepSeek-R1属于推理模型，温度通常落在0.5到0.7，数学与代码任务取0.6附近较稳，top_p取0.95可以保留一定多样性。上下文长度不要盲目拉满，R1虽然支持更长上下文，但Ollama默认上下文往往偏小，需要按显存逐步上调。若出现显存不足，可通过PARAMETER num_gpu控制卸载到GPU的层数，让部分层留在CPU内存，代价是生成速度下降。用ollama ps观察GPU与CPU比例，比凭感觉调参更可靠。
接口集成是参数调优后的下一步。Ollama提供/api/chat与/api/generate，也提供OpenAI兼容入口:11434/v1，教学工具和脚本可以把base_url指向本地服务，api_key填任意非空值即可。批量并发时要控制请求数，避免多个长上下文请求同时挤占显存。一个可复用的案例是24GB显卡运行32B Q4模型，把num_ctx设为8K、num_predict设为2048，先用课程问答集测试是否出现截断和重复，再根据ollama ps的GPU占用决定是否降低上下文。若回答开始重复或推理链过长，可适度提高repeat_penalty并缩短num_predict；若回答过于简略，则检查提示词是否要求分步解释，而不是单纯提高温度。
3. 本地知识库与教学工具链集成
把DeepSeek接入教学知识库，常见组合是Ollama加Open WebUI、AnythingLLM、Dify或LangChain。Open WebUI适合快速搭建带账号体系和文档上传的本地界面，可用Docker启动，命令中把host.docker.internal:11434作为Ollama地址，容器端口映射到本机3000。AnythingLLM桌面版适合个人教师快速导入PDF与Word，Dify适合需要工作流编排的团队，LangChain则适合把检索链路写进自有教研系统。无论选哪种前端，嵌入模型都不应直接复用DeepSeek-R1，而应单独拉取nomic-embed-text或bge-m3这类嵌入模型，由Ollama统一提供本地推理服务。
知识库效果取决于切分与检索策略。课程讲义按500到800字切分，重叠80字左右，保留标题和章节层级，避免把一道完整例题切成两半。检索top_k控制在4到6，提示词中明确要求“只依据检索内容回答，并标注来源段落”，可以减少模型编造。DeepSeek-R1擅长推理，但检索到的资料如果噪声过多，推理能力反而会放大错误，因此导入前要清理扫描版PDF的乱码和重复页。对于代码辅导场景，可把代码规范、常见报错和示例项目分成独立集合，检索时按问题类型路由，而不是把所有资料塞进一个向量库。
AI指导老师的典型工作流可以设计为课前资料入库、课中本地问答、课后记录复盘。教师把课程讲义、错题集和代码规范导入Open WebUI，学生通过内网地址提问，模型回答附带引用段落，教师再抽查回答是否忠实于资料。某类培训场景中，14B模型配合bge-m3和20份PDF讲义，在16GB显存机器上可以完成章节问答和术语解释，但遇到跨章节综合题时需要提高top_k并允许模型分步检索。所有学生数据应脱敏后再入库，知识库目录按课程和学期隔离，避免不同班级资料互相污染。工具链集成完成后，还要固定模型标签和嵌入模型版本，否则一次ollama pull更新就可能改变检索与生成效果。
4. 性能监控、故障排查与安全运维
日常运维先看三个信号：模型是否驻留GPU、显存是否接近上限、生成速度是否异常。ollama ps会显示模型加载位置和处理器比例，nvidia-smi用于观察显存与GPU利用率，Linux服务日志用journalctl -u ollama跟踪，macOS与Windows查看用户目录日志。/api/ps可以脚本化获取运行中模型，配合固定问题集记录tokens/s，能判断性能下降是模型变大、上下文变长还是CPU回退造成。教学机连续多人使用时，建议限制OLLAMA_NUM_PARALLEL并设置合理的keep_alive，避免模型频繁换入换出。
常见故障有显存不足、端口冲突、CPU回退和上下文溢出。显存不足时先降低num_ctx，再考虑换更小参数或更低比特量化，仍不够则用num_gpu做部分卸载。端口11434被占用可用lsof -i :11434定位，或通过OLLAMA_HOST=127.0.0.1:11435换端口。响应突然变慢要检查是否因显存不足回退到CPU，也要确认模型是否首次加载。上下文溢出表现为回答截断或忽略前文，需要缩短输入或提高num_ctx，但提高前要确认显存余量。Ollama升级后若输出风格变化，应回退到固定模型标签，并在测试端口用同一批问题对比。
安全运维的重点是访问边界和版本可控。OLLAMA_HOST=0.0.0.0会把服务暴露到局域网甚至公网，教学环境应保持127.0.0.1监听，确需共享时通过Nginx反向代理加认证和防火墙白名单。模型目录、Modelfile和知识库配置要纳入备份，模型标签固定到具体版本，避免latest标签漂移。学生姓名、成绩和内部讲义进入知识库前要脱敏，日志保留周期按机构规范设置。变更模型版本前先在测试端口拉起副本，用同一批问题对比输出质量与显存峰值，再替换生产实例。
