--- layout: post.njk source: https://yage.ai/share/small-models-real-work-20260817.html speaker: yage.ai title: 每天一千万次调用的 GPT-4o mini，不聊天也不写代码 date: '2026-08-17' summary: 文章分析了 GPT-4o mini 在 OpenRouter 平台上的调用数据，揭示了其在工程流水线中扮演的角色。该模型主要处理低吞吐量、短输出的任务，如数据分拣、结构化字段抽取等，而非复杂的多步代码生成或长文本对话。文章探讨了轻量模型在工程实践中作为特定分工的工具，其适用性取决于任务的输出结构和对长程规划的需求。 area: tech-engineering category: ai-application tags: - model - ai-application - ai-workflow - deployment - testing people: [] companies_orgs: - OpenRouter - Google - OpenAI products_models: - GPT-4o mini - Gemini 3.1 Flash-Lite - Gemini CLI - Ramp - ClickUp - Slack - n8n - Azure AI Foundry - GPT-5 Nano - Aider - DeepSeek - Qwen 27B - Llama 3.1 8B - Gemini 2.5 Flash-Lite - all-MiniLM-L6-v2 - Ollama - nomic-embed-text - Moonshot - Hugging Face media_books: [] draft: true status: evergreen --- 2026 年 8 月 13 日，在开发者按次付费调用推理的 OpenRouter 平台上，全天 509 条公开路由共消耗 11.135 万亿 token，处理了 6.392 亿次请求。GPT-4o mini 主路由消耗 317 亿 token，调用 1,761 万次，排在全站请求榜第七名，占 2.76%。若按 token 消耗量计算，它排在第四十四名，份额仅占 0.29%。在平均单次调用中，它吞吐约 1,800 个 token；全天输入总计 300.8 亿 token，输出 16.2 亿 token，单次平均仅输出 92 个 token。 这一进出特征直观反映了它的实际工作内容。编写代码单次需要吞吐数万 token，长文本与多轮对话通常也需往返数千 token，而它两者皆不涉及。18.6 比 1 的输入输出比例，呈现出典型的读多写少特征。读入大段上下文，仅返回单一标签或若干指定字段，软件流水线上的分拣工位恰好对应着这种形态。 若仅参考产品发布会，往往容易将轻量模型视作预算受限时的降级替代品，误以为其承担的任务与大模型相似、仅是能力有所折损。但综合分析付费流量分布、生产环境案例与实际失败记录，展现出的图景截然不同。小模型在工程流水线中牢牢占据了一批大模型无暇顾及的岗位；这些任务与人机对话关联不大，且相当一部分在过去并不属于传统软件的处理范畴。 ## 不聊天的第一名 在整体付费流量中，这项数据还呈现出几处明显的分布特征。当天全市场 509 条公开路由平均单次调用进出 17,419 个 token，而 GPT-4o mini 单次约 1,800 个 token 的吞吐量仅为全网均值的十分之一左右。在 7 月 1 日至 8 月 13 日连续 8 个采样日中，其请求量份额虽从 3.9% 缓慢回落至 2.8%，但单次长度始终保持在 1,700 到 2,400 个 token 之间，未见明显拓宽。在公开榜单中，头部应用的单次交互长度普遍落在 1.5 万至 18 万 token 之间，主流聊天或协同办公产品的调用体量极少会压缩至如此微小的范围。OpenRouter 的编程语言用量统计里也从来没有它的名字，这和一个标题就想宣称的判断一致：它不在那里写代码。 OpenRouter 与 a16z 曾联合发布覆盖 100 万亿 token 的用量研究，并在其平台数据分析报告（学术版见 arXiv:2601.10088）的留存章节中给出解释：2024 年 7 月早期开发者将 GPT-4o mini 接入系统后，形成了高度稳定的工作负载绑定。采纳的窗口期主要集中在模型发布初期，此后新增的用户群体多随时间沉淀流失，而 2024 年夏天嵌入生产系统的既有管线则长期稳定运转。该项联合研究未对 4o mini 按细分任务做过统计，原因在于任务标签分类体系直至 2025 年中才正式上线，追不回 2024 年的历史调用队列。这也印证了当前每日上千万次的调用中，有相当一部分源于两年前已部署落地的稳定管线。 ## 流水线上的四个工位 流水线上的分拣工位：小单元给传送带上的小包裹贴标签，远处一台吊车处理单个大箱子 结合具体工程实践排查，这些管线在后台承担的工作大致可划分为四类工位。第一个工位是前端分拣与请求路由。在复杂架构中让大模型直接吞吐所有原始输入会造成明显的算力浪费，Google 官方命令行工具便采用了分层路由机制。在 Gemini 3.1 Flash-Lite 官方技术文档 中，官方将轻量模型预判复杂度的架构列为生产环境中的推荐方案。Gemini CLI 维护者在社区讨论区 证实，后台统计中记录的 flash-lite 请求专门负责评估问题复杂度，简单任务分发至 Flash，复杂推理逻辑才递交给 Pro 处理。在工作流自动化平台 n8n 的常见 Intercom 客服消息路由模板 中，新接入的客服对话会直接交由 4o mini 处理，由其提取问题类型、用户情绪、紧急程度与相关标签，再依据结构化字段分流至 ClickUp 或 Slack 对应频道。 第二个工位是结构化字段抽取。非结构化文本中往往包含较多冗余信息，需要模型依循规范格式提取核心数据。在 OpenAI 的官方发布说明 中，财务管理平台 Ramp 演示了利用 4o mini 从各类收据与发票图像中抽取商家、金额、日期等结构化字段，将非结构化图像转化为标准格式表格。开源社区中的诸多自动化管线亦多遵循该逻辑：自合同文本中提取有效日期，自简历中检索联络方式，或自松散正文中抽离参数。此类任务无须深层长程推理，仅需遵循既定 JSON Schema 规范返回指定键值即可。 第三个工位是系统门卫与状态校验。在多步骤流程或多智能体架构中，轻量模型常驻守于各节点入口负责校验判定。例如，判断用户输入的补充信息是否延续上一轮对话主题，抑或评估当前上下文是否达到触发下游昂贵调用链路的阈值。它扮演着状态开关的角色，通常仅输出布尔值或枚举状态，完成判定后即刻退出上下文，将核心推理算力留给后置主模型。 第四个工位是离线批处理与异步作业。无须秒级实时响应的数据清洗与标注任务，通常会导流至成本更具优势的离线通道。OpenAI 提供的 Batch 接口具备半价费率优惠，于 24 小时内返回处理结果，适配非实时的批处理场景。在合成数据生成与模型微调领域，评测研究 AgoraBench 论文 记录了一组对比成本：利用 4o mini 生成 5 万条训练样本，相比使用 GPT-4o 生成 1 万条数据成本降低 3.4 倍，且据此训练出的学生模型在三个评测设置中有两个表现更优。在特定应用场景下，借助低成本模型扩大生成规模，其收益往往优于获取高单价的少量数据。在评估打分场景中，评测平台 Galtea 的实验博客 指出，经过校准的 4o mini 在评分对齐度指标上达到 0.71，与单次调用成本高出约 13 倍的 GPT-4.1（对齐度 0.75）差异有限。在常规业务数据整理中同样存在类似实践：有开发者花费约 30 美元调用 Gemini Flash 将数千条格式混乱的脏数据清洗为规范报表，替代了人工整理流程；亦有工程师通过 4o mini 剔除故障工单中的非关键干扰信息，在提炼出清晰的故障现象后再交由 Claude 深入分析根因。 四类工位的核心特征十分明确：输入的上下文可能包含数千字符，但最终输出通常仅为一个分类标签、若干抽取字段或单项评估得分。产出内容天然偏短，其调用频次直接挂钩业务处理量，而非取决于人机对话的轮次深度。 ## 它带不动多步任务 在多步复杂任务场景中，工程实践给出的反馈同样具备高度一致性。当尝试由 4o mini 承担中央调度角色、独立主导多步骤链式任务时，公开反馈记录大多以失败告终。 微软问答社区中的生产案例记录 记载了一个团队在 Azure AI Foundry 平台上的实际案例：部署于生产环境中的 4o mini 自动化流水线，在提示词未作调整的前提下突然无法按预期调用既定工具，直接跳过了工具执行环节；而在将相同提示词与工具定义迁移至 GPT-5 Nano 后，函数调用迅速恢复正常。在 OpenAI 开发者论坛的工具调用讨论 中，工程师列举了 4o mini 在面对复杂工具链时出现的具体异常：偶发性构造不存在的函数参数名称、向整型字段填入字符串数据、或在命名相近的工具间发生调用混淆。多位开发者在排查后指出，后续迭代的 4.1 mini 在复杂工具链调用的稳定性上相比 4o mini 有显著改善。 权威基准测试与一线工程实测给出了相互印证的结论。在 Aider 多语言代码生成基准测试中，业内常引用的数字是 4o mini 独立完成率仅 3% 左右，这一数字来自发布语境下的二手转述，但与一线开发人员的实际体验吻合。进行过独立实测的测评者亦指出，该模型适合承担单点独立任务，却难以胜任复杂的多步协作工作流。 此类失效现象并非偶发噪点。将基础模型缩减为轻量模型，缩减的不仅是参数规模与运算成本，更直接限制了其在长链条决策中的全局规划能力，以及步骤发生偏离时依赖上下文实现自我修正的容错空间。数据分拣、内容过滤与特征标注等单步工位无须统筹长程规划，小模型在其中能够维持高效稳定的表现；但一旦要求其主导全局任务调度，架构能力上的局限便会立刻显现。 ## 开源的那一半在家里 分屏画面：左边是安静的家庭书桌，右边是大型云数据中心，小单元们把小箱子从数据中心搬往家庭一侧 若将观察视角转向开源轻量模型，调用数据呈现出截然不同的分布格局。对于采用开源小模型的开发者而言，本地计算设备已足以支撑其日常运行，通常无须在云端持续承担 API 租赁成本。 在 2026 年 8 月 13 日当天，OpenRouter 平台用量首位由 DeepSeek 占据，占据全站 26.75% 的 token 份额，而 Qwen 家族仅占 2.00%。进一步审视 Qwen 27B 系列，两代版本合并统计全天仅产生 45.8 亿 token 与 83 万次调用，极少有用户在云端按 token 为其付费。其原因在于，27B 规模的模型借助单张消费级显卡或高规格个人工作站即可在本地完成部署推理，开发者无须持续向云端支付 API 调用开销。Llama 3.1 8B 在云端的分布形态亦十分接近，全天消耗 110.9 亿 token、响应 1,020 万次请求，单次平均长度为 1,088 token，与 4o mini 同属短请求阵营，但云端承接的总体请求规模明显偏低。作为对照，Gemini 2.5 Flash-Lite 全天处理 1,047 亿 token、3,755 万次请求，单次均值 2,788 token；DeepSeek V4 Flash 两代版本合计处理 2.32 万亿 token、1.24 亿次请求，单次平均吞吐达到 18,702 token。 而在 Hugging Face 开源社区中，统计数据则勾勒出另一幅全然不同的图景。根据 Hugging Face 官方下载统计规则文档，客户端每向模型文件发起一次 HTTP 请求（含 GET 与 HEAD 请求），计数器即自动递增，平台既不对具体用户进行去重，亦不区分人工下载与自动化脚本调用。在该统计口径下，Hugging Face 夏季开源模型报告 指出，在所有明确标注参数规模的仓库中，参数量小于 1B 的微型模型占据了历史下载总量的 83%。其中，明确标注参数的 Qwen 仓库累计下载量达 20.45 亿次，而 Moonshot 仅为 3700 万次。 位居下载榜榜首的并非通用对话模型，而是一款专门用于文本嵌入的微型工具 all-MiniLM-L6-v2。七个月里它累计了 15.5 亿次下载和 5,156 个赞，大量检索增强生成（RAG）入门教程默认把它写进依赖。Hugging Face 春季报告亦指出，自动化 CI/CD 流水线与容器镜像构建流程大幅推升了此类轻量模型的拉取频次。在本地推理引擎 Ollama 的累计拉取榜单中，排名前列的同样是 llama3.1、专注向量嵌入的 nomic-embed-text 以及 Qwen 镜像，前两者累计拉取量依次约为 1.18 亿次、8,200 万次，单个 Qwen 标签最高约为 3,680 万次。 综合对比云端 API 调用数据与开源社区下载记录，两者的分界线较为清晰。Qwen 27B 与 GPT-4o mini 在大众印象里都是小模型，前者在付费路由榜单中鲜有显现，后者则在云端维持着每日上千万次的高频调用。决定两者分流走向的核心并非绝对参数量，而在于模型权重能否低门槛地迁移至本地端运行，以及替换生产系统中既有默认 API 所需付出的工程与迁移成本。能够部署在单机显存内的开源轻量模型，其主要应用场景从云端付费接口分流至开发者的本地环境与私有服务器；而个人设备跑不动的开源大模型（如 DeepSeek 的旗舰系列），以及云厂商深度集成、迁移阻力较大的闭源轻量模型，则持续驻留于云端基础设施中。此处应当说明，OpenRouter 仅统计公开按量付费路由部分，并不等同于全球整体市场规模或总营收，各企业的私有自建机房、专属算力集群及区域独立镜像服务均未纳入该统计口径之内。 ## 先问答案的形状 在系统技术选型阶段，首要问题在于明确目标任务所需的输出结构究竟呈现何种形态。输出文本的长度与结构特征，往往比通用评测榜单上的基准跑分更能指导工程实践。 若业务目标仅限于判定分类标签、抽取规范的 JSON 键值、生成单项评估打分，或对松散输入执行前置清洗过滤，轻量模型兼具低成本与低延迟优势，便足以稳定满足需求。仅当任务涉及展开严密长程推理、跨工具链协同决策，或在多步执行中进行动态容错纠偏时，方需引入高规格大模型介入。轻量模型并非大模型的低质廉价替代品，它在工程流水线中对应着独立的分工定位，承接的是过去由初级处理人员、众包标注流程或后台定时任务脚本所负责的结构化处理工作。 这项基于调用形态的推论留有明确的可验证边界：若未来细粒度的应用监测数据表明，GPT-4o mini 的主要流量来自长篇对话产品，或其单次输出长度普遍涨到与代码智能体相当的水平，分拣工位的判断就需要修正。在那之前，看到小模型冲上调用榜，不必急着追问它是否变聪明了，先看看它的答案有多短。