跳到主要内容

构建与维护成本

自建 LLM 推理基础设施不仅仅是一项技术任务;它是一项昂贵、耗时的投入。

复杂性​

LLM 推理所需的远不止标准云原生技术栈所能提供的。构建正确的方案涉及:

  • 调配高性能 GPU(通常稀缺且受区域限制)
  • 管理 CUDA 版本兼容性与驱动依赖
  • 配置自动扩缩容、并发控制以及缩容到零(scale-to-zero)行为
  • 应用高级推理优化技术,如前缀缓存(prefix caching)和预填充-解码分离(prefill-decode disaggregation)
  • 搭建用于 GPU 监控、请求追踪与故障检测的可观测性工具
  • 处理流式输出、缓存、路由等模型特有的行为

这些步骤没有一项是微不足道的。大多数团队试图将这些需求强行套用到通用基础设施上,但结果只会是性能下降和交付周期变长。

即使一个团队真的做到了,每一周花在搭建基础设施上的时间,都是没有用来改进模型或交付产品价值的一周。对于高绩效的 AI 团队来说,这种机会成本与基础设施账单一样真实。

对 ML 工具和框架的灵活性受限​

许多 AI 技术栈将模型运行时(如 PyTorch、vLLM 或特定 transformers 版本)锁定在固定版本上。主要原因是为了缓存容器镜像并确保与基础设施相关组件的兼容性。虽然这简化了集群中的部署,但当你需要测试或部署不在支持列表中的更新模型或框架时,它也限制了灵活性。

但这种僵化带来了真实的限制:

  • 你无法轻松测试或部署较新的模型或框架版本。
  • 随着你的技术栈偏离社区或厂商更新,你会积累更多技术债务。
  • LLM 部署速度变慢,让你的团队处于竞争劣势。

扩展 LLM 应该意味着探索更快、更好的模型,而不是被困在等待基础设施跟上。

对复杂 AI 系统的支持​

LLM 本身并不能交付价值。它必须是集成系统的一部分,通常包括:

  • 用于清洗或转换用户输入的预处理(pre-processing)
  • 用于为前端使用格式化模型输出的后处理(post-processing)
  • 将模型包装在逻辑、流水线或控制流中的推理代码
  • 处理校验、规则和内部数据调用的业务逻辑
  • 连接数据库或特征存储的数据获取器
  • 用于检索增强生成或集成(ensemble)流水线的多模型组合
  • 以适合下游团队的形态暴露服务的自定义 API

问题在于:大多数 LLM 部署工具并不是为这种可扩展性而构建的。它们的设计目标是加载权重并暴露一个基础 API。任何更复杂的需求都需要胶水代码、变通方法,或将逻辑拆分到多个服务中。

这导致:

  • 仅仅为了交付可用功能就需要投入更多工程精力
  • 尝试消费这些 AI 服务的团队获得糟糕的开发者体验
  • 当工具不支持针对具体用例的定制时,创新受阻

隐藏成本:人才​

LLM 基础设施需要深度专业化。公司需要既懂 GPU、Kubernetes、ML 框架又懂分布式系统的工程师——所有能力集于一身。这类人才稀缺且昂贵,薪资通常比传统 DevOps 工程师高出 30–50%。

即使是拥有合适人才的团队,为维持内部能力而进行招聘与培训也是一笔重大投资。这项调查显示,超过 60% 的公共部门 IT 专业人士将 AI 人才短缺列为采用 AI 的最大障碍。私营部门也不例外。