AI 基础设施的构建路线——从 GPU 集群到 MLOps 平台的建设路径 AI 基础设施的构建路线——从 GPU 集群到 MLOps 平台的建设路径一、开篇导语AI 基础设施的建设不是采购清单而是演进路线2026 年AI 基础设施的建设已经从买几台 GPU 服务器跑模型升级为构建从训练到推理到运维的完整平台体系。架构师面临的不再是硬件选型问题而是如何规划一条从 GPU 集群到 MLOps 平台的渐进式建设路线——在预算约束下按阶段投入每一步都为下一步预留扩展空间。本文基于两个企业 AI 平台建设的实践经验提供结构化的建设路线图覆盖硬件规划、推理服务化、训练管道、MLOps 平台四个阶段。二、技术原理AI 基础设施的分层架构与核心组件2.1 AI 基础设施的分层模型AI 基础设施的建设遵循自下而上、逐层构建的演进路径每一层为上层提供基础能力建设路线的核心原则是逐层构建、不跳步——没有稳定的 GPU 集群就无法构建可靠的推理服务没有可靠的推理服务就无法规划训练管道没有训练管道就无法建设 MLOps 平台。每一层的稳定运行是下一层建设的必要前提。2.2 硬件层的规划要点GPU 集群的规划核心是推理优先、训练按需——绝大多数企业的 AI 工作负载以推理为主训练是低频但高资源密度的任务硬件组件推理场景配置训练场景配置GPUA100-80G × 4单节点H100 × 8单节点存储本地 SSD S3 对象存储NVMe SSD 高带宽并行文件系统网络25GbE 以太网RoCEv2 或 InfiniBandCPU64 核推理不需要密集计算128 核数据预处理需求大内存256GB推理 KV Cache512GB训练数据缓存关键判断推理集群和训练集群不应该混用——推理需要低延迟、高可用、弹性扩缩容训练需要高吞吐、大内存、长时间独占 GPU。混用会导致推理服务被训练任务抢占资源影响生产稳定性。2.3 推理层的服务化架构推理服务化的核心是将推理引擎vLLM/Triton从裸进程升级为可观测、可弹性、可治理的生产服务// 推理服务的统一 API 网关与路由管理 Service public class InferenceGatewayService { private final MapString, InferenceBackend backendMap; private final InferenceHealthChecker healthChecker; private final InferenceLoadBalancer loadBalancer; /** * 推理请求路由——根据模型和场景选择推理后端 */ public InferenceResult routeInference(InferenceRequest request) { String modelId request.getModelId(); // 1. 查找可用后端 ListInferenceBackend healthyBackends backendMap.entrySet().stream() .filter(entry - entry.getKey().startsWith(modelId)) .filter(entry - healthChecker.isHealthy(entry.getValue())) .map(Map.Entry::getValue) .collect(Collectors.toList()); if (healthyBackends.isEmpty()) { log.error(模型 {} 无可用推理后端, modelId); throw new InferenceException(推理服务暂时不可用模型: modelId); } // 2. 负载均衡选择 InferenceBackend selected loadBalancer.select(healthyBackends, request); log.debug(推理路由: 模型{} → 后端{}, modelId, selected.getEndpoint()); // 3. 执行推理调用 try { InferenceResult result selected.invoke(request); // 4. 记录指标 recordMetrics(modelId, selected, request, result); return result; } catch (InferenceTimeoutException e) { log.warn(推理超时模型: {}后端: {}耗时: {}ms, modelId, selected.getEndpoint(), e.getTimeoutMs()); // 故障转移排除超时后端后重新选择 return fallbackInference(request, selected); } catch (InferenceBackendException e) { log.error(推理后端异常模型: {}后端: {}, modelId, selected.getEndpoint(), e); return fallbackInference(request, selected); } } /** * 故障转移推理 */ private InferenceResult fallbackInference(InferenceRequest request, InferenceBackend failedBackend) { ListInferenceBackend fallbackBackends backendMap.entrySet().stream() .filter(entry - entry.getKey().startsWith(request.getModelId())) .filter(entry - !entry.getValue().equals(failedBackend)) .filter(entry - healthChecker.isHealthy(entry.getValue())) .map(Map.Entry::getValue) .collect(Collectors.toList()); if (fallbackBackends.isEmpty()) { throw new InferenceException(所有推理后端不可用); } InferenceBackend fallback loadBalancer.select(fallbackBackends, request); try { log.info(故障转移: {} → {}, failedBackend.getEndpoint(), fallback.getEndpoint()); return fallback.invoke(request); } catch (InferenceBackendException e) { log.error(故障转移后端仍然失败: {}, fallback.getEndpoint()); throw new InferenceException(推理集群不可用请联系管理员); } } /** * 记录推理指标——延迟、Token消耗、GPU利用率 */ private void recordMetrics(String modelId, InferenceBackend backend, InferenceRequest request, InferenceResult result) { try { MetricsCollector.collect( inference_latency_ms, result.getLatencyMs(), Map.of(model, modelId, backend, backend.getEndpoint()) ); MetricsCollector.collect( inference_tokens_total, result.getTokenUsage().getTotalTokens(), Map.of(model, modelId) ); MetricsCollector.collect( gpu_utilization_percent, backend.getGpuUtilization(), Map.of(backend, backend.getEndpoint()) ); } catch (MetricsCollectionException e) { // 指标采集失败不影响主流程 log.warn(推理指标采集异常: {}, e.getMessage()); } } }三、建设路线四阶段渐进式构建路径阶段一GPU 集群搭建0-3 个月目标建立稳定的推理基础设施支撑首批 AI 服务上线。核心任务GPU 服务器采购与网络配置RoCEv2 或 25GbEvLLM 推理引擎部署与参数调优PagedAttention Block Size、Continuous Batching 上限基础监控搭建GPU 利用率、推理延迟、Token 消耗模型加载与版本管理脚本关键避坑点GPU 间的 NVLink 通信配置必须与训练场景区分推理集群不需要全节点互联存储选择对象存储S3/MinIO而非 NFS——推理模型文件一次性加载不需要高带宽并行读推理引擎的 KV Cache 内存预算需要根据并发上限精确计算避免 OOM Kill阶段二推理服务化3-6 个月目标将推理引擎升级为生产级服务——负载均衡、健康检查、自动扩缩容、可观测性完整。核心任务推理 API 网关建设统一路由、鉴权、限流推理后端健康检查与故障转移机制GPU 利用率驱动的弹性扩缩容Kubernetes HPA Custom Metrics推理延迟 P99/P95 的持续监控与告警阶段三训练管道建设6-12 个月目标建立从数据到模型到评测到发布的自动化管道。核心任务数据管道搭建数据清洗 → 特征提取 → Feature Store训练框架选型与部署DeepSpeed/FSDP Kubernetes Job实验追踪平台搭建MLflow/WB自动化评测 PipelineGolden Dataset LLM-as-Judge 规则评分阶段四MLOps 平台完善12-18 个月目标实现模型全生命周期管理——从实验到发布到监控的自动化闭环。核心任务模型 CI/CD Pipeline代码变更 → 自动训练 → 自动评测 → 灰度发布模型质量监控输出质量评分、幻觉率统计、Token 成本追踪模型版本灰度发布A/B 对比 → 逐步切流 → 全量发布成本治理GPU 利用率优化、推理成本归因、预算告警四、代码实战推理服务的弹性扩缩容与成本治理/** * GPU 利用率驱动的推理服务弹性扩缩容 */ Component public class InferenceAutoScaler { private final KubernetesClient k8sClient; private final PrometheusMetricsClient metricsClient; /** * 定时检查 GPU 利用率并触发扩缩容 */ Scheduled(fixedRate 60000) public void autoScale() { try { double gpuUtilization metricsClient.getAverageGpuUtilization(vllm-inference); int currentReplicas k8sClient.getDeploymentReplicas(vllm-inference); double avgLatencyP95 metricsClient.getLatencyP95(vllm-inference); // 扩容条件GPU 利用率 80% 或 P95 延迟 目标阈值 if (gpuUtilization 80.0 || avgLatencyP95 3000) { int targetReplicas Math.min(currentReplicas 1, 8); // 最大 8 节点 if (targetReplicas currentReplicas) { k8sClient.scaleDeployment(vllm-inference, targetReplicas); log.info(推理服务扩容: {} → {}GPU利用率: {:.1f}%P95延迟: {:.0f}ms, currentReplicas, targetReplicas, gpuUtilization, avgLatencyP95); } } // 缩容条件GPU 利用率 30% 且 P95 延迟 目标阈值的 50% if (gpuUtilization 30.0 avgLatencyP95 1500 currentReplicas 2) { int targetReplicas currentReplicas - 1; k8sClient.scaleDeployment(vllm-inference, targetReplicas); log.info(推理服务缩容: {} → {}GPU利用率: {:.1f}%, currentReplicas, targetReplicas, gpuUtilization); } } catch (MetricsCollectionException e) { log.warn(指标采集失败本轮扩缩容跳过: {}, e.getMessage()); } catch (KubernetesOperationException e) { log.error(扩缩容操作失败: {}, e.getMessage()); } } } /** * 推理成本治理服务——按业务维度归因推理成本 */ Service public class InferenceCostGovernance { private final CostRepository costRepo; private final BudgetAlertService budgetAlert; /** * 每日推理成本归因与预算检查 */ Scheduled(cron 0 0 8 * * *) public void dailyCostAttribution() { try { // 按业务维度统计昨日推理成本 ListCostAttribution attributions costRepo.attributedByBusinessUnit( LocalDate.now().minusDays(1) ); for (CostAttribution attr : attributions) { log.info(业务单元: {}昨日推理成本: ¥{:.2f}Token消耗: {}, attr.getBusinessUnit(), attr.getCostYuan(), attr.getTotalTokens()); // 预算告警检查 if (attr.getCostYuan() attr.getDailyBudgetYuan()) { budgetAlert.sendOverBudgetAlert( attr.getBusinessUnit(), attr.getCostYuan(), attr.getDailyBudgetYuan() ); log.warn(预算超支告警: {}实际 ¥{:.2f} 预算 ¥{:.2f}, attr.getBusinessUnit(), attr.getCostYuan(), attr.getDailyBudgetYuan()); } } // GPU 利用率优化建议 double overallGpuUtilization costRepo.getOverallGpuUtilization(); if (overallGpuUtilization 50.0) { log.warn(GPU 整体利用率偏低: {:.1f}%建议优化推理服务配置或合并低负载模型, overallGpuUtilization); } } catch (CostAttributionException e) { log.error(成本归因计算异常: {}, e.getMessage()); } } }五、总结与建设路径建议核心建设原则三条核心建议推理优先是预算分配的核心原则企业在 AI 基础设施上的预算分配应该70% 推理 30% 训练——推理是持续运行的生产服务训练是低频迭代的开发活动。先让推理服务稳定运行并产生业务价值再逐步建设训练管道避免在训练基础设施上的过早投入变成闲置资产。成本治理必须在建设初期就规划GPU 的硬件成本和推理的 Token 成本是 AI 基础设施最大的持续性支出。如果不在建设初期就建立成本归因按业务单元/按模型/按场景和预算告警机制6 个月后成本失控几乎是必然的结果。建议在阶段二推理服务化就完成成本归因的基础建设。每阶段预留下一步的扩展接口硬件层预留训练集群的网络和存储扩展空间推理层预留模型版本管理和灰度发布的接口训练层预留 CI/CD Pipeline 的触发入口。每一步的建设不应该成为下一步的障碍而是下一步的基座。AI 基础设施建设的本质是硬件投入 × 服务化程度 × 成本治理的渐进式演进。2026 年的务实路径是先让 GPU 集群和推理服务跑稳再逐步叠加训练管道和 MLOps 平台——每一步都产生业务价值每一步都为下一步铺路。