<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Self-Hosting on Svtter's Blog</title><link>https://svtter.cn/tags/self-hosting/</link><description>Recent content in Self-Hosting on Svtter's Blog</description><generator>Hugo -- gohugo.io</generator><language>zh-cn</language><lastBuildDate>Thu, 19 Mar 2026 12:30:00 +0800</lastBuildDate><atom:link href="https://svtter.cn/tags/self-hosting/index.xml" rel="self" type="application/rss+xml"/><item><title>自己部署大模型，真的就能肆无忌惮地用吗？</title><link>https://svtter.cn/p/%E8%87%AA%E5%B7%B1%E9%83%A8%E7%BD%B2%E5%A4%A7%E6%A8%A1%E5%9E%8B%E7%9C%9F%E7%9A%84%E5%B0%B1%E8%83%BD%E8%82%86%E6%97%A0%E5%BF%8C%E6%83%AE%E5%9C%B0%E7%94%A8%E5%90%97/</link><pubDate>Thu, 19 Mar 2026 12:30:00 +0800</pubDate><guid>https://svtter.cn/p/%E8%87%AA%E5%B7%B1%E9%83%A8%E7%BD%B2%E5%A4%A7%E6%A8%A1%E5%9E%8B%E7%9C%9F%E7%9A%84%E5%B0%B1%E8%83%BD%E8%82%86%E6%97%A0%E5%BF%8C%E6%83%AE%E5%9C%B0%E7%94%A8%E5%90%97/</guid><description>&lt;img src="https://svtter.cn/p/%E8%87%AA%E5%B7%B1%E9%83%A8%E7%BD%B2%E5%A4%A7%E6%A8%A1%E5%9E%8B%E7%9C%9F%E7%9A%84%E5%B0%B1%E8%83%BD%E8%82%86%E6%97%A0%E5%BF%8C%E6%83%AE%E5%9C%B0%E7%94%A8%E5%90%97/cover.jpg" alt="Featured image of post 自己部署大模型，真的就能肆无忌惮地用吗？" /&gt;&lt;p&gt;很多人第一次认真考虑自建大模型，不是因为技术浪漫，而是因为 API 账单、限流，或者数据合规要求已经开始逼近业务现实。&lt;/p&gt;
&lt;p&gt;于是，一个很自然的问题就出现了：如果模型已经跑在自己机器上，是不是以后就能“肆无忌惮”地用了？&lt;/p&gt;
&lt;p&gt;我的判断是：&lt;strong&gt;不能。&lt;/strong&gt; 自己部署模型，并不等于无限自由，它只是把很多原本由平台承担的限制和成本，转移到了你自己身上。&lt;/p&gt;
&lt;p&gt;但这个问题还有后半句，而且更重要：如果使用量足够大，自建到底会不会更划算？&lt;/p&gt;
&lt;p&gt;答案是：&lt;strong&gt;有可能，但前提比很多人想的要苛刻。&lt;/strong&gt;&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;简单说：自己部署大模型，不等于无限自由。&lt;/p&gt;
&lt;p&gt;它只是把原本由平台承担的一部分成本和责任，转移到了你自己身上。只有在长期高负载、硬件利用率高、并且你能接受模型能力差异或有能力自己优化时，自建才可能真正划算。&lt;/p&gt;&lt;/blockquote&gt;
&lt;h2 id="本地部署不等于无限制"&gt;本地部署，不等于无限制
&lt;/h2&gt;&lt;p&gt;先把最容易出现的误解说清楚。&lt;/p&gt;
&lt;p&gt;很多人把“模型跑在自己机器上”理解成“以后想怎么用就怎么用”，但限制并不会消失，它们只是换了一种形式出现。&lt;/p&gt;
&lt;h3 id="第一层限制硬件"&gt;第一层限制：硬件
&lt;/h3&gt;&lt;p&gt;模型参数规模、显存容量、量化精度、KV cache、并发数，这些都是真正的物理约束。一个 70B 级模型即便做了量化，也依然会对显存和带宽提出很高要求。能跑，不代表跑得舒服；能输出，不代表延迟和吞吐能接受。&lt;/p&gt;
&lt;h3 id="第二层限制模型能力本身"&gt;第二层限制：模型能力本身
&lt;/h3&gt;&lt;p&gt;幻觉、知识截止、长上下文退化、复杂推理不稳定，这些问题不会因为你把模型搬到本地就自动消失。部署位置改变不了模型上限。更现实的一点是：大多数人所谓的“自建”，通常部署的是开源权重模型，而不是 Claude 或 GPT 这类闭源模型本体。&lt;/p&gt;
&lt;h3 id="第三层限制责任转移"&gt;第三层限制：责任转移
&lt;/h3&gt;&lt;p&gt;用 API 的时候，内容安全、服务稳定性、限流和大部分基础设施问题，平台已经帮你扛了一部分。自己部署之后，这些事情不会消失，只会变成你的运维、监控、审核和应急预案。&lt;/p&gt;
&lt;p&gt;所以，&lt;strong&gt;自建不是“肆无忌惮”，而是“边界自己扛”。&lt;/strong&gt;&lt;/p&gt;
&lt;h2 id="真正该算的不是一张显卡多少钱"&gt;真正该算的，不是一张显卡多少钱
&lt;/h2&gt;&lt;p&gt;如果我们要判断自建是否划算，真正该比较的不是“买卡贵不贵”，而是下面两笔总账。&lt;/p&gt;
&lt;p&gt;自建的年成本，大致可以写成：&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;div class="chroma"&gt;
&lt;table class="lntable"&gt;&lt;tr&gt;&lt;td class="lntd"&gt;
&lt;pre tabindex="0" class="chroma"&gt;&lt;code&gt;&lt;span class="lnt"&gt;1
&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/td&gt;
&lt;td class="lntd"&gt;
&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-text" data-lang="text"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;自建年成本 = 硬件折旧 + 电费 + 网络/机房 + 运维人力 + 故障冗余
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;
&lt;/div&gt;
&lt;/div&gt;&lt;p&gt;API 的年成本则更直接：&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;div class="chroma"&gt;
&lt;table class="lntable"&gt;&lt;tr&gt;&lt;td class="lntd"&gt;
&lt;pre tabindex="0" class="chroma"&gt;&lt;code&gt;&lt;span class="lnt"&gt;1
&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/td&gt;
&lt;td class="lntd"&gt;
&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-text" data-lang="text"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;API 年成本 = 日均 token 消耗 * 每百万 token 单价 * 365
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/td&gt;&lt;/tr&gt;&lt;/table&gt;
&lt;/div&gt;
&lt;/div&gt;&lt;p&gt;看起来很简单，但这里有三个特别容易被忽略的点。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;自建不是只花一次硬件钱。&lt;/strong&gt; 电费、备件、机房环境、监控告警、升级维护，这些都会持续发生。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;API 价格不是一个固定数字。&lt;/strong&gt; 不同模型、输入输出比例、缓存命中、是否带工具调用，都会明显改变最后的账单。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;利用率经常被低估。&lt;/strong&gt; 如果你的机器大部分时间都在空转，那么再便宜的单次推理成本也没有意义；反过来，如果业务负载足够稳定，硬件被长期打满，自建的财务优势才会真正体现出来。&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;所以，下面的数字只能当作一个粗略量级判断，而不是采购报价单。&lt;/p&gt;
&lt;h2 id="一个粗略但有用的盈亏平衡表"&gt;一个粗略但有用的盈亏平衡表
&lt;/h2&gt;&lt;p&gt;为了方便讨论，我先做一个非常粗糙的假设：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;API 成本按每百万 token 约 50 元人民币估算&lt;/li&gt;
&lt;li&gt;token 口径按输入和输出合计计算&lt;/li&gt;
&lt;li&gt;自建硬件按 3 年折旧计算&lt;/li&gt;
&lt;li&gt;自建成本里计入基础运维和电力开销&lt;/li&gt;
&lt;li&gt;本地方案默认以开源模型推理为主，不追求与闭源旗舰严格等效&lt;/li&gt;
&lt;li&gt;不计模型训练、微调和专职平台团队的人力成本&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;在这个假设下，大致会得到下面这样的量级判断：&lt;/p&gt;
&lt;table&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th style="text-align: left"&gt;使用场景&lt;/th&gt;
&lt;th style="text-align: left"&gt;日均 token 消耗&lt;/th&gt;
&lt;th style="text-align: left"&gt;可能的本地方案&lt;/th&gt;
&lt;th style="text-align: left"&gt;自建年成本&lt;/th&gt;
&lt;th style="text-align: left"&gt;API 年成本&lt;/th&gt;
&lt;th style="text-align: left"&gt;粗略结论&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td style="text-align: left"&gt;轻度使用&lt;/td&gt;
&lt;td style="text-align: left"&gt;50 万&lt;/td&gt;
&lt;td style="text-align: left"&gt;单卡高端消费级工作站&lt;/td&gt;
&lt;td style="text-align: left"&gt;2 万 - 4 万元&lt;/td&gt;
&lt;td style="text-align: left"&gt;约 0.9 万元&lt;/td&gt;
&lt;td style="text-align: left"&gt;API 更省钱&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style="text-align: left"&gt;中度使用&lt;/td&gt;
&lt;td style="text-align: left"&gt;500 万&lt;/td&gt;
&lt;td style="text-align: left"&gt;双卡或小型推理工作站&lt;/td&gt;
&lt;td style="text-align: left"&gt;6 万 - 12 万元&lt;/td&gt;
&lt;td style="text-align: left"&gt;约 9 万元&lt;/td&gt;
&lt;td style="text-align: left"&gt;接近平衡点&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td style="text-align: left"&gt;重度使用&lt;/td&gt;
&lt;td style="text-align: left"&gt;5000 万&lt;/td&gt;
&lt;td style="text-align: left"&gt;多卡服务器或集群&lt;/td&gt;
&lt;td style="text-align: left"&gt;40 万 - 80 万元&lt;/td&gt;
&lt;td style="text-align: left"&gt;约 91 万元&lt;/td&gt;
&lt;td style="text-align: left"&gt;自建可能更划算&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;&lt;img src="https://svtter.cn/p/%E8%87%AA%E5%B7%B1%E9%83%A8%E7%BD%B2%E5%A4%A7%E6%A8%A1%E5%9E%8B%E7%9C%9F%E7%9A%84%E5%B0%B1%E8%83%BD%E8%82%86%E6%97%A0%E5%BF%8C%E6%83%AE%E5%9C%B0%E7%94%A8%E5%90%97/pics/inline-01.jpg"
width="4800"
height="3584"
srcset="https://svtter.cn/p/%E8%87%AA%E5%B7%B1%E9%83%A8%E7%BD%B2%E5%A4%A7%E6%A8%A1%E5%9E%8B%E7%9C%9F%E7%9A%84%E5%B0%B1%E8%83%BD%E8%82%86%E6%97%A0%E5%BF%8C%E6%83%AE%E5%9C%B0%E7%94%A8%E5%90%97/pics/inline-01_hu_e538165957f7c9a8.jpg 480w, https://svtter.cn/p/%E8%87%AA%E5%B7%B1%E9%83%A8%E7%BD%B2%E5%A4%A7%E6%A8%A1%E5%9E%8B%E7%9C%9F%E7%9A%84%E5%B0%B1%E8%83%BD%E8%82%86%E6%97%A0%E5%BF%8C%E6%83%AE%E5%9C%B0%E7%94%A8%E5%90%97/pics/inline-01_hu_c17af6e4e0b01ddc.jpg 1024w"
loading="lazy"
alt="从轻度到重度使用场景中，API 成本与本地硬件投入逐渐发生变化的示意图"
class="gallery-image"
data-flex-grow="133"
data-flex-basis="321px"
&gt;&lt;/p&gt;
&lt;p&gt;如果你希望本地效果尽量逼近顶级闭源模型，那么这张表往往还会继续上修，因为更强的模型、更大的显存、更高的可用性目标，都会把硬件和运维成本继续往上推。&lt;/p&gt;
&lt;p&gt;这张表大概能说明三件事：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;个人和小团队通常很难靠自建省钱。&lt;/strong&gt; 如果你的调用量只有几十万 token/天，API 通常依然是更经济的选择。你少花了硬件钱，也少背了运维负担。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;真正接近平衡点的，往往是“稳定高用量”场景。&lt;/strong&gt; 不是偶尔一天冲到很高，而是每天都很高，而且业务负载相对稳定。只有利用率足够高，硬件成本才摊得下来。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;用量越大，自建的财务吸引力才越明显。&lt;/strong&gt; 这也是为什么大型公司会认真建设自己的推理平台：不是因为他们喜欢折腾，而是因为当规模上来之后，这笔账真的会反过来。&lt;/li&gt;
&lt;/ol&gt;
&lt;h2 id="但这里有一个很关键的前提你不一定在比较同一个东西"&gt;但这里有一个很关键的前提：你不一定在比较同一个东西
&lt;/h2&gt;&lt;p&gt;很多“自建比 API 便宜”的讨论，最大的问题不是数学，而是比较对象不一致。&lt;/p&gt;
&lt;p&gt;你在 API 侧，可能买的是当前最强的一线闭源模型；你在本地侧，跑的却是一个量化后的开源模型。两者当然都叫“大模型”，但它们并不是严格等价的商品。&lt;/p&gt;
&lt;p&gt;这意味着，至少有三件事要先说清楚：&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;如果你能接受开源模型的效果，自建的确有机会省很多钱。&lt;/li&gt;
&lt;li&gt;如果你的业务质量门槛很高，必须依赖顶级闭源模型，自建空间就会小很多。&lt;/li&gt;
&lt;li&gt;如果你只是把“更便宜的模型”拿来和“更贵的模型”比，那得到的不是部署结论，而是模型选择结论。&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;换句话说，&lt;strong&gt;很多人以为自己在算部署成本，其实先做的是能力降级。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;这件事本身没有问题，但要承认它。&lt;/p&gt;
&lt;p&gt;&lt;img src="https://svtter.cn/p/%E8%87%AA%E5%B7%B1%E9%83%A8%E7%BD%B2%E5%A4%A7%E6%A8%A1%E5%9E%8B%E7%9C%9F%E7%9A%84%E5%B0%B1%E8%83%BD%E8%82%86%E6%97%A0%E5%BF%8C%E6%83%AE%E5%9C%B0%E7%94%A8%E5%90%97/pics/inline-02.jpg"
width="4800"
height="3584"
srcset="https://svtter.cn/p/%E8%87%AA%E5%B7%B1%E9%83%A8%E7%BD%B2%E5%A4%A7%E6%A8%A1%E5%9E%8B%E7%9C%9F%E7%9A%84%E5%B0%B1%E8%83%BD%E8%82%86%E6%97%A0%E5%BF%8C%E6%83%AE%E5%9C%B0%E7%94%A8%E5%90%97/pics/inline-02_hu_3afbc14068dd055d.jpg 480w, https://svtter.cn/p/%E8%87%AA%E5%B7%B1%E9%83%A8%E7%BD%B2%E5%A4%A7%E6%A8%A1%E5%9E%8B%E7%9C%9F%E7%9A%84%E5%B0%B1%E8%83%BD%E8%82%86%E6%97%A0%E5%BF%8C%E6%83%AE%E5%9C%B0%E7%94%A8%E5%90%97/pics/inline-02_hu_7f9cead440467875.jpg 1024w"
loading="lazy"
alt="闭源云模型与本地开源模型在能力、成本和运维负担上并不完全等价的示意图"
class="gallery-image"
data-flex-grow="133"
data-flex-basis="321px"
&gt;&lt;/p&gt;
&lt;h2 id="除了省钱自建还有哪些真正的收益"&gt;除了省钱，自建还有哪些真正的收益
&lt;/h2&gt;&lt;p&gt;如果一家公司最后还是决定自建，通常不只是为了省 API 钱。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;数据主权&lt;/strong&gt;：某些业务天然不愿意把原始数据长期交给第三方服务商，这时本地部署会让合规和审计路径更清晰。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;可定制性&lt;/strong&gt;：你可以围绕自己的任务去做量化、路由、蒸馏、微调，甚至把推理链条和业务系统绑得更紧。这些事情在通用 API 上往往不够自由。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;成本上限更可控&lt;/strong&gt;：API 模式是典型的按量付费，业务一涨，账单也跟着涨。自建虽然前期投入大，但在高负载、稳定负载下，成本曲线通常更可预测。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;离线与可用性&lt;/strong&gt;：如果你的场景要求内网运行，或者无法接受关键流程完全依赖外部服务，那么本地部署会更符合工程要求。&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="一个更实用的判断方法"&gt;一个更实用的判断方法
&lt;/h2&gt;&lt;p&gt;如果你不想一上来就算太细，可以先用下面三个问题做快速筛选。&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;你的负载是不是长期稳定地高？&lt;/strong&gt; 如果只是偶尔出现一波高峰，而不是每天稳定消耗大量 token，那么 API 往往更划算，因为你不需要为闲置硬件买单。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;你能不能接受本地模型和闭源旗舰之间的差距？&lt;/strong&gt; 如果你的业务必须依赖最强模型效果，那么很多所谓的自建节省，其实是靠降低模型能力换来的，不是纯粹的部署优化。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;你有没有能力长期维护推理服务？&lt;/strong&gt; 显卡坏了怎么办，驱动冲突怎么办，服务抖动怎么办，模型版本怎么升级，监控和限流谁来做？这些问题如果没人接，就不是成本问题，而是交付问题。&lt;/li&gt;
&lt;/ol&gt;
&lt;h2 id="我的结论"&gt;我的结论
&lt;/h2&gt;&lt;p&gt;回到开头那个问题：自己部署大模型，真的就能“肆无忌惮”地用吗？&lt;/p&gt;
&lt;p&gt;我的答案是：&lt;strong&gt;不能。&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;它不会消灭硬件瓶颈，不会抹平模型能力差距，也不会替你自动解决审核、稳定性和运维问题。它带来的不是绝对自由，而是更高的控制权，以及与之对应的责任。&lt;/p&gt;
&lt;p&gt;但另一方面，&lt;strong&gt;自建也绝不是伪命题。&lt;/strong&gt; 当你满足下面几个条件时，它就会越来越合理：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;业务 token 消耗长期处在高位&lt;/li&gt;
&lt;li&gt;负载稳定，硬件利用率高&lt;/li&gt;
&lt;li&gt;能接受开源模型，或已经有能力做定制优化&lt;/li&gt;
&lt;li&gt;对数据主权、内网部署或成本上限有明确要求&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;换句话说，自建更像是一种工程与财务上的取舍，而不是一张“无限使用”的门票。&lt;/p&gt;
&lt;p&gt;如果你是个人用户、小团队，或者只是偶尔重度使用，API 往往还是更现实的解法：省心、省事、试错成本也低。&lt;/p&gt;
&lt;p&gt;如果你已经进入“每天都在稳定烧 token”的阶段，那就别再只盯着 API 单价了，认真把整笔账算一遍。很多时候，答案不会是“肆无忌惮”，而是一个更朴素也更重要的判断：&lt;strong&gt;这件事到底值不值得自己养。&lt;/strong&gt;&lt;/p&gt;</description></item></channel></rss>