--- title: "本地模型 vs API：欧盟企业盈亏平衡计算器" canonical: https://wavect.io/zh/blog/local-models-vs-apis-break-even-eu-2026/ language: zh description: "欧盟企业什么时候该用本地 LLM 而不是 API？这份盈亏平衡计算器覆盖 GPU 利用率、API 成本、数据驻留、运维、eval 和负载形态。" image: "https://wavect.io/img/blog/headers/header_local-models-vs-apis-break-even-eu-2026.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 分钟 阅读 · 2026年7月8日 [**下一篇**](/zh/blog/llm-cost-calculator-2026/) # 本地模型什么时候胜过 API：欧盟企业盈亏平衡计算器 要点速览 本地 LLM 只有在完整等式胜出时才会超过 API，而不是 GPU 小时看起来便宜时。API 成本应按每个成功任务计算；自托管成本应把 GPU 小时、冗余、存储、网络、可观测性、工程运维、eval 维护和空闲容量相加，再除以成功任务数。利用率研究显示，同一块 H100 因并发和负载不同，每百万输出 token 可以从很便宜变成非常昂贵，所以利用率是第一变量。托管 API 适合低量、波动或快速变化的工作；本地适合高而稳定的量、严格欧盟数据驻留，或在 open-weight 模型通过 eval 后替代昂贵 frontier API。计算器需要 token 量、每任务 token、并发、利用率、延迟 SLO、工程成本、eval 通过率和 API 替代方案。不要在测量 caching、batching、routing 和模型 right-sizing 之前自托管。数字是 2026 年 7 月快照；预算前请重新检查实时供应商价格。 相关服务: [AI 赋能](/zh/services/ai-enablement/) 本地 LLM 只有在负载、治理和运维能力同时成立时才会胜过 API。便宜的 GPU 小时不是商业理由。真正要算的是每个成功任务的成本，其中必须包括利用率、并发、冗余、工程时间、eval 维护和欧盟数据驻留。如果开源权重模型不能通过你的 eval，计算就结束。如果它能通过，但 GPU 一天大部分时间空闲，计算通常也会结束。 一个极端实例是我们的 [消费级硬件运行 GLM-5.2 的 Colibri 实测](/zh/blog/colibri-glm-5-2-consumer-hardware/) ：25 GB RAM 在技术上能执行模型，但冷缓存只有 0.05-0.1 token/s，说明“本地能跑”不等于“商业上划算”。检索会给这笔账单加上自己的一行：我们关于 [把 RAG 向量内存压到 1/16](/zh/blog/rag-vector-memory-quantization/) 的指南讲了 embedding 索引的占用与 recall 取舍。 这篇文章是 [LLM 成本计算器 2026](/zh/blog/llm-cost-calculator-2026/) 的自托管版。那篇文章比较 API 的每任务成本；这里比较 API 任务和本地推理。2026 年利用率研究给出的核心教训很简单：同一块 H100，因为负载和并发不同，每百万输出 token 的成本可能极低，也可能非常高。一篇近期 arXiv 论文在相同 H100 硬件上测得 $0.21 到 $15.25 每百万输出 token 的跨度，并指出忽略利用率的计算器会按 1 / U 低估成本。 本计算器只负责服务器和私有云经济性。如果负载可以在客户设备上运行，请阅读我们的 [Transformers.js 浏览器 AI 生产指南](/zh/blog/transformers-js-browser-ai-guide/) ，了解客户端隐私、模型交付、WebGPU 与 WASM 备用路径，以及转移到产品工程和用户硬件的成本。 ## 简短答案 当流量低、波动大、变化快，或依赖 frontier reasoning 时，通常用 API。当你有高而稳定的负载、一个能通过 eval 的模型、能运维该栈的团队，并且有严格欧盟数据驻留要求或昂贵 API baseline 时，本地模型才值得认真计算。欧盟区域 API 和托管 open-weight endpoint 通常是完全自托管前的中间答案。 | 场景 | 通常胜出 | 原因 | | --- | --- | --- | | 每月几千个任务的内部助手 | API | GPU 空闲和运维成本会吞掉 token 省下的钱。 | | 夜间处理数百万文档的抽取流程 | 本地或 Batch API | 稳定负载和异步延迟可以填满容量或享受 batch 折扣。 | | 含敏感数据的欧盟监管工作负载 | 欧盟 API、私有部署或本地 | 治理可能压倒纯成本，但托管欧盟选项应先比较。 | | 面向客户且流量尖峰明显的 SaaS 聊天机器人 | API 或混合 | 弹性、安全更新和峰值处理比 GPU 标价更重要。 | | 高频分类、路由、富集或摘要 | 本地候选 | 较小 open-weight 模型可能通过 eval 并充分利用便宜硬件。 | ## 计算器 比较 API 的每成功任务成本和本地的每成功任务成本。不要拿供应商账单和 GPU 账单直接比较。 | 项目 | 公式 | 说明 | | --- | --- | --- | | API 月成本 | tasks_per_month * api_cost_per_successful_task | 使用任务级计算，而不是单次调用估算。 | | API 任务成本 | sum(input + cached_input + output + tools + retries + failure_rework) | 只有真正符合条件的工作才应用 caching 和 batch。 | | 本地月成本 | gpu_hours + redundancy + storage + networking + observability + engineering_ops + eval_upkeep | 不要把人力成本藏在表外。 | | 本地任务成本 | self_host_monthly / successful_tasks_per_month + variable_task_cost | 用通过的任务做分母，不是 request。 | | 盈亏平衡任务数 | self_host_fixed_monthly / (api_task_cost - self_host_variable_task_cost) | 如果分母很小或为负，API 胜出。 | 本地每 1M token 有效成本 = ((gpu_hourly_rate + infra_hourly + ops_hourly) / (tokens_per_second * 3600 * measured_utilization)) * 1,000,000。 实际利用率是陷阱。如果表格假设 80%，而生产只有 12%，在冗余、值班和 eval 维护之前，成本已经大约错了 6.7 倍。 计算本地候选模型的成本前，先确认它能在目标机器上按计划上下文和量化版本运行。我们的 [llmfit 本地 LLM 硬件适配指南](/zh/blog/llmfit-local-llm-hardware-guide/) 说明如何生成候选清单，以及为什么速度估算仍需要真实基准测试。如果候选模型是 DeepSeek V4 Flash 0731，我们的 [单台 AI PC 部署评测](/zh/blog/deepseek-v4-flash-0731-local-ai-pc/) 说明 128 GB 与 192 GB 的哪些假设应进入计算。 ## 先收集哪些输入 | 输入 | 测量内容 | 为什么会改变决策 | | --- | --- | --- | | 任务量 | 每天和每月成功业务任务数 | 低量让本地固定成本很痛。 | | 每任务 token | 未缓存输入、缓存输入、输出、工具调用、验证调用 | 输出重的任务会抬高 API 成本；稳定输入让缓存更有价值。 | | 并发 | 每秒请求、p95 延迟、飞行中请求 | 并发决定 GPU 饱和和排队行为。 | | 可 batch 比例 | 可以等待几分钟或几小时的比例 | Batch API 可能先把成本降下来。 | | 模型通过率 | 本地候选模型相对 API baseline 的 eval | 便宜但失败的模型只是把成本转移到支持团队。 | | 运维能力 | Serving、安全、监控、更新和事故处理时间 | 本地系统有工资成本。 | | 数据约束 | GDPR、合同、数据驻留、审计 | 治理可能要求本地，即使 API 更便宜。 | ## 为什么利用率比 GPU 价格重要 GPU 报价很直观，利用率却来自你的流量形态。交互式助手可能长时间空闲并突然冲高。夜间抽取任务可以用受控队列深度连续运行数小时。后者可能让本地模型合理；前者通常不会。 Serving 栈同样重要。vLLM 与 HuggingFace TGI 的研究发现，高并发工作负载下 vLLM 吞吐最高可达 TGI 的 24 倍，而 TGI 在中等并发的交互场景中尾延迟更低。这并不表示 vLLM 永远胜出，而是说明你的计算器需要针对具体模型、量化、上下文长度和延迟目标做 benchmark。 ## 不要和错误的 API 比较 本地模型不需要击败价格表里最贵的 frontier 模型，除非你的任务真的需要它。它需要击败经过缓存、batch、路由和模型 right-sizing 之后仍能接受的最便宜托管路径。 - OpenAI pricing 区分输入、缓存输入和输出，因此稳定 prefix 会显著改变 baseline。 - Gemini pricing 在付费层包含 context caching 和 batch pricing，并按层级区分是否用于产品改进。 - Amazon Bedrock 表示部分 foundation model 的 batch inference 比 on-demand 低 50%。 - Azure OpenAI 对欧盟企业很重要，因为 data zone、provisioned throughput、预留和采购流程都可能和 token 价格同等重要。 优化顺序见 [2026 年如何降低 LLM token 成本](/zh/blog/reduce-llm-token-costs-2026/) 。模型选择见 [open-weight LLM 对比](/zh/blog/open-weight-llm-comparison-2026/) 。 ## 示例计算 假设一家欧盟 SaaS 公司运行文档富集流水线。当前 API 路径在缓存、batch、重试和验证调用之后，每个成功文档成本为 0.018 美元。本地候选模型通过同一 eval。本地栈每月总成本 9,800 美元，包括 GPU、热备容量、存储、日志、监控、网络、工程时间和 eval 维护。每个文档的本地可变成本为 0.003 美元。 | 指标 | 数值 | 解释 | | --- | --- | --- | | API 任务成本 | $0.018 | 每个成功文档的实测成本。 | | 本地可变成本 | $0.003 | 本地栈存在后的每文档额外成本。 | | 本地月固定成本 | $9,800 | 基础设施加人力和 eval 维护。 | | 每任务节省 | $0.015 | API 任务成本减去本地可变成本。 | | 盈亏平衡 | 每月 653,334 个成功文档 | 9,800 / 0.015，尚未加入风险缓冲。 | 需要加入风险缓冲。如果 eval 通过率下降、实际利用率低于 benchmark、failover 需要第二块热备 GPU，或需求有季节性，盈亏平衡点会右移。如果负载异步且能夜间填满 GPU，盈亏平衡点会左移。 ## 欧盟因素 对欧盟企业来说，本地还是 API 很少只是价格问题。GDPR、DPA、客户采购、行业规则和可审计性都可能决定架构。但治理并不自动等于自托管。 | 需求 | API 路径 | 本地路径 | | --- | --- | --- | | 欧盟数据驻留 | 在合同和风险允许时使用欧盟区域或 data zone。 | 在欧盟云或自有基础设施上推理，并控制日志和存储。 | | Prompt 不用于训练 | 按产品和层级核对 enterprise/API 条款。 | Prompt、输出、日志和 embedding 留在你的环境。 | | 客户审计 | 记录子处理方、保留策略、访问控制和供应商条款。 | 记录 GPU 供应商、镜像来源、模型许可证、serving 日志和访问控制。 | | 敏感行业数据 | 考虑 private endpoint、脱敏或带 policy 的 gateway。 | 如果原始数据不能离开 tenant 边界，优先本地。 | 更多背景见 [AI 应用的欧盟数据驻留](/zh/blog/eu-data-residency-ai-apps-2026/) 和 [在欧盟自托管 LLM 的真实成本](/zh/blog/self-hosting-llms-eu-cost/) 。 如果目标模型超过每一台单机，请看我们的 [Mesh LLM 多机分布式推理评测](/zh/blog/mesh-llm-distributed-inference-multiple-computers/) ，其中单独分析了组合内存带来的网络与可靠性成本。 ## 你真正付费的本地栈 这个栈不是“模型加 GPU”。生产部署通常包括 [vLLM](https://docs.vllm.ai/en/latest/) 这样的 serving runtime、模型 artifact 管理、量化决策、autoscaling 或队列控制、遥测、日志策略、访问控制、eval job、发布门禁、事故响应，以及本地模型失败或 GPU 池满载时的 fallback 路由。 更务实的架构往往是混合：本地处理便宜、稳定、高频工作；API 处理困难任务、overflow、多模态、工具重的推理，或 frontier 质量仍然胜出的场景。这时计算器会变成路由计算器：本地默认、API fallback、实测升级率，以及证明低价路径仍合格的 eval。 ## 来源和价格提醒 供应商价格和模型名称变化很快。公式是稳定的，示例价格机制是 2026 年 7 月快照。预算前请重新检查 [OpenAI pricing](https://developers.openai.com/api/docs/pricing) 、 [Gemini API pricing](https://ai.google.dev/gemini-api/docs/pricing) 、 [Amazon Bedrock pricing](https://aws.amazon.com/bedrock/pricing/) 和 [Azure OpenAI pricing](https://azure.microsoft.com/en-us/pricing/details/azure-openai/) 。利用率和 serving 假设见 [Beyond Per-Token Pricing](https://arxiv.org/abs/2606.11690) 与 [vLLM vs TGI 研究](https://arxiv.org/abs/2511.17593) 。 拿你自己的真实负载去跑这套对比，然后把胜出的那一侧真正建出来，就是我们的 [AI 落地服务](/zh/services/ai-enablement/) 。如果一开始把自托管摆上桌的理由就是欧盟数据驻留，那么我们的 [AI 产品开发服务](/zh/services/artificial-intelligence/) 会先梳理数据流向，再决定要不要押注硬件。 [Hyperstate AI](/zh/case-studies/hyperstate-ai/) 就是那个由 GPU 经济性真正决定架构的公开案例。 ## 最终思考 本地模型胜过 API 的条件是：模型通过 eval，负载能让硬件保持忙碌，固定运维成本低于 API 节省，并且欧盟治理收益是真实的。它们在低流量、波动流量、未优化 API baseline，或团队只算 GPU 不算人的情况下会输。 对很多欧盟企业来说，实际答案是混合：先用 API 同时测量每任务成本，再把稳定高频工作迁到本地，并保留 API 处理 overflow 和困难任务。盈亏平衡不是口号，而是生产遥测里的一行。 ## 你可能也喜欢.. [**LLM 成本计算器 2026** 配套的 API 每成功任务成本计算器：caching、batch、routing、重试和 eval 质量。](/zh/blog/llm-cost-calculator-2026/) [**AI Enablement vs 通用 AI 咨询** 一个交付战略幻灯片。另一个在你的基础设施上交付团队拥有的可运行系统。](/zh/compare/ai-enablement-vs-generic-ai-consultancy/) 模型与基础设施 ## 继续浏览此集群 模型选择、推理经济性、本地部署、压缩与服务架构。 [从核心文章开始**在欧盟自托管 LLM：开放权重模型何时才真正划算**](/zh/blog/self-hosting-llms-eu-cost/) - [Netflix 的 vLLM 与 Triton 推理栈：7 个生产经验](/zh/blog/netflix-vllm-triton-inference-stack/) - [Transformers.js 浏览器本地 AI：什么时候适合放进产品](/zh/blog/transformers-js-browser-ai-guide/) - [LiteLLM 生产级自托管指南：2026 架构与安全](/zh/blog/self-host-litellm-production-2026/) - [AI 就绪企业 Wiki：架构与实施指南](/zh/blog/ai-ready-company-wiki/) - [Claude 会给文本加水印吗？2026 API 实战解读](/zh/blog/claude-text-watermark-api-2026/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 分钟 阅读 · 2026年7月8日 [**下一篇**](/zh/blog/llm-cost-calculator-2026/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/local-models-vs-apis-break-even-eu-2026/#webpage", "@type": "WebPage", "dateModified": "2026-07-08", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-08", "url": "https://wavect.io/zh/blog/local-models-vs-apis-break-even-eu-2026/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "本地 LLM 只有在完整等式胜出时才会超过 API，而不是 GPU 小时看起来便宜时。API 成本应按每个成功任务计算；自托管成本应把 GPU 小时、冗余、存储、网络、可观测性、工程运维、eval 维护和空闲容量相加，再除以成功任务数。利用率研究显示，同一块 H100 因并发和负载不同，每百万输出 token 可以从很便宜变成非常昂贵，所以利用率是第一变量。托管 API 适合低量、波动或快速变化的工作；本地适合高而稳定的量、严格欧盟数据驻留，或在 open-weight 模型通过 eval 后替代昂贵 frontier API。计算器需要 token 量、每任务 token、并发、利用率、延迟 SLO、工程成本、eval 通过率和 API 替代方案。不要在测量 caching、batching、routing 和模型 right-sizing 之前自托管。数字是 2026 年 7 月快照；预算前请重新检查实时供应商价格。", "articleBody": " 博客概览/AI 与智能体/模型与基础设施 本地模型什么时候胜过 API：欧盟企业盈亏平衡计算器 要点速览 本地 LLM 只有在完整等式胜出时才会超过 API，而不是 GPU 小时看起来便宜时。API 成本应按每个成功任务计算；自托管成本应把 GPU 小时、冗余、存储、网络、可观测性、工程运维、eval 维护和空闲容量相加，再除以成功任务数。利用率研究显示，同一块 H100 因并发和负载不同，每百万输出 token 可以从很便宜变成非常昂贵，所以利用率是第一变量。托管 API 适合低量、波动或快速变化的工作；本地适合高而稳定的量、严格欧盟数据驻留，或在 open-weight 模型通过 eval 后替代昂贵 frontier API。计算器需要 token 量、每任务 token、并发、利用率、延迟 SLO、工程成本、eval 通过率和 API 替代方案。不要在测量 caching、batching、routing 和模型 right-sizing 之前自托管。数字是 2026 年 7 月快照；预算前请重新检查实时供应商价格。 相关服务: AI 赋能 本地 LLM 只有在负载、治理和运维能力同时成立时才会胜过 API。便宜的 GPU 小时不是商业理由。真正要算的是每个成功任务的成本，其中必须包括利用率、并发、冗余、工程时间、eval 维护和欧盟数据驻留。如果开源权重模型不能通过你的 eval，计算就结束。如果它能通过，但 GPU 一天大部分时间空闲，计算通常也会结束。 一个极端实例是我们的消费级硬件运行 GLM-5.2 的 Colibri 实测：25 GB RAM 在技术上能执行模型，但冷缓存只有 0.05-0.1 token/s，说明“本地能跑”不等于“商业上划算”。检索会给这笔账单加上自己的一行：我们关于把 RAG 向量内存压到 1/16的指南讲了 embedding 索引的占用与 recall 取舍。 这篇文章是 LLM 成本计算器 2026 的自托管版。那篇文章比较 API 的每任务成本；这里比较 API 任务和本地推理。2026 年利用率研究给出的核心教训很简单：同一块 H100，因为负载和并发不同，每百万输出 token 的成本可能极低，也可能非常高。一篇近期 arXiv 论文在相同 H100 硬件上测得 $0.21 到 $15.25 每百万输出 token 的跨度，并指出忽略利用率的计算器会按 1 / U 低估成本。 本计算器只负责服务器和私有云经济性。如果负载可以在客户设备上运行，请阅读我们的Transformers.js 浏览器 AI 生产指南，了解客户端隐私、模型交付、WebGPU 与 WASM 备用路径，以及转移到产品工程和用户硬件的成本。 简短答案 当流量低、波动大、变化快，或依赖 frontier reasoning 时，通常用 API。当你有高而稳定的负载、一个能通过 eval 的模型、能运维该栈的团队，并且有严格欧盟数据驻留要求或昂贵 API baseline 时，本地模型才值得认真计算。欧盟区域 API 和托管 open-weight endpoint 通常是完全自托管前的中间答案。 场景通常胜出原因 每月几千个任务的内部助手APIGPU 空闲和运维成本会吞掉 token 省下的钱。 夜间处理数百万文档的抽取流程本地或 Batch API稳定负载和异步延迟可以填满容量或享受 batch 折扣。 含敏感数据的欧盟监管工作负载欧盟 API、私有部署或本地治理可能压倒纯成本，但托管欧盟选项应先比较。 面向客户且流量尖峰明显的 SaaS 聊天机器人API 或混合弹性、安全更新和峰值处理比 GPU 标价更重要。 高频分类、路由、富集或摘要本地候选较小 open-weight 模型可能通过 eval 并充分利用便宜硬件。 计算器 比较 API 的每成功任务成本和本地的每成功任务成本。不要拿供应商账单和 GPU 账单直接比较。 项目公式说明 API 月成本tasks_per_month * api_cost_per_successful_task使用任务级计算，而不是单次调用估算。 API 任务成本sum(input + cached_input + output + tools + retries + failure_rework)只有真正符合条件的工作才应用 caching 和 batch。 本地月成本gpu_hours + redundancy + storage + networking + observability + engineering_ops + eval_upkeep不要把人力成本藏在表外。 本地任务成本self_host_monthly / successful_tasks_per_month + variable_task_cost用通过的任务做分母，不是 request。 盈亏平衡任务数self_host_fixed_monthly / (api_task_cost - self_host_variable_task_cost)如果分母很小或为负，API 胜出。 本地每 1M token 有效成本 = ((gpu_hourly_rate + infra_hourly + ops_hourly) / (tokens_per_second * 3600 * measured_utilization)) * 1,000,000。 实际利用率是陷阱。如果表格假设 80%，而生产只有 12%，在冗余、值班和 eval 维护之前，成本已经大约错了 6.7 倍。 计算本地候选模型的成本前，先确认它能在目标机器上按计划上下文和量化版本运行。我们的 llmfit 本地 LLM 硬件适配指南说明如何生成候选清单，以及为什么速度估算仍需要真实基准测试。如果候选模型是 DeepSeek V4 Flash 0731，我们的单台 AI PC 部署评测说明 128 GB 与 192 GB 的哪些假设应进入计算。 先收集哪些输入 输入测量内容为什么会改变决策 任务量每天和每月成功业务任务数低量让本地固定成本很痛。 每任务 token未缓存输入、缓存输入、输出、工具调用、验证调用输出重的任务会抬高 API 成本；稳定输入让缓存更有价值。 并发每秒请求、p95 延迟、飞行中请求并发决定 GPU 饱和和排队行为。 可 batch 比例可以等待几分钟或几小时的比例Batch API 可能先把成本降下来。 模型通过率本地候选模型相对 API baseline 的 eval便宜但失败的模型只是把成本转移到支持团队。 运维能力Serving、安全、监控、更新和事故处理时间本地系统有工资成本。 数据约束GDPR、合同、数据驻留、审计治理可能要求本地，即使 API 更便宜。 为什么利用率比 GPU 价格重要 GPU 报价很直观，利用率却来自你的流量形态。交互式助手可能长时间空闲并突然冲高。夜间抽取任务可以用受控队列深度连续运行数小时。后者可能让本地模型合理；前者通常不会。 Serving 栈同样重要。vLLM 与 HuggingFace TGI 的研究发现，高并发工作负载下 vLLM 吞吐最高可达 TGI 的 24 倍，而 TGI 在中等并发的交互场景中尾延迟更低。这并不表示 vLLM 永远胜出，而是说明你的计算器需要针对具体模型、量化、上下文长度和延迟目标做 benchmark。 不要和错误的 API 比较 本地模型不需要击败价格表里最贵的 frontier 模型，除非你的任务真的需要它。它需要击败经过缓存、batch、路由和模型 right-sizing 之后仍能接受的最便宜托管路径。 OpenAI pricing 区分输入、缓存输入和输出，因此稳定 prefix 会显著改变 baseline。 Gemini pricing 在付费层包含 context caching 和 batch pricing，并按层级区分是否用于产品改进。 Amazon Bedrock 表示部分 foundation model 的 batch inference 比 on-demand 低 50%。 Azure OpenAI 对欧盟企业很重要，因为 data zone、provisioned throughput、预留和采购流程都可能和 token 价格同等重要。 优化顺序见 2026 年如何降低 LLM token 成本。模型选择见 open-weight LLM 对比。 示例计算 假设一家欧盟 SaaS 公司运行文档富集流水线。当前 API 路径在缓存、batch、重试和验证调用之后，每个成功文档成本为 0.018 美元。本地候选模型通过同一 eval。本地栈每月总成本 9,800 美元，包括 GPU、热备容量、存储、日志、监控、网络、工程时间和 eval 维护。每个文档的本地可变成本为 0.003 美元。 指标数值解释 API 任务成本$0.018每个成功文档的实测成本。 本地可变成本$0.003本地栈存在后的每文档额外成本。 本地月固定成本$9,800基础设施加人力和 eval 维护。 每任务节省$0.015API 任务成本减去本地可变成本。 盈亏平衡每月 653,334 个成功文档9,800 / 0.015，尚未加入风险缓冲。 需要加入风险缓冲。如果 eval 通过率下降、实际利用率低于 benchmark、failover 需要第二块热备 GPU，或需求有季节性，盈亏平衡点会右移。如果负载异步且能夜间填满 GPU，盈亏平衡点会左移。 欧盟因素 对欧盟企业来说，本地还是 API 很少只是价格问题。GDPR、DPA、客户采购、行业规则和可审计性都可能决定架构。但治理并不自动等于自托管。 需求API 路径本地路径 欧盟数据驻留在合同和风险允许时使用欧盟区域或 data zone。在欧盟云或自有基础设施上推理，并控制日志和存储。 Prompt 不用于训练按产品和层级核对 enterprise/API 条款。Prompt、输出、日志和 embedding 留在你的环境。 客户审计记录子处理方、保留策略、访问控制和供应商条款。记录 GPU 供应商、镜像来源、模型许可证、serving 日志和访问控制。 敏感行业数据考虑 private endpoint、脱敏或带 policy 的 gateway。如果原始数据不能离开 tenant 边界，优先本地。 更多背景见 AI 应用的欧盟数据驻留 和 在欧盟自托管 LLM 的真实成本。 如果目标模型超过每一台单机，请看我们的 Mesh LLM 多机分布式推理评测，其中单独分析了组合内存带来的网络与可靠性成本。 你真正付费的本地栈 这个栈不是“模型加 GPU”。生产部署通常包括 vLLM 这样的 serving runtime、模型 artifact 管理、量化决策、autoscaling 或队列控制、遥测、日志策略、访问控制、eval job、发布门禁、事故响应，以及本地模型失败或 GPU 池满载时的 fallback 路由。 更务实的架构往往是混合：本地处理便宜、稳定、高频工作；API 处理困难任务、overflow、多模态、工具重的推理，或 frontier 质量仍然胜出的场景。这时计算器会变成路由计算器：本地默认、API fallback、实测升级率，以及证明低价路径仍合格的 eval。 来源和价格提醒 供应商价格和模型名称变化很快。公式是稳定的，示例价格机制是 2026 年 7 月快照。预算前请重新检查 OpenAI pricing、Gemini API pricing、Amazon Bedrock pricing 和 Azure OpenAI pricing。利用率和 serving 假设见 Beyond Per-Token Pricing 与 vLLM vs TGI 研究。 拿你自己的真实负载去跑这套对比，然后把胜出的那一侧真正建出来，就是我们的 AI 落地服务。如果一开始把自托", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-08", "datePublished": "2026-07-08", "description": "本地 LLM 只有在完整等式胜出时才会超过 API，而不是 GPU 小时看起来便宜时。API 成本应按每个成功任务计算；自托管成本应把 GPU 小时、冗余、存储、网络、可观测性、工程运维、eval 维护和空闲容量相加，再除以成功任务数。利用率研究显示，同一块 H100 因并发和负载不同，每百万输出 token 可以从很便宜变成非常昂贵，所以利用率是第一变量。托管 API 适合低量、波动或快速变化的工作；本地适合高而稳定的量、严格欧盟数据驻留，或在 open-weight 模型通过 eval 后替代昂贵 frontier API。计算器需要 token 量、每任务 token、并发、利用率、延迟 SLO、工程成本、eval 通过率和 API 替代方案。不要在测量 caching、batching、routing 和模型 right-sizing 之前自托管。数字是 2026 年 7 月快照；预算前请重新检查实时供应商价格。", "headline": "本地模型什么时候胜过 API：欧盟企业盈亏平衡计算器", "image": "https://wavect.io/img/blog/headers/header_local-models-vs-apis-break-even-eu-2026.svg", "inLanguage": "zh", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/local-models-vs-apis-break-even-eu-2026/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/local-models-vs-apis-break-even-eu-2026/", "wordCount": 573 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/models-infrastructure/", "name": "模型与基础设施", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/local-models-vs-apis-break-even-eu-2026/", "name": "本地模型 vs API：欧盟企业盈亏平衡计算器 | ", "position": 5 } ] } ```