构建与维护成本

构建自托管的 LLM 推理基础设施不仅仅是一项技术任务； 它更是一项高成本、耗时的长期投入。

复杂性

LLM 推理所需的能力远超标准云原生技术栈所能提供的范围。 要构建合适的部署体系，通常需要：

• 配置高性能 GPU（通常供应紧张且受区域限制）
• 管理 CUDA 版本兼容性与驱动依赖
• 配置自动扩缩容、并发控制以及 scale-to-zero 行为
• 应用高级推理优化技术，例如 prefix caching 和 prefill-decode disaggregation
• 搭建用于 GPU 监控、请求追踪与故障检测的可观测性工具
• 处理流式输出、缓存和路由等模型特有行为

这些步骤没有一项是简单的。大多数团队会尝试将这些需求强行套入 通用基础设施，但结果往往只是性能下降、交付周期拉长。

即使团队最终搭建成功，花在基础设施上的每一周， 都意味着少了一周去改进模型或交付产品价值。对于高绩效 AI 团队而言， 这种机会成本与基础设施账单一样真实。

对 ML 工具与框架的灵活性有限

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

但这种僵化会带来实实在在的限制：

• 你无法轻松测试或部署较新的模型或框架版本。
• 随着你的技术栈逐渐偏离社区或厂商更新，你会背上更多技术债。
• LLM 部署速度会变慢，使团队在竞争中处于不利位置。

扩展 LLM 的意义，本应是探索更快、更强的模型， 而不是被基础设施拖住，苦等它跟上。

对复杂 AI 系统的支持

单独一个 LLM 并不能直接产生价值。它必须成为集成系统的一部分， 而该系统通常包括：

• 用于清洗或转换用户输入的预处理
• 用于将模型输出整理为前端可用格式的后处理
• 通过逻辑、流水线或控制流封装模型的推理代码
• 处理校验、规则和内部数据调用的业务逻辑
• 连接数据库或特征存储的取数组件
• 用于检索增强生成或集成式流水线的多模型组合
• 以合适接口形式向下游团队暴露服务的自定义 API

问题在于：大多数 LLM 部署工具并不是为这种可扩展性而设计的。 它们的目标是加载权重并暴露一个基础 API。只要复杂度再高一些， 就需要编写胶水代码、采用变通方案，或把逻辑拆分到多个服务中。

这会导致：

• 仅仅为了交付可用功能，就需要投入更多工程工作
• 试图使用这些 AI 服务的团队会获得较差的开发者体验
• 当工具不支持特定用例定制时，创新会被卡住

隐性成本：人才

LLM 基础设施需要高度专业化的人才。企业需要的工程师既懂 GPU、 Kubernetes、ML 框架，又懂分布式系统，而且这些能力往往要求集中在 同一个岗位上。这类人才稀缺且昂贵，薪资通常比传统 DevOps 工程师高 30–50%。

即使团队已经拥有合适的人才，招聘与培养人员以维持内部能力本身 也是一项重大投入。 在这项调查中， 超过 60% 的公共部门 IT 专业人士将 AI 人才短缺列为采用 AI 的最大障碍。 私营部门的情况也并无不同。