Space Bunny匿名模型实测：百万上下文与原生多模态的真实表现

这几天，AI工具圈里传得最热闹的一件事，就是 WorkBuddy 宣布接入了一个叫 Space Bunny 的匿名模型。官方给出的三组数字确实唬人：100 万 token 上下文窗口、原生多模态、价格倍数只有常规旗舰大模型的 0.03x。说实话，第一眼看到这条消息时，我的第一反应是“又来了一个参数吹得天花乱坠、实际多半不好用的角色”。但在 WorkBuddy 里实际跑了几轮文档处理、代码补全和多模态表格识别之后，我发现之前的判断需要修正。下面把 Space Bunny 的身份猜测、三个核心卖点的真实含金量，以及接入 WorkBuddy 后我踩过的坑，一次性讲清楚。

1. Space Bunny 到底是谁：匿名模型身份的三种推测

1.1 三种可能性

“匿名模型”这个说法本身就很耐人寻味。Space Bunny 没有公开过训练细节、参数量、数据来源，甚至没有明确说自己属于哪个实验室或公司。根据圈子里的讨论和我自己的观察，这种突然冒出来的“无主模型”通常有三种来路。

第一种，某个未公开系列的试水版本。好多团队习惯在正式发布前用化名把模型丢出来探路，喂给一批真实用户免费或低价使用，收集反馈后再“转正”。这类模型的典型特征是：能力分布不均衡，某些任务强得离谱，某些任务却像没训练过一样。我在Space Bunny身上确实看到了这种“偏科”的影子，它对长文档的总结能力很强，但对极端口语化的指令有时会给出过于正式的回答。

第二种，某个开源大模型经过重新蒸馏、清洗和封装后的商业版本。这个在圈内太常见了。现在的开源模型生态已经很成熟，很多团队拿开源底座做针对性微调，配上自己的强化学习流程和产品化包装，就变成全新的商业产品。这类模型的优势是成本可以压得非常低，因为底座和训练技术本身是现成的。

第三种，某个研究团队的“中间产物”。有些实验性模型在某个专项任务上表现很好，但整体能力还达不到正式发布标准，于是被第三方团队拿来做了产品化封装。Space Bunny 的多模态能力确实有这种“偏科”的感觉，它在图文混排、表格数据这类场景下表现得比通用对话更突出。

1.2 匿名的动机

为什么非要匿名？我问过自己这个问题，也问过几个使用 WorkBuddy 的朋友。大家的判断基本一致：匿名不是玩神秘，而是为了降低试错成本。如果模型翻车了，匿名品牌可以随时换皮、下架，不伤原有品牌。如果模型表现好，可以慢慢酝酿一波正式发布。这种“先看市场脸色，再亮明身份”的打法，对中小团队尤其划算。

另外，匿名也能规避一部分竞对压力。模型行业现在的竞争烈度大家都懂，一个还没完全打磨好的新模型如果过早暴露底细，要么被挖人，要么被针对性研究弱点，很被动。Space Bunny 选择保持匿名，反而是比较聪明的策略。

我在实测中还有一个直观感受：它的回答风格既不像常见的开源模型那套“啰嗦且防御性十足”的话术，也不像几个主流闭源大模型那种“彬彬有礼但套话一堆”的腔调，更像一支工程团队用大量真实业务数据做了深度的 post-training 调校之后的产物。这让我更倾向前面的第二种推测——它大概率是“好底座 + 强调校”的组合，而不是从零训练的原生大模型。

2. 1M 上下文：真长文本，还是参数数字游戏

2.1 1M 上下文意味着什么

先说说 1M token 到底是个什么概念。简单换算一下，如果按中文文本粗算，100 万 token 大约能覆盖几十万字到接近百万字级别的材料。什么概念？一本大部头教材塞进去毫无压力；一个中型项目的全部核心代码库可以一次性丢进去；一整年的项目周报和会议纪要也能一口气作为上下文喂给模型。

这带来的最大变化是工作流变短了。以前处理长文档，我得先把材料切块、分段、做向量检索，再配合外挂知识库才能让模型回答相关的问题。有 1M 上下文之后，理论上可以把原始材料直接丢进去，免掉中间那套切片和检索逻辑。WorkBuddy 接入 Space Bunny 之后，这个“整包投喂”的体验确实存在，但后面我会讲到，它并不是默认全开的，而且预处理时间也不短。

不过，1M 这数字本身就带着营销属性。长上下文窗口的难点从来不是“能不能把内容塞进去”，而是“塞进去之后还能不能有效利用”。存储空间只是地基，真正的考验在于模型是否能在这么多 token 里定位到关键信息、维持对前面内容的记忆、并且在回答时优先参考正确的片段。

2.2 长窗口背后的三条技术路线

行业内实现超长上下文，主流思路无非三种：稀疏注意力、滑动窗口注意力、KV Cache 压缩。Space Bunny 没有公布技术细节，但从它的实际表现来推测，大概率是几种方案组合使用。

稀疏注意力（Sparse Attention）的思路是：不计算所有 token 两两之间的注意力权重，而是只挑一部分重要的 token 做计算。代价是“挑选”这个动作本身也有开销，而且如果选错了，关键信息就会被漏掉。这类模型的长文检索速度快，但在内容密集场景下容易丢细节。

滑动窗口注意力（Sliding Window Attention）则是只保留最近 N 个 token 的注意力计算，让模型永远聚焦在局部上下文。它的优点是计算稳定、记忆机制简单，但窗口之外更早期的信息会逐步衰减，对“全文理解”就不太友好。

KV Cache 压缩更像是“笔记精简化”。模型在生成回答时，需要回看之前处理过的历史状态，这些状态存在缓存里。缓存越大，显存压力越大。压缩技术就是把历史状态的存储做得更简洁，牺牲少量精度换取更长的可用窗口。这三条路线的关键参数对比如下：

2.3 别让“能装”骗了你：注意力稀释问题

就算技术方案组合得再好，1M 窗口仍然有个绕不开的“注意力稀释”问题。模型处理超长输入时，有限的注意力权重会摊到海量 token 上，中间部分的内容最容易变成“被忽略的中间人”。这也是为什么很多厂商敢秀长文本 Demo，却很少展示 500K token 场景下的精确检索成绩。

我自己做过一个很简单的测试。准备了一份约 20 万 token 的技术文档，在第 10 万 token 左右的位置藏了一条约束条件：“本项目所有数据库一律使用 PostgreSQL 以外的数据库”。然后让模型基于文档最后部分的内容做方案评审。结果有趣，Space Bunny 捕捉到了这条约束，但并不是在第一次就捕捉到，需要我主动追问“文档中部是否有限制条件”时，它才把那条隐藏信息翻出来。这说明它的长上下文能力是真实可用的，但你不能完全指望它像搜索引擎一样主动全量检索。

所以我的建议是：1M 上下文的正确用法，是把它当作“更大的工作台”，而不是“什么都能自动找到的记忆库”。对于需要精确引用某个细节的场景，提示词里最好带上“请先检索文档前半部分关于 XX 的限制条件”这类引导。实测下来，有引导和没引导的准确率差距非常明显。

3. 原生多模态：跟“拼出来的多模态”差在哪

3.1 拼装式与原生式的工作方式差异

市面上很多“多模态模型”其实是拼接出来的。图片先经过一个独立的视觉编码器，变成一串特征向量，再被翻译成语言模型能理解的 token，最后交给文本模型回答问题。这种做法的本质是：模型看到的并不是图片本身，而是视觉模块“翻译”过的一版描述。如果翻译环节有损，后面的理解就跟着出错。

Space Bunny 被冠以“原生多模态”，意思是它在预训练阶段就把图像、音频、文本统一映射到同一个 token 空间里处理，视觉和语言不再走两套独立通道。模型学到的不是“图片的文本转述”，而是图片结构本身与文字语义之间的关系。这个差异放在日常工作流里非常关键。

举个例子。一份图文混排的 PDF，里面有图片、表格、段落文字，还有跨页的图注说明。拼接式模型的处理路径是：视觉模块先把整页版面截成若干区域，再做 OCR 和图片描述，最后把结果拼成一段文字喂给语言模型。一旦版面复杂，OCR 切错区域，文字和图表对不上号，后续问答肯定跟着错。原生多模态模型因为是在统一空间中训练的，面对这种混合版面时，更有能力保持“图在哪里、文字在哪里、表格属于哪个章节”的空间位置关系。

3.2 实测：图文混排场景的优势真正出现

我拿一份真实的扫描版技术合同做测试。这份合同有扫描的签名页、设备清单表格、手写批注和若干段印刷体条款，另外还配了一张项目拓扑图。要求模型完成两件任务：第一，把设备清单整理成结构化表格；第二，结合拓扑图判断某两套系统之间是否存在直接数据链路。

Space Bunny 在 WorkBuddy 里的表现确实超出我预期。设备清单表格的结构还原度很高，手写批注也能识别出大部分；更重要的是，它能把拓扑图里的链路关系和合同文字中的网络描述关联起来回答第二个问题。换成一个拼接式多模态模型跑同样任务，表格区域和文字区域经常被割裂，设备型号还可能被 OCR 错误串行，最后输出的表格需要手工修正的地方明显更多。

这套能力的实用价值很大。凡是搞过文档自动化的人都知道，扫描件处理最大的痛点从来不是“把字认出来”，而是“把版式和语义关系一起保住”。原生多模态在这类场景下天然占优，因为它的表征空间允许模型同时看到“字”和“字的物理位置”。

3.3 仍要泼冷水的地方

夸了这么多，还是得说点不好听的。原生多模态不意味着全能。我测试了一张高分辨率 UI 设计图，模型对图片主体区域的布局描述很准确，但角落里的缩小版按钮文字识别失败。这说明长上下文很受益显存资源的多模态处理，同样绕不过“大尺寸、高分辨率图片”带来的计算资源限制。另一个弱点是音频和视频处理。Space Bunny 虽然声称支持音视频输入，但实测里视频理解速度偏慢，一段 20 分钟的访谈视频，处理耗时接近实际时长的三倍。把它当作偶尔使用的应急功能可以，但指望它做批量视频分析，目前还不够成熟。

4. 0.03x 倍率的账：便宜是真便宜，但有三笔隐藏费用

4.1 低价是怎么做到的

0.03x 倍率的意思是以同类旗舰模型的 API 价格为基准，Space Bunny 的报价大约是它的 3%。这个价格确实低到反常识。但低价并不是天上掉下来的，实现路径无外乎几条。

MoE 稀疏激活是第一条路。混合专家模型把网络拆分成多个专家模块，每次推理只激活其中一小部分专家，而不是全量参数都参与计算。这样单位请求消耗的算力大幅下降，成本自然压下来。第二条是量化部署。把模型权重从高精度压缩到低精度，显存占用和推理耗时都能下降，代价只是极少量的精度损失。第三条是蒸馏。用大模型生成的数据来训练小模型，让小模型去逼近大模型的能力。这么做训练成本低，推理也快，但能力天花板受制于“老师模型”的上限。

4.2 三笔容易漏算的隐藏费用

不过，单价便宜不意味着整体账单便宜。根据我自己的使用经验，有三笔隐藏费用容易漏算。

第一笔：低稳定性带来的重试成本。便宜模型在复杂任务上的输出方差通常比贵模型大。同一个任务第一次跑出 80 分的结果，第二次可能只有 60 分。为了拿到理想结果，我常常要跑三到五次再挑最优输出。虽然单次价格低，但乘以多次调用之后，总成本就不再那么惊艳了。

第二笔：长上下文导致的 token 量爆炸。1M 上下文窗口本身就是一把双刃剑。窗口大，意味着用户更容易选择一次性投入海量 token。而 API 计费是跟着 token 总量走的，就算单价是 0.03x，如果一次请求就耗费几十万 token，单次总价照样不低。我做过一次粗略测算，一个重度使用长上下文的批处理任务，在 Space Bunny 上的总花费大约是旧模型同等任务的 25% 左右，而不是 3%。省是真的省，但省不到宣传的幅度。

第三笔：支持与服务成本被转嫁。匿名模型通常没有企业级 SLA，也没有 724 小时的技术支持。遇到限流、报错、输出异常，只能靠社区讨论和自己 debug。时间成本也是成本，这点在正式项目里尤其要命。

别被“0.03x”这个数字迷住，真实项目的成本账要按“完整任务链路”来算。

4.3 怎么算清楚这笔账

我的方法是给每个任务定义“成功输出的标准”，然后分别记录两个模型的调用次数、token 消耗和最终效果。比如一个研报摘要任务，旧模型跑一次约 15 元，输出可以直接用；Space Bunny 平均要跑 5 次，其中第 3 次的结果可用，第 2 次和第 4 次有明显错误，总花费约 5 次调用乘以 0.45 元，等于 2.25 元。算下来成本仍然只有旧模型的 15%。但如果任务对格式要求极严格，旧模型一次就过，Space Bunny 可能需要人工额外修正，这时综合成本就不只是 API 费用了。

需要提醒的是，测试时一定要把“同样输出质量”作为前提。只看单次 API 价格没意义，因为便宜模型可能需要更多次采样和更多人工干预才能达到同样的输出标准。

5. 接入 WorkBuddy 的实际体验：三大卖点在真实工作流里的表现

5.1 我搭建的验证场景

我在 WorkBuddy 里搭了一条完整的工作流，用来模拟真实办公场景，而不是像跑分那样做单点测试。这个工作流主要处理三件事：批量总结行业研报、为旧项目的代码补充注释、把混合格式文档转成结构化参考资料。

研报总结任务里，我一次性把 5 份 PDF 研报（合计约 80 万 token）丢进长上下文模式，让模型分别输出摘要，再汇总成对比表格。代码注释任务里，我把一个模拟项目X 的源码仓库全部导入，要求它针对核心模块补充注释，同时找出几处明显的逻辑问题。混合格式文档任务里，我准备的是一批含图片、表格、扫描签名的合同扫描件。

三条链路跑完，整体感受是：Space Bunny 在“大量材料 + 结构化输出”这类任务上确实能打，尤其适合批处理场景。它的答案组织逻辑清晰，表格输出格式也很干净，基本不需要二次整理。代码注释任务反而一般，简单模块的注释质量不错，但涉及跨文件引用时，偶尔会出现张冠李戴的问题。这也印证了它长文本能力不等于深度代码推理能力。

5.2 踩坑记录：三个“没料到”

第一个没料到的是：1M 上下文不是默认全开。在 WorkBuddy 里首次使用长文本处理时，界面并不会自动开启 1M 模式，需要在任务设置里手动切换。而且超大文档的预处理时间很长，一份 100 万 token 级别的材料，上线后等待了将近三分钟才开始生成回答，中途一度以为任务卡死了。如果只是处理一个两三万 token 的中型文档，没必要开 1M 档位，速度和费用反而不划算。

第二个没料到的是：高分辨率图像的角落区域会失灵。多模态识别不是均匀的。我测试了一份设计稿，页面很大，模型对中心区域的识别很精准，但页面右下角几个被压缩的小图标上的文字全部认错。后来我把图片裁成四块分别上传，识别准确率立刻提上去了。这说明多模态模型也有自己的“视野盲区”，处理重要图像时先做分区裁剪比直接整图投喂更稳。

第三个没料到的是：低价模型的限流比想象中严格。某天晚上我做批处理任务，跑到一半请求直接被限流，提示“配额已用尽”。匿名模型为了保证成本可控，通常会对并发请求和每日调用量做更严格的限制。批量任务一定要提前算清楚配额，否则会在关键时刻掉链子。

5.3 哪些任务适合，哪些暂时别碰

基于我的实操经验，Space Bunny 在 WorkBuddy 里的最佳使用姿势是“大批量素材的结构化整理”。行业研报摘要、PDF 表格提取、会议纪要归档这类任务，它性价比极高。其次是“需要同时参考多份文档的问答任务”，1M 窗口可以把整批文档直接放进上下文，省去切片检索的繁琐。

暂时不太适合的场景包括：精度要求极高的代码重构、需要严格实时性的交互式对话、以及大规模视频内容理解。前者是因为代码推理能力还达不到主力模型水平，中者因为限流和高延迟会让你着急，后者则是因为视频处理的耗时太离谱。把这几个边界记住，能少踩不少坑。

6. 匿名模型越来越多，我们该怎么判断

6.1 四步实测法

现在市面上的匿名模型、化名模型越来越多，参数包装也越来越精致。我不能靠别人晒出的跑分来决定自己的工具选型，因为跑分和真实任务之间隔着一层又一层的数据偏差。我的固定做法是四步实测法。

第一步，用“真题集”做回放式验证。把过去几个月里已经处理过、并且确认结果正确的任务整理成一份任务集，新旧模型同时跑一遍，对比是否可以复现当时的正确结果。真实业务数据比任何公开基准都更有说服力。

第二步，故意埋雷测试。在提示词里插入一个反直觉的约束条件，比如“所有日期都按自然季度展示，不要使用财年定义”，看模型会不会被上下文里原有的惯例带偏。这一步能快速判断模型“遵守指令”的稳定性。

第三步，观察长文本末端遗忘现象。在长文档的末尾追加一条关键指令，看模型执行时是否还记得。这是测试长上下文是否真正有用的黄金方法，比直接问“你能处理多长文本”可靠得多。

第四步，向社区要样本，尤其是负面案例。找别人翻车的例子来分析，比看厂商宣传管用十倍。一个模型的弱点往往不是隐藏的，只要你愿意花时间翻社区吐槽帖，很快就能画出它的能力边界。

6.2 我的工具集管理策略

从前两年开始，我就没有再把主力工具限定在某个固定模型上了。每个模型都有自己擅长和不擅长的领域，与其寻找一个全能答案，不如把不同模型放进一个“工具篮子”里，按任务类型指派。Space Bunny 目前的定位是长文本整理和低成本批处理，主力模型仍然负责深度推理和高精度生成。

我的策略是给新模型一个“观察期”。第一周只跑低风险任务，比如文档总结、资料整理；第二周开始增加中风险的批处理任务；一个月后评估结果再决定是否让它进入核心链路。Space Bunny 现在正处于观察期，目前的长文本表现已经能和主力模型打平，多模态和成本则是明显加分项。

最后分享一个我处理这类新模型的固定动作。在切换任何新工具前，先把过去三个月里自己处理过且已经确认正确结果的任务重新整理成一份“真题集”，新旧模型同时跑，哪个赢了用哪个，而不是看别人晒出来的跑分。这个方法帮我避开过不少包装精美的“参数怪兽”。Space Bunny 会不会一直保持匿名、后续会不会推出正式版本，现在还不确定，但如果它能维持当前的表现水平，我愿意在更多真实任务里继续用下去。