📚 课程目录第4章大模型部署形态与场景

4、大模型部署形态与场景：在线推理、离线批处理、边缘部署、多租户服务等不同部署形态的适用场景与权衡

大模型从训练完成到真正产生业务价值，中间最关键的一环是部署。然而，部署并非“启动一个服务”那么简单。不同业务对延迟、吞吐、数据安全、成本的要求差异巨大：一个面向终端用户的智能客服系统需要毫秒级响应，一个离线文档解析任务可以接受数小时的处理时间，而一个部署在工厂车间的质检模型则必须运行在本地且不能联网。本章将系统拆解四种主流部署形态——在线推理、离线批处理、边缘部署、多租户服务，从核心原理、判断方法、实战案例到常见误区，帮助读者建立一套“按场景选型”的决策框架。

4.1 在线推理：低延迟交互的核心形态

核心原理

在线推理（Online Inference）指模型以常驻服务方式运行，接收实时请求并同步返回结果。其核心指标是端到端延迟（通常关注 P99 分位数）和并发吞吐（QPS）。在线推理服务通常部署在 GPU 集群上，通过负载均衡器分发请求，每个推理实例持有模型副本，利用批处理（Dynamic Batching）提升 GPU 利用率。当前主流框架如 vLLM、TensorRT-LLM、TGI 均针对在线推理做了 PagedAttention、Continuous Batching 等优化，以在延迟和吞吐间取得平衡。

判断方法

延迟敏感度：如果业务要求 2 秒内返回结果（如聊天机器人、实时翻译、代码补全），则必须选择在线推理。
流量模式：请求到达时间随机且不可预测，存在明显高峰低谷，需要弹性伸缩能力。
状态管理：多轮对话场景需要维护会话上下文（KV Cache），在线推理框架需支持前缀缓存或多轮对话优化。
可用性要求：SLA 要求 99.9% 以上，需要多副本部署、健康检查、自动故障转移。

案例拆解：智能客服系统的在线推理部署

某电商平台构建智能客服助手，基于 70B 参数开源模型微调。初始方案采用单节点 8×A100 部署，但上线后出现两个问题：高峰期 P99 延迟达到 4.2 秒（超过 3 秒的容忍阈值），且 GPU 利用率仅 35%。分析发现：请求文本长度差异大（平均 800 tokens，最长 4000 tokens），导致显存碎片化严重；同时框架未开启 Continuous Batching，短请求被长请求阻塞。

优化措施：① 切换至 vLLM 并启用 PagedAttention，显存利用率提升 60%；② 设置 max_num_seqs=256 和 max_model_len=8192，允许动态组合不同长度的请求；③ 部署 3 个副本，通过 K8s HPA 基于 QPS 和 GPU 利用率自动扩缩容。优化后 P99 延迟降至 1.8 秒，GPU 利用率提升至 72%，高峰期自动扩容至 5 副本，低谷期缩容至 2 副本，月度 GPU 成本下降 28%。

经验提醒：在线推理的延迟优化不能只看模型推理时间。网络传输、负载均衡、反序列化、Token 流式输出都会贡献延迟。建议端到端压测，并关注首 Token 延迟（TTFT）和 Token 间延迟（ITL）两个细分指标。

常见误区

盲目追求低延迟而忽略吞吐：将 Batch Size 设为 1 虽然延迟最低，但 GPU 利用率极低，成本翻倍。应通过压测找到延迟与吞吐的平衡点。
忽略冷启动：模型加载到显存需要 10-30 秒，弹性伸缩时新 Pod 无法立即服务。需配置预热探针（Readiness Probe）和最小副本数。
不区分流式与非流式：SSE 流式输出能显著改善用户感知延迟，但会增加连接管理和日志采集复杂度。

4.2 离线批处理：高吞吐的非实时计算

核心原理

离线批处理（Offline Batch Inference）面向非实时、大批量的数据处理任务，如历史日志分析、文档批量向量化、图像批量审核。其核心指标是总吞吐量（如每小时处理多少万条）和任务完成时间。批处理任务通常通过消息队列（如 Kafka、RabbitMQ）或工作流引擎（如 Argo Workflows、Airflow）触发，计算资源可以按需申请，任务结束后释放。由于不要求实时响应，可以采用更大的 Batch Size、模型量化（INT8/FP8）甚至多卡张量并行来最大化吞吐。

操作流程

任务拆分：将输入数据按文件、ID 范围或时间窗口切分为多个分片（Shard），每个分片作为一个独立任务单元。
队列调度：任务进入队列，Worker 从队列拉取任务并执行推理。
结果汇聚：推理结果写回对象存储或数据库，通过任务 ID 关联原始数据。
失败重试：设置最大重试次数（如 3 次），失败任务进入死信队列供人工排查。
资源释放：任务完成后自动缩容至零，避免空闲计费。

案例拆解：文档智能解析批处理平台

某法律科技公司需要将 500 万份历史合同进行信息抽取（当事人、金额、日期）。每份合同约 3000 tokens，使用 13B 模型。若采用在线推理，按每份 0.5 秒计算，单卡需连续运行 29 天，且高峰期排队严重。改为批处理架构后：使用 20 台 8×A10 实例（共 160 卡），通过 Argo Workflows 将任务拆分为 5000 个分片（每片 1000 份合同），每个分片内使用动态 Batch Size 32 进行推理。实际运行 11 小时完成全部处理，平均吞吐达到 126 份/秒。成本方面，使用抢占式实例（Spot Instance）进一步降低 60% 费用，整体处理成本仅为在线方案的 1/5。

关键参数参考：

# 批处理任务资源配置示例
resources:
  requests:
    nvidia.com/gpu: 8
  limits:
    nvidia.com/gpu: 8
# 批处理框架参数
batch_size: 32
max_retries: 3
timeout_seconds: 3600
queue: contracts-batch-v1

常见误区

忽略数据倾斜：部分分片包含超长文档，导致该分片处理时间远高于平均。需在拆分时按 Token 数而非文件数进行均衡。
检查点缺失：任务中途失败后若不能从断点恢复，将浪费大量已计算资源。建议每处理 100 条记录保存一次检查点。
结果写入瓶颈：高吞吐推理后，结果写入数据库可能成为新瓶颈。建议先写临时文件，再批量导入。

4.3 边缘部署：数据本地化与低延迟的极致

核心原理

边缘部署（Edge Deployment）将模型运行在靠近数据源的设备上，如工厂工控机、医疗影像设备、手机终端、车载计算平台。其核心驱动力是数据隐私合规（如医疗数据不能出医院）和网络不可靠（如海上钻井平台无稳定网络）。边缘部署面临严格的资源约束：CPU/GPU 算力有限、内存小、功耗受限。因此需要模型压缩技术（量化、剪枝、蒸馏）和轻量级推理引擎（ONNX Runtime、TensorRT、OpenVINO、llama.cpp）。

判断方法

判断维度	适合边缘部署	不适合边缘部署
网络条件	弱网、无网、高延迟网络	稳定低延迟专线
数据合规	数据禁止出域（医疗/政务/军工）	数据可脱敏后上传云端
模型规模	7B 以下（量化后）	70B 以上超大模型
硬件预算	已有边缘设备或可采购专用硬件	无硬件预算，依赖云资源
更新频率	模型版本更新不频繁（周/月级）	需要每日更新模型

案例拆解：工厂质检场景的边缘部署

某汽车零部件工厂需要在产线上实时检测零件表面缺陷。原始方案将高清摄像头图像（2048×2048）上传至云端 GPU 服务器推理，但产线节拍要求每件检测时间不超过 800ms，而网络传输+云端推理平均耗时 1.6 秒，且断网时产线停摆。改造方案：在产线旁部署一台配备 RTX 4000 Ada（20GB 显存）的工控机，将原 13B 视觉语言模型蒸馏为 3B 模型，并量化至 INT8。通过 TensorRT 优化后，单张图像推理耗时 420ms，满足节拍要求。模型更新采用离线方式：每两周由工程师携带移动硬盘到现场更新模型文件，通过版本管理工具切换。该方案使产线效率提升 30%，且彻底消除了网络依赖。

风险提示：边缘设备的硬件故障率高于云端服务器，且缺乏远程运维手段。建议：① 设备内置双系统冗余（A/B 分区），系统升级失败可自动回滚；② 定期上报健康状态（CPU/内存/温度）至中心端；③ 为关键设备配置 UPS 电源，防止突然断电损坏模型文件。

常见误区

过度压缩导致精度不可接受：量化到 INT4 可能使准确率下降 5% 以上。建议先在验证集上评估量化前后指标差异，设定可接受阈值。
忽略推理引擎的硬件适配：TensorRT 仅支持 NVIDIA GPU，OpenVINO 对 Intel 平台优化更好。选型需与硬件绑定。
边缘设备缺乏监控：模型漂移（数据分布变化）在边缘场景更隐蔽，需定期回传少量样本进行质量监控。

4.4 多租户服务：资源共享与隔离的平衡

核心原理

多租户服务（Multi-tenant Serving）指多个业务方（租户）共享同一套模型推理基础设施，但彼此在资源、数据、性能上相互隔离。典型场景包括：云厂商的模型 API 服务（如 OpenAI API）、企业内部多个部门共享大模型平台。多租户的核心挑战是公平调度与性能隔离——一个租户的突发流量不应影响其他租户的延迟。实现方式包括：K8s 命名空间隔离、GPU 时间片切分（MIG）、请求级优先级队列、租户级配额（Rate Limit）。

关键设计维度

维度	方案选项	权衡点
资源隔离	独立实例 / GPU MIG / 共享池	隔离性越强，资源利用率越低
调度策略	FIFO / 加权公平队列 / 优先级抢占	公平性 vs 重要租户的 SLA
数据隔离	租户 ID 前缀 / 独立数据库 / 加密	实现复杂度与安全等级
计费模式	按 Token 数 / 按调用次数 / 按 GPU 时长	业务友好度 vs 成本核算精度

案例拆解：企业内部大模型平台的多租户改造

某大型银行建设了统一的大模型推理平台，服务零售、风控、法务三个部门。初期采用“每个部门一套独立 GPU 集群”模式，导致资源利用率不足 30%，且运维成本高。改造为多租户架构：使用 K8s + KServe 部署共享的 8 节点 A100 集群，每个部门一个 Namespace，设置资源配额（零售部 40% GPU、风控部 35%、法务部 25%）。引入 Istio 进行流量管理，配置租户级 Rate Limit（零售部 100 QPS、风控部 50 QPS、法务部 20 QPS）。同时实现 Token 级计费，各部门按月分摊成本。改造后 GPU 利用率提升至 68%，但出现一个新问题：零售部的突发流量（营销活动期间）会挤占风控部的算力，导致风控模型延迟从 800ms 升至 2.1 秒。解决方案：为风控部设置优先级标签，调度器优先处理高优先级租户的请求，并设置弹性配额——当风控部利用率超过 80% 时，自动从零售部借用 10% 配额。

多租户调度策略伪代码：

# 加权公平队列调度简化逻辑
def schedule(request):
    tenant = request.tenant_id
    if tenant.priority == "high":
        queue = high_priority_queue
    else:
        queue = normal_priority_queue
    if tenant.usage > tenant.quota:
        return 429  # Too Many Requests
    if gpu_available():
        dispatch(request)
    else:
        queue.enqueue(request, weight=tenant.weight)

常见误区

只做资源隔离，不做性能隔离：即使 GPU 资源按配额分配，共享显存带宽和 L2 缓存仍可能互相干扰。需监控 IPC（每周期指令数）和显存带宽指标。
配额设置过于刚性：固定配额导致资源闲置时其他租户也无法使用。建议采用弹性配额（Borrow/Return 机制）。
忽略租户间的数据隐私：共享模型时，需确保 Prompt 和输出结果不泄露给其他租户。建议在网关层做租户 ID 校验和日志脱敏。

4.5 部署形态对比与选型总结

对比维度	在线推理	离线批处理	边缘部署	多租户服务
核心指标	P99 延迟 / QPS	吞吐 / 完成时间	单次延迟 / 功耗	隔离性 / 公平性
GPU 利用率	中（40-70%）	高（80-95%）	低（受限于设备）	中高（60-80%）
典型成本	高（常驻资源）	中（按需弹性）	中（硬件采购）	中（共享摊薄）
运维复杂度	中	低	高（分散设备）	高（多租户管理）
适用模型规模	7B-70B	7B-70B+	≤7B（量化后）	7B-70B

在实际项目中，这四种形态并非互斥。一个完整的大模型应用可能同时包含多种部署形态：例如，智能客服系统使用在线推理处理实时对话，同时每天凌晨通过离线批处理更新知识库向量索引，而敏感数据的处理则通过边缘部署在客户本地完成。选型的关键在于明确业务的核心约束——是延迟优先、成本优先、数据安全优先，还是资源效率优先。建议团队在项目初期完成一次部署形态评估，输出包含延迟预算、吞吐预估、数据合规要求、硬件预算、运维能力的决策矩阵，再结合本章的框架进行组合设计。

复盘建议：每季度回顾一次部署形态是否仍然匹配业务需求。常见触发调整的信号包括：① 业务量增长导致在线推理成本失控；② 新增数据合规要求；③ 模型升级后体积变化超出边缘设备容量；④ 多租户平台出现频繁的租户投诉。及时调整部署形态，往往比盲目优化单一指标更有效。