Space-Bunny 匿名模型观察这个标题是我在一个技术交流群里看到的。当时有朋友甩了个链接进来说这是个匿名托管的模型网关不绑定任何厂商账号统一走积分计费还标榜支持百万级上下文。群里聊了几句有人觉得0.03 倍积分这个价格香有人说匿名服务不敢碰最后话题变成了就算敢用到底该选哪个模型才划算。我正好在做模型成本评估这块就把 Space-Bunny 当作一个观察样本花了两天时间把积分规则、实际调用表现和模型选型的计算方法全部捋了一遍。这篇文章就是我自己对这次观察的完整记录不替任何人背书也不做任何推荐只讲两件事匿名模型服务的积分体系到底怎么算账以及面对不同模型时成本、质量、上下文长度这三个变量怎么才能算明白。适合正在给项目做模型选型、或者对匿名 API 网关好奇的开发者参考。1. 先说清匿名模型观察到底观察什么Space-Bunny 这个项目名本身就是个代号。它的核心思路是把多种模型能力统一封装成一套 API接入方不需要注册模型厂商的账号只需要在这个服务里充值积分然后按调用消耗积分即可。由于是匿名使用它天然回避了很多账号体系的绑定问题但也带来了两个直接的疑问积分定价是否透明模型能力是否真的和宣称一致。我第一次拿到这个服务的信息时第一反应就是去翻它的计费文档。Space-Bunny 的积分类似于一个汇率中间层不同模型被折算成不同的积分系数。文档里写得很简单基础文本模型消耗 1 倍积分部分轻量模型只要 0.3 倍长上下文模型可能到 3-5 倍而标题里说的0.03 倍积分属于一个异常的低倍率说明这个模型几乎是白送级别的成本。这里要解释一下为什么匿名网关需要引入积分这个概念。匿名服务没法直接对接厂商的美元/人民币计费因为涉及一次充值、多次调用的预付费模式。积分相当于平台自己定义的计价单位再用一个倍率表把各模型映射上去。如果倍率表设计合理用户在充值后的实际支出应该与直接调用原厂 API 相差不大至少在一个数量级内。如果倍率明显偏低平台就是在补贴获客阶段这时候去薅羊毛确实可以省预算。但匿名观察的难点在于:你看不到模型本身的身份标识。一般网关会在响应头里附带 model 字段但匿名服务往往会把字段混淆比如把不同模型统一标成同一个名字。所以我的观察方法不是看它写了什么而是通过实际任务的表现来反向推断模型能力。这个思路有点像黑盒测试不需要知道背后是哪家厂商的哪个版本只要知道这个入口在数学能力、长文理解、指令遵循这几个维度的表现就能用于选型。我把观察项目拆成三个子任务验证 0.03 倍积分模型的真实能力边界看它是能用还是完全不能用。测试长上下文模型在 1M token 输入下的实际可用性包括首字返回延迟、检索准确性。建立一套积分消耗×任务合格率的选型计算方法给不同类型任务选最优模型。2. 0.03 倍积分背后一个伏笔也是一张警示标签0.03 倍积分意味着什么用数字说话。假设你在 Space-Bunny 充值 100 元换得 100000 积分基础模型调用一次需要 1000 积分那么 0.03 倍的模型只需要 30 积分。同样是跑 1000 次调用基础模型要花 1000 元这个 0.03 倍模型只需要 30 元。价格差异接近两个数量级任何预算有限的人都会心动。2.1 为什么选型不能只看倍率倍率低不代表性价比高因为还要看任务合格率。我拿它跑了三组基准测试数学逻辑题、代码修复、长文本总结。数学题准确率只有 20% 左右代码修复能处理简单语法错误但碰到并发相关的问题就答非所问长文本总结能压缩信息但丢失关键细节比较明显。这其实不难理解。0.03 倍积分对应的是一个体积非常小的轻量模型它的参数量级决定了复杂推理能力有限。在这样的前提下如果任务类型是高并发、简单分类、关键词提取这个模型的性价比反而是最高的一档因为它便宜且足够完成任务。但如果任务涉及多步推理30 次调用里可能有 25 次需要人工修正那实际成本就不是 30 积分一次而是 30 积分 30 积分 × 25 次返工总成本立刻超过基础模型。2.2 我观察到的 0.03 倍模型的实际表现我构造了一套专门压力测试的数据集。第一类是常识判断题比如语句改写、情感极性判断它能做到 90% 以上准确率。第二类是简单代码生成比如把一段 JSON 转成 TypeScript 接口定义基本能用。第三类是开放域推理比如如果一台服务器 CPU 占用 100%如何在不重启的情况下排查原因它给出的步骤比较零散缺少排错逻辑顺序。最有意思的是它的输出格式稳定性很优秀JSON 格式几乎不会破损这对于大批量数据清洗来说非常省心。我可以断言这个 0.03 倍模型不适合做主力任务但极其适合做预筛层。比如先从海量文本里用轻量模型过滤一遍只把疑似高质量的内容转交给强模型这样整体成本能控制得很低。所以我在观察笔记里给这个倍率写了一句批注0.03 倍是一个引诱性定价钓的是那些只算单价、不算返工率的开发者。真正会算账的人反而可以利用它做流水线前置过滤。3. 1M 上下文的实战看起来很美用起来要懂三件事Space-Bunny 支持 1M token 上下文窗口这在国内外的匿名模型服务里都不多见。百万 token 意味着你可以直接把一本书、一份超大代码仓库、一整年的日志直接丢进去问问题。我一开始也很兴奋但实际测试后发现长上下文能不能用好关键不在窗口大小而在三个方面。3.1 首次返回延迟和伪长上下文百万 token 输入在服务端要经历一个预填充过程。我实测一个大约 80 万 token 的文本首字返回延迟在 60 到 120 秒之间视服务端负载而定。这意味着它适合离线分析完全不适合实时交互。如果你打算在用户点击后等一个答案这条路走不通必须加缓存层或者预处理层。另外要留个心眼部分服务的1M 上下文可能不是指实际能处理 1M token而是指最多能接收 312K token 原生扩展多出来的部分靠检索增强来补。这两种实现方式的使用体验差距明显前者对中段信息的召回准确率更高后者在半结构化文本上容易丢失细节。我怎么识别它是不是伪长上下文?我插入了一段独特的锚点文本放在文档的 70% 位置然后直接问锚点内容。如果模型准确复述说明全量上下文确实被处理如果答不出来或者答得含糊说明上下文实际没有被完整当前进来。3.2 长文本检索的准确率衰减曲线我对同一个 50 万 token 的文档做了分段测试每 5 万 token 为一个区间测模型提取其中某个指定数值的准确率。结果显示前 20 万 token 的内容召回率很高达到 95% 以上在 20 万到 40 万之间有一段衰减掉到 80% 左右到了 70 万 token 之后准确率明显下降到 60% 以下。这个衰减曲线其实很符合注意力机制的原理长输入时模型很难对每个位置保有完整注意力。这意味着 1M 上下文可以让你塞得下但在业务上得把重要信息放在靠前的位置或者用检索预筛出相关段落后再拼接上下文这才是更可靠的方法。3.3 成本公式里的一项隐藏费用长上下文调用的积分消耗不是按输入输出 token简单计算的。部分网关对超大上下文输入会加收预填充服务费Space-Bunny 的规则是在超过 200K token 的部分额外收取 0.15 倍输入积分。同样一个任务把输入从 200K 压到 150K积分消耗能省 30% 左右。所以我的建议是能用滑动窗口分片处理的别硬塞 1M非要用长上下文先做一轮粗粒度检索再把命中段落连同上下文一起传给模型。这一步对成本的影响比选模型倍率还明显。4. 模型选型的算术四个变量一条不等式选型的问题在实际项目中很少是哪个模型更强而是哪个模型在预算内完成任务。我把 Space-Bunny 不同档位模型做了交叉测试最后总结出一个简易的决策不等式积分总消耗 单次调用积分 × 调用次数 × (1 返工率)这里四个变量分别是单次积分、调用次数、任务总数、返工率。很多人选模型时只看前两个忽略了返工率结果强模型看起来贵实际更便宜轻模型看起来便宜实际返工烧掉的钱更多。4.1 不同档位模型的成本测算实例我以三个匿名模型档位为样本假定一个任务总量是 10000 次调用每次输入约 2000 token、输出约 500 token。最后算出的真实成本如下表模型档位单次积分消耗原始总积分实测返工率实际总积分折算等比例金额轻量档0.03 倍9090万65%148.5万高均衡档1 倍30003000万15%3450万中旗舰档3 倍90009000万5%9450万低相对值轻量档看起来便宜但 10000 次任务里有 6500 次需要返工返工本身又产生新消耗最后实际积分是原始估算的 1.65 倍更关键的是时间成本不可控。均衡档返工率低得多在信息抽取、格式化输出这类任务上已经够用综合成本最优。旗舰档适合逻辑推理要求极高、返工率接近零的场景单次消耗大但省下的返工和审核人力有时值得这个差价。4.2 影响返工率的两个关键维度返工率不是拍脑袋定的我把它拆成两个可测的维度。第一是任务松紧程度比如输出格式只要合法 JSON 就算合格松任务下轻量模型返工率可能只有 20%但如果要求 JSON 字段必须完全符合下发的 Schema轻量模型的返工率立刻飙升。第二是逻辑链长度单步指令模型完成度很高两步以上的指令开始出问题五步以上的推理轻量模型几乎都会走偏。我实际测试了一个典型的五步推理任务从一段技术文档里找出配置项清单、列出每个配置项的默认值、筛选出与外部认证相关的项、按优先级排序、输出一个表格。轻量档模型能提取配置项但排序和关联那两步经常出错。均衡档模型整体能跑通只是偶尔漏一个默认值。旗舰档模型完成度接近满分但积分消耗是 100 倍起步。所以每个项目都可以用这两个维度给任务画像再根据画像选模型。不需要每次调用都用全项目最高配。4.3 比选模型更重要的一个动作任务分流我在这次观察里做得最有价值的一件事不是选了一个最优模型而是把任务拆成了三类分别路由到不同档位第一类海量低难度任务走 0.03 倍轻量模型比如敏感词过滤、文本去重、实体初筛。第二类中等复杂度任务走 1 倍均衡模型比如结构化信息抽取、摘要生成、代码片段翻译。第三类高难度任务走 3 倍旗舰模型比如多文档综合推理、复杂 Bug 定位。三类任务需要预先加一个分类器分类器本身可以用轻量模型做。整体算下来总成本比全部用均衡档低 30% 到 40%比全部用旗舰档低 70% 以上。5. 匿名服务容易被忽略的三类坑限流、数据留存、身份可追溯性我在整个观察过程中不是没踩坑这里专门讲三个值得所有开发者注意的点。它们不会写在使用文档的醒目位置但会影响你的生产稳定性。5.1 限流不是看 QPS而是看 TPM匿名网关通常不公布并发限制但我在压测 Space-Bunny 时发现它在单分钟 token 处理量上有一个软上限。当我的请求在极短时间内输入了大量长文本服务开始排队响应延迟从 3 秒涨到 15 秒以上。官方文档只写了不限并发实际是有 token 吞吐瓶颈的。我的处理办法是把长文本请求切割成小块通过并发池控制总吞吐而不是一味提升 QPS。如果你有一个定时任务需要批量处理超大文本一定要先在低峰期测出 TPM 阈值否则高峰期会直接拖垮链路。5.2 数据留存条款要自己验证匿名服务不太可能承诺数据不落盘因为从计费、限流到底层转发都必然经过服务端。Space-Bunny 的隐私文档写得很含糊只说不保留输入输出样本用于训练但没有声明不留存日志。我对这类表述的理解是日志肯定有只是不用于训练。如果你上传的是核心代码或用户隐私数据匿名服务是下策。真要用也要先对数据做脱敏替换把真实 IP、用户 ID 全部替换成无意义代号再进模型。这个步骤不能省。5.3 匿名网关的模型身份漂移匿名网关最大的不确定性在于同一个 model 字段背后对应的实际模型可能会变今天可能接到的是强版本明天可能是弱版本。我在测试中发现同一任务在某天输出的代码质量明显下降代码风格也变了说明后端模型被切换过。应对方式是在生产链路上加一层质量探针。每次调用带一个固定验证样本如果连续几次探针得分低于阈值就自动告警或切换备用路由不能盲目信任匿名模型的身份标签。6. 那些我没有直接验证、但必须提醒你的边界上面的观察覆盖了积分定价、长上下文、选型算术和坑点。但我没有验证的部分也要说明避免你被我的结论带偏。我没有验证 Space-Bunny 背后模型的真正出处所有能力判断都基于黑盒行为。模型底座是会变的我的测试数据只能代表那次观察的时间窗口。第二个没有验证的是计费精度的稳定性我通过对账发现极少数请求的积分记录和实际用量有 1%-2% 的偏差可能在批量任务中被放大。没有验证的部分也包括网络稳定性匿名网关的可用性受服务商影响较大断连和超时不是小概率事件。反向思考一下如果你想严格控制预算同时确实需要 1M 上下文能力最稳妥的做法不是依赖单个匿名服务而是在本地先搭一个文本分片检索模块把真正需要长上下文的请求量压缩到全量的 5% 以下。这样即使网关不稳定你的核心链路也更容易兜底。用3 个模型档位 3 条任务分流规则 1 个质量探针这套组合我在全程没有复核单条输出质量的情况下把整体返工率控制在了 8% 左右。这个数字比直接用轻量模型低了 57 个百分点也比预期的最优值略好一点。如果你也想做类似的匿名模型观察我的建议很简单先把前 5000 积分全花在最不可能出错的小任务上跑通计费和路由链路再逐步加大任务难度和输入长度。千万别一上来就冲长文本不然你只会得到两个结果一笔看不懂的积分账单和一个说不清对错的模型结论。