开源模型与闭源模型的区别

很多人在选型会上被问「用开源还是闭源」，嘴上能说一堆道理，真到要签字的时候又卡住：账单怎么算、数据能不能出去、以后换模型要付多少代价。这篇不重复概念定义，而是把三条线拆成可以动手核对的动作：先算清账、再对合规、最后看退出成本，并给出什么情况下这套判断会失效。

选型会上被问「用开源还是闭源」，谁都能讲几句，真要签字又卡住。卡点通常不是不懂概念，而是三件事没落到纸面上：账单长什么样、数据能碰到哪一层、以后想换要付多少代价。这篇不掰扯定义，直接把这三条线拆成能动手核对的动作。

先说个判断顺序：三条线不要同时比。先挑出那条绝对不能让步的硬约束，比如数据不许出网、或者必须锁死某个独占能力；硬约束定完，剩下的空间里再比账单和退出代价，会快得多，也不容易吵成各说各话。

先分清三条线：成本、安全、可控性各自在问什么

很多人把这三条混着谈，结果谁也不服谁。拆开看，成本线真正问的不是谁单价低，而是用量忽高忽低时谁的可预测性更好；安全线问的是数据、日志、权重分别落在谁手里；可控性线问的是出事时你能改到哪一层。三个问题的答案可以完全不同。

成本线

不问单价高低，问用量波动时账单形状是否可控，按量和自持是两种形状

安全线

不问谁更安全，问数据、日志、权重分别由谁持有、留存多久

可控性线

不问能不能改，问能改到哪一层：提示词、参数、权重、还是推理框架

每条线都有它的边界。用量极小、还在验证期的阶段，成本线基本算不准，别为它做长期决策；任务只涉及公开资料时，安全线往往不构成约束；团队没有稳定运维人力时，可控性线的后两档想都别想。先承认哪条线不适用，再谈剩下两条。

成本怎么算：把账单拆成用量、闲置和退出三块

账单被算错，基本都因为只算了用量那一块。用量按调用量和 token 走，具体单价别信记忆，到官方 API 价格页面核对当时的数字。闲置和退出这两块更容易被漏掉，而且恰恰是两条路线差别最大的地方。

可执行的做法是拉真实数据代入，不要凭感觉估。拿最近一个月的实际调用量，先到站内的模型成本计算器跑一遍，再把同一批请求丢进开源模型比价页面看托管报价，两条账放进同一张表并列。这样比出来的差值才有说服力，也方便复核。

• 先量后价：先统计真实调用量和输入输出比例，再去价格页取当时数字，顺序反了容易算成理论值
• 自建按峰值算钱、按均值看浪费，两个数一起报，别只报好看的那个
• 退出预算单列一行：换回另一条路要花多少人天，提前估个数量级
• 验证期不算长期账，用可随时退出的方式先跑起来，等需求稳定再回头精算

安全与合规：先画数据边界，再决定谁能碰你的数据

谈安全别一上来就比谁更安全，先把自己要过手的数据分三类：能公开的、内部但脱敏的、绝对不许出网的。只有第三类才真正逼你走本地或专属部署，前两类往往在托管路线下也能接受。把数据分类做完，选项通常会收敛一大半。

走闭源路线，要逐项确认数据是否进入训练、留存周期多长、有哪些子处理方、能否关闭日志。这些在厂商条款里能查到，条款里查不到的，就按最坏情况处理，别指望口头承诺。走开源路线，风险其实挪到了自己这边：权重是下下来了，但推理服务的访问控制、日志落盘、备份同步做没做，往往才是真正的泄漏点。

1. 画数据流表从用户输入一路画到存储端，标出每一次跨边界的点，包括缓存、日志、备份和监控上报
2. 给每个边界点标控制措施加密、脱敏、访问控制、留存期限，逐个对上；没有措施的标红
3. 两条路线各补一遍看闭源需要补几个控制点，开源需要补几个，数量差就是安全线的实际差距
4. 留证据把条款截图、配置说明和评估结论归档，合同或审计要的时候能直接拿出来

这套做法有明确的失效条件：如果只是拿公开资料做摘要，不涉及任何内部数据，安全线基本不构成选型约束，硬拿它当理由会被问穿。反过来，一旦第三类数据出现，讨论就回到「能不能不出网」这一个是非题上。

可控性对照：四种改造深度，对应四档团队能力

可控性不是「能不能改」的是非题，而是分层的。第一档改提示词和参数，两条路线差别不大，也是大多数团队实际停留的位置；越往后走，自由度越高，但要付出的工程代价也越陡，关键是想清楚半年内会不会用到那一档。

选型时问一句：半年内会不会用到后两档。用不到就别为它买单，因为后两档的能力成本是持续性的，不是一次性投入。用到的话，先用部署测算页面估一遍自建规模，把卡数、并发和预算范围大致框出来，再评估团队接不接得住。

这一节的不适用条件也很清楚：团队没有稳定运维人力，硬上自建往往在第二档就卡住，日常稳定性反而不如托管路线。可控性的上限受团队能力约束，不是受路线本身约束。

一份可照做的选型动作清单

前面三节是拆解，这一节是合起来用。按顺序走，每步都有明确的产出，走完能拿出一句可签字的结论。中途出现硬约束冲突就回上一步，不要带着矛盾往下推。

1. 定硬约束合规是否禁止数据出网，是否必须锁定某个能力档位，写成非黑即白的筛选条件，先把不符合的路排除掉
2. 算两份账用 Token 单价换算把调用量折成月成本，再用按模型算一遍的部署测算折出自建月成本，同一张表并列对比
3. 做小规模对照拿二三十条真实任务同时跑两条路线，重点看失败案例的形态，而不是谁的平均表现更好
4. 定退出方案写清换回另一条路要动哪些文件、重跑哪些评测、大概多少人天
5. 写结论浓缩成一句话：在什么条件下选哪条；条件一变，就重跑上面四步

这套动作里最容易偷工减料的是第三步和第四步。小规模对照只看平均表现，会漏掉失败形态的差异，而那恰恰是上线后最要命的；不写退出方案，等于把未来的决策权全部让给了当前选择，这两步别省。

什么情况下这篇的判断不成立

上面这套框架有边界，踩到以下情况时不要硬套，否则算出来的结论会误导决策。判断依据很简单：只要其中一条成立，就按它单独处理，不用再走三条线的对比流程。

• 任务本身就是厂商独占能力，另一条路没有可用替代品，此时成本和可控性都不构成选项，只能接受现状
• 处在极早期验证阶段，需求两周内可能推翻，任何长期成本模型都是自欺，优先选切换成本最低的方式
• 团队已有成熟内部推理平台和运维体系，边际成本结构与默认假设不同，应以自己的实际单位成本为准
• 监管或客户合同直接指定了部署形态，这种情况不需要选型，只需要执行并留好证明材料

除了这四种，还有一种隐性失效：评估人拿的是过期的价格或条款。站内的价格追踪和厂商条款都是会变的，动手算账之前先确认手上的数字是当时的，别拿着半年前的结论去签字。