这几天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 压缩更像是“笔记精简化”。模型在生成回答时需要回看之前处理过的历史状态这些状态存在缓存里。缓存越大显存压力越大。压缩技术就是把历史状态的存储做得更简洁牺牲少量精度换取更长的可用窗口。这三条路线的关键参数对比如下技术路线核心思路主要代价长文档下的表现特征稀疏注意力只对挑选出的部分 token 计算注意力选错 key 就会漏关键信息速度快但密集文档容易丢细节滑动窗口注意力只覆盖最近窗口早期信息逐步衰减尾部理解强开头容易“忘”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。时间成本也是成本这点在正式项目里尤其要命。成本项旧旗舰模型Space Bunny单次调用单价1x0.03x同一任务平均调用次数1-2 次3-5 次长上下文单请求 token 量中偏高实际综合成本占比1x约 0.2x-0.3x别被“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 会不会一直保持匿名、后续会不会推出正式版本现在还不确定但如果它能维持当前的表现水平我愿意在更多真实任务里继续用下去。 
长河君 · 2026/10/22 21:24:18 · 阅读 1.2k 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 压缩更像是“笔记精简化”。模型在生成回答时需要回看之前处理过的历史状态这些状态存在缓存里。缓存越大显存压力越大。压缩技术就是把历史状态的存储做得更简洁牺牲少量精度换取更长的可用窗口。这三条路线的关键参数对比如下技术路线核心思路主要代价长文档下的表现特征稀疏注意力只对挑选出的部分 token 计算注意力选错 key 就会漏关键信息速度快但密集文档容易丢细节滑动窗口注意力只覆盖最近窗口早期信息逐步衰减尾部理解强开头容易“忘”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。时间成本也是成本这点在正式项目里尤其要命。成本项旧旗舰模型Space Bunny单次调用单价1x0.03x同一任务平均调用次数1-2 次3-5 次长上下文单请求 token 量中偏高实际综合成本占比1x约 0.2x-0.3x别被“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 会不会一直保持匿名、后续会不会推出正式版本现在还不确定但如果它能维持当前的表现水平我愿意在更多真实任务里继续用下去。