3. 云原生架构概览
大模型从训练到推理服务化，本质上是从“单机重型计算”向“分布式弹性服务”的跃迁。传统以虚拟机为单位的部署方式，在面对GB级模型文件、动态流量峰值、GPU异构调度和持续迭代发布时，暴露出启动慢、资源利用率低、环境一致性差等致命短板。云原生架构正是为解决这类规模化分布式系统问题而生。本章将系统梳理容器、微服务、编排、服务网格、Serverless五大核心概念，并逐一剖析它们在大模型部署链路中的具体价值与落地方式。
上图展示了云原生五大核心概念与大模型部署之间的支撑关系。容器提供标准化的运行环境，微服务将推理链路拆分为可独立扩展的组件，编排层负责GPU资源调度与生命周期管理，服务网格解决分布式调用中的流量治理与可观测性，Serverless则进一步将资源管理抽象化，使开发者聚焦于模型本身。下面逐一深入展开。
3.1 容器：大模型部署的“标准化交付单元”
核心原理
容器通过Linux内核的namespace和cgroup技术实现进程级别的隔离与资源限制。与虚拟机相比，容器共享宿主机内核，无需模拟完整操作系统，因此启动时间通常在毫秒至秒级，镜像体积也远小于虚拟机镜像。对于大模型部署，容器将模型权重、推理代码、依赖库、CUDA驱动、环境变量等全部打包进镜像，确保开发、测试、生产环境完全一致。
大模型部署中的关键实践
- 镜像分层优化：将基础镜像（如PyTorch官方镜像）、依赖层、模型权重层分离。模型权重作为独立层，更新权重时无需重新构建整个镜像，利用Docker的层缓存机制可大幅提升构建效率。
- GPU运行时透传：使用
--gpus all或Kubernetes的device plugin将宿主机GPU显式映射到容器内，确保CUDA库与驱动版本匹配。推荐使用NVIDIA官方提供的nvidia/cuda基础镜像，并锁定精确版本号。 - 资源限制声明：在容器编排文件中明确
resources.limits.nvidia.com/gpu: 1以及内存、CPU上限，防止单个推理实例耗尽节点资源。
案例拆解：多模态模型推理镜像构建
某团队部署一个70B参数的多模态模型，初始镜像构建耗时45分钟，体积达22GB。通过分析Dockerfile，发现每次修改推理代码都会导致模型权重层缓存失效。优化策略为：将模型权重通过ADD命令单独分层，并在CI流水线中设置权重层缓存不过期。优化后，代码更新时镜像构建时间缩短至3分钟，且节点扩容时镜像拉取时间从8分钟降至2分钟（配合P2P分发）。
常见误区
3.2 微服务：将推理链路拆分为可独立演进的组件
核心原理
微服务架构将单一应用拆分为一组小型服务，每个服务围绕业务能力构建，可独立开发、部署、扩展。在大模型场景中，典型的推理链路包括：请求接入层、鉴权与限流、提示词预处理、模型推理、结果后处理、日志与审计。将这些环节拆分为独立微服务，可以针对瓶颈单独扩容，例如当并发请求激增时，仅扩展推理服务实例，而无需扩容整个单体应用。
大模型微服务拆分策略
| 服务名称 | 职责 | 扩展特性 | 典型技术 |
|---|---|---|---|
| API Gateway | 统一入口、鉴权、限流 | 无状态，水平扩展 | Kong / APISIX |
| Prompt Service | 模板管理、变量注入 | 无状态，低延迟 | FastAPI |
| Inference Service | 模型加载、推理计算 | 有状态，GPU密集 | Triton / vLLM |
| Post-process Service | 结果解析、格式化 | 无状态，CPU密集 | Node.js / Go |
| Audit Service | 请求日志、敏感信息过滤 | 异步，消息队列 | Kafka + Flink |
实战场景：推理服务与预处理服务分离
某智能客服系统初期将提示词拼接与模型推理放在同一服务中。当业务方频繁调整提示词模板时，不得不重新部署整个推理服务，导致GPU实例重启，造成服务中断。拆分为独立服务后，Prompt Service修改模板仅需滚动更新无状态Pod，推理服务保持稳定运行。同时，Prompt Service可针对不同业务线（如电商、金融）提供不同模板版本，实现多租户隔离。
常见误区
3.3 编排：Kubernetes驱动的GPU资源调度与自愈
核心原理
容器编排工具（以Kubernetes为代表）负责容器的自动部署、弹性伸缩、服务发现和故障恢复。在大模型场景中，编排层需要感知GPU资源，实现GPU显存调度、节点亲和性、拓扑感知调度（如NVLink/NVSwitch拓扑优化）。Kubernetes通过Device Plugin机制将GPU资源上报为可调度的扩展资源，配合自定义调度器实现更精细的分配策略。
大模型编排的关键操作流程
- 集群规划：根据模型规模估算GPU总量，预留10%-20%冗余用于故障转移。使用节点池区分训练节点（A100/H100）与推理节点（L4/A10）。
- 部署工作负载：使用
Deployment管理无状态推理服务，使用StatefulSet管理需要稳定网络标识和存储的推理实例（如TensorFlow Serving）。 - 配置自动伸缩：基于自定义指标（如GPU利用率、推理队列深度）配置HPA（Horizontal Pod Autoscaler），而非仅依赖CPU指标。
- 设置PodDisruptionBudget：确保节点维护时，可用推理实例不低于总实例的50%。
案例拆解：推理集群的弹性伸缩策略
某AI绘画平台使用Kubernetes管理Stable Diffusion推理服务。初始配置为固定10个Pod，每Pod占用1张A10 GPU。业务流量呈现明显波峰波谷（工作日白天高峰，夜间低谷）。团队配置了基于GPU利用率的HPA：当GPU利用率超过70%持续3分钟，扩容2个Pod；低于30%持续10分钟，缩容2个Pod。同时设置最大实例数30，最小实例数4。实施后，GPU整体利用率从平均35%提升至62%，月度GPU成本下降约28%。
KEDA基于队列长度（如Kafka消费积压数）进行预测性伸缩，或使用cluster-autoscaler配合节点池的按需扩容。
常见误区
resources.requests与limits不一致，可能导致调度器分配不足或运行时被强制杀死。
3.4 服务网格：治理推理流量的“交通警察”
核心原理
服务网格通过Sidecar代理（如Envoy）拦截服务间所有网络通信，提供流量路由、熔断、重试、超时控制、双向TLS、分布式追踪等能力，而无需修改业务代码。在大模型部署中，服务网格的价值体现在：推理服务多副本间的负载均衡策略、灰度发布时的金丝雀流量分配、以及跨版本模型对比时的流量镜像。
大模型场景下的服务网格配置要点
- 负载均衡策略：默认轮询可能不适用于GPU推理，因为不同请求的推理耗时差异大。建议使用
LEAST_REQUEST算法，将新请求转发给当前活跃请求数最少的实例。 - 超时与重试：推理请求通常有较长超时（如30秒），重试需谨慎。若模型推理本身已消耗大量算力，重试可能加剧过载。建议设置重试次数为0或仅在连接错误时重试。
- 熔断降级：当下游推理服务因GPU故障或OOM返回5xx错误时，熔断器快速打开，将请求转发至备用模型版本或返回降级提示。
实战场景：模型版本灰度发布
某推荐系统将排序模型从v1升级到v2，使用Istio进行金丝雀发布。初始将v2的权重设为5%，通过监控v2的推理延迟、错误率和推荐点击率，确认无异常后逐步提升至50%、100%。整个过程无需修改任何业务代码，仅通过VirtualService和DestinationRule调整权重。若v2出现推理延迟飙升，可立即将权重回滚至0%，实现秒级止损。
常见误区
3.5 Serverless：按需运行的推理服务新范式
核心原理
Serverless架构（如Knative、阿里云函数计算）将底层服务器管理完全抽象，开发者只需提交代码或容器镜像，平台根据请求自动伸缩实例，空闲时缩容至零。对于大模型推理，Serverless的价值在于：应对突发流量时无需预置GPU资源，按实际调用次数计费，避免GPU闲置成本。但需注意冷启动问题——当实例从零启动时，加载模型权重可能需要数十秒。
大模型Serverless部署的适用场景
| 场景特征 | 适用性 | 原因 |
|---|---|---|
| 低频调用（如每日<1000次） | 高度适用 | 避免GPU长期空闲，按次计费成本低 |
| 流量波动剧烈（如营销活动） | 适用 | 自动弹性，无需人工预估容量 |
| 延迟敏感（P99<500ms） | 不适用 | 冷启动+模型加载导致首请求延迟过高 |
| 长连接/流式输出 | 部分适用 | 需平台支持WebSocket或流式响应 |
案例拆解：基于Knative的按需推理服务
某文档分析工具提供PDF摘要生成功能，日均调用约2000次，集中在工作日上午。使用Knative部署推理服务，设置minScale: 0，maxScale: 5，并发上限为10。当请求到达时，Knative在2秒内拉起新Pod，但模型加载需15秒，导致首个请求延迟约17秒。为缓解冷启动，团队采用provisioner预热策略：在集群中常驻1个“热Pod”加载模型，但保持最小资源占用。最终将P95延迟控制在3秒内，同时GPU成本相比常驻3个实例降低了55%。
常见误区
3.6 五大概念协同：构建大模型部署的完整云原生底座
上述五大概念并非孤立存在，而是形成层次化的协同体系。容器提供标准化单元，微服务定义架构边界，编排负责资源调度与生命周期，服务网格治理服务间通信，Serverless则提供更高层的抽象。在实际落地中，建议采用渐进式策略：初期以容器+编排为核心，先解决环境一致性和弹性伸缩问题；中期引入微服务拆分，提升迭代效率；当服务规模超过20个时，再考虑服务网格；Serverless则根据业务特征选择性应用于特定场景。