调用量登顶的太空兔：OpenAI兼容网关与动态路由实测

1. 太空兔到底是什么：从一次“调用量登顶”事件说起

1.1 一次反常的榜单变化

上周四晚上，我在一个开发者群里看到有人丢出链接：SpaceRabbit，中文圈里都叫它“太空兔”。消息附带了一张截图，某个第三方API观测平台上，这个新项目的调用量在72小时内从0一路冲到了接近2300万次，直接把几个老牌大模型API甩到了身后。我当时的反应和大多数人一样：这榜单是不是刷的？毕竟AI行业这半年见过太多“出场即巅峰”的项目，最后大多都是靠补贴撑几天流量就凉了。

但第二天早上，事情开始变得不对味。推特上几个我关注了挺久的工程圈大V都在聊它，而且聊的不是“这个项目多牛逼”，而是很具体的问题：为什么这家连官网都做得很简陋的团队，能在一夜之间让几万开发者迁移过来？我这才意识到，光靠在群里抬杠没有意义，不如直接注册一个账号，从鉴权到并发全部实测一遍。于是我把周六下午到周日晚上的时间全部砸了进去，把这只“太空兔”从头到脚拆了一遍。

先说结论：它确实有火的原因，但也有不少文档没写清楚的坑。这篇文章不是安利文，也不是骂文，就是一个开发者花了十几个小时亲手跑完测试之后的完整记录。想接它的人，可以从这里开始少走点弯路。

1.2 太空兔的产品本质是什么

我看了它的官方文档和技术说明，给一个相对准确的定义：太空兔是一个开放的模型API网关，它本身不训练任何大模型，而是把全球多个开源模型通过统一的HTTP接口暴露给开发者。你只需要申请一个API Key，就能用同一套协议调用到轻量级对话模型、长上下文推理模型、视觉理解模型等不同规格的服务。

官方给它内部的模型起了几个代号：rabbit-lite、rabbit-reason、rabbit-vision。其中rabbit-lite对应的是小参数模型，主打低延迟高并发，适合闲聊和分类任务；rabbit-reason对应的是强推理大模型，专门用在数学、代码生成和逻辑分析这类场景；rabbit-vision自然是多模态模型，我测试下来支持图片输入和文档解析。

这个产品形态本身并不稀奇，类似的路由聚合平台之前也有人做过。但太空兔做得非常激进的一点是：它对外宣称“前1000万次调用免费”，并且支持OpenAI SDK直接切换base_url接入。这两个动作叠加在一起，等于把新用户的接入成本降到了史无前例的低。只要你会调OpenAI，五分钟之内就能把流量切过来。

1.3 “神秘”这两个字带来的传播势能

太空兔的团队信息到现在都很少。GitHub组织头像只是一只戴着头盔的兔子，项目描述写着“给所有人一个没有锁的AI入口”。没有公司主体，没有团队介绍，官网也只是草草地放了文档和价格页，看起来非常“临时工”。

但恰恰是这种神秘感，在开发者社区里引发了一轮又一轮的“人肉搜索”。有人去扒域名注册信息，发现注册地在新加坡；有人翻github提交记录，推测核心开发者时区在东八区；还有人说这可能是某个国内大模型团队出海试水。各种猜测都指向一个结论：这不是小作坊随便玩票，而是一个有备而来的项目。

这种“大家都不知道它后台是谁”的状态，配合上惊人的调用量曲线，形成了非常强的话题势能。开发者本质上也是爱凑热闹的物种，当朋友圈和推特同时被同一只兔子刷屏时，新的注册用户就会指数级增长。我自己的加入路径也是如此：先看到榜单截图，再看到大V讨论，最后变成亲自来测一测。

2. 3天登顶全球调用量第一，靠的不只是免费

2.1 兼容OpenAI格式的降门槛操作

过去接一个新的模型API，最大的麻烦不是技术难度，而是要重新学一套SDK、重新理解鉴权方式、重新处理错误码。这中间的时间成本，足以劝退很多只想快速验证效果的个人开发者。

太空兔直接把OpenAI的接口格式复制了过来。你不用改任何代码逻辑，只需要把原来的https://api.openai.com/v1换成一个新的Base URL，再把API Key换成太空兔的，就能跑通天上的大部分AI项目。这一点听起来简单，实际体验是真的很“解渴”。

我测试时的第一个请求，就是用Python里的openai库发出去的。只改了base_url和api_key两个参数，原本跑得好好的脚本就立刻跑通了。对一个开发者来说，没有比这更舒服的接入方式了。很多人说太空兔爆火是因为免费，我觉得免费只是表面诱因，真正的核心其实是“几乎零迁移成本”。

下面这个示例是我实测时用的完整请求代码：

from openai import OpenAI client = OpenAI( base_url="https://api.spacetoa.io/v1", api_key="sk-sr-你的密钥" ) response = client.chat.completions.create( model="rabbit-lite", messages=[ {"role": "user", "content": "用一句话解释什么是API网关"} ] ) print(response.choices[0].message.content)

在同一台机器上，同样的网络环境，我换成OpenAI官方API跑一遍，响应结构几乎一模一样。兼容性这块，它不是“兼容了个大概”，而是连finish_reason、usage的字段都对齐了，确实用心。

2.2 黑盒背后的多级缓存和动态路由

很多人都好奇一个问题：调用量这么大，他们靠什么扛住并发？靠什么把成本压到比OpenAI还便宜？我通过实测和一些公开信息拼凑出一个相对靠谱的解释：太空兔在技术架构上做了三个关键设计。

第一是多级缓存。它对高频请求做了Prompt级别的缓存，也就是如果你两次请求的Prompt完全相同，第二次会直接命中缓存，不需要再调用底层大模型。我实测下来，命中缓存后首字节延迟能从400毫秒左右骤降到100毫秒以内，这不仅是速度提升，更是成本的大幅下降。

第二是动态模型路由。太空兔在接收到请求后，会通过一个内部分类器判断这个请求属于什么类型，然后自动选择最合适的底层模型。比如简单的翻译直接走小模型，复杂的代码生成则路由到大模型。这种“看菜下饭”的方式，让它在保证回答质量和控制成本之间找到了一个平衡点。

第三是全球边缘节点分布。它的接入点在多个大洲都有部署，请求会自动路由到离你最近的节点。我测试了从香港服务器发出请求，延迟基本稳定在80到150毫秒之间，北美节点200毫秒左右，整体表现比较均衡。

说句实话，这三层设计里的很多细节都处于黑盒状态，官方文档没有完全公开。但从结果倒推，如果你也想做一个类似的网关产品，这套架构逻辑是值得参考的。

2.3 免费额度与社区传播的节奏控制

免费策略很多平台都做过，但太空兔这次把节奏踩得很准。它没有一开始就把所有模型全部免费，而是限定了“前1000万次调用免费”这个总量池子。开发者注册后看到的是一个非常有诱惑力的数字：这个项目目前还处于限时免费阶段，你可以无限调用，直到总量池用完。

这就有一种“薅到就赚到”的心理效应。我在好几个群里看到有人晒出自己的调用量截图，几千次、几万次都拿出来比较。紧接着，太空兔又推出了邀请机制：老用户每邀请一个有效注册用户，双方都能获得额外的免费额度。这一下就是典型的裂变增长，质量先不谈，数量确实在短短几天内冲起来了。

冷静下来想，这类玩法不可能长期持续。每个API调用背后都是真金白银的算力成本，等免费池烧完，它肯定会进入正常计费阶段。但我个人认为，太空兔这波操盘最聪明的地方，是在免费期内先把开发者心智抢占下来，等开发者把代码写进去、业务跑起来，再想迁移就没那么容易了。

3. 实测全记录：从注册到并发压测的每一步

3.1 注册与获取API Key

太空兔目前支持GitHub一键登录，也有邮箱注册入口。我用的GitHub登录，整个流程大概一分钟，中间没有任何电话验证、人工审核之类的麻烦环节。登录进去之后，控制台首页会直接显示一个API Key，前缀是sk-sr-，和OpenAI的sk-proj-风格很接近。

控制台里的信息非常简洁：一个总调用量计数器、一个免费额度剩余量、一个API Key管理区块。我注意到它没有提供“创建多个Key”的功能，至少我当时的版本是这样。这对企业用户来说其实不太方便，因为没法做到按项目隔离密钥。如果你准备用在生产环境，建议还是通过自己的后端再做一层转发。

获取Key之后，建议马上把它复制到本地环境变量里。我当时因为偷懒直接写在命令行历史里，后来要清理半天，这个细节后面会在避坑部分展开说。

3.2 第一个Chat接口调用与响应结构

既然是做实测，那就不能只跑一个示例就完事。我先用curl发了一个最基础的Chat请求，确认最原始的HTTP层面是不是真的和OpenAI对齐。

curl https://api.spacetoa.io/v1/chat/completions \ -H "Authorization: Bearer sk-sr-你的密钥" \ -H "Content-Type: application/json" \ -d '{ "model": "rabbit-lite", "messages": [{"role": "user", "content": "9.11和9.8哪个大？"}] }'

返回的JSON如下：

{ "id": "chatcmpl-sr-8f3a1c2b", "object": "chat.completion", "created": 1743672000, "model": "rabbit-lite", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "9.8大。比较小数大小时，不能只看小数点后的位数，要从整数部分开始逐位比较。" }, "finish_reason": "stop" } ], "usage": { "prompt_tokens": 24, "completion_tokens": 31, "total_tokens": 55 } }

从结构上看，字段和OpenAI官方响应完全一致。让我比较意外的是，rabbit-lite这个“小模型”在基础数学问题上没有翻车，说明它的底层模型参数可能比我预想的要大一些。整体首次调用从发出到收到完整响应，耗时大约460毫秒，速度算是不错。

3.3 流式输出与多模型路由测试

普通单次调用只测了最基本的功能，我紧接着测试了流式输出，因为很多AI应用都有打字机效果的需求。流式模式下，太空兔同样使用了stream: true参数，并且以data: [DONE]结尾，和OpenAI那边完全一致。

为了验证它的多模型路由到底是不是“伪路由”，我特意用同一个问题连续调用了rabbit-reason和rabbit-lite，并在响应Header里观察一个叫做x-debug-model的字段。官方文档说这个字段会显示实际命中的底层模型。我实测得到的结果如下：

这说明它确实在做底层模型路由，而不是自己训练了一个模型。对开发者来说，这个机制的好处是能够用相对便宜的价格拿到不同规模的能力；坏处是，当底层模型出现波动时，你的场上表现可能也会跟着变。如果你要做严格的A/B测试，这一点需要留意。

我还顺便测了视觉模型。上传了一张带文字的截图，它能把截图里的主要文字准确提取出来，包括繁体字和英文混排的情况，表现尚可。不过由于我是用Python的base64直接传图片，一次请求的Payload有6MB多，网络传输占了不少时间。建议生产环境尽量把图片压缩一下再上传。

3.4 并发压测的真实数据

跑完功能测试之后，更关键的环节是压测。毕竟一个API如果只能单线程跑得快，在真实业务场景里并没有意义。我利用一台8核16G的香港云主机，分别用wrk和k6做了两轮测试。

先看wrk的结果，100个并发连接，持续压了5分钟：

Running 5m test @ https://api.spacetoa.io/v1/chat/completions 100 threads and 100 connections Thread Stats Avg Stdev Max +/- Stdev Latency 228.55ms 187.24ms 3.84s 81.33% Req/Sec 59.21 19.34 141.00 76.10% Latency Distribution 50% 185ms 75% 275ms 90% 438ms 99% 1.58s 385239 requests in 5.00m, 51.48MB read Requests/sec: 1284.05

从数据上看，太空兔扛100并发没什么压力，总请求量约38万，成功率接近100%，只有少数请求因为测试机到节点之间的网络抖动出现了超时。P99延迟在1.58秒左右，对于Chat类接口来说可以接受，但如果你有强实时性要求，建议不要把超时时间设置得太死。

第二轮我用k6模拟了更接近业务的负载模型，每秒钟从0逐步增加到80个虚拟用户，持续10分钟。最终成功率99.97%，平均响应时间243ms。唯一出现的错误是429 Too Many Requests，出现在压测脚本跑到第6分钟时我临时提高并发的瞬间。这个后续会专门讲限流的问题。

整体来说，太空兔的并发表现超出了我一开始对“免费API”的预期。如果是做个人项目或者中小规模产品，它目前的稳定性暂时是够用的。

4. 接入之后最容易踩的坑和避坑建议

4.1 超时和重试：别把OpenAI的习惯照搬过来

很多开发者接太空兔的时候，会顺手沿用OpenAI SDK默认的10秒超时配置。我劝你最好别这么干。实测中，太空兔在高峰期处理rabbit-reason这类强推理模型时，响应经常需要5到10秒，如果用10秒超时，刚好卡在临界点，容易出现超时误判。

我的建议是：把超时时间放宽到30秒，同时对于非流式接口，在客户端设置合理的重试机制。重试策略上一定要用指数退避，不能一失败就立即重试，否则你自己的服务已经把流量打过去，太空兔那边又触发限流，两边一起抖，体验会很差。

下面是我实测后觉得比较稳的一个重试配置片段：

import time import openai def call_with_retry(client, max_retries=3): for attempt in range(max_retries): try: response = client.chat.completions.create( model="rabbit-reason", messages=[{"role": "user", "content": "1+1=?"}], timeout=30 ) return response except Exception as e: if attempt == max_retries - 1: raise e wait_time = 2 ** attempt + 1 time.sleep(wait_time)

这套逻辑帮我避开了好几次因为网络抖动导致的偶发失败，当并发不高的时候，基本能做到“零感知”恢复。

4.2 配额与计费规则里容易误解的四个点

太空兔虽然没有把计费文档写得特别复杂，但我在实际使用中发现了几个坑，这里直接列一个速查表：

我实际测试了缓存命中计费这一项：用同一个Prompt连续调用20次，前1次是冷启动，后面19次都命中了缓存，但usage里的prompt_tokens依然计满了。也就是说官方没有在token数量上“作假”，但计费后端应该单独识别了缓存请求，所以不会重复扣费。这算是良心做法。

关于限流，这里要特别提醒一句：太空兔的限流是基于滑动窗口的，不是最朴素的“每分钟重置计数器”模型。我压测时发现，如果前一分钟已经把请求跑到接近上限，下一分钟开始的一瞬间马上发请求，有概率触发429。解决方案也很简单，本地把请求速率控制在每秒不超过0.8个请求，基本可以避开限流。

4.3 API Key管理：别学我把Key硬编码进前端

我在测试的第一天，为了图省事，直接在Next.js项目的前端写死了API Key，想着反正是免费测试，问题不大。结果第二天早上醒来，看到调用量统计里多了几千次来自陌生IP的请求，显然是有人扫描到了我部署的测试页面，然后薅了我的免费额度。

太空兔的鉴权方式比较传统：在Authorization头里带Bearer凭证，而且它没有开放“域名白名单”之类的公网安全策略。所以我强烈建议，所有调用必须放在后端服务里，API Key只存在于环境变量中。如果非要给前端用，你一定要自己写一个轻量级的BFF层，由后端去转发请求，这样才能有效保护Key。

另外，太空兔控制台目前没有提供Key轮换的自动化接口，如果怀疑Key泄露，只能手动删除重建。这一点在大规模团队里会比较麻烦，建议提前设计好审计机制。

4.4 常见错误码速查

我在实测过程中收集了一些典型的错误响应，整理成表格，方便大家对接时快速定位问题：

这张表看起来简单，但每一个状态码背后都对应着一个真实的踩坑场景。尤其是408，我当初就是因为沿用了OpenAI的超时设置，导致逻辑推理模型总是报错，找了大半天才发现问题不在服务端，而在客户端。

5. 太空兔适合谁用，以及我对这个生态的后续观察

5.1 个人开发者和独立产品的接入场景

如果你是一个正在做AI应用的独立开发者，太空兔目前的性价比确实很高。首先，它的接入成本几乎为零，现有代码改两行就能跑通。其次，免费额度非常适合用来做MVP验证：你可以先拿它把业务流程跑通，等用户量起来了再考虑迁移到更稳定的商业服务。

我拿它实际跑了一个小工具：把公众号文章的正文抓下来，用rabbit-lite做自动摘要，再用rabbit-reason生成三条发布用的推荐语。整体效果不错，尤其是小模型的响应速度很快，用户体验很流畅。这个场景如果放在OpenAI正价计费下，大概是每天几美元的成本，但到现在为止，我还没花一分钱。

它还适合做一个“多模型对比工具”。因为太空兔在底层帮你切换了不同模型，你可以在同一套代码里快速比较不同开源模型在你的数据上的表现，这对做技术选型非常方便。我自己就利用x-debug-model字段记录了每次请求对应的底层模型，然后离线算准确率。

5.2 企业级落地的三个注意点

企业接入前，我建议冷静评估三个问题。

第一是可观测性和审计能力。太空兔目前没有提供详细的调用链日志和按部门拆分的用量报表，这对于需要做内部成本分摊和审计的团队来说是个短板。你必须在自己的服务层记录日志，才能弥补这块缺失。

第二是稳定性承诺。目前它的官网没有SLA协议，也没有具体的故障赔偿条款。免费阶段跑得很欢不代表它能一直在生产环境“裸奔”，如果业务对可用性要求很高，建议搭配一个备用供应商做热切换。

第三是数据安全。你发到太空兔的Prompt内容，底层实际上会分发到多个第三方开源模型服务，这个链路里的数据留存政策并不透明。如果你处理的是用户隐私数据或企业机密，上线之前一定要经过法务和安全的双重评估。

5.3 这种模式会成为常态吗

虽然现在还很难判断太空兔能不能笑到最后，但“统一网关+动态模型路由”的模式，我认为会在未来半年里成为API市场的主流形态之一。开发者的需求从来都是“少对接几个供应商、少学几套协议”，太空兔只是在这个方向上验证了市场空间。

它现在最大的风险是成本控制。免费策略带来的海量调用，必然伴随着巨额的底层算力账单。如果融资不够或者没有后续商业化落地，这个项目随时可能调整政策甚至关停。所以，如果你在生产环境已经重度依赖它，我的建议是做好抽象层隔离，把所有对太空兔的调用封装在一个独立模块里，方便未来切换。

6. 写在最后：一些零碎的实操心得

如果让我用一句话总结这次实测，我会说：太空兔是一只跑得很快的兔子，但它的赛道本身才刚刚开始。

最后分享三个我这几天实际用出来的小技巧，算是给这篇长文的收尾。

第一，如果你想让响应速度再上一个台阶，可以考虑把系统提示词固定下来。太空兔对完整的Prompt做了缓存，只要system prompt不动，后续相同请求的响应会快得多。我在测日志摘要时，系统提示词固定后，平均首字节延迟从400毫秒降到了120毫秒左右，这个提升非常可观。

第二，如果你的业务主要是短对话或简单分类，放心用rabbit-lite，不要一言不合就上rabbit-reason。我拿100条客服短消息分别用两个模型跑了一遍，回答质量几乎持平，但延迟差距接近10倍，成本差距更是大得离谱。

第三，对429错误码要建立“本地限流优先，重试兜底”的朴素观念。不要指望靠重试解决所有问题，因为重试本身也会消耗你的配额。我后来在本地用一个简单的令牌桶算法把请求速率压到每秒0.7个，限流返回率直接归零，接口反而更稳了。

这是我第一次花一整块时间在一个新出现的API产品上做深度实测，整体的体验不错，但也没有到“无脑吹”的程度。后续如果太空兔调整了定价或模型列表，我大概率还会再跑一轮新测试，到时候再出来更新数据。