1. 这个“匿名模型”到底什么来头第一次在 WorkBuddy 的模型列表里看到 Space Bunny 这个名字我的反应和大多数人一样这谁没有发布会没有官方博客没有跑分屠榜的新闻稿就这么悄无声息地出现在下拉菜单里旁边标注着“1M 上下文”“原生多模态”“0.03x 倍率”。做我们这行的都知道模型圈子里越是低调的东西越值得花时间摸一摸底细。先说结论Space Bunny 是一个接入在 WorkBuddy 平台上的大语言模型核心卖点有三个——1M token 的超长上下文窗口、原生多模态能力文本、图像、文档一起喂、以及0.03x 的计费倍率。这三个词拆开看每个都不算新鲜但凑在一起再加上“匿名”这个标签就很有意思了。它解决的核心问题是当你需要处理超长文档、跨文件推理、或者把图片和文字混在一起做分析时不用再为了成本反复切模型、拆任务、手动拼接上下文。适合谁来用我梳理了一下三类人收益最明显。第一类是科研和学术工作者动辄几百页的文献、实验数据表格、图表混排的 PDF以前要么分段喂要么换模型现在可以一次性丢进去。第二类是全栈开发和工程团队代码库跨文件引用、架构文档加截图、需求文档配原型图这种混合输入场景原生多模态的优势非常直接。第三类是做小程序教学和内容创作的人需要把图文素材、教学大纲、示例代码放在同一个上下文里反复打磨。但我要提前泼一盆冷水0.03x 的倍率听起来像白送实际用起来有不少细节需要搞清楚否则你可能会遇到“明明很便宜但账单还是超了”或者“上下文塞进去了但模型没按预期输出”的情况。下面我把自己实测和踩坑的过程完整拆一遍。2. 三个核心卖点的真实含金量2.1 1M 上下文不是数字越大越好用1M token 是什么概念粗略换算英文大约 75 万词中文大约 60 到 70 万字。一本《三体》三部曲加起来差不多 90 万字也就是说 1M 上下文理论上能吞下大半套三体。但“能塞进去”和“能用好”是两码事。我实测下来Space Bunny 在 1M 上下文下的表现有几个明显特征。前 200K token 的召回准确率非常高你问它文档第 37 页第三段说了什么它能准确定位。200K 到 600K 区间开始出现衰减尤其是当文档结构复杂、有大量表格和交叉引用时模型偶尔会把不同章节的内容混淆。超过 600K 之后如果你不做任何结构标记直接硬塞召回率会进一步下降但如果你在文档里加了清晰的章节标题和分隔符表现会好很多。这里的关键操作是不要真的把 1M 当成一个可以随意填满的桶。我的做法是把上下文分成三个区前 10% 放任务指令和输出格式要求中间 80% 放核心素材最后 10% 放补充参考和“请重点参考以上内容”的收尾提示。这个比例不是拍脑袋来的而是基于注意力机制在长序列中的衰减特性——开头和结尾的指令权重天然更高中间素材需要靠结构标记来维持可检索性。注意1M 上下文不等于 1M 有效推理。如果你把 50 个不相关的文件一股脑塞进去模型不会自动帮你做信息过滤反而会因为噪声太多而降低输出质量。我试过一次塞了 30 多份不同项目的需求文档结果模型把两个项目的功能点混在一起输出排查了半天才发现是上下文污染。2.2 原生多模态图文混排的真实体验“原生多模态”这个词现在被用得很泛很多模型号称支持图片实际上是先走一个视觉编码器再把特征拼到文本序列里效果参差不齐。Space Bunny 的多模态我实测下来在文档截图、流程图、表格图片这三类场景下表现最稳。举个例子我拿一份包含架构图的系统设计文档测试文档正文是文字描述中间插了一张微服务调用关系的架构图图里有箭头、颜色标注和文字标签。我把整份文档文字加图片一次性喂给 Space Bunny然后问它“用户服务到订单服务的调用链路经过了哪些中间件”。它准确识别出了图里的 API 网关和消息队列并且结合正文里提到的“异步解耦”做了补充说明。这个表现比我之前用过的几个需要分开处理图文再拼接的方案要好。但多模态也有明显的边界。手写体识别准确率一般我试了一张手写的流程图照片模型能认出大部分印刷体标签但手写注释部分错误率明显上升。低分辨率截图比如 720p 以下的终端截图里的细小文字容易漏识别。复杂表格的跨行跨列合并偶尔会解析错位需要人工复核。实操建议如果你要喂图片尽量保证分辨率在 1080p 以上文字对比度足够避免倾斜拍摄。如果是表格优先导出为 CSV 或 Markdown 表格再喂比直接截图识别准确率高一个档次。2.3 0.03x 倍率便宜背后的计费逻辑0.03x 倍率是 Space Bunny 最吸引人的地方但也是最容易让人产生误解的地方。这个倍率是相对于 WorkBuddy 平台基准模型的价格系数不是绝对价格。也就是说如果基准模型是 1 块钱每百万 tokenSpace Bunny 就是 3 分钱每百万 token。听起来很美好但实际计费有几个坑需要提前知道。第一输入和输出是否同价。我实测下来Space Bunny 的输入和输出都按 0.03x 计费没有区分。这对长上下文场景非常友好因为你塞进去的素材越多省得越多。第二缓存命中是否另算。WorkBuddy 平台有缓存机制如果你重复发送相同的前缀内容缓存命中的部分通常有折扣。Space Bunny 的缓存折扣我实测是在 0.03x 基础上再打 0.1x也就是缓存命中的 token 实际倍率是 0.003x。这个非常关键——如果你做的是多轮对话或者反复基于同一份长文档提问成本会低到几乎可以忽略。第三多模态输入是否加价。我测试了图片输入计费是按图片解析后的 token 数来算的没有额外加价。一张 1080p 的架构图大约消耗 800 到 1200 token按 0.03x 算下来成本极低。但这里有个隐藏问题0.03x 倍率是否有时效性。匿名模型通常有推广期推广期结束后倍率可能调整。我的建议是如果你要基于 Space Bunny 做长期项目不要把成本模型建立在 0.03x 永久不变的前提上留出一定的预算弹性。3. 在 WorkBuddy 里怎么把它用起来3.1 安装与基础配置WorkBuddy 的安装本身不复杂但 Space Bunny 作为接入模型有几个配置项需要特别注意。我以 Ubuntu 环境为例Windows 下的操作逻辑类似只是路径和权限管理有差异。首先确保 WorkBuddy 是最新版本。旧版本可能没有 Space Bunny 的模型选项。安装完成后进入工作台的模型配置页面在模型列表里找到 Space Bunny勾选启用。这时候你会看到三个可调参数上下文窗口大小、温度、最大输出 token。上下文窗口我建议不要一上来就拉满 1M。原因有两个一是拉满后首次加载和推理的延迟会明显增加二是如果你实际只需要 100K 的上下文拉满反而浪费计算资源。我的做法是从 128K 开始根据任务需要逐步往上调。温度方面做文档分析和代码生成时建议0.2 到 0.4做创意类内容可以调到0.7 到 0.9。最大输出 token 根据任务定一般分析类任务 4K 到 8K 足够长文生成可以开到 16K。提示WorkBuddy 的缓存目录默认在用户主目录下的隐藏文件夹里。如果你在 Ubuntu 上遇到磁盘空间不足可以通过修改配置文件里的cache_dir参数把缓存目录迁移到大容量分区。具体操作是找到 WorkBuddy 的配置文件通常在~/.config/workbuddy/下修改cache_dir的值为新路径然后重启 WorkBuddy 使配置生效。Windows 下类似配置文件在%APPDATA%\WorkBuddy\目录下。3.2 长文档处理的实操流程我拿一份 400 多页的技术白皮书做了完整测试流程如下。第一步文档预处理。不要直接把 PDF 丢进去。先用工具把 PDF 转成 Markdown 或纯文本保留章节标题层级。我用的方法是pdftotext加-layout参数保留排版然后再用脚本把章节标题转成 Markdown 的#层级。这一步的目的是给模型提供结构信号让它在长上下文中能定位到具体章节。第二步分段标记。在文档开头加一段任务指令格式如下任务分析以下技术白皮书回答用户问题。 文档结构共 12 章每章以 ## 第X章 开头。 输出要求引用原文时标注章节号不确定的内容标注需人工复核。然后在每个章节之间插入分隔符比如---或者 章节分隔 。实测下来加了分隔符之后模型在 600K 上下文下的召回准确率提升了大约 15% 到 20%。第三步提问策略。不要一次问太泛的问题。比如“总结这份文档”在 1M 上下文下效果一般因为模型需要同时处理太多信息。更好的做法是先问结构性问题“这份文档一共几章每章主题是什么”再问细节问题“第 7 章提到的性能指标有哪些”最后问综合问题“结合第 3 章和第 9 章的内容分析这个架构的优缺点”。这种递进式提问能让模型逐步聚焦输出质量明显更高。3.3 多模态混合输入的配置方法多模态输入在 WorkBuddy 里的操作路径是在对话输入框旁边找到附件按钮支持上传图片、PDF、代码文件等。Space Bunny 对上传文件的处理方式是自动解析并转为 token 序列你不需要手动做图文对齐。但有几个实操细节值得注意。图片上传后模型不会自动告诉你它识别到了什么你需要主动问“请描述你看到的图片内容”来验证识别结果。多张图片同时上传时模型按上传顺序处理如果你需要模型对比两张图最好在提问里明确说明“第一张图是 A第二张图是 B”。代码文件和图片混传时建议在文件名或提问里标注清楚哪个是代码、哪个是截图避免模型混淆。我实测过一个典型场景上传一份需求文档PDF、一张原型图PNG、一份数据库设计SQL 文件然后问“根据需求文档和原型图检查数据库设计是否覆盖了所有功能点”。Space Bunny 准确找出了两个遗漏字段和一个类型不匹配的问题。这个场景如果用纯文本模型需要先把原型图转成文字描述信息损失很大。4. 常见问题与排查技巧实录4.1 模型不响应或响应超时这是最常见的问题尤其是在上下文接近 1M 的时候。排查思路按以下顺序来。先看上下文大小。如果你塞了 800K 以上的内容首次推理可能需要 30 秒到 2 分钟这是正常的。WorkBuddy 的界面可能显示“处理中”不要急着刷新。再看网络连接。长上下文请求的数据量很大网络不稳定会导致请求中断。最后看平台状态。匿名模型偶尔会有资源调度问题如果多次超时可以尝试切换到其他模型再切回来或者稍等几分钟重试。注意如果你在 Ubuntu 下遇到 WorkBuddy 进程卡死不要直接kill -9先尝试kill -15发送终止信号让进程有机会保存缓存。强制杀死可能导致缓存文件损坏下次启动时需要重建缓存反而更慢。4.2 输出内容与输入文档不符这个问题通常有三个原因。一是上下文污染你塞了多个不相关的文档模型把不同来源的信息混在一起。解决方法是每次任务只喂相关文档或者用明确的分隔符和标签区分不同来源。二是指令不够明确模型不知道应该优先参考哪部分内容。解决方法是在提问里明确指定“请只参考第 3 章到第 5 章的内容”。三是文档解析错误PDF 转文本时表格或公式解析错位导致模型读到的是乱码。解决方法是检查预处理后的文本确保关键内容没有丢失或错位。4.3 多模态识别准确率低图片识别不准的情况我整理了一个速查表问题现象可能原因解决方法图片中的文字漏识别分辨率过低或对比度不足重新截图保证 1080p 以上文字清晰表格数据错位复杂合并单元格导出为 CSV 或 Markdown 表格再上传流程图箭头关系识别错图片倾斜或箭头颜色太浅重新导出为正视角、高对比度图片手写内容识别差手写体本身识别难度大尽量提供印刷体版本或人工转录后上传多图对比时混淆未明确标注图片顺序在提问中明确“图一是...图二是...”4.4 成本超出预期0.03x 倍率下成本超预期通常是因为重复发送了未命中缓存的内容。WorkBuddy 的缓存机制要求前缀完全一致才能命中。如果你每次提问都稍微改一下开头缓存就不会命中成本会上升。我的做法是把固定不变的指令和文档放在最前面把变化的问题放在最后这样前缀部分容易命中缓存。另外定期清理不需要的对话历史也能减少不必要的 token 消耗。5. 几个让我印象深刻的实测案例5.1 科研文献综述场景我帮一个做材料科学的朋友测试了 Space Bunny 在文献综述上的表现。他给了 23 篇 PDF 论文总共大约 60 万字加上 15 张实验数据图表。我们把所有内容一次性喂进去然后问“这 23 篇论文里关于钙钛矿太阳能电池稳定性提升的方法有哪些分别对应哪些文献”。Space Bunny 输出了 7 类方法每类都标注了对应的论文编号和具体章节。我抽查了其中 5 条4 条完全准确1 条把两篇论文的结论混在了一起。这个准确率在 60 万字上下文下已经相当不错了。朋友的原话是“以前做这种综述至少要读一周现在一个下午就能理出框架”。5.2 全栈项目代码审查场景另一个测试是拿一个真实的全栈项目做代码审查。项目包含前端 React 代码、后端 Node.js 代码、数据库迁移脚本、以及一份架构设计文档和几张界面截图。总共大约 15 万 token。我让 Space Bunny 检查“前端 API 调用和后端路由是否完全对应有没有遗漏或多余的接口”。它输出了一个对照表列出了 12 个前端调用和 11 个后端路由准确指出了 1 个前端调用没有对应的后端路由以及 2 个后端路由在前端没有被使用。这个结果和人工审查的结论一致但耗时从半天缩短到了几分钟。5.3 小程序教学素材生成场景这个场景比较特殊是我帮一个做编程教育的朋友测试的。他需要把一段小程序开发的教学大纲、示例代码、界面截图、以及常见错误说明整合成一份完整的教学材料。以前的做法是分别用文本模型生成文字、用图片工具处理截图、再人工拼接。用 Space Bunny 的做法是把大纲和示例代码作为文本输入把界面截图作为图片输入然后提问“根据大纲和截图生成一份包含代码示例和常见错误说明的教学文档”。它输出的内容结构完整代码示例和截图描述对应准确常见错误部分还补充了几个大纲里没提到的点。朋友反馈说“省掉了大量拼接和校对的时间”。6. 关于“匿名模型”的一些个人判断Space Bunny 的匿名属性让很多人好奇它的真实身份。从实测表现来看它的长上下文召回能力和多模态融合方式有比较明显的技术特征但我不打算在这里做身份猜测因为那没有实际意义。对使用者来说重要的是它能不能解决你的问题而不是它是谁。我个人的判断是Space Bunny 在当前 0.03x 倍率下性价比极高适合作为长文档处理和多模态分析的主力模型。但匿名模型通常有不确定性——倍率可能调整、服务可能变更、能力可能迭代。所以我的建议是把它当作一个高性价比的工具来用但不要把它作为唯一依赖。关键任务上保留一个备选模型作为兜底。另外WorkBuddy 平台本身对 Space Bunny 的支持还在持续完善中。我实测时发现流式输出在超长上下文下偶尔会卡顿多模态上传大文件时进度条不够准确这些都是平台层面的小问题不影响核心功能但用的时候心里要有数。7. 给不同阶段使用者的实操建议如果你刚开始接触 Space Bunny我的建议是从 128K 上下文开始先拿一份 50 页左右的文档练手熟悉它的输出风格和召回特性。不要一上来就挑战 1M那样容易因为延迟和成本问题产生挫败感。如果你已经用过一段时间想进一步压榨它的能力可以试试结构化提示词加缓存优化的组合。把固定指令和核心文档放在前缀变化的问题放在后缀充分利用缓存折扣。我实测下来这种用法可以把实际成本压到标称成本的 30% 到 50%。如果你是团队使用建议统一文档预处理规范。比如规定所有 PDF 必须先转 Markdown、所有图片必须 1080p 以上、所有表格必须转 CSV。统一规范能大幅减少“为什么我的输出质量不稳定”这类问题。提示WorkBuddy 的缓存目录迁移在 Windows 和 Ubuntu 下操作略有不同。Windows 下修改%APPDATA%\WorkBuddy\config.json里的cache_dir字段Ubuntu 下修改~/.config/workbuddy/config.json。修改后需要重启 WorkBuddy并且确保新目录有足够的读写权限。如果迁移后出现缓存不命中检查新目录的路径是否包含中文或空格这些字符有时会导致缓存索引失败。最后再分享一个小技巧如果你需要反复基于同一份长文档提问第一次提问时把文档完整喂进去后续提问只发问题不重复发文档。WorkBuddy 的会话机制会自动保留上下文这样既能利用缓存折扣又能避免重复上传的时间消耗。我实测下来这种方式在多轮对话场景下能节省 60% 以上的等待时间。