千问每天有多少免费额度

很多人用千问写东西或调 API，用着用着突然提示额度没了，但又不确定是当天用完还是整体配额见底，第二天到底会不会回血也说不准。这篇不报具体数字（那类数字一直在动），而是把额度分几层、按什么周期刷新、去哪一页看当期数字讲清楚，再给你一套按用量倒推的安排方法，让你在额度用尽前就把活干完。

很多人用千问写东西或者调 API，用着用着突然提示额度没了，但又不确定是当天用完还是整体配额见底，第二天到底会不会回血也说不准。这篇不报具体数字，那类数字一直在动，写死了很快就会过期；我们只把额度分几层、按什么周期刷新、去哪一页看当期数字讲清楚，再给你一套按用量倒推的安排方法，让你在额度用尽前就把活干完。

先记住一个原则：你需要的不是「千问每天有多少免费额度」这个答案本身，而是「我怎么在几分钟内查到当期口径，并且判断自己够不够用」。前者随时会变，后者可以一直用下去。下面按七个小节展开，从判断标准到可执行动作都有，照着做就行。

为什么没人能给你一个固定的数字

因为额度政策会跟着活动、账号类型、渠道变化。同一个模型在网页入口、App、API 三条路上的额度口径不是一回事，混着算必错。你在网上看到的任何「每天 N 次」的说法，都只对某个时间点的某条入口有效，换条路就不成立。

正确做法是记住「去哪看」，而不是记住「是多少」。价格与规格到站内官方 API 的供应商页核对，额度规则到官方 API 总览页看当期说明；这两处的数字是跟着政策走的，比你脑子里的记忆可靠。

网页入口

在官网或 App 里直接对话，通常按天给次数，用完等次日

API 入口

用密钥调用，扣的是赠送额度池或账户余额，按 token 计

第三方入口

中转站或套壳工具，规则自成一套，不能按官方周期预期

先把「额度」拆成三层，再谈够不够

大部分人被额度问题绕晕，是因为把三层混成了一层。拆开之后你会发现，每一层的刷新逻辑和用完后的表现都不一样，判断方法自然就清楚了。

• 第一层是入口层：网页或 App 的免费对话次数，通常按天给、按天清，用完提示里一般会带「次日恢复」这类时间词
• 第二层是 API 层：新账号赠送的额度池，一般是一次性给的总额，按 token 扣，用完不会自动补
• 第三层是活动层：限时赠送、任务奖励这类额外额度，有独立有效期，跟自然日没关系
• 常见误判：以为网页额度用完就等于 API 也用不了，其实两边互不影响；反过来也一样，API 池子空了不代表网页不能聊

什么情况下这套分层不适用？账号已经绑卡并开了按量计费的时候。这时扣的是账户余额而不是赠送额度，你看到的「剩余」可能只是赠送部分，实际还能继续用，只是开始花钱。这种情况下要去看的是账单页而不是额度页。

刷新规则的判断顺序：按天、按池、还是按活动

不用去猜政策原文，直接看提示文案里的时间词就能判断大半。下面给一个排查顺序，遇到「额度没了」先走这三步，基本能定位是哪一层的问题。

1. 第一步：看时间词提示里出现「次日」「明日」基本是入口层的日额度，凌晨按自然日重置；出现「本月剩余」这类总量提示，多半是赠送额度池，用完不自动补。
2. 第二步：看调用路径确认这次请求是从网页、App 还是 API 发出的。同一句话在不同路径上扣的是不同的池子，路径搞错会把结论带偏。
3. 第三步：比对站内页面到站内官方 API 相关页面看当期剩余量和刷新说明，跟你的实际调用记录对一遍，对不上就说明还有一层没考虑到。

活动额度是个例外，它看的是活动截止时间，跟自然日无关。所以你在月底看到「额度明天就没了」不一定是日额度的问题，可能只是某个活动要结束。判断标准很简单：把时间词和活动名称一起看，能对上活动就是活动层。

先分清扣的是哪个池子，再讨论够不够用；顺序反了，怎么算都是错的。

算自己一天要花多少，而不是问额度多少

额度是别人定的，用量是你自己的，后者可控。与其纠结当期额度是多少，不如先把自己的日均消耗算出来，再拿它去和当期额度比，差值就是你的安全边际。

记录三件事就够了：一天几次调用、每次输入大概多长、输出大概多长。用站内的 token 价格计算器换算成 token 量，这个数比「次数」准得多，因为长文档和短问答的差距可能很大。

• 轻量问答：每天十几次短对话，对日额度的压力很小，基本不用管
• 中等强度：每天几十次带长文档的问答，需要留意输入长度，长文最容易吃额度
• 重度使用：脚本化批量调用，最容易被日额度卡住，必须提前拆任务
• 换算完成后，拿日均乘以一点五作为计划用量，留出的差额就是缓冲

这张对照表只是思路，别当成固定标准：不同任务的实际消耗差异很大，真正的数字一定要用自己的记录去换算。如果不方便记录，可以先跑两天，把提示出现的时间点记下来，也能倒推出大致消耗速度。

把调用排进额度周期里：四个可执行动作

知道额度在哪个周期刷新之后，剩下的就是把活儿排进这个周期里。下面四个动作门槛都不高，但能明显减少「跑到一半被截断」的情况。

1. 拆批量任务把大批量任务拆到多天跑，别在一天里把日额度打满。拆的时候按优先级排，先跑急的，剩下的留到额度重置后再跑。
2. 切分长文档长文档先切分再送，减少无效输入。这一步在任何模型上都是最直接的省额度手段，效果往往比换模型还明显。
3. 加用量记录给脚本加一个当天用量记录，接近上限就自动停，避免跑到一半被截断。记录方式不限，本地写个计数文件就行。
4. 排执行时段把不着急的活放到额度重置后的时段做，急活优先走当天剩余额度。重置时间点以站内页面的说明为准，别按自己的印象来。

如果任务必须当天完成、又确实超过日额度，那就不要硬拆，直接走下一节的第三条路。硬扛的结果通常是任务做到一半断掉，重跑反而更浪费。

额度不够时的三条路，以及什么时候别硬扛

额度不够用不是只能等第二天。先试前两条，成本最低；都不行再考虑第三条。但第三条有明确的适用边界，下面会讲清楚什么时候不该用。

• 第一条：换任务粒度，把一次大请求拆成几次小请求，往往能压下来一部分消耗，代价是多几次调用轮次
• 第二条：粗活改用更省额度的模型档位，精修再换回好档位，整体消耗通常能降下来
• 第三条：接官方 API 按量付费，成本上限更可控，适合稳定有量的场景；只是偶尔查一下的话，继续用免费入口更合适
• 提醒：中转站或第三方入口的免费额度规则跟官方不是一套，用站内检测口径先确认，别按官方的刷新周期去预期

什么时候别硬扛？当你发现自己的日均消耗已经稳定超过日额度，而且任务没法拆、没法降档的时候，继续在免费入口上每天卡一次，时间成本比省下的那点额度更贵。这时候要么把量迁到按量计费，要么把任务重新排期。反过来，如果只是偶尔超一次，那就拆任务或者等重置，不值得为此改动整套调用方式。

一张能直接照着做的检查清单

把前面几节压缩成一张清单，新账号上手或者换项目时照着走一遍，基本不会再出现「用着用着突然没了」的情况。

这份清单的核心是第二步：把「去哪看」固定下来。官方 API 供应商页看价格与规格，官方 API 总览页看额度与刷新说明；中转站相关规则到站内对应页面核对。养成先抄口径再排计划的习惯，额度就不会再是个玄学问题。