在欧盟自托管 LLM：开放权重模型何时才真正划算

在表格上，自托管一个开放权重 LLM 看起来是稳赚的。每小时花几美元租一块 GPU，跑一个免费模型，不再按 token 付费。账单变平，整套栈归你所有。这就是它的卖点，而它只对了一半。它略过的那一半，恰恰决定你是省了钱还是在悄悄亏钱：GPU 是便宜的部分。贵的是那个让推理服务器一直活着的工程师、那个证明量化模型仍能正确作答的评测框架，以及当两个月后更好的开放模型发布时不会停下来的升级节奏。

这是工程与流程视角，不是供应商推销。下面的数字是方向性的，取自 2026 年的公开趋势，在你做决定前应当对照实时报价复核，因为 GPU 价格和 token 价格都按月波动。我们在 AI Enablement 工作中把内部 AI 部署到客户的基础设施上，所以这里的取舍是我们真的会和客户一起权衡的，不是纸上模型。本文延伸我们的token 成本手册（那篇只略微提及自托管），深入讲清楚那个决定一切的问题：自建推理何时能胜过托管 API？

除了 GPU，自托管一个 LLM 到底要花多少？

GPU 这一项是人人都会报的。2026 年 9 月 2 日，Scaleway 列出 H100 PCIe 起价为每 GPU 小时 2.86 欧元，OVHcloud 列出单块 H100 每小时 3.10 欧元。按 730 小时计算，每月约为 2,088 欧元和 2,263 欧元，尚未包含税、存储、网络、冗余和运维。计算前请复核当前条款。

这个数字是真的，同时也是总成本里最小的一块。决定这笔账的，是表格跳过的那些成本：

• 工程师时间。得有人搭起推理服务器、调 batch 大小、管理 GPU 驱动和 CUDA 版本、处理模型加载与回滚，并让它一直跑着。这不是一次性安装，而是持续运维，而在欧盟，一名称职的 ML-ops 工程师每月的成本远高于那块 GPU。
• 冗余。单块 GPU 是单点故障。生产通常意味着至少两块外加故障切换方案，这大致让硬件这一项翻倍，还要加上负载均衡的工作。
• 评测与质量保障。自托管模型一旦退化，责任在你。你需要一套评测框架，证明模型在每次量化决策和每次版本升级后都守住了质量。没有它，你就是在盲飞。
• 升级节奏。开放权重迭代很快。今天有竞争力的模型一个季度后就成了中游。保持跟进是反复出现的工程工作，不是装好就忘的事。

把这些加起来，诚实的定调和我们 token 成本工作里的一样：盈亏平衡由工程师时间决定，而不是 GPU 机架价。模型运行起来便宜。围绕它的纪律不便宜。

相对一个托管 API，盈亏平衡点在哪？

不存在单一的平衡点数字，因为它完全取决于你要替换的是哪个 API。区间宽到足以让这里判断失误成为最常见的自托管错误。

• 相对昂贵的前沿 API，自托管可能更早达到平衡，但前提是开放权重模型能为该任务提供同等的质量、延迟和可用性。
• 相对便宜的开放权重 API，平衡点会更高，因为你在与已优化的基础设施和规模经济竞争。

用你自己的数据计算平衡点：将 GPU、冗余、存储、网络、工程和评测的月度总成本，除以加权后的 API 每 token 或每任务成本。突发流量会让自托管更不利，因为闲置 GPU 也要付费。有意义的比较还必须保证质量和服务水平等价。更宏观的成本曲线见便宜的 token 会改变你的 AI 架构什么。

"大多数团队自托管得太早。他们给 GPU 定了价，却没给那个要让它一直活着的工程师定价，几个月后托管 API 本会更便宜也更省事。"

数据驻留何时会不计成本地逼你自托管？

成本只是一个维度。另一个是治理，对某些欧盟工作负载而言，它会彻底压过那笔账。如果你处理个人或受监管的数据，又不能把它发往欧盟以外的端点，那么成本比较就无关紧要了。问题不再是"自托管是否更便宜"，而变成"最便宜的合规选项是什么"。

GDPR 并未一刀切要求所有处理都只在欧盟内完成。其第五章规范向第三国的数据传输，处理委托、目的限制、安全与架构记录也同样重要。在自有欧盟基础设施上自托管可以减少外部子处理者，但不会自动消除第三方：云、网络、支持和可观测性供应商仍可能参与。同时，服务、日志、访问控制和回滚都成为你的责任。更多选项见面向 AI 应用的欧盟数据驻留。

之上还有一层监管。欧盟 AI 法案正在分阶段生效。通用型 AI 模型义务已经适用，第 50 条透明度义务自 2026 年 8 月 2 日起适用，独立高风险系统义务自 2027 年 12 月 2 日起适用，嵌入产品的高风险系统义务自 2028 年 8 月 2 日起适用。对欧盟团队的实际要点不只是日期。掌控模型在哪里运行，正在成为一项治理资产，而不只是一笔成本，自托管是把这份掌控握在自己手里的一种方式。在提出合规主张之前，请对照官方来源确认分类与角色。

如果你确实要自托管，生产栈长什么样？

如果量或合规已经替你做了决定，2026 年的生产栈已经相当成熟，而且它和你在笔记本上做原型用的那套不一样。本地单流运行器适合做实验，但用于生产就是错的，因为它让 GPU 大部分时间闲着。

本节负责通用生产栈选择。更具体的运维问题，请看我们的 Netflix vLLM 与 Triton 生产分析，其中拆解约束解码、版本固定、安全发布、模型缓存与统一指标。

• 推理引擎：vLLM。vLLM 的持续批处理、PagedAttention 和并行能力可以显著改善 GPU 利用率和聚合吞吐。收益取决于模型、硬件、提示长度、批处理和服务水平，因此应使用自己的负载测试。SGLang 和 TensorRT-LLM 是同类替代方案。我们的共享 KV 缓存 14x 基准是特定系统结果，不是 vLLM 的通用倍数。
• 量化的开放权重。量化可以降低内存和计算成本，但对质量与性能的影响取决于模型、格式、硬件、内核和任务。FP8、AWQ 和 GPTQ 是候选项，不是通用排名。用自己的评测集测量内存、延迟、吞吐和质量。
• 模型本身。Llama、Qwen、DeepSeek 和 Mistral 级别的开放权重是常见候选。在它们之间取舍是另一个独立决策，我们在开放权重模型对比里逐一梳理。如果手机或笔记本内存是硬约束，我们的 Bonsai 27B 评测会把 3.9 GB 权重标题与真实运行内存、任务质量分开分析。模型权重只是内存账单的一部分：如果你用检索，embedding 索引有自己的占用，我们关于把 RAG 向量内存压到 1/16的指南讲了数据无关量化如何缩小它。

你怎么知道更便宜的路真的守住了质量？

这是团队会跳过、然后后悔的一部分。自托管栈里的每一个选择，模型、量化、batch 设置，都可能悄悄拉低质量，而一条悄无声息答得更差的便宜路径，是所有结果里最贵的。唯一诚实的防线，是一套对你真实任务打分的评测框架，而不是公开基准。

这一点我们刻意保持谦逊。建立并维护好的评测，比搭起推理服务器更难，自托管的大部分持续工程成本就在这里，而不在 GPU。你需要一个有代表性的任务集、一套你信得过的打分方法，以及一道在每次更换模型或量化前都会运行的关卡。没有它，你无法判断换成 FP8 是否在要紧的用例上让你损失了两个百分点的准确率。这正是我们在 Twinsoft AI 这类生产 AI 项目中应用的纪律：模型选择只有建立在一套能证明它守住了底线的评测之上才是安全的。

那么，你该自托管吗？一份决策清单。

按顺序过这几个问题。如果前两个的诚实答案都是否，就默认选托管 API，以后再回头看。

1. 数据驻留是否在逼你？如果你在法律上不能把数据发往欧盟以外的端点，又没有合适的欧盟托管 API，那么自托管可能是最便宜的合规选项，与 token 账目无关。仅此一条就能拍板。
2. 你的量是否又高又稳？用月度总成本和实际 API 用量组合计算阈值。突发或低量通常更适合 API。
3. 你有运维能力吗？自托管是反复出现的工程工作：驱动、冗余、升级、监控。如果你的团队不丢下产品工作就扛不起这些，GPU 省下的钱就蒸发了。
4. 你能用评测证明质量吗？如果你无法衡量一个量化的开放模型是否守住你的质量底线，你就还没准备好在生产里依赖它。
5. 你把整张图都定价了吗？GPU 加冗余加工程师时间加评测维护，对比 API 的全包成本。比的是总额，不是拿 GPU 那一项去比 token 那一项。

对大多数早期和中期产品，答案仍然是：留在托管 API，若驻留要紧就选一个数据驻留在欧盟的。当量或合规逼出这个问题时再自托管，而不是一开始就自托管。如果你想在自己的数字和基础设施上做这个比较，那正是我们 AI Enablement 工作的用途。