国产模型推荐性价比高的

预算有限的时候，选国产模型很容易走两个极端：要么盯着榜单挑最贵的，要么为了省钱选了个跑不动、许可证还不能商用的。这篇不讲谁排第几，只讲怎么按自己手里的卡、调用量和合规要求，一步步把候选缩到两三个，再决定要不要长期用。

预算有限的时候挑国产模型，最容易走两个极端：一种是盯着榜单挑最贵的，觉得贵一定稳；另一种是为了省钱选了个本地跑不动、并发上不去、许可证还不能商用的，最后返工的钱比省下的还多。这篇不讲谁排第几，只讲怎么按你自己手里的卡、调用量和合规要求，一步步把候选缩到两三个，再决定要不要长期用。

整个过程的核心不是找「最强模型」，而是找「单位成本下能力最匹配你任务的那个模型」。判断标准必须由你自己定义，因为别人榜单里的高分任务，可能跟你的业务一点关系都没有。下面按顺序走，每一步都给出可执行的判断动作。

先把「单位成本能力」定义清楚，不然比不出来

很多人算成本只算电费和 API 账单，这会把结论带偏。真正的单位成本要拆成三块：算力或调用费、搭进去的工程人力、以及质量不达标导致的返工。第三块最容易被忽略，却往往是长期使用里金额最大的一块。把这三块都摆出来，再除以同一套任务上的实际通过量，才叫单位成本能力。

能力这块，别用公开榜单当唯一依据。把你线上真实请求里抽 30 到 50 条，做成固定任务集，人工过一遍答案，记录通过率。同一批题跑不同模型，差距立刻显现。这个任务集以后每次换档位、换模型都复用它，比任何排行榜都贴近你的业务。

口径统一之后，所有价格数字都别写进文档里，因为会变。统一写成「到 /price-watch 核对当时的数字」，这样文档不用频繁改，同事看的时候也知道去哪查最新情况。

量化档位怎么定：先定误差容忍度，再定档位

顺序很容易搞反。多数人先看哪一档省显存，再想着适配任务；正确做法是先问这个任务错了会怎样，再反过来决定能接受哪一档量化。一个客服问答错一句顶多重问一次，一个结构化抽取错了可能导致下游入库全乱，两者能接受的档位完全不同。

生成类任务

文案、对话、摘要，通常能容忍更激进的低比特量化，先试低档再往上调

精确敏感任务

抽取、结构化输出、代码改动，档位要往上走，宁可多占显存也别牺牲准确率

吞吐与并发

量化不只改精度，也改吞吐和单卡并发数，这两项会反过来影响你的单位成本

1. 分类任务把你的请求按容忍度分成两三类，写清楚每类错了的后果是什么
2. 对应档位高容忍类从低档位起步，敏感类直接从较高档位起步，别统一用一个档
3. 复跑验证每换一次档位，拿同一套任务集重跑，记录通过率和延迟变化，别用上一次的结论

还有一个常被忽略的点：低比特量化后吞吐可能变快，单位成本看起来降了，但如果通过率跌到需要人工大量补，总成本反而上升。所以档位选择一定要连着任务集结果一起看，不能只看资源占用。

按显存和并发算一遍：你到底能跑多大、几个并发

选型之前先把三个数量出来：单条请求的平均输入输出长度、你的峰值并发、你能接受的响应时间。少任何一个都算不准。这三个数决定了显存需求，也决定了你是在本地部署还是走按量接口更划算。

显存要同时装权重和 KV 缓存。权重是固定的，缓存会随上下文长度和并发线性涨，长上下文场景下缓存占比能把你的估算直接翻倍。算完之后留出两成余量，显存碎片和流量峰值会吃掉你以为空着的那部分。

拿不准的时候，先到 /tools/speed-test 按模型和量化方式过一遍测算，再决定买卡还是买接口。测算结果和真实环境会有差距，但能帮你排除明显跑不动的组合，省掉一次试错开销。

许可证与商用边界：便宜但用不了等于零

一个模型再便宜，许可证不允许商用，对你来说成本就是零——因为你用不了。看许可证重点盯四件事：能不能商用、有没有调用量或营收门槛、衍生物要不要同样开源、要不要署名。这四条任何一条踩线，前面的比价都白做。

• 能不能商用：直接决定这个候选是否存在
• 调用量或营收门槛：超过阈值可能触发额外条件，要提前看清
• 衍生物开源要求：你微调或蒸馏出来的东西可能要被迫开源
• 署名要求：产品界面或文档里要不要标注来源
• 备案与采购资质：许可证之外，备案和企业采购清单可能另有要求

「开放权重」不等于「可自由商用」，这两个概念经常被混用。具体差别到 /guides 里的词条对照看，接入之前过一眼，比事后返工便宜得多。个人学习和内部工具可以直接跳过这一步，只要对外交付就别跳。

两三天跑完的短名单验证流程

候选不要一次列五个以上，挑三个就够：一个偏便宜的通用档、一个偏强的、一个折中的。同一套任务集、同一套提示词、同一台机器跑，避免环境差异污染结论。跑完只留两个进正式环境，第三个当备份，别留一堆并行维护。

1. 挑三个候选按上面三档各选一个，先把许可证过一遍筛掉不能商用的
2. 统一环境同一台机器、同一套任务集和提示词，避免变量干扰结果
3. 记录四列单位成本、任务通过率、平均延迟、人工返工次数，最后一列最容易被漏掉但最决定长期选型
4. 留二备一正式环境只上两个，第三个留作备份，减少维护面

跑完这一轮之后，你对每个候选的短板应该心里有数了。这时候再去 /rankings 看别人整理的对比，只是用来交叉验证，不是用来替代你自己的结论。两者不一致时，以你的任务集结果为准，因为那才是你真实的负载。

换模型的时机和回退准备

换模型不该凭感觉，触发条件要提前写清楚：单位成本涨幅、任务通过率下滑、限速影响业务，达到其中哪个就启动评估。写下来之后，团队里谁都能判断，不用等某个人拍板。

• 提示词和输出解析层解耦，换模型不用改业务代码
• 旧模型保留一段时间，接口层可切换，别直接下线
• 迁移后第一周重点看失败样本，新模型的错法和旧模型不一样
• 把触发条件写进监控，让它自动报警而不是靠人发现

回退路径是这套流程里最容易被省掉的一环。换模型当天如果出问题，没有回退路径就意味着业务停摆。所以在切换之前，先在接口层留一个开关，能一键切回去，验证稳定之后再考虑清理旧链路。

这几种情况不用折腾性价比

这套方法不是万能的，有几种情况硬套反而浪费时间。原型阶段、日调用量很小的时候，直接用现成的按量接口就好，选型花掉的时间成本比省下的调用费高得多。先把产品跑通，量起来之后再回头算单位成本。

• 日调用量很小或还在做原型，直接走按量接口
• 对延迟极敏感或要求能力上限，省钱不是第一目标
• 要过监管或客户审计，先满足合规再谈成本
• 任务集还没建起来，先建十到二十条也行，别等完美

顺序不能反：合规和可用性排前面，成本优化排后面。反过来做的结果通常是省了小钱、赔了大钱。等你确实有稳定调用量、也有了任务集和监控，再回到 /sites 挑接入方，这时候的比价才是有意义的。