openrouter 哪个免费模型好用

很多人第一次上 OpenRouter 是为了白嫖几个免费额度，结果要么挑了个跑不动的，要么免费位被限流限到没法用，要么隐私条款没看清就把数据送出去了。这篇不讲模型谁强谁弱，只讲一套能落地的挑选顺序：先看免费位的性质，再按任务筛模型，再用小样本测通，最后决定要不要留作日常主力。

很多人第一次上 OpenRouter，动机很朴素：先白嫖几个免费额度试试水。结果常见三种结局——挑了个跑不动的，免费位被限流限到没法用，或者隐私条款没看清就把数据送出去了。这篇不讲哪个模型最强，只讲一套能落地的挑选顺序：先分清免费位的性质，再按任务筛模型，再用小样本测通，最后决定要不要留作日常主力。

提前说一句前提：免费位天生带不确定性，随时可能下线、降速、改条款。所以下面所有动作的目标不是「找到唯一最优解」，而是「用最低成本找到两三个能轮换的备胎，并且知道什么情况下必须切走」。具体模型的当前状态和数字，一律以站内页面当时显示的为准，别信任何写死的结论。

先搞清 OpenRouter 的「免费」是哪几种

很多人把「免费」当成一个东西，其实至少有三类，性质差别很大。第一类是带 :free 后缀的免费位，通常是厂商放出的一部分额度，长期存在但容易被限流；第二类是限时免费的上新模型，厂商为了收集反馈短期开放，热度一过就收；第三类是账号层面的免费试用额度，跟你绑不绑付款方式直接相关。搞混这三类，就会出现「昨天还能用今天怎么没了」的困惑。

看模型卡片时，比看名字重要的就四项：上下文长度、限流口径、是否要求绑定付款方式、数据是否会被用于训练。这四项里任何一项没看清，后面都可能翻车。前两项决定你能拿它干什么，后两项决定你敢不敢拿它处理真实数据。具体每个模型这四项现在是什么状态，到站内模型资料库逐个核对，别凭印象。

按任务类型筛，而不是按排行榜筛

排行榜看的是综合能力，但你的任务往往只占其中一角。按排行榜挑免费位，最常见的后果是：挑了个大而慢的，做短问答排队排到怀疑人生。正确的做法是先把任务分类，再按每类的硬性要求去过滤。分类不用太细，四类够用：短问答与改写、长文摘要、代码补全、结构化抽取。

短问答与改写

对上下文要求低，能容忍排队和波动，免费位试错成本最低的一类

长文摘要

先确认上下文长度够不够，不够的直接排除，别指望模型自己「压缩」

代码补全

对格式稳定性和上下文连续性要求高，免费位波动时体验断崖式下跌

结构化抽取

重点看能不能稳定吐 JSON，跑偏一次的返工成本可能比调用费还高

还有一个容易被忽略的点：推理类任务要不要用免费位。思考型模型本身耗时就长，免费位又更容易被限速拖死，两者叠加的结果就是「等很久，然后失败」。这类任务如果不是拿来玩，建议直接走付费通道，或者换非思考型模型先把流程跑通。想知道同一档模型有哪些可选来源和大致价位，去站内的开源模型比价页看当时的数字。

建候选清单的四个动作

1. 按硬性条件过滤到站内模型资料库，用上下文长度、是否支持工具调用这两个条件先筛一遍，不满足的直接划掉，别留着犹豫。
2. 看当前排位与用量分布到中转站与聚合平台相关页面，看当前排位和用量分布，优先挑有人在用的，长期没人碰的免费位往往有隐藏问题。
3. 每个任务类型留两到三个候选别只留一个。免费位掉线是常态，留两三个才能轮换，只剩一个的时候你没有任何腾挪空间。
4. 写成一张对比表列上上下文、限流口径、是否要绑卡、数据条款四项，四个候选一行，横向对比比来回翻页面快得多。

这张表填完，你手里应该有三到六个候选。接下来别急着选「最好的那个」，先保证每个候选你都真的能调通。名字看起来再合适的模型，接口报错也是白搭。

用之前必须做的三组小测

免费位最大的风险不是「不够聪明」，而是「不稳定」。所以测试的重点不是文笔，是延迟、失败率和格式稳定性。三组小测做完，基本就能判断它是能当主力还是只能当备用。只跑过一个 hello world 就下结论，是最常见的坑。

• 延迟测：用站内测速工具量首字节和整体耗时，免费位的延迟波动通常比付费位大，重点看波动幅度而不是单次数值
• 稳定性测：同一个提示词连打十几次，记录失败率、超时率、返回被截断的比例，一次成功说明不了任何问题
• 任务测：拿你自己真实任务里的三五条样本跑一遍，重点看格式稳不稳、JSON 会不会跑偏，而不是读起来顺不顺
• 边界测：把最长输入、最刁钻格式各喂一次，看它是报错、截断，还是硬着头皮编一段出来

免费位的测试目标不是证明它能用，而是尽快找出它什么时候不能用。

测完把结果记下来，尤其是「第几次开始变慢」「哪种输入会崩」这类具体现象。这些记录是你后面判断去留的依据，也是轮换时决定先切谁的依据。三组测下来如果失败率明显偏高，别硬撑，直接换下一个候选。

限流、掉线和降级怎么兜

免费位一定会遇到限流，问题是遇到的时候你的程序会不会直接崩。正确做法是把调用写成可切换结构：免费位优先，付费位兜底，失败自动回落。模型名不要写死在代码里，用一个配置项或者一层简单的路由去管，换的时候改一行而不是全局搜索替换。

什么情况下别用免费位，这条要写清楚：需要对外承诺响应时间的服务、要处理敏感数据的场景、要跑大批量并发的任务，这三类都不适合。免费位适合的是个人工具、内部脚本、能重试的批处理——共同点是失败了可以再来一次，没有人在对面等着你。

白嫖之前先看清数据与条款

免费额度不是白给的，代价往往在数据条款里。有些免费位明确写着请求内容可能被记录或用于改进模型。如果你只是问天气、改写一段公开文案，这无所谓；但如果是客户资料、合同文本、公司内部代码，性质就完全不同了。

• 先判断数据敏感度：会不会涉及个人信息、商业秘密、未公开代码，有任何一项就先看条款
• 再确认请求数据是否被记录、是否用于训练，这一条优先级高于其他所有因素
• 确认是否需要绑定付款方式，绑卡前后免费额度的口径可能变化，别默认一直不变
• 判断标准很朴素：这份数据流出去了你会不会觉得麻烦，会的话就换付费通道或者本地跑

这条不是吓唬人，而是个很实际的取舍：免费位省的是调用成本，一旦涉及到不该外发的数据，省下的那点成本远不够补救。拿不准的时候，就按最保守的来。

用一阵子之后怎么决定去留

免费位不是选中了就一劳永逸，得定期回头看。建议按周看三个指标：可用率、平均耗时、返工率。可用率掉、耗时涨、返工变多，只要有一项持续变差，就该考虑换。注意是「持续」，偶发一两次波动不用大惊小怪。

1. 每周记一次三项指标可用率、平均耗时、返工率，用最土的方式记在表格里也行，重点是别凭感觉。
2. 给每个免费位留退出路径提前想好它挂了换谁，候选清单里随时有备胎，别等它下线了才开始找。
3. 把结论沉淀成短清单哪种任务优先用谁、什么信号触发切换，写成几条，下次同类任务直接照着选。

最后提醒一句：这套流程的目的不是让你永远用免费位，而是让你清楚自己为什么用它、什么时候该不用它。免费位适合验证想法和跑低风险任务，一旦任务的重要性上来了，主动切到更稳定的通道才是省钱而不是费钱。想先看看当前有哪些免费位、各家的实时状态和价格分布，可以去站内的中转站导航和价格追踪页对一遍，再决定留谁。