企业引入大模型通常同时面临三个约束:数据不可出内网、调用量增长后公有云 API 成本不可控、以及缺乏把推理服务稳定运行起来的能力。私有化部署能同时满足这三条,但前提是服务必须真正承载生产负载,而不是停留在可演示状态。
服务范围:推理侧
硬件选型:按模型参数量、上下文长度、并发会话数与批量规模反推显存需求,再确定卡型与卡数。选型依据是算得出的显存预算,不是可承受的预算金额。
部署与调优:推理框架部署、模型加载策略、批处理机制、并发调度、显存管理、长时稳定性验证。
① 批处理机制
文档处理、票据整理、数据核对类任务的负载形态是批量运行,不是对话。逐条请求的吞吐无法覆盖真实工作量,需要实现任务队列与批提交,把请求聚合后统一处理。
这也是自建推理相对公有云 API 的成本分界点:批处理场景下单位成本相差数量级,前提是批处理机制真正落地而非仅配置参数。
② 并发调度
多人同时使用需要处理三个问题:请求排队、超时控制、优先级配置。业务高峰期与日常查询的负载量级不同,优先级必须可配置,否则紧急请求会排在队尾。长请求与短请求混跑时的调度策略需单独设计。
③ 显存管理
显存需要同时容纳模型权重、KV Cache、批输入与并发会话。管理不到位时的典型表现是:批量增大即显存溢出、并发升高即吞吐下降、显存未满却出现排队等待。
调优目标是显存占用与排队行为可预测,而非把显存占满。
不做什么
模型微调与训练不在服务范围内。推理部署与模型训练是两个方向的能力要求,我会明确说明,避免客户形成错误预期。
适用场景
- 数据不可出厂区:财务、法务、研发、人事、客户资料
- 批量处理量大,公有云 API 费用不可承受:文档处理、票据整理、数据核对
- 内网为主、无公网出口,或外网访问需受控
- 审计要求高:谁在何时查询了什么,日志须留存于本地
交付内容
- 硬件选型方案与显存预算测算
- 部署架构与配置文件
- 并发与批处理参数调优记录
- 长时稳定性验证记录
- 运维手册与故障处置预案