大多数团队都会搞错的 LLM 基础设施“自研还是购买”决策

一家金融科技团队基于 GPT-4o 构建了他们的 AI 聊天机器人。第一个月：1.5 万美元。第二个月：3.5 万美元。第三个月：6 万美元。预计年支出将达到 70 万美元，他们慌了，并决定转向自托管。六个月后，在耗尽了一名工程师的精力后，他们每月在基础设施、一名兼职 DevOps 工程师以及三次导致生产环境宕机的 CUDA 事故上花费 8.5 万美元。他们最终将开支降到了每月 8000 美元 —— 但并不是通过全盘自托管实现的，而是通过智能路由。

这两个决定都是错误的。真正的失败在于他们从未进行过实际的成本核算。

LLM 基础设施的“自建还是购买”（build-vs-buy）决策无疑是团队最常犯的代价昂贵的错误，而且无论选哪一边都可能踩坑。团队在托管 API 上停留太久，会被高昂的成本搞得措手不及。团队过早进行自托管，却发现“免费”的开源权重模型在工程时间上每月会产生 6000 美元的隐藏账单。问题不在于选错，而在于基于不完整的数据做决定。

这篇文章将为你提供实际的数据、在你特定规模下进行核算的框架，以及答案真正发生转变的盈亏平衡点。

托管 API 的隐藏成本：你的账单上没显示的那些东西

定价页面上的每 Token 费率是你支付的最低费用，而非实际成本。

速率限制迫使过度设计。 大多数托管服务商都有严格的限制：每分钟 Token 数（TPM）上限、每分钟请求数（RPM）上限，以及与宣传不符的上下文窗口限制。当一个新的 Claude Sonnet 账号实际上被限制在 50 RPM 和 20K 输入 TPM 时，你不能直接把流量导向它 —— 你需要一个队列层、重试逻辑、背压处理和指数退避。这需要 2–4 周的工程量。为生产级请求封装预留 1.5 万至 3 万美元的开发时间成本，以及后续的维护费用。

出口流量和开销增加 5–15%。 云出口费用（取决于提供商，约为 0.05–0.12 美元/GB）在高吞吐量应用中会产生复利效应。JSON 封装开销、流式传输元数据和冗长的响应格式使实际的 Token 成本超出了定价计算器的预估。对于每日调用数百万次的应用来说，这一点至关重要。

承诺吞吐量导致财务锁定。 AWS Bedrock 的预置吞吐量模型是一个代表性例子：Llama 3 70B 的 6 个月承诺使用成本约为 13 美元/小时，而按需使用为 24 美元/小时。折扣是真实的，但你是在为一个每季度都会发生变化的术景观提前 6 个月承诺使用量。当 DeepSeek 在 2025 年底将价格减半时，签署了承诺合同的团队并没有自动受益。

微调权限昂贵或无法获得。 如果你的用例需要特定领域的微调 —— 医疗词汇、法律文件结构、专有代码规范 —— 大多数托管服务商要么不提供，要么在已经很高的基础成本之上收取高额溢价，或者限制你可以提交的数据。这种差距迫使团队要么为微调后的 7B 模型就能处理的任务支付尖端模型的价格，要么为了微调而专门进行自托管，同时保留托管推理。两者都不理想。

340% 的成本超支统计数据。 2025 年对多租户 SaaS 产品的一项分析发现，团队的 LLM 成本预算经常超支 340%。根本原因几乎从未是每 Token 费率 —— 而是缺乏对每个租户的使用跟踪，以及没有查询级别的成本归因。你的账单告诉你花了多少钱；它不会告诉你哪个客户、哪个功能或哪个 Prompt 模板消耗了 80% 的预算。没有监控手段，你就无法优化。

自托管的隐藏成本：硬件报价单上没显示的那些东西

GPU 租赁价格 —— 或自有硬件的购买报价 —— 同样是你支付的最低费用。

人力是主导成本，而非硬件。 一项针对 54 个 LLM 部署场景的同行评审分析发现，对于大多数组织而言，硬件成本和电力合计占自托管总成本的 20–30%。70–80% 的大头是人力。按照市场价，分配一名资深工程师 20–30% 的时间用于基础设施维护，每月成本为 3000–6000 美元 —— 这还不包括事故处理、模型升级和合规性工作。

CUDA 驱动维护是一项经常性支出。 自托管 LLM 意味着拥有整个软件栈：NVIDIA 驱动程序、CUDA 工具包、cuDNN、推理框架（vLLM、SGLang、llama.cpp）以及模型权重。这些组件都有各自的发布周期、相互依赖关系和破坏性变更。升级 vLLM 以支持新模型的架构需要验证新版本不会破坏现有的 CUDA 环境。FlashAttention 和 xformers 必须针对你的特定 CUDA 版本进行编译，否则你会遇到性能静默下降而非报错。实际成本：每次重大模型版本升级需要 1–3 个工程日，外加平均每月 8–20 小时的日常维护。

安全性是你的问题，而非框架的问题。 没有任何一个主流推理框架 —— vLLM、llama.cpp、Ollama 或已进入维护模式的 TGI —— 默认提供身份验证或授权。每个自托管部署都需要反向代理、API 网关或服务网格来实现基本的访问控制。以 PyTorch pickle 格式序列化的模型权重带有任意代码执行风险；迁移到 safetensors 格式需要额外的工作。为 AI 功能申请 SOC 2 或 HIPAA 认证每年会增加 1.5 万至 2.5 万美元的审计开销。

框架更迭是真实存在的。 Hugging Face 的 Text Generation Inference (TGI) 于 2025 年 12 月进入维护模式，Hugging Face 明确建议团队迁移到 vLLM 或 SGLang。那些基于 TGI 构建的团队当初并没有选择一个弃用的框架 —— 他们选择的是当时最流行的方案。预计这种模式还会重复。

模型存储不是免费的。 一个 16 位精度的 7B 参数模型需要 14GB 存储空间。70B 模型：140GB。如果你要维护多个模型检查点、在模型版本之间进行 A/B 测试，或存储微调数据集，每月 0.08–0.12 美元/GB 的存储费用将成为一项值得跟踪的支出。

各阶段盈亏平衡点计算

实际的计算需要三个输入：你的月度 API 支出、按模型层级划分的 Token 吞吐量，以及对你现有 MLOps 能力的诚实评估。

创业阶段（月度 API 支出 < $10K）

在这个阶段，自托管在经济上并无意义。运行 70B 模型生产级推理的最低硬件要求——在云端租赁 4-8 张 H100——在计入人员成本前每月就需要 $15K–$40K。在这种规模下，部署一个 70B 模型的盈亏平衡期在乐观估计下也需要 34 个月。API 具有压倒性优势，即便这感觉像是在交房租而不是在积累资产，但它就是正确答案。

增长阶段（月度 API 支出 $10K–$50K）

这是混合路由（Hybrid Routing）开始产生回报的阶段。策略是：将前沿模型调用（复杂推理、创意生成、低频率高价值任务）保留在托管 API 上，而将大规模任务（大规模分类、摘要、提取）路由到自托管的 7B–13B 模型。运行 13B 模型、GPU 利用率为 50% 的单张 H100 每天大约可处理 8,000 次对话，包含人员开销在内的成本为每月 $1,500–$5,000。对于处于这一范围的团队，对大宗流量进行选择性自托管通常可以将总 AI 支出降低 40–70%。

引言中提到的金融科技案例在探索自托管方面并没有错——错在他们试图自托管所有内容。通过将每天 60 万次 Prompt（大宗分类和提取工作）路由到自托管基础设施，同时将每天 5,000 次复杂查询保留在托管 API 上，他们的月支出从 $47K 降至了$8K。

规模化阶段（月度 API 支出 $50K+，每月 Token 量 1 亿以上）

在这样的吞吐量下，为了保证利润率，对大宗流量进行自托管几乎是强制性的——但计算过程比看起来更微妙，因为前沿模型的价格战已经重置了盈亏平衡点。

在每月 1 亿 Token 的规模下，对比自托管（云端 GPU）与托管 API：

• 对标 GPT-5 Mini / Claude Haiku 层级：自托管胜出 3–5 倍。
• 对标 DeepSeek V3 定价（输入每百万 Token $0.28）：在处理常规大宗任务时，自托管反而会亏损——模型提供商的规模经济效应已经击败了你。

这就是 2026 年令人不安的现实。DeepSeek 等具有价格竞争力的提供商，使得仅凭成本理由就对常规推理进行自托管变得更加难以立足。在规模化阶段仍迫使企业选择自托管的原因包括：禁止数据离开基础设施的合规性要求、网络往返时间（RTT）导致 API 无法实现的低于 100 毫秒延迟要求，以及无法在第三方基础设施上运行的私有微调模型。

决策框架

在进行数学计算之前，请先回答以下问题：

合规性要求是什么？ 如果你处于医疗保健、金融服务或任何需要数据驻留的受监管行业——决策首要考虑的不是成本。无论盈亏平衡计算结果如何，你可能都被要求自托管特定类型的数据。

你真实的月度 Token 吞吐量是多少？ 不是预测的，也不是理论上的。运行一周的生产日志。让大多数团队感到惊讶的是 Token 使用的集中度：80% 的 Token 来自于 20% 的查询类型。这些高频率、低复杂度的查询才是自托管的首选方案。

你拥有什么样的 MLOps 能力？ “我们会招人”并不代表能力。诚实评估：你目前是否有员工在生产环境中运行过推理基础设施？如果没有，请考虑到 3-6 个月的磨合期以及在此期间 30-40% 的生产力下降。

延迟要求是什么？ API 推理会增加 30–100 毫秒的网络 RTT 以及排队延迟。对于 p95 目标值在 200 毫秒以下的交互式功能，这一点至关重要。对于异步批处理，则无关紧要。

该框架可简化为：月支出 $10K 以下以及任何吞吐量的前沿模型任务全部使用 API；$10K–$50K 之间的大宗任务采用混合路由；$50K 以上采用自托管大宗任务 + API 前沿模型，若有合规性要求则完全覆盖成本估算。

选择你的自托管技术栈

如果计算结果表明自托管是合理的，那么技术栈的选择比团队意识到的更为重要。推理框架决定了你后续运维（Day-two operations）的开销，这甚至比原始模型的选择更关键。

vLLM 是多用户服务的生产环境默认选择。在 10 个以上并发用户时，它的请求吞吐量是 llama.cpp 的 35 倍以上，支持 FP8 和 FlashAttention，并拥有兼容 OpenAI 的 API，从而减少了迁移工作量。它需要设置 CUDA 环境和容器管理——预留 1-2 周时间进行初始生产环境加固。

Ollama 仅适用于开发和单用户原型设计。在 10 个以上并发用户时，它会出现队头阻塞（Head-of-line blocking），吞吐量会崩塌至比 vLLM 低 20 倍。不要将其用于生产环境的多用户负载。

llama.cpp 负责边缘侧部署以及没有 GPU 的环境。在高并发情况下，其吞吐量比 vLLM 低 44 倍。对于纯 CPU 推理或单用户生产部署，它是有效的。对于多租户服务，它并不适用。

TGI (Text Generation Inference) 已于 2025 年 12 月进入维护模式。不要在其基础上启动新项目。

核心结语

自研还是采购（build-vs-buy）的决策不在于哪种方案“更好”——而在于将你的实际成本结构与你在实际规模下的实际运营能力相匹配。等式两边都有标准分析容易忽略的隐藏成本：托管 API 在账单上收取的费用较少，但在工程师的时间成本上却开销巨大；自托管在每个 Token 的成本上看起来更便宜，直到你算上那个在凌晨 2 点因为 CUDA 驱动更新搞崩了生产环境推理服务器而被叫醒的工程师。

做得出色的团队不会预设立场。他们很早就构建了一个路由层，为每个查询埋点记录 Token 数量和延迟，并让数据来决定哪些流量应该迁移。而那些走弯路的团队则仅仅根据定价页面和 GitHub 的 Star 数量来做决定。

算清这笔账。然后在六个月后重新计算，因为市场环境瞬息万变。