Bespoke Curator：把合成数据流水线从脚本堆里拎出来的 Python 库
Synthetic data curation for post-training and structured data extraction
秒懂
- 它是什么？
- Curator 用装饰器把「调用模型生成数据」变成可缓存、可断点续跑、可观察的流水线。它解决的是批量推理的工程问题，不是数据质量问题，这两件事经常被混为一谈。
- 适合谁用？
- 如果你的团队已经在写「读一批 prompt、调模型、存 JSONL」的脚本，并且被重复调用烧掉过真金白银，Curator 值得试一次：先跑 pip install bespokelabs-curator，然后用一个最小 examples 目录里的脚本验证缓存命中行为，再确认你选的推理后端是否支持 batch。如果你的需求是单次几十条 prompt 的探索性调用，或者你需要对采样逻辑做细粒度控制，Curator 的抽象层只会挡在你和 API 之间。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 14 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
Curator 真正在解决的那件事：批量推理的工程债
合成数据生成的难点通常不在 prompt 写得好不好，而在调用模型的那一层。一个朴素脚本会这样写：遍历数据集，对每一行调用一次 API，把结果 append 到文件。这套写法在几百条样本时没问题，到几万条时会出现三个具体故障：进程崩溃后已经花掉的钱白费、并发控制靠手写 semaphore 容易把速率限制打爆、以及同一份数据被重复生成多次而没人察觉。
Curator 的定位就是接管这一层。README 把它描述为「Bulk Inference and Scalable Data Curation for Post-Training」，并列出四项能力：结构化输出、异步操作的性能优化、缓存、以及故障恢复。注意这些词全部指向工程属性，没有一项在承诺生成的数据质量更高。数据质量取决于你的 prompt 和验证逻辑，Curator 只保证这些逻辑被执行得足够稳、足够省。
目标用户是有 post-training 需求的研究和工程团队。README 提到 OpenThoughts2-1M、s1K-1.1、Bespoke-Stratos-17k 等数据集是用 Curator 生成的，也提到 OpenThoughts-Agents 的数据来自 Curator。这些是项目方的自述，可以当作使用场景的参考，但不要当作质量背书：数据集本身的好坏由配方决定。
装饰器、缓存与断点恢复：机制层面的取舍
Curator 的核心抽象是把一个 Python 函数标记为「需要调用模型」。函数体里写 prompt 构造逻辑，返回值是待处理的样本，Curator 负责调度、并发、重试和落盘。这个设计的好处是 prompt 逻辑仍然是普通 Python，可以用变量、循环、外部文件，不需要学一套模板 DSL。代价是执行模型被框架接管，你对调用时序和并发粒度的控制权交出去了一部分。
缓存是这个设计里最有实际价值的部分。同一份输入在第二次运行时命中缓存，不会再次产生 token 费用。对迭代 prompt 的场景，这意味着你只为核心逻辑的改动付费，而不是为整批数据付费。但缓存也带来一个容易踩的坑：如果你把模型名、温度或系统提示这类参数写在函数体外部的可变状态里，缓存键可能无法反映真实输入，导致拿到过期结果。使用前需要确认自己的缓存键覆盖了所有影响输出的变量。
故障恢复和缓存是同一套机制的两种表现。批量任务跑到一半中断，重启后已完成的样本从缓存读取，未完成的继续执行。README 用「fault recovery at every scale」描述这一点，没有给出具体的重试次数或退避策略，这部分需要看文档的 API reference 才能确认。
README 还提到一个 Viewer，用于在数据生成过程中监控进度。对长任务来说这比日志有用，但也意味着多了一个需要维护的运行时组件。
推理后端与批处理：省一半钱，换一套失败语义
Curator 通过 LiteLLM、vLLM 以及各家批处理 API 接入模型。这个组合覆盖了两类完全不同的部署形态：LiteLLM 走在线同步接口，vLLM 走自托管推理，批处理 API 走异步提交。
批处理是成本上最值得关注的一项。README 在 2025 年 1 月的更新里直接写了「Cut Token Costs in Half」，并在同年 3 月补充了 Gemini Batch 支持，此前 1 月已加入 OpenAI、Anthropic 及兼容 API 的批处理。半价是真实的吸引力，但批处理 API 的语义和在线接口不同：请求提交后进入队列，结果异步返回，单条失败不会立即报错。Curator 帮你屏蔽了提交和轮询的复杂度，屏蔽不了的是「一批里有一条格式错误，你要怎么发现它」这个问题。
README 提到 Gemini 批处理「extremely challenging」，项目方的做法是把它包装成和其他后端一致的接口。这种统一接口的代价是抽象泄漏：不同后端的速率限制、超时行为、结构化输出的支持程度并不一致，遇到后端特有的错误时，你仍然要回到该后端的文档里找答案。
接入哪一类后端取决于数据规模。几千条样本用在线接口更省心，几十万条样本不上批处理就是在浪费预算。
结构化输出与代码执行：两个需要单独评估的模块
结构化输出被 README 列为「first class support」。对数据抽取类任务，这是刚需：你需要模型返回符合某个 schema 的 JSON，而不是一段需要正则解析的自由文本。Curator 与 Pydantic 生态的配合方式在文档的 API reference 里有说明，但 README 没有展开。实际使用时要确认的是：当模型返回不符合 schema 的内容时，Curator 是重试、丢弃还是抛异常。这三种行为对最终数据集的行数影响完全不同。
代码执行是另一个独立模块。README 在 2025 年 2 月的更新里介绍了 CodeExecutor，支持四种后端：local（实现上叫 multiprocessing）、Ray、Docker 和 e2b。这个设计说明项目方预期的使用场景包括「让模型生成代码，然后把代码跑起来验证」，这在数学和编程类合成数据里很常见。
四种后端的安全性差异很大。local 后端直接在宿主机进程里执行模型生成的代码，只适合完全可信的来源。Docker 和 e2b 提供了隔离层，代价是启动延迟和运维复杂度。Ray 后端面向的是已有 Ray 集群的团队。选择哪一个不是性能问题，是安全边界问题，README 没有替你做这个判断。
微调闭环与它的边界
2026 年的两次更新把 Curator 往下游推了一步。3 月加入 Tinker 集成，README 给的定位是「从整理好的数据到 LoRA 微调模型只需要几行 Python」；6 月加入 Fireworks AI 的 FireworksTrainer，做托管式 SFT，README 特别说明它和 Tinker 共用同一套 trainer 接口。
这个方向意味着 Curator 不再只是数据生成工具，而是想覆盖「生成数据、微调模型、采样验证」的循环。对做小规模实验的团队，少写一层胶水代码确实省事。但接口统一也带来约束：你能调的微调超参数，取决于 trainer 抽象层暴露了什么，超出范围就得绕开这层直接用底层 SDK。
需要明确的是，这两个集成只在 README 的更新日志和 examples 目录里出现，属于较新的功能。生产环境依赖它们之前，应该先确认对应的 example 脚本在当前版本上可以跑通。
Curator 不适合的场景同样清楚。如果你只需要对几十条 prompt 做一次性探索，引入这个库的调度层是净负担。如果你的流水线需要精确控制每次采样的随机种子和调用顺序，用于可复现的对比实验，框架的并发调度会给你添麻烦。如果你的数据质量瓶颈在于 prompt 设计而非吞吐，换工具解决不了问题。
和直接写异步脚本相比，差异在哪里
最直接的替代方案是自己写 asyncio 脚本。用 aiohttp 或官方 SDK 的异步客户端，配 asyncio.Semaphore 控制并发，结果写 JSONL，加一层基于输入哈希的本地缓存。这套代码大概两三百行，完全可控，没有任何抽象层。
Curator 相对它的增量在于三处。第一是缓存和断点恢复被做成默认行为而非可选项，你自己的脚本里这通常是最后才补上的部分。第二是批处理 API 的适配，各家批处理的提交格式、轮询端点、结果下载方式都不同，Curator 把这些差异收敛到统一接口。第三是 Viewer 提供的过程可见性。
代价是调试路径变长。当一次调用返回了意料之外的结果，自写脚本里你可以直接在调用点打断点；在 Curator 里你需要先理解它的调度层在哪一层捕获了异常、缓存键是怎么算出来的、以及重试发生在哪一步。这个学习成本对小团队是真实的。
另一个方向的替代是各家云厂商自己的批量推理服务。它们同样提供半价和异步提交，但把数据准备、结果解析、格式转换留给你。Curator 的价值在于把「准备数据」和「调用模型」缝在一起，如果你已经有一套成熟的数据处理管线，这个缝合点的价值会下降。
版本、许可与长期维护成本
Curator 采用 Apache-2.0 许可。这意味着你可以商用、可以修改、可以再分发，需要保留版权声明和许可文本，修改过的文件需要标注。Apache-2.0 还包含专利授权条款，对企业用户比 MIT 更明确。以上是许可文本的通行理解，具体到你的使用方式是否合规，需要法务判断，本文不构成法律意见。
版本节奏值得注意。v0.1.25 在 2025 年 5 月，v0.1.26 在 2025 年 7 月，v0.1.27 在 2026 年 3 月。三个版本跨越约十个月，且全部停留在 0.1.x。README 的更新日志显示 2026 年 6 月还有新功能合并进主分支，也就是说主分支的活跃度高于已发布版本。这对使用者意味着：想用最新的 Fireworks 集成，可能要从源码安装而非 pip。
升级成本主要来自依赖链。Curator 依赖 LiteLLM 做模型接入，LiteLLM 本身的版本迭代很快，模型名称和参数时有变动。锁死 Curator 版本可能让你用不上新模型，放开版本又可能引入不兼容。建议在项目里固定 bespokelabs-curator 和 litellm 两个包的版本，并在升级时先跑一遍缓存未命中的完整流程。
0.1.x 的版本号本身是一个信号：API 尚未承诺稳定。把它用在一次性的数据集生成任务上风险可控，用在需要长期维护的生产流水线上，要有跟随 breaking change 的准备。
编辑结论
如果你的团队已经在写「读一批 prompt、调模型、存 JSONL」的脚本，并且被重复调用烧掉过真金白银，Curator 值得试一次：先跑 pip install bespokelabs-curator，然后用一个最小 examples 目录里的脚本验证缓存命中行为，再确认你选的推理后端是否支持 batch。如果你的需求是单次几十条 prompt 的探索性调用，或者你需要对采样逻辑做细粒度控制，Curator 的抽象层只会挡在你和 API 之间。上手前务必确认三件事：v0.1.27 与你使用的 LiteLLM 版本是否兼容、缓存目录在容器重启后是否持久化、以及批处理模式下失败请求的重试策略是否满足你的数据完整性要求。
社区笔记