这个主张很有吸引力。开源模型具有竞争力，GPU也可以买到，vLLM、TGI和SGLang等推理服务器已经成熟。既然可以自行托管同等能力的模型，为什么还要向OpenAI或Anthropic支付5–10倍的溢价？
现实更加复杂。在某些规模下，自托管确实胜出；在另一些规模下，运维成本会远远超过推理成本的节省。盈亏平衡点取决于工作负载、模型大小、延迟要求和团队能力。
本文深入介绍相关计算、运维现实，以及区分哪些团队应该自托管、哪些团队不应该自托管的模式。我们假设你正在认真考虑这个问题，并希望看到诚实的数字。
何时适合自托管
以下特征有利于自托管：
规模。 推理量很大。具体而言，每月API推理支出超过€5K–10K时，通常值得考虑自托管。
可预测的工作负载。 使用量稳定且可预测。自托管需要容量规划；突发工作负载会浪费容量（利用率不足）或导致故障（过度饱和）。
隐私/合规要求。 数据不能发送给云提供商（受监管行业、某些政府合同、仅限内部的数据）。
自定义模型。 托管提供商不提供的微调模型、自定义架构或专用变体。
延迟控制。 某些应用需要低于100ms的首token延迟，这就要求在你控制的基础设施上运行模型。
单次调用成本低于盈亏平衡点。 经过计算，自托管确实胜出。
当其中大多数条件成立时，值得认真考虑自托管。
何时不适合自托管
再看另一面。以下特征更适合托管API：
规模小或波动大。 推理支出低于每月€5K。节省不足以抵消运维成本。
突发工作负载。 高峰期与低谷期使用量相差10倍。自托管会在低谷浪费容量。
需要前沿能力。 GPT-5.5、Claude Opus 4.8、最新推理档位——这些模型是闭源的，只能通过API使用。如果你的工作负载确实需要前沿质量，就必须为API付费。
团队规模小。 自托管推理需要运维专业知识。没有专门投入，系统就会出问题。
快速迭代。 需要尝试许多不同模型、配置和提供商。API让这很容易；自托管则意味着每次变更都要部署。
多区域/全球用户。 自托管要求你在每个区域运营。托管API会替你处理。
在这些情况下，即使成本不低，托管API仍是正确答案。
成本计算（仔细算）
下面对一个有代表性的案例进行实际计算。假设：
- 工作负载：每月1亿输入token、3,000万输出token。
- 质量目标：与Claude Sonnet 5或当前GPT-5.x档位相当。
- 可用的开源模型：Llama 3.3 70B（许多任务的质量接近闭源旗舰；注意并不存在“Llama 4 70B”——Llama 4以Scout/Maverick MoE模型发布）。
方案A：调用闭源模型API。
- 闭源旗舰API（Claude Sonnet 5标价，核验于2026-07-07）：输入$3/M × 100M = $300；输出$15/M × 30M = $450。合计约$750/月。
这一支出水平不足以支持自托管。
将工作负载扩大10倍：
- 10亿输入token、3亿输出token。
- 闭源API：$7,500/月。
此时自托管开始变得有吸引力。
方案B：通过托管开源提供商调用开源模型API。
- Together AI上的Llama 3.3 70B：输入和输出均为$0.88/M（标价，核验于2026-07-07）。
- 1B输入 × $0.88/M = $880；300M输出 × $0.88/M = $264。合计约$1,144/月。
与闭源方案相比节省约85%，相当可观。
方案C：租用GPU自托管。
- 量化（INT8/FP8）后的70B模型可装入一张H100 80GB；若使用FP16权重或需要批处理吞吐余量，则应规划约2张H100——以下容量估算假设使用2张以保证吞吐量。
- H100租金：每张每小时$2–3。
- 2张H100 × $2.50/小时 × 730小时/月 = 仅计算资源每月$3,650。
- 另加：存储、网络和运维时间。
对于这一工作负载，在托管提供商上运行开源模型，单看成本也胜过自托管。只有当你还需要控制权（隐私、自定义模型），或吞吐量高得多时，自托管才会胜出。
方案D：在自有/长期预留GPU上自托管。
- 购买或长期预留2张H100：有效成本为每张每小时$1–2。
- 2张H100 × $1.50/小时 × 730小时 = $2,190/月。
- 更高利用率可摊薄成本：如果这些GPU处理多个工作负载，则单个工作负载的成本更低。
现在已经可以与托管开源提供商竞争，但运维开销确实存在。
关键洞察： 在这一工作负载规模（约每月1.3B token）下，自托管相对于托管开源提供商的节省很有限。相对于闭源API的节省非常显著，但托管开源方案已经拿走了其中大部分收益。
当工作负载再扩大10倍（约每月13B token）时，自托管开始明显胜出。缩小10倍时，则应选择托管方案。
运维成本
除原始推理成本外，自托管还有运维成本。
初始设置：
- 选择合适的推理服务器（vLLM、TGI、SGLang）。
- 针对模型和硬件进行配置。
- 设置GPU基础设施（云端或自有）。
- 网络、安全和可观测性。
- 量化与优化。
典型投入：首次部署需要1–4个工程师周。
持续运维：
- 监控（延迟、吞吐量、错误、GPU利用率）。
- 容量规划。
- 升级（新模型版本、推理服务器更新、安全补丁）。
- 事件响应（GPU故障、OOM崩溃、软件bug）。
- 扩容（随负载增长增加GPU）。
典型投入：持续需要0.25–1名全职工程师，具体取决于规模。
隐藏成本：
- GPU价格波动。
- 混合部署时的云出口流量费用。
- 专项专业知识（CUDA、量化、优化）。
- 自有硬件的更换/故障成本。
按每名工程师每年€100K–200K的完全成本计算，即使只占用部分工程时间也很可观。每月节省€5K推理成本，会被每月€15K的工程成本完全吞没。
团队往往正是在这里低估自托管成本。孤立看推理计算很漂亮，但总拥有成本高得多。
推理服务器
如果决定自托管，主要选项包括：
vLLM。 开源，可能是目前最流行的开源LLM服务方案。支持PagedAttention、连续批处理和广泛的模型，是默认选择。
TGI（Text Generation Inference）。 Hugging Face的服务器。成熟、模型支持广泛、性能良好。近期功能开发速度不如vLLM。
SGLang。 更新、性能很高，尤其擅长结构化生成，开发活跃。
LMDeploy。 来自InternLM团队。量化能力强、速度快。
llama.cpp / Ollama。 适合较小模型和较低吞吐量，对CPU友好。在某些使用场景中已达到生产级。
Hugging Face TGI Inference Endpoints。 托管式自托管。按实例小时付费，由HF运维。介于完全自托管与托管服务之间。
Modal、RunPod、Replicate。 推理函数即服务。投入低于完全自托管；成本高于自己动手。
对大多数团队而言：生产自托管选vLLM或SGLang。两者都成熟、快速且文档完善。
硬件选择
GPU方面：
NVIDIA H100。 当前推理领域的顶尖选择。租金约每小时$2–3，提供80GB VRAM和快速推理。70B模型量化后可在单张H100上良好运行，未量化则需2张。
NVIDIA H200。 H100的后继产品，VRAM更大（141GB），适合超大模型。
NVIDIA L40S。 更易获得，约每小时$1–2。适合中等规模模型（量化后最高约30B）。
NVIDIA A100。 上一代产品，仍广泛可用。约每小时$1–2，是许多生产部署的主力。
AMD MI300X。 在某些工作负载上可与H100竞争，供应日益增加。软件成熟度仍不及NVIDIA技术栈。
Apple M系列。 对于很小的模型（低于8B），配备统一内存的Mac Studio或Mac Pro可以胜任，属于小众使用场景。
2026年的大多数生产自托管场景：大模型选H100或H200；中等模型选L40S或A100。
租赁来源：AWS、GCP、Azure（主流），Lambda Labs、Runpod、Together、Vast.ai（专业服务商）。价格各不相同。若能容忍中断，竞价/可抢占实例可节省50–70%。
量化
大多数生产自托管部署会使用量化模型。取舍如下：
FP16（16位）。 默认精度。质量完整，占用内存最多。
INT8 / FP8（8位）。 内存减半，质量略有损失。常见的生产选择。
INT4（4位）。 内存降至四分之一，质量损失更明显，但仍有实用价值。较激进的选择。
AWQ、GPTQ、GGUF。 不同的量化格式，各有取舍。
对于70B模型：
- FP16：140GB VRAM。
- INT8：70GB VRAM。
- INT4：35GB VRAM。
H100有80GB VRAM。INT8可以轻松装入；FP16需要2张GPU。
质量影响：
- INT8：基准测试通常下降不到1%。
- INT4：下降1–5%，因任务而异。
部署前请在你的工作负载上测试。某些任务（尤其是结构化任务/代码）比其他任务对量化更敏感。
吞吐量与容量规划
一个关键的规划问题：你需要每秒处理多少token？
单请求吞吐量。
- H100上的70B模型，INT8：单用户约每秒50–80 token。
批处理吞吐量。
- 多个并发请求：所有请求合计每秒1000–3000 token（使用批处理配置良好的vLLM）。
延迟考量。
- 首token延迟：通常为100–500ms。
- 单token延迟：10–30ms。
容量规划时：
- 估算高峰并发请求数。
- 估算平均请求长度。
- 计算所需的总token/秒。
- 预留50%余量。
一个每小时处理1M token、峰值并发用户数为50的团队，在利用率良好的情况下通常需要2–4张H100。
可靠性与故障回退
自托管意味着可靠性由你负责。
健康检查。 持续监控健康状态，重启不健康的实例。
优雅降级。 容量饱和时，宁可响应变慢，也不要直接失败。
回退到API。 许多团队以自托管承接主要流量，过载时回退到托管API。兼得两者优势，但复杂度真实存在。
备用硬件。 GPU会发生故障，应准备好备用容量。
多区域。 面向全球用户时，在各区域复制部署，或对远端区域使用托管API。
更新策略。 新模型版本、服务器升级。使用蓝绿部署避免停机。
这些都需要工程工作，而托管API会替你承担。
完整示例：某团队的自托管决策
一个真实示例。某SaaS团队提供AI功能，使用托管API的月度推理成本为€18,000。
计算：
- 80%的推理是分类和提取（可以在更小的开源模型上运行）。
- 20%是复杂生成（需要闭源前沿模型）。
计划：
- 对80%的工作负载自托管Llama 3.3 70B。
- 其余20%继续使用Claude/GPT API。
- 在Lambda Labs预留3张H100：约€4,500/月。
- 工程设置：4周，一次性€25K。
- 持续运维：0.25名全职工程师，约€30K/年。
6个月后的结果：
- 推理成本从每月€18K降至€6K（自托管€4.5K + 困难任务的闭源API €1.5K）。
- 相比原方案净节省：€12K/月 = €144K/年。
- 扣除工程投入：€25K + €30K = €55K/年。
- 净财务收益：约€89K/年。
隐藏的复杂性：
- 一次部署配置bug导致停机，部分功能降级2小时。
- 为达到最佳吞吐量，持续调优了数周。
- 负责自托管的工程师希望把时间用于其他工作。
结果： 财务上有利，但运维负担比预期更重。团队继续自托管；如果使用量下降50%，他们会切回托管方案。
这才是真实、成功的自托管决策。它不是魔法，而是具有可衡量投资回报的工程工作。
完整示例：某团队“回归API”的决策
另一支起点相近的团队。
原始设置： 在租用的GPU上自托管Llama 3 70B。推理租金为每月€3K，另加每年约€20K的持续工程成本。
变化：
- 托管开源提供商的价格在18个月内下降50%。
- 团队规模扩大，但没有招聘专职MLOps。
- 自托管设施需要大量工作才能跟上新模型。
决策：
- 停止自托管。
- 迁移到Together AI托管开源模型。
- 托管开源模型成本：每月€2.5K。略有节省，复杂度更低。
- 释放工程师时间。
结果：
- 财务上小幅节省。
- 工程师可以投入产品工作。
- 运维压力降低。
结论： 对他们而言，这是正确选择。自托管适合一些团队，不适合另一些团队。
何时重新审视决策
这一决策并非永久不变。应定期重新审视：
用量变化。 大幅增长：自托管更有吸引力。大幅下降：吸引力降低。
价格变化。 闭源API变便宜或变贵，托管开源方案变便宜，硬件变便宜。
模型改进。 新开源模型追平闭源质量；新闭源模型再次拉开差距。
运维能力。 团队的机器学习/运维能力增强或减弱。
隐私/合规变化。 新要求强制采用自托管。
每季度检查一次是合理频率。无需持续不断地重新评估，但也不能“一次决定，永不再议”。
常见错误
我们在自托管决策中常看到以下模式：
错误1：计算成本时不包括运维。 “自托管每月节省€10K”——但忽略了每月€15K的工程成本。投资回报为负。
错误2：过早自托管。 工作负载还很小时，就把工程精力投入自托管。这是过早优化。
错误3：用小型开源模型实现前沿质量。 “使用小模型可以省钱”——但质量下降，用户投诉，最后又回退到API。
错误4：没有故障回退。 自托管基础设施宕机，却没有优雅降级。API客户原本不会遇到的停机因此发生。
错误5：优化投入不足。 单张GPU上的70B模型每秒只跑5 token，而正确设置可达到50。大部分价值被白白浪费。
错误6：忽略质量漂移。 自托管模型相对当前闭源模型已经落后。客户注意到了，团队却没有。
错误7：不再重新考虑。 一旦自托管就永不复评。两年前正确的决定，如今可能已经错误。
错误8：使用竞价/可抢占实例却不做优雅处理。 计算成本节省了60%，但实例每隔几小时被回收时就会停机。
决策清单
请有意识地做出决定：
- API推理支出是否至少为€5–10K/月？
- 工作负载是否稳定且可预测？
- 团队是否拥有或能够招聘MLOps/推理专业人才？
- 是否存在质量足够的开源模型？
- 延迟要求是否适合自托管？
- 是否已进行包含运维成本的详细计算？
- 是否有故障回退计划？
- 合规/隐私要求是否未强制指定某一条路径？
- 是否会每季度重新审视？
如果大多数答案为“是”，就值得认真考虑自托管。
混合模式
这不是非此即彼。许多团队采用混合模式：
大部分流量自托管，困难案例使用API。 分类、简单生成走自托管；复杂推理走闭源API。
稳定负载自托管，峰值使用API。 自托管承接基础负载，API吸收峰值。
敏感数据自托管，一般数据使用API。 敏感数据通过自托管处理；一般查询通过API处理。
微调模型自托管，基础模型使用API。 自行运行自定义模型；通过API使用现成模型。
混合模式会增加复杂度，但往往能兼得两者优势。对于达到一定规模的团队，混合通常是正确答案。
核心结论
2026年，自托管LLM推理确实可行。开源模型具有竞争力，推理服务器已经成熟，硬件可以买到。
但运维成本真实存在，而且很容易低估。相对于托管API，盈亏平衡点大致是每月€5–10K的推理支出；低于这一水平，工程投入无法收回。
成功自托管的团队：
- 如实完成了计算，包括运维成本。
- 拥有或能够建立MLOps能力。
- 规模足以证明投资合理。
- 工作负载稳定。
- 不依赖只有前沿闭源模型才具备的能力。
- 对可靠性、监控和更新做好规划。
应该继续使用API的团队：
- 规模较小。
- 工作负载突发性强。
- 需要快速迭代。
- 团队较小，缺乏运维能力。
- 需要闭源前沿能力。
正确答案取决于你的具体情况。仔细计算，如实评估运维能力。除非自托管明显胜出，否则默认使用API。
当自托管胜出时，它会在经济和架构层面带来巨大收益。当它不胜出时，你会用高昂代价才发现：托管API从一开始就是正确选择。
