技术深度解析
AI基础设施工程师的工作处于分布式系统、GPU计算和现代DevOps的交汇点。他们管理的核心架构可分为三个层次：
1. GPU集群层： 这是物理或虚拟硬件层。工程师必须理解GPU拓扑（NVLink、NVSwitch）、内存带宽（HBM2e vs HBM3），以及GPU间通信对张量并行的含义。他们管理使用Slurm或Kubernetes配合GPU设备插件的集群调度器。一个关键挑战是处理GPU故障——一块H100成本高达3万美元，停机直接影响收入。工程师需实施健康检查、自动节点排空和抢占式Spot实例管理。
2. 编排层： Kubernetes是事实标准，但原生K8s不足以应对AI工作负载。工程师需部署Kueue（用于批处理作业调度）和Volcano（用于组调度）等专用算子。他们使用Cluster Autoscaler或Karpenter配置集群自动扩缩，但必须考虑GPU分配粒度（例如A100上的MIG分区）。真正的复杂性在于多租户：如何在最大化GPU利用率的同时隔离不同团队的工作负载。常用技术包括节点级隔离、命名空间配额和自定义准入Webhook。
3. 推理引擎层： 这是魔法发生的地方。工程师选择并配置推理引擎：
| 引擎 | 关键特性 | 吞吐量（tokens/秒, Llama-3-70B） | 延迟（TTFT, p99） | GitHub Stars |
|---|---|---|---|---|
| vLLM | PagedAttention、连续批处理、前缀缓存 | 1,200 | 150ms | 45k+ |
| TensorRT-LLM | NVIDIA优化、FP8量化、飞行中批处理 | 1,800 | 100ms | 12k+ |
| TGI (Hugging Face) | Token流式传输、量化、水印 | 900 | 200ms | 8k+ |
| SGLang | 结构化生成、RadixAttention | 1,100 | 130ms | 6k+ |
数据要点： TensorRT-LLM凭借NVIDIA硬件优化在原始吞吐量上领先，但vLLM在性能和社区支持之间提供了最佳平衡。工程师必须针对自己的特定模型和硬件对每个引擎进行基准测试。
除引擎选择外，工程师还需实现连续批处理（动态向运行中的批次添加请求）、张量并行（跨GPU拆分模型层）和流水线并行（跨节点拆分层）。他们还构建处理负载均衡、重试和熔断的请求路由层。Envoy和Linkerd等开源项目常被使用，但许多公司用Go或Rust构建自定义代理以降低延迟。
值得关注的GitHub仓库：
- vllm-project/vllm: 最流行的推理引擎；近期更新包括FP8支持和多模态模型。
- ray-project/ray: 用于分布式服务和模型组合。
- kubernetes-sigs/kueue: 用于K8s上的批处理作业调度。
- NVIDIA/TensorRT-LLM: 在NVIDIA硬件上实现最大性能。
关键玩家与案例研究
对AI基础设施工程师的需求正由超大规模云厂商和初创公司共同推动。以下是关键玩家及其策略：
| 公司 | 方法 | 关键工具 | 招聘重点 |
|---|---|---|---|
| OpenAI | 自定义推理栈，专有编排 | 内部GPU集群管理器、自定义K8s算子 | 具备Python/Go技能的SRE、分布式系统专家 |
| Anthropic | Claude推理平台基于AWS，带自定义路由 | AWS Bedrock、内部代理层、用于研究的vLLM | 具备MLOps经验的后端工程师 |
| Meta | 开源栈，Llama模型，PyTorch原生服务 | PyTorch、TorchServe、自定义GPU调度器 | 具备GPU内核经验的系统工程师 |
| Together AI | 面向开放模型的云原生推理平台 | vLLM、Kubernetes、自定义自动扩缩器 | 具备K8s经验的全栈工程师 |
| Replicate | 面向社区模型的无服务器推理 | Cog、Docker、自定义GPU池管理器 | 具备Python经验的DevOps工程师 |
案例研究：Together AI的基础设施栈
Together AI构建了最透明的AI基础设施平台之一。其工程团队公开讨论使用vLLM作为核心推理引擎，配合一个处理GPU分配、模型加载和请求路由的自定义Kubernetes算子。他们采用分层存储系统管理模型权重（热模型用SSD缓存，冷模型用S3），并实现了一个基于历史使用模式预测需求的自定义自动扩缩器。其关键创新是一个请求合并器，将相似提示批量处理以最大化GPU利用率。这种方法使他们能够以低于200ms的延迟服务超过200个模型，同时保持85%的GPU利用率。
案例研究：OpenAI的内部SRE文化
OpenAI的基础设施团队由来自Google和Meta的资深人士领导，将每一次推理请求都视为可靠性挑战。他们实行7x24小时轮班待命，使用基于Prometheus和Grafana的自定义监控系统，并维护一个详细的运行手册库。他们的GPU集群管理方法包括预测性故障检测——使用机器学习模型在GPU硬件故障发生前预测——以及自动工作负载迁移。OpenAI还开发了专有的推理引擎优化，包括自定义CUDA内核和动态批处理策略，这些尚未开源。