Jev调用次数统计只计入成功抵达服务端、鉴权通过且返回2xx的请求；未抵达（超时/DNS失败）、401/404/403错误、429限流拦截均不计数，重试可能导致重复计数或漏计。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
调用次数统计不准，通常不是模型本身“记错了”，而是统计逻辑和你的实际调用行为之间存在偏差。Jev 的计数是服务端按请求粒度统计的，它只认真实抵达 API 端点、通过鉴权、且返回 2xx 的完整 HTTP 请求。以下几类情况最常导致你看到的“调用数”和预期对不上：
一、未成功抵达服务端的请求不计入
客户端超时、网络中断、DNS 解析失败、代理拦截、本地防火墙阻断——这些请求压根没发到 Jev 服务器，自然不会被统计。尤其在高并发或弱网环境下，这类“静默丢包”容易被误认为“调用没生效”，其实服务端根本不知道有这回事。
二、401/403/404 等错误请求不计费也不计次
Jev 的调用计数只针对鉴权通过（401 不计）、路径正确（404 不计）、模型可用（403 不计）且最终返回 2xx 的请求。比如 Key 写错一次，触发 401，这次不算；URL 少写 /api 导致 404，也不算；模型 ID 拼错或权限不匹配返回 403，同样不进统计。很多人把报错请求也当成“已调用”，其实是误解了计数口径。
三、重试机制重复发送但服务端只认一次
如果你在 SDK 或自研逻辑里设置了自动重试（比如遇到超时就再发一遍），而第一次请求其实在后台已成功处理并返回，只是客户端没收到响应（即“网络分区”场景），那么第二次请求会被服务端当作新请求计数——结果就是你调用 1 次，服务端记录 2 次。反之，若重试前一次已失败（如 429），重试又撞上限，也可能被多次拒绝但不计次，造成“明明重试了却没涨数”的错觉。
四、429 限流后部分请求被直接拒绝
当 Key 触发限流（429），服务端会在网关层直接拦截后续请求，不进入鉴权和路由流程。这类请求既不返回内容，也不计入调用总数。如果你在限流窗口内密集发请求，会发现日志里一堆 429，但控制台调用计数几乎不动——因为它们全被“卡在门外”了。
