使用教程
DeepSeek 模型选型指南：云端 API、本地部署怎么选
按数据边界、延迟并发与维护能力逐层排除，再比较云端与本地的成本项，最后决定先在哪一步试点。
6 分钟阅读
本文目录
先按任务分层，再谈部署方式
同一条业务里往往混着好几类任务，它们对部署方式的要求完全不同。先按下面五层拆开，再决定每层放哪里，比整体选一个方案更接近实际。
- 高频简单层：分类、打标签、意图识别、敏感信息脱敏。请求量大、单次很轻，对延迟敏感，对模型强度要求低。
- 内容生产层：草稿、改写、摘要、多语言转换。质量要求中等，通常可以异步，可以批量，可以重试。
- 结构化抽取层：把合同、工单、邮件整理成固定字段。对格式稳定性要求最高，一次不合法就要重跑，所以要专门测格式成功率。
- 代码辅助层：补全、解释、单测草稿、重构建议。既要低延迟又要求准确，而且代码本身可能是敏感资产。
- 复杂推理层：方案设计、跨文档分析、多步骤任务。频率低、单次贵，对延迟容忍度高。
拆完之后一般会发现：真正需要“最强模型”的只有最后一层，而真正卡数据边界的往往是前三层。
决策表：四个约束逐层排除
用法是从上往下问自己，第一个答不上来的那一行，就是当前的瓶颈所在。
- 数据边界：这类数据能不能离开指定环境？如果法规、合同或客户要求禁止外发，直接进入本地路径，不用再比较其他维度；如果可以外发但要脱敏，就先把脱敏层放到本地。
- 延迟与并发：峰值并发是多少，可接受的首字延迟是多少？交互式场景对首字延迟敏感，批量场景对吞吐敏感。并发波动大的业务，云端弹性更好；负载平稳且可预测的业务，本地的峰值冗余成本反而更容易算清。
- 维护能力：谁负责推理服务的升级、监控和故障处理？如果没有明确的人，本地部署会在第一次模型升级或显存报错时停摆。这是最常见的失败原因，而不是硬件不够。
- 任务强度匹配：这层任务真的需要大模型吗？分类和脱敏用小模型往往就够，把大模型留给复杂推理，成本结构会完全不同。
四个问题答完，结论通常是混合而不是二选一：边界敏感的部分放本地，质量敏感的部分放云端，中间加一层路由决定请求去哪。
云端 API 的成本项清单
云端的显性成本容易看到，隐性成本才是预算失准的原因。评估时至少把这些列进表里。
- 输入与输出分别计费：长材料反复作为上下文送入，输入侧会持续累积；输出越长越贵。把“每次任务的总 token”而不是“每次问答的 token”作为统计口径。
- 缓存与重复请求：相同前缀的重复计算、失败重试、超时重发都会计入消耗。
- 重试与兜底：解析失败重跑、降级到备用供应商，都属于有效成本。
- 人工返工：最难估也最常被漏掉。返工率高的任务，单价再低也不划算。
- 限流与配额：高峰被限流后，业务要么排队要么切供应商，两者都有代价。
- 数据合规与审计：日志留存、访问控制、供应商数据处理条款的确认工作，属于人力成本。
- 供应商切换成本：提示词、工具定义、输出解析都与具体接口绑定，换一次要重跑一轮评测。
本地部署的成本项清单
本地的成本结构完全不同：起步高、边际低，但要自己承担运维。
- 硬件：显存或统一内存决定能跑多大的模型，通常这一项就是预算主体。
- 电力与散热：长期满载运行的机房或工作站要考虑供电与散热改造。
- 工程时间：模型选型、量化、推理服务化、接口适配、压测，这些工作在第一次落地时占用最多时间。
- 持续维护：版本升级、依赖变动、显存溢出排查、日志与监控，是长期支出。
- 峰值冗余：本地容量按峰值准备，平时闲置的部分也是成本。
- 质量差距带来的返工：如果本地模型在某个任务上明显弱于云端，要么接受返工，要么为它单独设计流程。
混合方案怎么落地
混合不是“两个都部署”，而是明确请求分流规则。常见的三种做法：
- 前置本地：本地小模型先做分类、脱敏和意图识别，只有真正需要强推理的请求才出网。这样既减少外发数据量，也降低了云端调用次数。
- 前置云端，敏感回退：默认走云端，检测到敏感字段时自动切到本地。实现简单，但要求分类准确，否则会把敏感内容误发出去。
- 双供应商互备：同一任务配置主备两条通道，在质量、延迟或可用性下降时切换。需要预先验证两条通道的输出格式是否一致，否则下游解析会崩。
分流规则要能观测：每次请求记下走了哪条通道、为什么这样分流、耗时与结果是否合格。没有观测，混合方案很快就会退化成“谁响应用谁”。
统一评测表：六个维度
把云端与本地放在同一张表里比较，才谈得上选型。建议固定这六项，每项都要有可核对的记录方式。
- 任务成功率：能否满足预先定义的验收条件，按任务类型分别统计，不取平均。
- 人工返工比例：需要人改写、补全或推翻的比例，最接近真实成本。
- 首字延迟与完整耗时：区分用户体验指标和批处理吞吐指标。
- 并发能力：在目标并发下的成功率与延迟退化情况，而不是单请求的漂亮数字。
- 数据能力：保留策略、审计日志、权限控制、地区可用性。
- 可迁移性：升级、降级、退出与供应商切换的难度和预计工作量。
评测集建议从真实历史任务中抽取，包含至少两类你已经知道会失败的难题。全部由简单样本组成的评测集，任何方案都会看起来合格。
上线顺序与回退设计
- 先选一个只读、低风险、可回退的任务试点，例如工单分类或文档摘要。
- 保留输入、提示词、模型版本与失败样本，形成自己的回归集。
- 所有会产生外部影响的动作加人工确认点，不做全自动执行。
- 设定明确的回退触发条件（连续失败、延迟超限、成本超出预期），并提前写好回退步骤。
- 每周看误差分布而不是调用量，确认失败是否集中在某一类输入上。
如果团队还在评估云端服务本身的能力与限制，可以参考 DeepSeek 工具页了解能力定位，或在 对话问答分类里对比同类产品；长上下文任务的表现差异也可以先看 长上下文测试方法，自己设计一遍再决定是否依赖这一项。
模型规格、上下文长度、限流规则和计费方式变化很快，本文只提供评估方法，具体数字与条款请以 DeepSeek 官方文档为准。