围绕DeepSeek模型选型、推理框架配置、教学场景调优与运维成本控制，给出可落地的私有化部署路径与AI指导老师应用方法。
DeepSeek模型进入教学业务后，挑战已经从“能否运行”转为“能否稳定、可控、低成本地服务学生”。AI指导老师既需要学科知识准确，又需要多轮对话、低延迟和内容安全。下面从环境评估、框架配置、场景调优和运维迭代四个层面展开，给出可执行的部署与使用方法。
1. 环境评估与模型选型
DeepSeek模型并非单一权重，而是覆盖通用对话、推理、代码和多模态的模型族。以DeepSeek-V3为例，总参数671B，MoE结构激活约37B，FP8权重文件接近671GB；DeepSeek-R1同量级，推理时还需要额外KV cache和激活显存。若用BF16加载，权重超过1.3TB，普通八卡H800单机640GB显存放不下FP8全量，需要八卡H200的1128GB或多机H800，或采用AWQ、GPTQ、GGUF量化。蒸馏版从1.5B、7B、8B、14B、32B到70B，32B的BF16权重约64GB，单卡80GB可运行但上下文和并发余量有限，4-bit量化后约20GB，单卡48GB即可起步；70B的BF16约140GB，通常需要两张80GB卡，4-bit约40GB可在单卡80GB上运行。选型要先明确任务是通用答疑、数学推理还是代码辅导，R1系列更适合需要显式推理链的题目讲解，V3更适合高并发通用对话。
硬件评估不能只看显存总量，还要看GPU互联、CPU内存、磁盘吞吐和网络。多机部署MoE模型时，节点间至少需要高速RDMA或InfiniBand，否则专家并行通信会成为瓶颈；模型权重从对象存储拉取时，磁盘顺序读建议不低于1GB/s，否则冷启动时间过长。软件侧应统一CUDA 12.x、PyTorch、驱动和推理框架版本，避免同一集群出现驱动不一致导致的NCCL通信故障。对AI指导老师场景，若机构已有课程知识库和题库，优先选择32B蒸馏模型做私有化起步，用两台A100 80GB或单台H100 80GB承载，既能保留中文教学表达能力，又便于后续扩容；只有在高难度理科推理和多轮追问质量要求很高时，才上671B全量模型。
数据与合规评估同样应在部署前完成。教学数据涉及未成年人信息，模型服务需要与业务库隔离，日志脱敏后再落盘，权重和知识库放在内网对象存储，API网关只暴露必要端口。若采用云上GPU，需确认地域、数据出境和等保要求；若采用本地机房，要核算机柜功率和散热，八卡H800整机功耗可达10kW量级，普通机房往往需要改造。把模型选型、硬件预算、合规边界放在同一张评估表中，才能避免先买卡再发现模型跑不动或业务不能用。
2. 推理框架与部署配置
框架选择决定部署效率和后续运维成本。面向DeepSeek全量MoE模型，vLLM和SGLang是生产环境常用选择，前者OpenAI兼容接口成熟、社区插件多，后者对多轮对话前缀复用和MoE调度有针对性优化；TensorRT-LLM适合追求极致吞吐且有专门编译调优团队的场景；llama.cpp与Ollama更适合GGUF量化的蒸馏模型和边缘验证。以vLLM部署DeepSeek-V3 FP8为例，典型启动参数包括–tensor-parallel-size 8、–max-model-len 32768、–gpu-memory-utilization 0.9和–enable-prefix-caching，张量并行度要与GPU数量匹配，最大上下文要按显存余量逐步上调，不能直接拉到模型上限。DeepSeek系列使用MLA注意力，KV cache相对同规模模型更省，但仍需为并发请求预留空间。
容器化部署要把权重、配置和密钥分离。镜像内只放推理框架和依赖，权重通过挂载卷或启动时从内网对象存储下载，API密钥由环境变量或密钥管理服务注入，禁止写进镜像。Kubernetes部署时，为GPU节点打标签，使用nvidia device plugin分配整卡，readiness探针检查/v1/models接口，liveness探针检查进程和显存状态；多机多卡场景要配置hostNetwork或RDMA设备插件，并固定NCCL参数。启动后先用短请求验证模型输出，再用长上下文请求检查KV cache分配，最后用并发压测观察是否出现OOM。对32B蒸馏模型，单卡A100 80GB可设置–tensor-parallel-size 1、–max-model-len 16384，开启连续批处理和前缀缓存，能明显改善多轮教学对话的首token延迟。
API层要承担鉴权、限流、审计和协议适配。推理框架暴露OpenAI兼容接口后，业务侧不要直接调用GPU服务，而应经过网关统一做API key校验、按租户限流、请求日志脱敏和超时重试。AI指导老师常有流式输出需求，网关要支持SSE透传，避免缓冲导致学生端等待。上线前按真实教学请求做压测，记录不同并发下的首token时延、每token时延和错误率，再反推单卡可承载的并发数。若使用SGLang，可关注RadixAttention对系统提示和教材片段的复用效果；若使用vLLM，应观察gpu_cache_usage_perc和等待队列，缓存占用长期高于0.9时要么降低最大上下文，要么增加副本。
3. 教学场景的调用调优
AI指导老师的效果很大程度取决于调用而非单纯模型规模。系统提示要明确角色边界、学段、学科和回答格式，例如要求先判断题目考点，再给出分步提示，最后才给答案；对低年级学生要控制术语密度，对高中生可保留公式推导。DeepSeek-R1系列会返回reasoning_content字段，业务端应只把最终答案流式展示给学生，思维链写入审计日志供教师复盘，不能直接暴露，否则既影响体验也可能泄露内部提示。温度设置要按任务区分，数学和物理计算建议0.2到0.4，开放讨论可到0.7；max_tokens要结合学段控制，避免长篇输出拖慢课堂互动。多轮对话要保留最近若干轮摘要而非无限拼接历史，防止上下文膨胀。
知识准确性要靠检索增强和工具调用补齐。把教材、课程标准、校本题库按500到800字分块，重叠100字，使用bge-m3等中文嵌入模型写入Milvus或pgvector，检索时取top-k 6到8条，再用重排模型筛到3到4条注入提示词。数学题可接入计算工具或代码执行器，让模型负责拆解步骤、工具负责验算，降低计算幻觉。某K12机构在32B蒸馏模型上做学科问答时，将题库标准答案和解析作为检索源，并把“不确定时先追问”写进系统提示，人工抽检的答案可用率从直接生成的约七成提升到九成左右，代价是平均响应多出数百毫秒。这个权衡在教学场景通常值得，因为错答的修复成本远高于一次检索。
评测和安全要贯穿调优过程。建立覆盖学科、学段和题型的小型评测集，至少包含500条真实问题，分别统计答案正确率、步骤完整性、幻觉率和拒答率；对R1蒸馏模型还要检查思维链是否冗长、是否在简单题上过度推理。未成年人场景需要内容过滤和教师兜底，涉及心理、医疗和法律的问题应转人工或给出明确边界。流式输出要支持中断，学生点击停止后网关应取消上游请求，释放KV cache。对话缓存可按“学科+知识点+题型”做前缀复用，把系统提示和教材片段放在请求前部，能提高前缀命中率并降低首token延迟。
4. 运维监控与成本迭代
生产环境要把推理服务当作有状态的基础设施来监控。GPU层关注利用率、显存占用、温度、功耗和ECC错误；推理层关注运行中请求数、等待队列、KV cache使用率、首token时延、每token时延和吞吐；业务层关注会话完成率、流式中断率、用户负反馈和转人工率。vLLM和SGLang都暴露Prometheus指标，可用Grafana做面板，按模型版本、租户和接口维度拆分。告警阈值要结合压测基线设置，例如gpu_cache_usage_perc持续超过0.95、首token时延P95超过3秒或错误率超过1%时触发告警。日志中保留请求ID、模型版本、输入输出token数和耗时，但学生原文和思维链要脱敏或加密存储。
成本控制要从容量和调度两端入手。全量671B模型按八卡H200或多机H800部署，单月GPU折旧或租赁成本很高，适合高价值推理和教师侧辅助；面向大规模学生答疑的常规问题，用32B蒸馏模型或按流量拆分到小模型，能把单位请求成本降一个量级。推理侧开启连续批处理、前缀缓存和合理的最大上下文，避免为极少数超长请求长期预留大量KV cache；对夜间低峰设置最小副本数，白天按队列长度扩容。量化要经过评测再上线，4-bit模型在通用问答上往往可用，但理科推导可能出现步骤跳跃，需要用同一套评测集对比BF16基线，确认正确率下降在可接受范围内。
模型和配置迭代要灰度进行。新权重先在小流量租户验证，比较首token时延、答案正确率和负反馈，再逐步扩大比例；保留上一版本权重、启动参数和容器镜像，出现异常可在分钟级回滚。教学场景还要定期更新知识库和提示词模板，把教师复盘中的典型错题加入评测集，形成“线上反馈、离线评测、灰度发布”的闭环。容量规划按学期和考试季峰值预留余量，至少保留20%到30%的GPU缓冲，避免临时扩容受限于机房资源和采购周期。当评测指标稳定且灰度反馈无异常时，再扩大流量比例，并保留上一版本权重与配置以便快速回滚。
