1. 从"0.03 倍积分"说起：这个匿名模型到底在玩什么
第一次看到"Space-Bunny"这个名字，加上"匿名模型观察"这几个字，我脑子里冒出来的第一个念头是：又一个套壳中转站？但仔细看完它的定价策略和上下文规格之后，我发现事情没那么简单。0.03 倍积分、1M 上下文，这两个数字放在一起，本身就构成了一道很有意思的算术题。
先解释一下背景。所谓"匿名模型"，通常是指那些不公开底层模型具体来源、只以代号或别名对外提供服务的接口。你调用的时候看到的是一个名字，比如 Space-Bunny，但你不知道它背后到底是哪个厂商的哪个版本。这类服务在圈子里一直存在，有人拿来当便宜替代品，有人拿来当备用通道，也有人纯粹是好奇想测一测它到底像谁。
Space-Bunny 最抓眼球的地方在于它的积分倍率——0.03 倍。什么意思呢？假设某个基准模型的调用成本是 1 积分/千 token，那 Space-Bunny 只收 0.03 积分/千 token。这个价格低到让人第一反应是"肯定有坑"。但结合它标称的 1M 上下文窗口来看，事情就变得微妙了：一个能吃下百万级 token 的模型，收费却只有常规模型的百分之三，这背后的账到底怎么算？
我花了大概两周时间，断断续续用 Space-Bunny 跑了一些真实任务，包括长文档摘要、代码补全、多轮对话和结构化抽取。这篇文章不是评测报告，更像是一份"选型笔记"——把我观察到的现象、算过的账、踩过的坑，原原本本摊开来讲。如果你正在纠结要不要把某个任务迁到这类匿名模型上，或者单纯想搞清楚"0.03 倍积分 + 1M 上下文"这套组合拳背后的逻辑，那接下来的内容应该对你有用。
需要提前说明的是，我不会去猜测 Space-Bunny 背后到底是哪家模型，也不会鼓励任何人用它来替代关键生产链路。我要聊的是：当一个模型以这种参数出现在你面前时，你应该怎么判断它值不值得用、用在什么地方、以及怎么算清楚那笔账。
2. 0.03 倍积分背后的定价逻辑：便宜到底从哪里来
2.1 积分倍率的本质是成本转嫁
很多人看到"0.03 倍积分"第一反应是"打折"，但我觉得更准确的理解是"成本结构的差异"。一个模型的调用成本大致由三块构成：算力消耗、上下文长度带来的显存占用、以及服务方的运营加价。常规商业模型之所以贵，是因为它在每一层都加了利润，而且往往用"输入/输出分别计价"的方式把长上下文的成本转嫁给用户。
Space-Bunny 的 0.03 倍，我推测它压缩的主要是第三块——运营加价。也就是说，它可能拿的是某个开源模型或者某个厂商的批量授权，然后以极低的毛利对外放量。这种模式在圈子里不新鲜，新鲜的是它同时把上下文拉到了 1M。因为 1M 上下文本身是很吃资源的，如果真是全量注意力，那 0.03 倍根本覆盖不了成本。所以这里大概率用了某种稀疏注意力或者分块检索的工程优化，把长上下文的边际成本压下来了。
我实测下来的感受是：当你输入长度在 8K 以内时，Space-Bunny 的响应速度和输出质量和常规中型模型差不多；但当你把输入拉到 100K 以上时，它的首 token 延迟会明显上升，而且偶尔会出现"中间段落被忽略"的情况。这其实反过来印证了我的猜测——它的长上下文不是无损的，而是有取舍的。
2.2 1M 上下文是卖点还是噱头
1M 上下文这个数字，放在两年前是天文数字，放在今天虽然不稀奇，但配合 0.03 倍积分就很有冲击力了。问题是：你真的需要 1M 吗？
我拿一个实际场景来算。假设你要处理一份 80 万 token 的技术文档合集，想让它做跨文档的关联分析。如果用常规模型，按 1 积分/千 token 算，一次调用就是 800 积分。如果用 Space-Bunny，0.03 倍就是 24 积分。差距是 33 倍。这个差距足以让很多原本"不敢想"的长上下文任务变得可行。
但这里有个陷阱：长上下文不等于长记忆。我试过把一份 60 万 token 的代码库塞进去，问它"某个函数在哪个文件里定义"，它答对了；但问它"这个函数和另一个模块的调用关系"，它就开始胡编。这说明它的长上下文更擅长"定位"而不是"推理"。所以 1M 是卖点，但你要清楚它的能力边界在哪里。
2.3 积分消耗的隐藏规则
还有一个细节值得注意：很多这类服务在计费时会把"系统提示词"也算进去。Space-Bunny 我测下来，系统提示词部分似乎是不计费的，或者计费权重很低。这一点很关键，因为如果你用的是一个很长的系统提示词（比如几千 token 的角色设定），那实际成本会比表面看起来更低。
另外，输出 token 的倍率我观察下来和输入是一致的，没有像某些服务那样输出加价。这对生成类任务比较友好。但要注意，它的输出长度上限似乎和输入长度是共享 1M 额度的，也就是说如果你输入了 90 万 token，输出空间就只剩 10 万 token 左右。这个限制在长文档摘要场景下要特别留意。
3. 1M 上下文实测：哪些任务真能吃下，哪些会翻车
3.1 长文档摘要：表现最稳的场景
我拿了一份约 45 万 token 的行业报告合集做测试，让它生成一份 3000 字的结构化摘要。结果是：它确实把主要章节都覆盖到了，而且能引用具体的数据点。但有个问题——它在处理中间部分的时候，偶尔会把两个不同报告的结论混在一起。我后来调整了提示词，要求它"按文档顺序逐份总结，每份单独成段"，混串的情况就少了很多。
这说明它的长上下文注意力分布不是均匀的，中间部分容易被"稀释"。应对方法很简单：在提示词里显式要求它按顺序处理，或者把长输入切成几段分别调用。虽然切段会损失一些跨文档关联能力，但准确性会高很多。
3.2 代码库理解：定位准，推理弱
代码场景是我比较看重的。我试了一个约 30 万 token 的前端项目，问它"某个组件的 props 类型定义在哪个文件"。它准确给出了文件路径和行号范围，这个表现超出我预期。但当我问"这个组件在哪些页面被引用，引用时传了哪些参数"时，它给出的答案有一半是错的——它把相似名字的组件混在一起了。
我的判断是：它的长上下文检索能力（类似 RAG 的定位）不错，但需要跨文件做符号级推理时，就容易出错。所以如果你要用它做代码问答，最好把问题限定在"单点定位"层面，不要指望它做复杂的调用链分析。
3.3 多轮对话：上下文越长越容易"忘事"
多轮对话是另一个有意思的观察点。我开了一个 20 轮的对话，每轮都带一些新信息。到第 15 轮左右，它开始忘记前面几轮提到的约束条件。比如我在第 3 轮说"所有输出用 JSON 格式"，到第 15 轮它又变回普通文本了。
这不是 Space-Bunny 独有的问题，很多长上下文模型都有"中间遗忘"现象。但 Space-Bunny 因为便宜，你可能更倾向于开很长的对话，所以这个问题会被放大。我的建议是：重要约束在每轮都重复一遍，或者用系统提示词固定住。别指望它自己记住。
3.4 结构化抽取：性价比最高的用法
如果让我推荐一个 Space-Bunny 最适合的场景，我会说是"大批量结构化抽取"。比如你有一万份简历、一万条商品评论、一万篇新闻，想批量抽取出固定字段。这种任务的特点是：单次输入不长（通常几百到几千 token），但调用量大。0.03 倍积分在这种场景下优势极其明显。
我实测了 500 条评论的情感抽取，准确率大概在 85% 左右，和常规中型模型差距不大，但成本只有几十分之一。对于这种"量大、容错率高、不需要深度推理"的任务，Space-Bunny 的性价比是碾压级的。
4. 模型选型的算术题：什么情况下该用它，什么情况下别碰
4.1 先算清楚你的成本结构
选型的第一步永远是算账。我列了一个简单的对比表，假设你每月有 1000 万 token 的处理需求：
| 方案 | 单价（积分/千token） | 月成本（积分） | 适用场景 |
|---|---|---|---|
| 常规商业模型 | 1.0 | 10000 | 关键生产链路、复杂推理 |
| 中型开源模型 | 0.3 | 3000 | 一般任务、平衡成本 |
| Space-Bunny | 0.03 | 300 | 大批量抽取、长文档初筛 |
| 本地部署 | 固定成本 | 视硬件 | 数据敏感、高频调用 |
这张表的关键不是绝对数字，而是"量级差异"。Space-Bunny 的成本比常规模型低两个数量级，这意味着原本因为成本被否决的任务，现在可以重新考虑了。比如"对全量用户评论做主题聚类"这种任务，以前可能因为太贵而只抽样做，现在可以全量跑。
但反过来，如果你的任务本身调用量很小（比如每月几万 token），那省下来的钱可能还不够你折腾迁移的功夫。选型要看绝对节省额，不是看倍率。
4.2 任务类型决定一切
我把任务分成四类，对应不同的选型策略：
- 高精度推理类（数学证明、复杂逻辑链、代码架构设计）：别用 Space-Bunny。它的推理深度不够，省下的钱不够你修 bug 的。
- 大批量抽取类（信息抽取、分类、打标）：强烈推荐。成本优势最大，容错空间也大。
- 长文档初筛类（海量文档找相关、粗摘要）：推荐。先用它做初筛，把范围缩小后再用贵模型精处理。
- 实时交互类（客服对话、实时补全）：谨慎。它的延迟波动比较大，长输入时首 token 延迟可能到好几秒。
这个分类的核心逻辑是：把 Space-Bunny 当成"粗加工"工具，而不是"精加工"工具。它适合做第一道过滤，把数据量降下来，然后再交给更贵的模型做精细处理。这样组合使用，整体成本能降一个数量级，质量还不受太大影响。
4.3 一个真实的组合方案
我目前在一个内部项目里用的就是组合方案：先用 Space-Bunny 对每天新增的几千份文档做初筛和摘要，把不相关的过滤掉，相关的打上标签；然后只把筛选出来的 5% 左右交给常规模型做深度分析。整体成本比全量用常规模型降了约 80%，而最终输出的质量几乎没有下降。
这个方案的关键在于：初筛阶段的错误是可容忍的。就算 Space-Bunny 漏掉了几篇相关文档，对最终结果影响也不大。但如果你的任务不允许任何遗漏，那就不能这么用。
5. 踩过的坑与实操心得
5.1 提示词要"防呆"
Space-Bunny 对提示词的敏感度比常规模型高。同样的提示词，在常规模型上能稳定输出 JSON，在它这里可能十次里有两次格式跑偏。我的应对方法是：在提示词里加一个简单的格式示例，并且明确说"只输出 JSON，不要任何解释文字"。加了这两句之后，格式稳定性明显提升。
另外，它对"否定指令"的理解比较弱。你说"不要用 markdown"，它可能还是会用。更好的做法是正面描述你要什么，而不是说不要什么。
5.2 长输入要分段验证
如果你要输入超过 10 万 token 的内容，建议先做一次小规模验证：把输入切成几段，分别调用，看看每段的输出是否合理。如果某一段的输出明显跑偏，说明这段内容可能触发了它的某种边界。我遇到过几次"输入里包含大量重复结构时，输出开始复读"的情况，后来把重复部分去重后就正常了。
5.3 别把它当唯一通道
匿名模型的一个固有风险是：你无法保证它明天还在、后天还这个价。所以我在任何项目里用它，都会保留一个降级方案——一旦 Space-Bunny 不可用，能快速切到备用模型。具体做法是把调用层抽象成一个接口，模型名和参数走配置，切换时只改配置不改代码。
5.4 监控输出质量的变化
匿名模型的底层可能会悄悄换版本。我遇到过同一段提示词，上周输出还很规整，这周突然变得啰嗦。所以如果你在生产环境用它，最好加一个简单的质量监控：定期跑一组固定测试用例，对比输出长度、格式合规率、关键信息命中率。一旦指标明显下滑，就要警惕是不是底层换了。
6. 关于"匿名"这件事的一些个人看法
用了这段时间，我对"匿名模型"这个品类的看法有些变化。一开始我觉得匿名就意味着不可靠，但后来发现，可靠与否和匿名与否没有必然关系——关键看你的使用方式。如果你把它当成一个"便宜但能力有限的工具"，在合适的场景里用，它就能创造价值；如果你指望它替代所有模型，那失望是必然的。
Space-Bunny 的 0.03 倍积分和 1M 上下文，本质上是在用极低的价格卖"够用"的能力。它不追求最强，只追求在特定场景下"划算"。这个定位其实很聪明，因为大部分实际任务并不需要顶级推理能力，只需要"差不多对"就行。
我现在对它的定位是：批量任务的默认选项，关键任务的前置过滤器。这个定位下，它的性价比很难被替代。但如果哪天它的价格涨了，或者质量掉了，我也会毫不犹豫地换掉它。工具就是工具，算清楚账，用对地方，就够了。
