2、AI模型部署基础：模型部署的常见方式（在线推理、批处理、边缘部署）及安全挑战

2.1 三种部署方式的核心原理与适用边界

模型部署的本质是将训练完成的模型参数、推理逻辑与运行时依赖打包为可对外提供服务的形态。根据延迟敏感度、数据驻留位置和算力分布的不同，生产环境通常划分为三种部署范式：在线推理（Online Inference）、批处理（Batch Processing）和边缘部署（Edge Deployment）。三者并非互斥，实际系统中常以混合架构共存。

维度	在线推理	批处理	边缘部署
触发方式	单条请求实时触发	定时/事件批量触发	本地事件或离线缓存触发
延迟要求	P99 < 200ms（典型）	分钟~小时级	P99 < 50ms（本地）
数据流方向	客户端 → 服务端 → 返回	存储系统 → 计算集群 → 存储	传感器/本地库 → 边缘节点 → 本地消费
典型算力	GPU/CPU 集群，水平扩展	大规模CPU/GPU 弹性作业	嵌入式GPU/NPU/CPU，功耗受限
网络依赖	强依赖，断网即不可用	弱依赖，可断点续跑	弱依赖，支持本地自治

在线推理的核心矛盾在于并发与延迟的权衡。每次请求独立走完“预处理→模型前向→后处理”全链路，需要常驻内存的模型副本和负载均衡器。批处理则通过窗口聚合（如每5分钟或每1000条）提高GPU利用率，但牺牲了实时性。边缘部署将推理下沉到数据产生端，解决带宽和隐私问题，但模型体积和算力受限。

选型判断依据：若业务要求“用户点击后立即返回结果”，选在线推理；若业务是“夜间结算、批量审核、离线特征生成”，选批处理；若业务发生在弱网环境或涉及敏感数据（如医疗影像、工业质检），优先考虑边缘部署。

2.2 三种部署方式的工程实现路径

2.2.1 在线推理：模型服务化与弹性伸缩

在线推理的标准链路包含API网关 → 推理服务 → 模型仓库 → 监控告警。模型需封装为无状态服务，通过容器化（Docker）和编排平台（Kubernetes）管理生命周期。关键参数包括：max_batch_size（动态批处理上限）、instance_per_model（模型副本数）、timeout_ms（超时熔断阈值）。

# 在线推理服务配置示例（Kubernetes Deployment）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: resnet50-online
spec:
  replicas: 4
  template:
    spec:
      containers:
      - name: predictor
        image: registry.internal/ai/resnet50:2.1.0
        env:
        - name: MODEL_NAME
          value: "resnet50_v2"
        - name: MAX_BATCH_SIZE
          value: "8"
        resources:
          limits:
            nvidia.com/gpu: 1
        livenessProbe:
          httpGet:
            path: /health
            port: 8501
          initialDelaySeconds: 30

安全要点：在线推理暴露在公网或内网，必须启用身份认证（JWT/mTLS）、请求体大小限制（防止恶意超大输入）、速率限制（防爬虫/DoS）。模型文件应存储在私有仓库，禁止通过URL直接加载外部模型。

2.2.2 批处理：作业编排与容错

批处理通常使用工作流引擎（如Argo Workflows、Apache Airflow）或云原生Job。核心流程为：数据切分 → 分布式推理 → 结果聚合 → 异常重试。需关注数据倾斜和检查点（Checkpoint）设计。

# 批处理作业提交（Argo Workflow 片段）
apiVersion: argoproj.io/v1alpha1
kind: Workflow
spec:
  entrypoint: batch-infer
  templates:
  - name: batch-infer
    steps:
    - - name: split-data
        template: spark-split
    - - name: infer-shard
        template: model-infer
        arguments:
          parameters: [{name: shard_id, value: "{{item}}"}]
        withSequence: {start: "0", end: "9"}
    - - name: merge-results
        template: hive-merge

批处理的安全挑战集中在数据泄露和作业投毒。中间结果可能落盘到共享存储，必须加密（如KMS管理的AES-256）。同时，要校验输入数据的哈希值，防止恶意构造的数据导致模型输出偏差（数据投毒攻击）。

2.2.3 边缘部署：模型压缩与离线自治

边缘部署需将模型转换为轻量格式（TensorRT、ONNX Runtime、TFLite），并量化到INT8或FP16。典型流程：模型剪枝 → 量化 → 编译 → 固件打包。边缘节点需具备本地缓存和断网续跑能力。

# 边缘设备模型转换（TensorRT）
trtexec --onnx=model_fp32.onnx \
        --saveEngine=model_fp16.engine \
        --fp16 \
        --workspace=2048 \
        --minShapes=input:1x3x224x224 \
        --optShapes=input:8x3x224x224 \
        --maxShapes=input:16x3x224x224

边缘安全需关注物理攻击（设备被盗导致模型参数泄露）和模型窃取。应对措施包括：将模型加密存储在安全芯片（TEE/SE）中，推理时仅解密到内存；对模型输出添加水印或指纹；定期远程更新模型并校验签名。

2.3 安全挑战全景：从模型到管道的四层风险

三种部署方式共享一套安全威胁模型，但风险优先级不同。下图展示了从模型层→数据层→系统层→网络层的威胁传导路径。

从上图可见，在线推理的主要暴露面在网络层和系统层（API被扫描、容器逃逸）；批处理的风险集中在数据层（中间结果泄露、作业依赖投毒）；边缘部署则面临模型层和物理层威胁（设备丢失、固件逆向）。

2.4 实战案例：金融风控模型的多模式部署

某银行信用卡反欺诈系统采用混合部署架构：

在线推理：交易发生时，通过API网关调用部署在私有云GPU集群的欺诈检测模型，要求P99延迟<100ms。安全措施：mTLS双向认证、每用户QPS限制、请求体加密（AES-GCM）。
批处理：每日凌晨对全量历史交易进行回溯评分，使用Spark + TensorFlow on YARN。安全措施：中间结果写入加密HDFS，作业参数签名校验，禁止动态加载外部UDF。
边缘部署：在ATM机和POS终端部署轻量化模型（量化至INT8，体积从350MB压缩至45MB），用于断网场景的本地欺诈拦截。安全措施：模型加密存储在安全SD卡，每次启动校验固件签名，远程更新需双人授权。

事故复盘：该银行曾因在线推理API未设置速率限制，被攻击者用脚本高频调用，通过对比不同输入的置信度差异，成功逆向出模型决策边界（模型窃取）。修复方案：增加差分隐私噪声、限制单IP调用频率、对异常高置信度请求触发告警。

2.5 常见误区与设计原则

误区一：认为边缘部署“离线”就安全。实际上，边缘设备缺乏物理防护，攻击者可直接读取存储芯片。必须假设设备会被攻破，采用可信执行环境（TEE）或模型分割（仅部署部分层在边缘）。

误区二：批处理作业“内部系统”不需要认证。内部威胁（恶意员工或失陷账号）是批处理数据泄露的主要来源。应遵循最小权限原则，作业间使用独立服务账号，并审计所有数据访问。

误区三：在线推理只关注模型精度，忽略输入校验。对抗样本可导致模型输出错误，但更危险的是恶意构造的超大输入（如10GB的图片）引发内存溢出。必须设置输入尺寸、类型、范围的严格校验。

  安全部署三原则：
  默认不信任：所有请求、数据、模型文件均需验证来源与完整性。
最小暴露面：在线推理不直接暴露模型端口，通过API网关转发；批处理不开放外部存储直连。
可审计性：所有推理请求、作业执行、模型更新均记录不可篡改的日志（如区块链哈希链）。

最后需要强调，三种部署方式的安全策略不是孤立的。在线推理的模型版本可能来自批处理训练的产物，边缘模型的更新包也需经过在线通道分发。因此，生产环境应建立统一的模型仓库安全基线：模型文件加密存储、版本签名、部署前扫描（检测已知漏洞依赖）、部署后持续监控异常行为。只有将安全嵌入模型生命周期的每个环节，才能构建真正可信的AI服务管道。