围绕Ollama本地运行DeepSeek，讲清环境配置、模型选型、推理调优与教学落地，给出可复现的实战路径和避坑要点。
本地大模型正在从演示环境走进教研与实训场景，Ollama把模型下载、量化加载和服务暴露收敛为几条命令，DeepSeek-R1系列则提供了从1.5B到671B的推理模型选择。对AI指导老师而言，关键不在于把参数最大的模型跑起来，而在于用可控的硬件成本获得稳定的课堂答疑、代码辅导和备课辅助能力。下面以工程落地为主线，拆解环境准备、模型选型、参数调优和教学评估四个环节。
1. 环境准备与Ollama服务配置
部署前需要先确认硬件边界。Ollama支持macOS、Windows和Linux，GPU加速覆盖NVIDIA CUDA、AMD ROCm以及Apple Metal。以教学机房常见的RTX 3060 12GB为例，运行7B或8B的Q4量化模型比较从容，14B模型则建议24GB显存；如果只有CPU，32B以上模型会出现明显的首token延迟。磁盘空间要预留模型文件与量化缓存的余量，DeepSeek-R1 7B的Q4文件通常在5GB左右，14B约10GB，32B约20GB，模型目录建议挂载到独立数据盘。Linux环境可用官方脚本安装，执行curl -fsSL | sh后由systemd托管服务；Windows和macOS直接安装桌面程序即可。
服务配置决定后续能否被教学平台调用。默认监听127.0.0.1:11434，若要让局域网内的学生终端访问，需要设置OLLAMA_HOST=0.0.0.0:11434并重启服务，同时确认防火墙放行端口。模型存储路径通过OLLAMA_MODELS指定，避免系统盘被占满；多用户场景还要关注OLLAMA_NUM_PARALLEL和OLLAMA_MAX_LOADED_MODELS，防止并发请求把显存打爆。拉取模型时执行ollama pull deepseek-r1:7b，完成后用ollama list确认标签，再用ollama run做一次简单推理，观察ollama ps中GPU占用是否正常。
常见故障集中在权限、代理和GPU识别三处。Linux下非root用户运行服务需要把账号加入ollama组，否则会出现模型目录不可写；企业网络内拉取模型失败时，要为服务进程配置HTTP_PROXY和HTTPS_PROXY，而不是只在当前终端设置。若ollama ps显示纯CPU推理，先检查nvidia-smi是否正常，再查看journalctl -u ollama日志中的CUDA初始化信息，必要时设置OLLAMA_DEBUG=1定位。教学环境还应固定模型版本标签，避免课堂演示时因自动更新导致行为漂移。
2. DeepSeek模型选型与量化策略
Ollama模型库中的DeepSeek-R1包含多个蒸馏版本，常见标签有1.5B、7B、8B、14B、32B、70B和671B。1.5B适合提示词验证和低配笔记本演示，7B与8B是课堂答疑的主力，14B在数学推理和代码解释上更稳，32B适合教师备课与复杂任务，70B以上则需要多卡或高内存服务器。选型时不要只看参数量，还要看模型卡上的上下文长度和量化格式；Ollama默认提供Q4_K_M量化，它在显存占用和精度之间比较均衡，Q8_0精度更高但显存需求接近翻倍。
显存估算要同时考虑模型权重和KV缓存。7B的Q4模型权重约4.5GB，加上4K上下文和运行时开销，实际占用约5GB到6GB；14B的Q4约9GB到10GB，32B的Q4约19GB到21GB。若把num_ctx从4096提高到16384，KV缓存会明显增长，长文档问答前要先做压力测试。教学场景中，代码辅导需要较完整的上下文，建议14B起步并设置8K上下文；通识答疑用7B配合4K上下文即可，把省下的显存留给并发。
量化策略要服从教学任务而不是追求跑分。Q4_K_M在中文问答和Python代码解释上的退化通常可以接受，若发现模型频繁出现符号错误或步骤跳跃，可切换到Q5_K_M或Q8_0做对比实验，并把差异记录到课程案例中。AI指导老师还应建立模型基线表，记录每个模型在固定题目集上的准确率、平均响应时长和显存峰值，避免凭感觉切换模型。对于需要离线运行的实训室，建议只保留两到三个标签，减少磁盘和维护成本。
3. 推理参数调优与API集成
Ollama通过Modelfile把推理参数固化下来，适合教学平台统一调用。常见做法是新建一个Modelfile，写入FROM deepseek-r1:7b，再用PARAMETER num_ctx 8192扩大上下文，PARAMETER temperature 0.3降低发散，PARAMETER top_p 0.9控制采样范围，PARAMETER repeat_penalty 1.1抑制重复。需要限制GPU层数时可设置num_gpu，混合CPU推理时它直接影响速度。执行ollama create teaching-r1 -f Modelfile后，平台只需引用teaching-r1这个名称，参数就不会因终端环境不同而漂移。
接口层有两种接入。原生/api/chat适合需要完整控制消息角色的场景，请求体包含model、messages和stream字段，流式返回便于课堂大屏逐字展示；OpenAI兼容端点位于:11434/v1，可以直接复用openai Python SDK，把base_url指向本地服务、api_key填任意非空字符串即可。并发教学时要在服务端设置OLLAMA_NUM_PARALLEL=4，并在应用层加排队和超时，避免三十名学生同时提问导致请求堆积。对需要反复调用的答疑机器人，可以用keep_alive延长模型驻留时间，减少冷启动。
调优效果要用指标说话。以一台RTX 4090 24GB运行deepseek-r1:14b Q4为例，4K上下文下单请求首token延迟约0.6秒到1秒，生成速度约25到35 tokens/s；并发提到4路后首token延迟会上升到2秒左右，生成速度分摊下降。教学问答可接受2秒内首token，代码辅导则要控制上下文长度，避免把整份工程文件塞进提示词导致延迟失控。日志中应记录请求耗时、token数和错误码，便于定位是模型能力问题还是服务容量问题。
4. 教学场景实战与效果评估
AI指导老师的落地场景可以分成备课、答疑和代码辅导三类。备课时用14B或32B模型生成分层练习题、知识点拆解和课堂案例，再把输出交给教师修订；答疑场景用7B模型配合固定提示词，要求学生先描述已尝试的步骤，模型再给出下一步提示，避免直接给答案；代码辅导需要把报错信息、相关代码片段和运行环境一起送入模型，并限制回答必须包含复现步骤和修改建议。若要接入课程资料，可用nomic-embed-text生成向量，在应用层做检索增强，把命中的讲义片段拼进提示词，减少模型凭空编造。
一个可复用的实训室案例是：配备RTX 4090的机房部署Ollama，拉取deepseek-r1:14b的Q4版本，设置8K上下文和4路并发，通过OpenAI兼容接口接入校内问答页面。三十名学生分六组轮转使用，页面记录每次提问的耗时与人工评分。运行两周后统计，通识答疑的首token中位数约1.1秒，代码报错解释的可用率约八成，教师主要反馈是模型对课程专有术语不熟，后来通过检索增强和术语表提示词把可用率提高到九成左右。这个案例说明，教学效果更多取决于提示词、资料和流程设计，而不是单纯堆参数。
效果评估要建立可操作的指标组合。响应侧看首token延迟、生成速度和并发失败率，质量侧看固定题集的准确率、步骤完整性和幻觉率，教学侧看学生是否能在提示后独立完成任务。每周抽取一部分对话做人工复核，把典型错误回流到提示词库和检索库。风险控制同样重要，学生数据要脱敏后再送入模型，代码执行必须放在沙箱，作业批改结果只能作为辅助意见。模型版本、参数和评估集要一起归档，确保下一轮教学迭代有据可查。
