当 AI 从实验室走向产业落地算力、数据、模型服务这些底层设施正在成为比单一算法更关键的竞争要素。本文围绕一封关于“在德州建设负责任 AI 基础设施”的公开信展开把信中涉及的规划思路转换成一套技术团队可以直接参考的建设框架从算力调度、数据治理、模型服务部署到监控审计与可持续运营完整拆解 AI 基础设施的工程化落地路径。适合正在做 AI 平台建设、私有化模型部署、政企数字化方案的同学阅读读完你可以理解 AI 基础设施的分层架构并能搭建一个包含推理服务、负载监控、审计日志的完整 Demo。1. AI 基础设施为什么重要从模型竞赛到工程竞赛1.1 什么是 AI 基础设施AI 基础设施并不是某一个产品而是支撑 AI 应用开发、训练、部署和运营的一整套技术栈。它至少包含算力资源GPU、NPU、CPU 集群以及对应的调度系统。存储与网络分布式文件存储、对象存储、高速互联网络。数据平台数据采集、清洗、标注、特征工程、数据版本管理。模型平台模型训练、微调、评估、打包、版本管理。推理服务模型在线推理、离线批量推理、弹性伸缩。可观测与治理监控、日志、审计、安全策略、成本管理。过去几年大家关注的是“哪个模型效果更好”但当模型真正进入业务系统后关注点会转移到“模型能否稳定服务”“数据是否合规”“算力成本是否可控”“出问题能否追溯”这些工程问题上。这就是负责任的 AI 基础设施要解决的核心问题。1.2 为什么政企和云厂商都在强调“负责任”“负责任”在 AI 基础设施语境下包含几层含义安全可控数据和模型不能失控访问要有权限管理操作要有审计记录。稳定可靠AI 服务要像传统业务系统一样具备 SLA不能因为资源争抢导致服务中断。可持续算力消耗巨大需要考虑能效和成本优化。合规透明数据来源合法、使用透明、模型决策可解释、可追溯。德州作为美国重要的算力聚集地在电力资源和数据中心方面有天然优势。公开信呼吁建设负责任的 AI 基础设施本质上是希望把这种地理位置优势转化为可持续的产业能力而不是短期炒作。1.3 对技术团队的启示不管你在哪个地区建设 AI 基础设施时都会面对同样的技术挑战GPU 资源利用率低训练和推理任务互相争抢。数据散落在不同团队缺少统一权限和版本管理。模型上线后缺少监控性能下降无法感知。算力成本无法核算到具体项目和部门。安全审计能力不足出现问题难以回溯。这篇文章后面的内容会围绕这些实际问题展开。2. AI 基础设施的分层架构与核心模块2.1 分层架构总览一个可落地的 AI 基础设施通常分为六层应用层 AI 应用、业务系统、智能体Agent 模型服务层 模型推理、模型微调、Prompt 网关 模型管理平台 模型仓库、版本控制、评估与发布 数据平台 数据接入、清洗、标注、特征存储、数据版本 资源调度层 GPU 调度、容器编排、任务队列、弹性伸缩 基础设施层 服务器、存储、网络、数据中心电力与散热每层之间通过 API 和统一元数据串联。越往下越关注资源效率越往上越关注业务价值。2.2 资源调度层算力池化与调度这层是整个基础设施的底座。关键点不是“买了多少张 GPU”而是“GPU 能不能被高效地用起来”。常见的做法是用 Kubernetes 结合 GPU 调度插件如 k8s-device-plugin实现算力池化。GPU 不再归属于某个团队而是统一纳入资源池按需申请。调度策略要考虑任务类型训练任务需要独占 GPU时长较长适合批量调度。微调任务单卡或多卡需要灵活的抢占策略。推理任务长驻服务需要稳定分配和弹性伸缩。2.3 数据平台AI 的数据治理数据是模型的“原材料”数据质量直接决定模型效果。AI 基础设施中的数据平台必须提供数据接入支持数据库、文件、消息队列等多种来源。数据版本每次训练使用的数据集要能追溯。数据权限按角色控制读取范围敏感数据脱敏。数据质量异常值检测、缺失值统计、标签一致性校验。不要以为买了数据湖就解决了数据问题真正的难点在于数据血缘、版本关联和权限控制。2.4 模型管理平台模型全生命周期管理模型管理平台Model Registry是连接训练和推理的桥梁。建议包含以下能力模型版本管理每个模型包有唯一版本号记录训练参数、数据集版本、评估指标。模型评估上线前自动跑评估集设定指标阈值。灰度发布新模型先切小流量验证稳定后再全量。模型回滚线上效果异常时能一键回滚到历史版本。2.5 可观测与治理让 AI 系统被管理AI 系统比传统系统更难排查因为中间多了“模型行为”这个不确定因素。因此基础设施必须额外采集三类指标资源指标GPU 利用率、显存占用、温度、功耗。服务指标推理延迟、吞吐量、错误率、排队长度。模型指标预测分布漂移、特征漂移、置信度变化。同时所有操作行为谁在什么时候部署了什么模型、谁访问了哪个数据集都要记录审计日志。3. 环境准备与软硬件栈选型3.1 硬件选型原则这里不推荐具体型号因为硬件更新速度太快但可以给出通用选型思路场景算力需求特点选型建议大模型预训练大规模分布式训练需要高速互联高性能 GPU/NPU 集群InfiniBand 或 RoCE 网络模型微调单机多卡或小规模多机中高端 GPU 即可注重显存容量在线推理低延迟、高并发关注推理芯片的 TOPS/W 能效比批量离线推理吞吐优先延迟容忍可使用性价比更高的芯片组合3.2 软件栈选型软件栈建议遵循“成熟优先、生态优先”的原则。以下是一套比较通用的组合操作系统Ubuntu Server LTS 或兼容的 Linux 发行版。容器运行时Docker containerd。编排调度Kubernetes建议 1.28 以上版本。GPU 调度NVIDIA/k8s-device-plugin 或厂商自研插件。AI 框架PyTorch、TensorFlow 或国产深度学习框架。推理服务FastAPI vLLM / Triton Inference Server。监控Prometheus Grafana。日志ELK 或 Loki。任务流编排Kubeflow / Argo Workflows。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。3.3 示例项目结构下面是一个最小可用的 AI 基础设施 Demo 的目录结构ai-infra-demo/ ├── terraform/ │ ├── main.tf │ └── variables.tf ├── inference/ │ ├── app.py │ ├── requirements.txt │ └── Dockerfile ├── k8s/ │ ├── deployment.yaml │ ├── service.yaml │ └── hpa.yaml ├── monitor/ │ ├── prometheus-config.yaml │ └── grafana-dashboard.json └── audit/ └── audit-log.py这个结构很小但覆盖了资源定义、模型服务、调度部署、监控采集、审计日志五个关键环节。4. 核心设计部署一个带审计的 AI 推理基础设施这一节我们动手搭建一个最小闭环。假设你已经有一个 Kubernetes 集群并且节点上安装了 GPU 驱动。我们将完成用 Terraform 定义算力资源演示为主。编写一个 FastAPI 推理服务。部署到 Kubernetes并配置弹性伸缩。配置 Prometheus 监控和审计日志采集。4.1 用 Terraform 定义 GPU 资源池Terraform 用于基础设施即代码IaC可以让你用配置文件管理云上或本地数据中心的资源。下面是一个简化示例展示如何声明一组 GPU 实例。# 文件路径ai-infra-demo/terraform/main.tf terraform { required_version 1.5.0 } provider aws { region var.region } # 定义一个 GPU 节点组 resource aws_eks_node_group gpu_nodes { cluster_name var.cluster_name node_group_name gpu-node-group node_role_arn var.node_role_arn scaling_config { desired_size 2 max_size 10 min_size 1 } instance_types [g5.xlarge] labels { node-type gpu } tags { Name ai-gpu-node Environment var.environment } }# 文件路径ai-infra-demo/terraform/variables.tf variable region { default us-east-1 } variable cluster_name { description EKS cluster name } variable node_role_arn { description IAM role for the node group } variable environment { default dev }关键点解释instance_types根据实际需要改成你的算力实例规格。scaling_config中min_size和max_size控制资源池的弹性范围。labels用于给节点打标后续调度 GPU 任务时可以通过 nodeSelector 指定。在真实生产环境中还要考虑 spot 实例、抢占策略、网络 ACL 和安全组。这里的示例重点在于“用代码管理算力”而不是在控制台手动点击创建。4.2 编写模型推理服务推理服务使用 FastAPI。为了演示我们写一个简单的文本分类接口。实际项目中可以把这里替换成 vLLM 或 Triton 加载的大模型。# 文件路径ai-infra-demo/inference/app.py import time import uuid import logging from typing import Dict from fastapi import FastAPI, Request from pydantic import BaseModel # 配置审计日志 logging.basicConfig( filename/var/log/audit.log, levellogging.INFO, format%(asctime)s|%(levelname)s|%(message)s, ) app FastAPI(titleAI Inference Demo) # 简单模拟模型预测结果 LABELS [positive, negative, neutral] class PredictRequest(BaseModel): text: str model_version: str v1.0 class PredictResponse(BaseModel): request_id: str label: str confidence: float model_version: str inference_ms: int app.post(/predict, response_modelPredictResponse) async def predict(req: PredictRequest, raw_request: Request): request_id str(uuid.uuid4()) start_time time.time() # 模拟模型推理 # 实际项目中这里调用模型引擎例如: # result model_engine.generate(req.text) label LABELS[len(req.text) % len(LABELS)] confidence round(0.5 (len(req.text) % 50) / 100, 4) inference_ms int((time.time() - start_time) * 1000) # 写入审计日志 logging.info( frequest_id{request_id}|client_ip{raw_request.client.host}| fmodel_version{req.model_version}|label{label}| fconfidence{confidence}|inference_ms{inference_ms} ) return PredictResponse( request_idrequest_id, labellabel, confidenceconfidence, model_versionreq.model_version, inference_msinference_ms, ) app.get(/health) async def health(): return {status: ok}审计日志设计的核心考量每个请求都有唯一request_id便于链路追踪。记录客户端 IP、模型版本、推理结果和耗时。审计日志写到独立文件与业务日志分离方便合规审查。实际生产建议把审计日志采集到 Elasticsearch 或 S3而不是只存在本地。# 文件路径ai-infra-demo/inference/requirements.txt fastapi0.109.0 uvicorn0.27.0 pydantic2.5.3# 文件路径ai-infra-demo/inference/Dockerfile FROM python:3.10-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . EXPOSE 8000 CMD [uvicorn, app:app, --host, 0.0.0.0, --port, 8000]构建镜像docker build -t ai-infra-demo/inference:latest ./inference4.3 部署到 Kubernetes 并配置弹性伸缩推理服务部署到 Kubernetes 时需要重点配置资源声明和弹性策略。GPU 推理服务要注意nvidia.com/gpu资源字段。# 文件路径ai-infra-demo/k8s/deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: inference-server namespace: ai spec: replicas: 2 selector: matchLabels: app: inference-server template: metadata: labels: app: inference-server spec: containers: - name: inference-server image: ai-infra-demo/inference:latest ports: - containerPort: 8000 resources: requests: cpu: 1 memory: 2Gi nvidia.com/gpu: 1 # 请求 1 张 GPU limits: cpu: 2 memory: 4Gi nvidia.com/gpu: 1 volumeMounts: - name: audit-log mountPath: /var/log volumes: - name: audit-log hostPath: path: /var/log/ai-audit# 文件路径ai-infra-demo/k8s/service.yaml apiVersion: v1 kind: Service metadata: name: inference-server namespace: ai spec: selector: app: inference-server ports: - port: 80 targetPort: 8000 type: ClusterIP下面配置水平弹性伸缩。这里以 CPU 利用率为触发条件生产环境建议同时配置 GPU 利用率和请求 QPS。# 文件路径ai-infra-demo/k8s/hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: inference-server-hpa namespace: ai spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: inference-server minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 60 - type: Resource resource: name: nvidia.com/gpu target: type: Utilization averageUtilization: 70部署命令kubectl create namespace ai kubectl apply -f k8s/deployment.yaml kubectl apply -f k8s/service.yaml kubectl apply -f k8s/hpa.yaml4.4 配置监控Prometheus 指标采集没有监控的 AI 基础设施等于盲人摸象。下面给出一份 Prometheus 配置片段用于抓取推理服务的指标。# 文件路径ai-infra-demo/monitor/prometheus-config.yaml scrape_configs: - job_name: inference-server static_configs: - targets: [inference-server.ai.svc.cluster.local:8000] metrics_path: /metrics建议在推理服务中暴露 Prometheus 指标例如inference_requests_total请求总数。inference_duration_ms推理耗时直方图。inference_gpu_utilizationGPU 利用率。# 在 app.py 中加入以下代码 from prometheus_client import Counter, Histogram, start_http_server REQUESTS Counter(inference_requests_total, Total inference requests) DURATION Histogram(inference_duration_ms, Inference latency, buckets[10, 50, 100, 200, 500, 1000]) # 在 predict 函数中埋点 REQUESTS.inc() DURATION.observe(inference_ms)4.5 运行与验证# 端口转发到本地 kubectl -n ai port-forward svc/inference-server 8080:80 # 调用预测接口 curl -X POST http://localhost:8080/predict \ -H Content-Type: application/json \ -d {text: This is a great course about AI infrastructure!, model_version: v1.0} # 预期响应 { request_id: 9c3f4c6e-8b6a-4a01-9db0-3d7f0f16a2e1, label: positive, confidence: 0.54, model_version: v1.0, inference_ms: 12 }5. 常见问题与排查思路问题现象常见原因解决思路Pod 调度失败一直 PendingGPU 资源不足或节点缺少 GPU 标签kubectl describe pod查看事件确认节点nvidia.com/gpu可分配数量推理服务接口超时模型体积过大显存不足导致频繁换入换出检查显存用量考虑模型量化或改用更大显存实例GPU 利用率很低但响应慢数据预处理成为瓶颈GPU 在等待数据优化数据加载使用异步预处理和高速存储弹性伸缩触发频繁HPA 阈值设置过小或单请求消耗资源波动大观察监控曲线调大阈值并设置冷却时间审计日志丢失容器重建导致本地文件丢失使用共享存储或日志采集器实时上报模型更新后效果下降缺少灰度发布就直接全量部署配置金丝雀发布先切 5%~10% 流量观察典型排查流程kubectl get pods -n ai查看 Pod 状态。kubectl describe pod pod-name -n ai查看调度事件和容器状态。kubectl logs pod-name -n ai查看应用日志。kubectl top node查看节点资源使用。在 Grafana 中查看 GPU 利用率、推理延迟和错误率。6. 最佳实践与工程建议6.1 算力资源先池化再分配不要给每个团队单独分配固定的 GPU 机器否则一定出现“有的团队用不完有的团队不够用”的情况。统一纳入资源池按配额和优先级分配。6.2 数据安全最小权限 审计数据和模型访问遵循最小权限原则。数据集使用前必须经过脱敏和合规审查。所有训练任务、模型部署行为都要有审计记录。6.3 模型发布强制评估与回滚模型发布流程建议固定为训练 - 离线评估 - 上线评审 - 金丝雀发布 - 全量发布 - 持续监控每一步都要有记录。特别是“回滚到哪个版本”必须提前确认好不要等问题发生后再查模型仓库。6.4 成本管理标签与配额在云环境或多团队环境下给所有资源打上成本标签项目名称project所属团队team环境dev/staging/prod用途training/inference这样月底成本核算就有据可查。6.5 可持续性能效优先推理服务优先选择能效比高的芯片。非高峰时段自动缩容到最小值。训练任务尽量满负荷运行避免资源碎片化。6.6 异常处理与日志记录所有模型推理异常都要有明确错误码而不是只返回 500。关键操作写审计日志应用日志和审计日志分开存储。日志要包含request_id和model_version便于回溯。7. 更进一步从“能用”到“可治理”如果上面的 Demo 你已经跑通了下一步可以往这几个方向深入引入 Model Registry如 MLflow、Seldon Core标准化模型版本。接入特征存储Feast 等统一线上和离线特征。配置 AI 网关统一处理鉴权、限流、模型路由。使用向量数据库为 RAG 应用提供知识库底座。设计成本核算系统把 GPU 消耗精确到每一次请求。技术选型上不必追求最新的组件稳定性和可维护性优先。一个 AI 基础设施团队真正稀缺的能力不是会用某个框架而是能在算力、数据、模型、成本、安全之间做出合理权衡。回到“负责任的 AI 基础设施”这个话题上——负责任不是一句口号而是落在资源配额、审计日志、灰度策略、监控告警这些具体工程动作里的。设备可以用钱买但治理能力只能通过一次次规范上线和排障慢慢沉淀下来。