本文面向AI教学与本地部署场景，梳理Ollama运行DeepSeek的硬件选型、安装拉取、推理调优与教学集成方法。
本地大模型用于教学时，数据不出校、响应可控和成本可测是三个现实诉求，Ollama把模型下载、量化加载和接口服务封装成相对统一的操作路径，DeepSeek则在推理与代码理解上具备可用性。真正影响体验的并不是能否跑起来，而是模型规格与显存、上下文长度、并发策略和教学提示词是否匹配。下面从环境准备到课堂集成给出一条可复用的工程路径。
1. 环境准备与模型选型
本地运行DeepSeek前要先确认推理形态。Ollama中的DeepSeek-R1多为蒸馏版本，参数量从1.5B、7B、8B、14B、32B、70B到671B不等，1.5B适合低配设备做流程演示，7B和8B适合课程问答与文档摘要，14B和32B在代码解释、多步推理上更稳，70B以上通常需要服务器级显卡或多卡环境，671B不适合普通教学终端。量化文件以Q4_K_M最常用，7B权重约4到5GB，14B约9GB，32B约20GB，70B约40GB，实际占用还要加上KV缓存和运行时开销。AI指导老师应把“能加载”与“能稳定上课”分开评估，至少预留20%的显存或统一内存余量。
硬件侧，NVIDIA显卡需要较新的驱动和CUDA环境，8GB显存可覆盖7B/8B的Q4推理，12GB到16GB可尝试14B，24GB更适合32B，70B则要64GB以上显存或多卡；Apple Silicon依赖统一内存，16GB可跑7B/8B，32GB可覆盖14B并在较小上下文下试32B，64GB以上才有条件运行70B。CPU模式可用但生成速度受内存带宽限制，适合验证接口和低并发答疑。磁盘应预留模型目录空间，Ollama默认存放在用户目录，可通过OLLAMA_MODELS迁移到容量更大的盘。教学环境还要确认模型许可、教材版权和日志留存策略，避免把未授权资料放入公开模型服务。
2. Ollama部署与DeepSeek拉取
Ollama的安装按操作系统区分，Linux常用官方脚本完成安装并注册systemd服务，macOS和Windows使用安装包，容器环境可用Docker镜像并挂载模型目录。安装后通过ollama –version确认版本，用systemctl status ollama或ollama serve检查服务状态。模型拉取使用ollama pull deepseek-r1:7b，运行使用ollama run deepseek-r1:7b，ollama list查看已下载模型，ollama show deepseek-r1:7b查看参数规模、量化格式和模板。教学机建议把OLLAMA_MODELS指向独立数据盘，并在拉取前确认磁盘余量和网络代理，模型文件较大时断点续传失败要清理残留后重试。
默认参数不一定适合教学，建议用Modelfile固化配置。在Modelfile中用FROM指定基座，用PARAMETER num_ctx 8192控制上下文，用PARAMETER temperature 0.6和top_p 0.95贴近DeepSeek-R1的推荐采样，用PARAMETER num_gpu 99让Ollama尽量把层放到GPU，再执行ollama create deepseek-r1-7b-teach -f Modelfile生成教学专用模型。接口层可直接调用/api/generate或/api/chat，也可使用OpenAI兼容的/v1/chat/completions，方便接入现有客户端。若要让局域网内其他教师访问，可设置OLLAMA_HOST=0.0.0.0:11434，但必须配合防火墙、身份认证和反向代理，不能把11434端口直接暴露到公网。
拉取和运行阶段常见问题集中在模型名、显存和模板。模型名写错会返回not found，显存不足会触发CPU回退导致速度骤降，上下文设置过大则可能在长文档问答时OOM。教学部署应先用1.5B或7B跑通拉取、运行、API调用和日志记录链路，再替换为14B或32B做质量评估，避免一开始就在大模型上排查环境问题。
3. 推理参数与性能调优
Ollama的性能由显存容量、内存带宽、量化格式、上下文长度和并发数共同决定。num_gpu决定卸载到GPU的层数，数值过低会让部分层留在CPU，生成速度受PCIe和内存带宽拖累；num_ctx从4k提升到32k会显著增加KV缓存，7B模型在长上下文下也可能吃掉数GB显存。教学问答通常设置4k到8k上下文即可，课程文档检索可提高到16k，但要用实际显存监控确认不OOM。量化选择上Q4_K_M在质量和体积之间较平衡，Q5_K_M质量略好但占用更高，Q8_0接近原始精度却对消费级显卡不友好。
并发与常驻策略直接影响课堂体验。OLLAMA_NUM_PARALLEL控制同时处理的请求数，OLLAMA_MAX_LOADED_MODELS限制同时加载的模型数量，OLLAMA_KEEP_ALIVE决定模型空闲后保留多久。多人提问时把并行数调到2到4可减少排队，但会成倍增加KV缓存和显存压力；把keep_alive设为30m可避免频繁冷加载，适合连续授课。CPU推理可调整num_thread接近物理核心数，GPU推理则要关注驱动版本和CUDA/ROCm兼容性。调优时用ollama run –verbose观察eval rate和首token延迟，用固定提示集记录不同参数下的输出质量，不能只看生成速度。
实际调优应遵循从链路到质量的顺序。先用7B/8B在4k上下文下建立基线，记录显存占用、每秒生成token数和典型问题回答质量；再逐步增加上下文或换14B/32B，观察长文档问答是否因截断或KV缓存而退化；完成基线后再调整并行数和常驻时间。AI指导老师还应把温度参数按任务区分，知识问答用较低温度减少发散，头脑风暴和提示词生成可略高，但DeepSeek-R1的推理类任务不宜频繁改动采样参数，否则难以复现课堂效果。
4. 教学场景集成与效果评估
在教学场景中，Ollama更适合承担课程助教和代码教练两类角色。课程助教可接入Open WebUI、Dify或自建Web页面，通过/api/chat维持多轮对话，把课程大纲、实验手册和常见错误整理成系统提示词，要求模型先给思路再给答案；代码教练可接入VS Code的Continue插件，用7B/8B做代码解释和补全，用14B/32B做项目评审。若要做课程知识库问答，可用nomic-embed-text生成向量，配合Chroma或Qdrant做检索增强，把检索片段和问题一起送入DeepSeek，减少模型对校内资料的自由发挥。
教学集成要重点处理输出形态和边界。DeepSeek-R1可能展示推理过程，直接呈现给学生会造成认知负担，也会暴露不稳定的中间步骤，建议在系统提示中要求仅输出最终答案和关键步骤，并在前端隐藏思考内容。提示词应明确角色、课程范围、禁止编造和引用来源要求，对作业场景要限制直接给出完整答案，改为分步提示和自检清单。数据侧只把脱敏后的课程材料放入本地模型，日志记录问题、模型版本和参数，便于复盘。模型许可、教材版权和学生隐私应在部署前由教学团队确认。
效果评估不能只看回答是否流畅，而要建立小规模基准集。可以按课程章节整理30到50条问题，覆盖概念解释、代码纠错、实验步骤和开放讨论，由教师按准确性、教学性、安全性和延迟打分，记录幻觉率、拒答率和平均首token时间。7B/8B适合低延迟日常答疑，14B/32B适合复杂项目评审，70B以上只在服务器环境用于高价值任务。把评估结果与模型版本、量化格式、上下文长度绑定，后续升级Ollama或替换模型时才能判断课堂体验是否真的提升。
