1. 开源与闭源的分水岭：不止是"要不要掏钱"这么简单
这两年每隔几天就会有人拿着同一个问题来找我——开源大模型和闭源大模型到底怎么选。我自己从2023年初开始做LLM应用落地，先是用闭源API一路梭哈，后来又把几个核心服务迁到了自部署的开源模型上，中间踩过的坑、算过的账、推翻过好几次的结论，加起来能写小半本流水账。这篇文章不打算写那种"各有优劣，视情况而定"的正确废话，而是把我在真实项目里的选型逻辑、成本测算、踩坑经历和最终落地架构摊开讲，希望能帮还在纠结的人少走点弯路。
先说清一个前提：这里说的开源大模型，指的是权重公开、可以自部署、可以微调的那一类，代表选手有 Llama 系列、Qwen（通义千问的开源版本）、DeepSeek、GLM、Mistral 等；闭源大模型则是以 API 方式提供的 GPT-4o、Claude、Gemini 这类服务，你只能调用，拿不到权重，也管不了它内部怎么跑。这个区别听起来不过是"本地跑还是云端调"，但实际牵扯到成本结构、数据边界、团队能力、长期演进路径，每一项都可能决定一个项目的生死。
1.1 先给两者定个性
我把两者的本质差异压缩成一句话：开源模型给你的是"控制权"，闭源模型给你的是"省心"。这不是抽象说法，而是非常具体的权衡。
选开源，意味着你拥有模型本身。权重在你手里，部署在哪里、数据往哪里走、什么时候升级、要不要微调、按什么样的吞吐量做优化，全部自己说了算。代价是这些决策的后果也全部自己扛：显存规划错了要自己排查，推理框架崩了要自己修，模型效果不达标也只能自己一点点调。
选闭源，意味着你买的是一个"承诺的服务"。厂商负责把模型训好、把服务稳定性兜住、持续发布新版本，你只需要调用接口。但你也因此把一些东西交了出去：数据要经过别人的服务、延迟和限流不完全由你控制、模型行为说变就变（有时是变好，有时只是变了，但你的业务逻辑可能因此出现连锁反应）。
这两种路线没有优劣，只有适不适合。关键是要搞清楚自己的项目到底处于什么约束条件下。
1.2 开源不等于免费：那些容易漏算的隐性成本
很多团队一开始被开源吸引，是因为"免费"两个字。但开源模型真正的代价不在授权费，而在别处。
首先是算力成本。一个 7B 模型用 FP16 推理，光权重就要占 14GB 显存，再加上 KV Cache 和中间激活，一张 24GB 的消费级卡勉强能跑，但并发一上来就捉襟见肘。真要支撑线上流量，通常需要 A100/A800 这类数据中心级显卡，云端租用一小时几十块到上百块，自购则是一台上百万的投入。这项成本在你打开下载链接的那一刻就已经开始了。
其次是工程成本。部署一个能稳定服务线上流量的模型，不是"下载权重、起个服务"那么简单。你要处理并发调度、显存管理、量化取舍、热更新、监控告警、模型版本管理……每一项都需要有经验的工程师投入时间。我见过好几个团队模型下下来了，但没人搞得定 vLLM 的参数调优，卡在这里一两个月，最后还是回去用 API。这笔时间成本，比 GPU 账单更贵。
第三是演进成本。开源社区迭代极快，今天你部署好的 Qwen 2.5，明年可能就被 3.0 全面超越；DeepSeek 从一个版本跳到另一个版本时，效果提升非常明显。这意味着你必须持续跟进新版本、重新评测、重新部署。如果你没有一套高效的评测和发布流程，每次升级都是一次伤筋动骨。
1.3 闭源也不等于省心：你买到的"稳定"是有边界的
闭源 API 看起来是"交钱就行"，但真正用起来，你会发现"稳定"这件事并不是绝对的。
最常被忽视的是模型版本漂移。厂商不会通知你"我这周四要改模型行为"，但同一个 API 背后的模型可能已经悄悄换了好几个版本。你今天精心调好的提示词，下周效果可能就变了。我做过一个抽取类任务，只用了一次小版本升级，输出格式的失败率就从 3% 涨到了 15%，排查了大半天才发现是模型行为变了，而我们的代码一行都没改。
还有限流和延迟。闭源 API 在高峰期出现 p99 延迟飙高是常态，你要是对时延敏感（比如客服机器人要求 1 秒内响应），就得自己加缓存、加超时重试、做降级方案。这些工程复杂度，跟自部署比起来并没有少多少。
更核心的是数据边界。数据一旦发给 API 服务，无论厂商承诺"不留存"还是"不用于训练"，在合规层面你都要承担额外举证责任。对很多企业来说，这笔信任成本和法务成本，可能比模型调用费本身高得多。
2. 选型前先算清四笔账：成本、数据、能力、团队
我自己的经验是，选型讨论如果停留在"开源好还是闭源好"的层面，永远争论不出结果。真正有效的做法，是把它拆成四笔独立的账，一笔一笔算清楚。算完这四笔账，大概率你已经有了答案。
2.1 成本账：别只看单价，要看全生命周期
先说 API 调用的直接成本。以我近期拿到的公开报价为数量级参考：GPT-4o 一类的主流闭源模型，输入约 2.5 美元/百万 token，输出约 10 美元/百万 token；Claude 系列略贵一些；国内厂商的闭源 API（比如通义千问的 Max 版本、豆包大模型）价格要低一截，输出大概在 2~4 美元/百万 token 的量级。这里不展开精确比价，因为价格战让这些数字三个月就变一次，但数量级你可以有个概念。
然后看自部署的成本。一台 8 卡 A100/A800 的服务器，云端月租金通常在数万元人民币的量级，一次性采购则是几十万到上百万。一个 7B 模型在量化后大概用 1~2 张卡就能服务中小流量；14B 大概需要 2~4 张卡；70B 级别的模型基本就得整台 8 卡服务器伺候。
我做一个粗算例子：一个聊天机器人业务，日均处理 2000 万 token（输入输出合计），月均 6 亿 token。用闭源 API，按混合价 5 美元/百万 token 算，月度成本约 3000 美元，折合人民币两万多。这个数字看起来还好，但注意它是线性增长的——流量翻十倍，账单就翻十倍。自部署的话，一台能扛住这个量级的 8 卡服务器，月成本也是两万多到三万，但它扛不住再翻十倍的流量吗？未必，可能要加卡，但加的幅度远小于 API 账单的涨幅（吞吐优化空间很大，量化和批处理能把有效吞吐拉高好几倍）。
所以我的经验法则是：月调用量在千万级 token 以下、流量还不稳定时，API 几乎总是更划算，因为你不用为了尖峰流量预留算力；当业务稳定跑在亿级 token 量级，自部署的性价比就开始显现；到了十亿级，几乎没有第二种选择。当然，前提是你有能把它按住的工程团队。
2.2 数据账：有些行业的答案在一开始就写死了
四笔账里，数据账往往是决定性的，因为它不是钱的问题，而是"能不能"的问题。
我接触过的项目里，医疗数据、法律数据、企业内部财务和人事数据、未公开的研发资料，这些场景几乎从一开始就排除了闭源 API。不是你信不信任厂商的问题，而是合规要求根本不允许数据离开内部网络。哪怕厂商提供"零留存"选项，很多行业客户依然不接受——因为一旦走了外部服务，举证责任就落到了你头上，出任何问题都是你的锅。
这里有个很现实的细节：就算你自己不敏感，你的客户会敏感。我们接过一个服务制造业客户的单子，对方的信息安全团队直接出具了一份清单，列明了哪些数据类别不得传往外部模型服务。这份清单一出，技术选型就不用讨论了，直接往开源自部署方向走。
反过来，如果你的业务数据本身就不敏感（比如处理公开商品信息、生成营销文案），那数据账就不是选闭源的障碍，你可以更从容地按成本账和能力账来做决定。
2.3 能力账：公开榜单的数据跟你业务那点数据根本不是一回事
说到能力对比，2023 年那会儿是真没悬念，闭源把开源甩开一大截。但到了 2024 年下半年，开源模型的进步速度远超大多数人预期。Qwen 系列、DeepSeek-V3、Llama 3.1 这些模型在不少公开评测里跟闭源旗舰已经互有胜负，尤其在中文场景下，国内开源模型的表现经常比同尺寸的海外闭源模型更贴合本地需求。
但我要提醒一句：公开榜单的分数，跟你的业务效果之间，隔着十万八千里。榜单测的是通用任务，你的业务往往是某个非常窄的场景。我见过一个团队兴冲冲地按照榜单选了"最强"模型，上线后发现在他们的客服意图识别场景里，效果还不如一个参数小一倍的模型。
正确做法是建一个属于你自己的评测集，挑 200~500 条真实业务请求（输入、期望输出、判定标准），把候选模型全部跑一遍。这个评测集不用很复杂，但必须是你自己的数据。我每次做选型都先干这件事，成本很低，但能帮你避开大量"榜单幻觉"。
还有一点容易被忽略：能力差距在"中间态"最明显。简单任务（比如信息抽取、关键词分类），开源小模型已经做得不错；顶尖任务（复杂推理、长文档理解、多步工具调用），闭源旗舰仍然有明显优势。最尴尬的是中间地带——你以为开源模型能搞定，结果它给出一个"看起来合理但细节全错"的答案。这种错误比直接答不出来更麻烦，因为它不容易被用户察觉，却会在后台积累成事故。
2.4 团队账：没那个运维能力，开源就是定时炸弹
最后一笔账最现实：你有没有人能把这个模型管起来。
自部署不是"跑起来就行"，而是一个持续的运营工作。模型出显存溢出（OOM）了谁会排查？推理服务被突发流量打挂了谁会做扩容？新模型版本发布了，谁负责评估升级？如果答案都是"没有这样的人"，那开源模型的隐性成本会无限膨胀。
我见过最典型的反面案例：一个十来人的创业团队，CTO 很懂算法，但公司没有专职的运维和基础设施工程师，他们硬是选了自部署路线。结果两周后模型服务挂了三次，每次都是 CTO 自己半夜爬起来重启容器。表面上看省了 API 费用，实际上把团队最稀缺的人的时间全搭进去了。
反过来，如果你的团队里有能搞定推理框架的人，哪怕只有一个，自部署的可行性就会高很多。这不是在贬低闭源、抬高开源——而是提醒你，团队账要在选型一开始就摆上桌面，而不是等项目黄了才意识到。
3. 真实场景选型复盘：五个项目，五套解法
讲了这么多原则，我挑几个自己做过的项目复盘一下。你会发现每个场景的答案都不一样，但决策逻辑是同一套：先看数据边界，再看团队能力，最后算成本和效果。
3.1 场景一：to C 产品的闲聊陪伴
这是一个面向 C 端的陪伴类应用，日活 8 万左右，用户人均每天跟"AI 朋友"聊几十轮。一开始用的是闭源旗舰 API，效果确实好，用户反馈很正面。但快速增长期一到，账单先撑不住了——这产品的 token 消耗量级是千万到亿级每天，闭源 API 的成本直接吃掉了一大块毛利。
我们的解法是分层：大多数日常闲聊走自部署的开源 7B 模型（量化到 4-bit，用单张 A100 就能扛住），只有遇到情感支持、复杂话题这类高难度场景，才把请求升级到闭源旗舰。迁移后成本直接降了六成以上，整体用户体验下降幅度非常小——因为闲聊场景对"答得漂亮"的敏感度远低于对"响应快、不离谱"的敏感度。
事后复盘，这个场景下开源模型能胜出的核心原因是：闲聊任务的容错度很高，用户要的更多是"有人陪"的即时感，而不是每句话都惊艳。
3.2 场景二：企业内部知识库问答（RAG）
这是一个典型的企业知识库问答项目，客户要求所有数据不得离开内部网络。数据都进内部库了，模型当然也必须内部部署，所以第一轮选型就直接排除了闭源 API，只能从开源模型里挑。
实际跑下来发现，14B 级别的开源模型配合一套合格的 RAG 架构（好的向量库+重排序模型+提示词模板），在内部知识问答上的表现已经足够好了。很多团队一开始总觉得"必须用最强模型"，但在这个场景里，答案的主要来源是检索回来的文档片段，模型的任务只是忠实归纳。14B 模型完全胜任，32B 是锦上添花，70B 在这个场景属于浪费。
这里最大的教训是：RAG 项目里 80% 的效果问题出在检索环节——切分策略不对、召回文档不相关、重排序没做——而模型本身能发挥的空间只有 20%。别一上来就追大模型，先把检索链路做好，你会发现根本不需要多大的模型。
3.3 场景三：高并发低延迟的在线推理
一个电商客服机器人，业务方要求 p95 响应时间低于 1 秒。我们用闭源 API 跑了一段时间，发现高峰期的延迟波动非常难受，冷启动和限流时不时捣乱，p95 经常冲到 2 秒以上。
后来我们把核心流程迁到了自部署方案：vLLM 做推理框架，开启 continuous batching，7B 模型量化到 8-bit，两张卡做张量并行。调优之后 p95 稳定在 800ms 以内，而且完全由自己控制，不再受厂商挤牙膏式的性能波动影响。
这个场景的关键结论是：如果你对延迟有硬性要求，闭源 API 的"黑盒延迟特征"会是个很难受的心智负担。你既不知道它什么时候会慢，也不知道高峰期会不会突然限流。自部署至少让你有了一个可以调、可以测、可以优化的对象。
3.4 场景四：垂直领域微调
我们接过一个法律文书生成的活儿，需要稳定输出特定格式、特定条款表述的文书。用通用闭源 API 做 few-shot 提示，效果时好时坏，格式漂移问题尤其明显——不是做不到，而是"每次都在不同的地方犯错"。
这种场景基本只能走开源路线，因为微调需要拿到权重。我们收集了三千多对高质量样本（律所人工标注的样本对），在 14B 开源模型上用 LoRA 微调了三个 epoch。效果非常显著：格式合规率从 70% 拉到 98% 以上，而且行为稳定得多，不再需要反复调提示词去"碰运气"。
我的建议是：只有当你的业务有非常固定的输出模式、专业术语体系或行文风格时，才值得考虑微调。而且微调前一定要先试 RAG + 提示工程，把这条最简单的路走到极限再说。90% 的场景下，提示工程就能解决，微调是用来解决剩下那 10% 的。
3.5 场景五：出海产品的多语言与合规
一个出海产品需要覆盖英语、西班牙语、阿拉伯语等多个市场。业务数据涉及用户隐私，欧洲市场的合规要求也很严格。我们的选择是两个方向同时走：标准用户请求用闭源 API（选那些支持数据本地化处理和零留存承诺的厂商），涉及隐私数据的内部分析则用自部署开源模型。
这个场景里，"开源还是闭源"不是二选一，而是按数据处理链路拆开的：出境的、低敏感的走 API，留内部的、高敏感的走本地。数据边界在哪里，模型就部署在哪里。
4. 开源路线实操：从选基座模型到部署调优的关键节点
如果你的四笔账算下来指向了开源路线，接下来就是怎么落地的问题。这里我把从选型到上线过程中最容易出问题的几个节点梳理一遍，全部是我自己踩过或看别人踩过的坑。
4.1 基座模型怎么挑
卡在第一步的人很多，因为可选模型实在太多了。我的建议是先看三个维度：参数规模、许可证、生态成熟度。
参数规模上，按照自己的算力预算倒推。7B/8B 级别的模型适合单卡部署、边缘场景、高并发低复杂度任务；14B 到 32B 是生产环境的主力区间，效果和成本平衡最好；70B 以上留给预算充足、效果要求极高的场景。别小看 7B 的 14B——很多任务上它们已经追上了上一代的大模型。
许可证是很多人忽略的坑。不同开源模型的商用条款差异极大：有的用 Apache 2.0（对商用非常友好，Qwen 系列、Mistral 都在这一档），有的用 MIT（DeepSeek 大部分模型采用，基本无限制），Llama 家族用的是自有许可证，对高月活用户有额外的授权要求，Gemma 也是自有许可证。我的建议是：动手之前把许可证原文逐字读一遍，尤其是"商用限制"和"月活门槛"这两节，否则产品做大了才发现授权有问题，那才叫欲哭无泪。
生态成熟度看三样：HuggingFace 上的下载量和社区活跃度（代表踩过坑的人多，提问有人答）、推理框架的兼容性（vLLM、SGLang、llama.cpp 是否第一时间支持）、微调生态的丰富度（有没有现成的 LoRA 教程和脚本）。一个生态成熟的模型，能帮你省掉大量"前人没踩过坑"的额外探索时间。
4.2 部署里的那些坑：显存、量化、并发
我见过最多的部署事故，几乎都出在显存估算上。这里给一个最简单的估算公式：模型权重占用的显存约等于"参数量（十亿）乘以精度对应的字节数"。FP16 是每参数 2 字节，INT8 是 1 字节，INT4 是 0.5 字节。也就是说一个 7B 模型，FP16 权重约 14GB，INT8 约 7GB，INT4 约 3.5GB。
但注意，这只是权重，别忘了一件事：推理时还有 KV Cache、激活值、框架自己的开销都要吃显存。我的经验是：实际预留显存要在权重的基础上再富余 30%~50%。很多新手看着 24GB 的卡算了下"7B 量化后 4GB，绰绰有余"，结果一跑并发就 OOM，原因就是没算 KV Cache 和框架开销。
量化选择上，我的建议是：INT8 是你的安全底线，效果基本无损；INT4（比如 AWQ、GPTQ）能省一半显存，速度也有提升，但部分任务上会有肉眼可见的质量损失，尤其是数学和逻辑推理类任务。GGUF 格式主要用于本地 CPU/边缘设备（llama.cpp 生态），在数据中心级 GPU 上更推荐 AWQ 或 GPTQ，吞吐表现更好。
vLLM 是最常用的生产级推理框架，几个关键参数我直接给出经验值：--gpu-memory-utilization设到 0.85 到 0.9，别设满，留出余量；--max-model-len按业务实际最大输入长度来设，设太大 KV Cache 会吃掉大量显存；多卡场景用--tensor-parallel-size做张量并行。并发不是越高越好，要在吞吐和延迟之间做取舍，这个必须用你自己的业务流量做压测，没有通用答案。
4.3 微调还是 RAG：别一上来就干微调
我见过太多团队，遇到效果不好，第一反应就是"微调吧"。但微调是个一次性投入大、回报却不总是正向的路：数据要人工标、训练要烧卡、实验要跑很多轮，而且很容易过拟合到你那几千条样本上，把模型原本的泛化能力搞坏。
我的顺序是：先 RAG，再提示工程，最后才微调。RAG 解决"模型不知道某件事"的问题，提示工程解决"模型知道但不会按要求输出"的问题，微调解决的是"模型的行为模式（格式、风格、术语）与业务需求不一致"的问题。这三层各管一摊，别混在一起。
真到了要微调那一步，记住两个经验：一是样本质量远比数量重要，三千条高质量人工标注样本的效果，好过一万条自动生成的脏样本；二是 LoRA 永远是第一选择，相比全参数微调，它训练快、成本低、容易回滚。全参数微调要不要碰，等你的算法团队和算力预算都到位了再说。
5. 闭源路线实操：选厂商、控成本、防锁定
选择闭源 API 不代表可以躺平。厂商选型、成本控制、被锁定风险这三件事，我几乎在每次闭源项目里都要处理。
5.1 选厂商：能力之外还要看活力和稳定性
只看模型跑分选厂商，是新手最常见的选择方式。我额外看几样东西：SLA 承诺和历史稳定性（这个厂商过去一年有没有频繁的故障记录）、限流策略是否透明（高峰期会不会突然把并发砍掉）、数据条款是否清晰（留存、训练用途、传输路径都要落在纸面上）、生态兼容性（是不是走 OpenAI 兼容接口，方便以后切换）。
还有一点很实际：看这个厂商的迭代节奏。闭源模型的核心风险在于你无法控制它的演进方向，所以你要找一个"至少值得信任"的玩家。我个人的判断标准是，过去一年有没有持续发布新版本、有没有明确的路线图、对兼容性的态度是激进还是保守。更新太激进的厂商，你的提示词可能每个月都要跟着改；更新太慢的厂商，你用的模型可能很快落后于同行。
5.2 API 成本失控的四个常见原因
闭源 API 的成本失控，几乎总是这四种情况：
一是不做缓存。同样的用户请求天天来，你不做语义缓存，每一轮都在烧钱。给重复请求加一层缓存，成本立刻降 30% 以上，这是性价比最高的优化。
二是把上下文无脑拉长。每次请求把完整的历史对话、超长的 system prompt 全部塞进去，token 呈 O(n²) 增长。我在生产环境里见过一个"对话历史越积越长、每轮请求越来越贵"的项目，最后的优化方案只是加了一个滑动窗口，把超出N轮的历史交给摘要模型压缩，成本直接降了一半。
三是过度使用大模型。有些任务用 7B 开源模型甚至规则就能解决，但代码里写死了调用旗舰 API。一个抽取任务用旗舰模型做和用小模型做，效果可能差不多，价格差几十倍。
四是对失败请求不做重试和降级区分。用户重试一次，你的成本就翻一倍。我建议统一做一个路由层：简单任务走小模型，困难任务走大模型，大模型失败降级小模型，而不是傻乎乎地反复重试同一个昂贵接口。
5.3 防止被锁定的三条退路
闭源模型最大的隐忧是"离开它你还能不能活"。我的建议是提前做好三层准备。
第一层，代码层面抽象。所有的模型调用都走一个内部接口，接口后面是哪家服务商，只是配置项，不是代码逻辑。这样哪天要换厂商，你改的是配置，而不是满世界的代码。
第二层，输出格式解耦。别把业务逻辑建立在某个模型的输出格式上。用结构化输出（JSON mode / 函数调用）并且做严格的 schema 校验，模型输出不规范就重试或降级。千万别在代码里写"返回字段 A 一定是这么命名的"，否则换模型必炸。
第三层，保留可替换的候选清单。每季度跑一次自己的评测集，把各家闭源模型和开源模型的分数都记下来。这样你不用等到"必须换了"才临时找替代品，而是随时对局面有数。我自己有个小表格，记录了十几个模型在三个自有评测集上的表现，每次换模型的决策都靠它，不靠感觉。
6. 混合架构：大多数团队最终会走到的那个中间态
说实话，我在实际项目里几乎没见过"纯开源"或"纯闭源"走到最后的团队。做得越久，大家的架构越长越像：开源和闭源并存，按场景分流。这不是和稀泥，而是被成本和效果逼出来的必然。
6.1 什么时候值得混合
判断要不要上混合架构，我给两个条件：第一，你的月调用量已经稳定在千万级 token 以上，混合带来的成本节省能覆盖增加的工程复杂度；第二，你的业务有明显的难易分层，一部分请求非常简单（比如问候、查询、格式化），另一部分请求确实需要最强模型。
有这两个条件，混合架构会非常划算。还是拿客服场景举例子：我们线上大约 80% 的请求是常见问题（退换货政策、物流查询、订单状态），这类请求本地 7B 模型就能答得很好；剩下 20% 是复杂投诉、多轮纠缠、情绪激烈的高难度对话，必须让闭源旗舰顶上。整个系统跑下来，调用闭源 API 的比例只有两三成，总成本比"全闭源"省了三分之二以上，用户体验还没出现明显滑坡。
没有这两个条件，我劝你别折腾。如果月调用量只有几百万 token，混合架构省下的那点钱，还不够你搭路由、做监控、维护两套系统的人力成本。
6.2 混合路由的一条可落地思路
混合架构的核心是路由逻辑。我的做法是分级路由，三层判断：
第一层，意图判断。用规则或者一个小模型先判断请求属于哪一类。是简单问题就走开源小模型，是复杂场景就走闭源大模型。这个分类器本身的成本要压到极低，否则路由都比你省下的钱贵。
第二层，置信度判断。如果第一层分类器的置信度处于模糊区间，宁可走更强模型，也不要赌小了。误伤用户的风险远比多花几分钱高。
第三层，兜底降级。闭源大模型超时或失败，自动降级到开源小模型；开源小模型输出置信度低（比如模型打分低），升级到闭源大模型。一升一降，形成一个完整的闭环。
这条路线在工程上并不复杂，关键是要在灰度阶段用 shadow mode 跑一段时间——也就是说新路由逻辑和旧架构并行运行，路由结果只记录不生效，等数据证明它可靠了，再切换到线上。这一步能帮你避开大量"路由引入的新问题"。
7. 最后聊几句选型心态
绕了一大圈，你会发现选开源还是闭源，根本没有一劳永逸的答案。业务规模变了要重新算账，新模型发布了要重新评测，合规要求收紧了要重新评估，这本身就是做 LLM 应用落地的一部分。
我个人目前的心态是：默认先考虑开源，尤其是在中文场景、垂直领域、数据敏感性强、有工程能力的团队里——因为开源模型和闭源模型的体验差距在快速缩小，而开源带来的控制权和数据私密性越来越值钱。Qwen、DeepSeek 这一波开源模型把"自部署也能效果很好"变成了现实，很多之前必须依赖 API 的场景，现在本地就能解决。
但我也同样认真地提醒一句：别为了开源而开源。如果你团队里连一个能搞定 vLLM 的人都没有，老老实实用闭源 API，把省下来的时间花在业务上。工具是服务于目标的，开源和闭源都只是手段。把四笔账重新算一遍，答案往往就摆在那里了。
