这个设想颇具吸引力：租用或购买加速器，部署开放权重模型，以此取代金额浮动的 API 账单。但模型不会自动具备同等能力，GPU 也不会始终保持充分利用，而服务技术栈的安全性和可靠性将由你负责。
这是一份成本建模指南，而非基准测试。在选择服务器之前，请查阅当前的 vLLM 文档、vLLM 安全指南、SGLang 文档和 Hugging Face TGI 文档。在目标硬件上对支持的版本进行基准测试。
现实更加复杂。在某些规模下，自托管的成本确实更低；在另一些规模下，运维成本会远远超过推理成本的节省。盈亏平衡点取决于工作负载、模型大小、延迟要求和团队能力。
本文深入介绍相关计算、运维现实，以及区分哪些团队应该自托管、哪些团队不应该自托管的模式。我们假设你正在认真考虑这个问题，并希望看到诚实的数字。
何时适合自托管
以下特征有利于自托管：
规模与利用率。 持续且可预测的需求可以分摊预留容量的成本。请使用测量的每小时负载分布；仅凭每月API支出无法作为盈亏平衡测试。
可预测的工作负载。 使用量稳定且可预测。自托管需要容量规划；突发工作负载会浪费容量（利用率不足）或导致故障（过度饱和）。
隐私/合规要求。 数据不能发送给云提供商（受监管行业、某些政府合同、仅限内部的数据）。
自定义模型。 托管提供商不提供的微调模型、自定义架构或专用变体。
延迟控制。 将服务部署得更靠近用户并控制批处理可能有助于降低延迟，但网络、排队、模型大小、提示长度和负载仍占主导地位。请对目标百分位进行基准测试。
单次调用成本低于盈亏平衡点。 经过计算，自托管确实胜出。
当其中大多数条件成立时，值得认真考虑自托管。
何时不适合自托管
再看另一面。以下特征更适合托管API：
低或变化的规模。 空闲容量和峰值配置可能会抵消看似节省的每令牌价格。托管推理可能更适合，但仍应对两种方案进行测试。
波动性工作负载。 峰值与低谷期之间的巨大差异可能导致预留容量闲置，或需要昂贵的峰值配置。
需要封闭模型能力。 当前某些模型、模态、安全系统或托管工具仅能通过服务提供商提供。如果工作负载评估需要其中之一，请包含提供商路径及其合同约束，而不是使用未经评估的开源模型进行替代。
团队规模小。 自托管推理需要运维专业知识。没有专门投入，系统就会出问题。
快速迭代。 需要尝试许多不同模型、配置和提供商。API让这很容易；自托管则意味着每次变更都要部署。
多区域/全球用户。 自托管可能需要区域容量、路由、数据传输和恢复工作。托管 API 可以减少部分基础设施运维责任，但区域可用性、驻留性、故障转移和网络延迟仍需验证。
在这些情况下，即使托管 API 的直接使用成本更高，它仍可能是风险更低或运营责任更少的候选方案。
成本计算（仔细算）
构建三个基于当前条件且质量相当的场景：封闭模型 API、托管开放权重服务和自托管。在模型通过相同任务评估之前，不要进行模型之间的比较。
针对每个场景，计算：
monthly total = metered inference or dedicated capacity + storage + network + observability + support + security/compliance + engineering + expected incident loss
对于计费 API，推理成本来源于计费的未缓存输入、缓存写入/读取、输出/推理令牌、工具、批次和重试。对于自托管或托管的专用容量，加速器成本池必须包括已使用、空闲、冗余容量、滚动发布所需容量以及故障/回退容量；除非合同中存在一个单独且互斥的计量项，否则不得额外添加“推理”费用。应使用在所需延迟和可用性条件下，经基准测试的每加速器小时请求数来将该容量成本分配给工作负载单元，而非供应商的峰值吞吐量。
对用量、峰均比、模型质量、加速器价格、利用率、员工时间及迁移成本进行敏感性分析。盈亏平衡点是指在一组合理假设下，质量相当的方案其净成本曲线相交的位置。
运维成本
除原始推理成本外，自托管还有运维成本。
初始设置：
- 选择合适的推理服务器（vLLM、TGI、SGLang）。
- 针对模型和硬件进行配置。
- 设置GPU基础设施（云端或自有）。
- 网络、安全和可观测性。
- 量化与优化。
根据范围明确的工作分解、硬件或供应商的交付周期、安全审查、基准测试矩阵、可用性设计以及团队测得的交付能力，估算初始交付周期。本文不提供可直接套用于其他团队的工程师周数范围。
持续运维：
- 监控（延迟、吞吐量、错误、GPU利用率）。
- 容量规划。
- 升级（新模型版本、推理服务器更新、安全补丁）。
- 事件响应（GPU故障、OOM崩溃、软件bug）。
- 扩容（随负载增长增加GPU）。
记录平台、机器学习、安全和值班工作中的实际投入。有关非全职投入（fractional-FTE）的假设无法在不同组织之间通用。
隐藏成本：
- GPU价格波动。
- 混合部署时的云出口流量费用。
- 专项专业知识（CUDA、量化、优化）。
- 自有硬件的更换/故障成本。
使用组织包含全部用工成本的人力费率和机会成本。只有在包含运营责任的情况下，令牌价格节省才能视为净节省。
推理服务器
如果决定自托管，主要选项包括：
vLLM。 一个开源的推理服务引擎，支持连续批处理和广泛的模型，但具体支持范围依版本而定。应将它的安全指南视为必读内容。
TGI（文本生成推理）。Hugging Face 的服务项目。请验证当前的维护状态和模型支持情况，而不是依赖本文的快照。
SGLang。一个正在积极开发中的服务和编程栈。请对所需模型、结构化输出路径和操作工具进行基准测试。
LMDeploy。另一个服务候选方案，其模型、量化和硬件支持依赖于版本；请在相同的接受测试下对其进行基准测试。
llama.cpp / Ollama。适用于本地和某些服务器工作负载的候选方案。必须测试其支持的硬件、并发性、安全边界、操作控制和生产适配性；这两个名称均不保证吞吐量更低或生产就绪性更高。
托管专用端点。Hugging Face 及其他提供商提供的托管端点产品，其引擎、计费、隔离和操作分工会随时间变化。请验证当前服务，而不是假设其运行 TGI 或使用单一计费模式。
托管 GPU 或推理平台。这些方案可以减少部分容量管理和服务运维工作，同时保留集成、安全、评估和提供商依赖。请比较当前的报价和责任划分；不要假设与自主运营存在固定的价格关系。
仅筛选支持指定模型、加速器、量化方式、API 契约和安全控制的方案。最终选择应以可重复的负载测试为依据。
硬件选择
GPU方面：
加速器代数、内存容量和租赁价格变化迅速。请获取所需地区和承诺期限的最新报价。
比较内存容量和带宽、支持的数值格式、互连方式、软件兼容性、配额、区域可用性、故障行为和价格。仅在模型中包含中断处理和可衡量的恢复路径时，才应考虑使用Spot或可抢占的容量。
量化
量化是容量/性能的一种选项。其权衡取决于模型、格式、内核、硬件和任务：
FP16/BF16类参考精度。 通常用作支持模型和硬件的比较基准；它并非自动为模型的原始或“全质量”格式。
INT8 / FP8（8位）。 可能减少权重内存或提高支持的执行路径；质量和速度的影响因情况而异。
INT4（4位）。可进一步减少内存占用；需对具体模型的质量和内核性能进行测量，以确定实际效果。
AWQ、GPTQ、GGUF。 不同的量化格式，各有取舍。
原始参数数量的计算仅为一个下限估计；运行时内存还包括 KV 缓存、激活值、工作区、碎片化以及副本。应使用服务引擎的性能分析工具和负载测试。评估输出质量应基于生产任务，而不仅仅是一般性基准测试。
吞吐量与容量规划
一个关键的规划问题：你需要每秒处理多少token？
测量首个 token 生成时间、token 间延迟、端到端延迟、吞吐量、排队时间、错误率和内存余量，覆盖不同提示和输出长度及并发级别。
对于容量规划：
- 估算峰值并发请求数。
- 估算平均请求长度。
- 计算每秒所需的总token数。
- 根据突发流量、故障和发布需求增加余量。
可靠性与故障回退
自托管意味着可靠性由你负责。
健康检查。 持续监控健康状态，重启不健康的实例。
过载行为。使用有界队列、准入控制、反压机制以及经过测试的降级或拒绝策略。让请求无限等待可能会加剧过载并违反延迟目标。
回退至API。受控的回退机制可以吸收部分故障或峰值流量，但前提是模型质量、数据策略、合同、速率限制、状态和故障转移行为已兼容并经过测试。这会增加复杂性，并可能同时失败。
故障容错能力。 从可用性目标和已测试的故障模式中得出的备用容量或替代路径的大小；每个加速器都可能发生故障，但专用空闲硬件并不是唯一的设计方案。
多区域。 面向全球用户时，在各区域复制部署，或对远端区域使用托管API。
更新策略。 新模型版本、服务器升级。使用蓝绿部署避免停机。
这些都需要工程工作，而托管 API 会替你承担其中一部分。
生成两个决策记录
不要虚构匿名化结果。根据当前报价和基准测试产物生成可审计的决策记录。
自托管候选记录：
- 模型产物、版本、许可证、量化方式、服务版本、加速器、区域和部署拓扑，
- 工作负载分布和与当前托管基线的质量评估，
- 负载测试命令、数据集、延迟/吞吐量结果、饱和点和恢复行为，
- 资本或租赁成本、利用率、工程工作量、安全工作和预期事故成本，
- 带有敏感性分析和退出标准的盈亏平衡范围。
托管候选记录：
- 提供方、模型/版本行为、区域、价格表日期、配额和合同条款，
- 等效质量、延迟、限速、停机和数据边界证据，
- 迁移工作量和供应商集中风险，
- 会触发另一次自托管评估的条件。
何时重新审视决策
这一决策并非永久不变。应定期重新审视：
用量变化。 大幅增长：自托管更有吸引力。大幅下降：吸引力降低。
价格变化。 闭源API变便宜或变贵，托管开放模型方案变便宜，硬件变便宜。
模型改进。 新的开放权重或源代码可用候选模型满足工作负载目标，或新的闭源模型改变了质量比较。验证许可证和实际可用性。
运维能力。 团队的机器学习/运维能力增强或减弱。
隐私/合规变化。 新要求强制采用自托管。
根据合同、价格、模型、工作负载、安全性和容量波动情况设定审查周期，并添加事件驱动的触发器。每季度审查是一个示例，而非通用默认值。
常见错误
我们在自托管决策中常看到以下模式：
错误 1：未考虑运营成本的费用计算。 报告了令牌或加速器的节省，但忽略了工程、值班、安全和事件成本。
错误2：过早自托管。 工作负载还很小时，就把工程精力投入自托管。这是过早优化。
错误 3：比较非等效质量。 在未证明其满足工作负载的质量、安全性和延迟要求的情况下选择了成本较低的模型。
错误 4：没有故障计划。 自托管基础设施发生故障时，没有经过测试的降级、队列、拒绝或回退路径。托管 API 也可能失败；将两种架构都与相同的可用性目标进行比较。
错误 5：假设初始服务配置是高效的。 没有对支持的量化、批处理、并发性、提示长度和服务器设置进行可复现的扫描，因此容量模型基于未经验证的配置。
错误6：忽略质量漂移。 自托管模型相对当前闭源模型已经落后。客户注意到了，团队却没有。
错误7：不再重新考虑。 一旦自托管就永不复评。两年前正确的决定，如今可能已经错误。
错误 8：使用 spot/preemptible 实例但未进行优雅处理。 折扣容量模型未考虑中断频率、恢复时间、重复工作或回退成本。
决策清单
请有意识地做出决定：
- 是否已对质量相当的托管和自托管候选方案进行了基准测试？
- 工作负载是否稳定且可预测？
- 团队是否已有或可以雇佣 MLOps/推理专家？
- 是否存在一个许可证合适的开放权重或源代码可用候选方案，并满足工作负载的质量和安全目标？
- 延迟要求是否与自托管兼容？
- 是否已详细计算成本，包括运营成本？
- 是否有回退计划？
- 合规性/隐私要求是否并未强制指定某一条路径？
- 是否有记录的审查周期和针对模型、价格、合同、工作负载、安全或容量重大变化的事件驱动触发机制？
不要将其简化为复选框的数量。即使所有财务输入看起来都利好，安全、模型质量或运营责任仍可能成为否决因素。
混合模式
这并非非此即彼的选择。候选的混合模式包括：
大部分流量自托管，困难案例使用 API。 分类、简单生成走自托管；复杂推理走闭源 API。
稳定负载自托管，峰值使用 API。 自托管承接基础负载，API 吸收峰值。
敏感数据自托管，一般数据使用 API。 敏感数据通过自托管处理；一般查询通过 API 处理。
微调模型自托管，基础模型使用 API。 自行运行自定义模型；通过 API 使用现成模型。
混合模式会增加路由、数据策略、评估、可观测性、合同和故障复杂性。仅在测试表明拆分能提升明确目标时才应采用。
依据当前证据作出决定
当支持的模型满足工作负载的质量目标，且组织能够承担服务全生命周期的责任时，自托管是一种可行的架构。
盈亏平衡点并不是一个固定的月度支出。它会随着模型质量、需求形态、利用率、加速器和提供商价格、可用性、数据边界要求以及员工成本的变化而变化。
支持自托管决策的证据应包括：
- 仔细完成了计算，包括运维成本。
- 具备或能够建立MLOps能力。
- 规模足以证明投资合理。
- 工作负载稳定。
- 不依赖只有前沿闭源模型才具备的能力。
- 对可靠性、监控和更新做好规划。
支持托管服务决策的证据可能包括：
- 规模较小。
- 工作负载突发性强。
- 需要快速迭代。
- 团队较小，缺乏运维能力。
- 需要闭源前沿能力。
正确答案取决于具体的工作负载。运行质量、负载、故障、安全和成本的比较，并评估运营能力。优先选择满足强制性要求且责任负担最低的方案；这可能是托管服务、自托管或混合模式。
当选择自托管时，请记录所测得的效益、假设、负责人、退出条件以及下次审查触发条件。对托管推理也应执行相同操作；在没有当前证据的情况下，这两种路径均不正确。
