综合分
Jev
74.4 · 第 1 名
OpenJev
66.4 · 第 11 名
JevBench 可提供背景参考，迁移仍应由自己的答案质量和延迟测试决定。
迁移简报 · JevBench v1.3.0
请求格式可以相似，运行方式却完全不同。
OpenJev 尝试兼容 TypeSafe 请求格式，同时把推理迁移到你能控制的环境。
因此初始接入可能很小，生产迁移却不一定简单。请重新验证图像能力、选项数量、置信度行为，以及谁来负责模型运维。
集成检查点
请求兼容只是迁移测试的起点
两者的请求形态相似，但能力边界和运维行为不同。应测试应用当前依赖的每一项假设。
校准分数
Jev
82.7
OpenJev
64.8
响应字段兼容，不代表可以继续使用同一个置信度阈值。
输入能力
Jev
文本及结构化文本
OpenJev
最多 8 张图像
OpenJev 支持视觉输入；Jev 聚焦文本和结构化文本。
检查请求契约的边缘情况
迁移风险往往藏在正常路径之外的假设中。
01
现有 SDK 请求格式已经满足业务需求。
OpenJev 可减少改动兼容接口有机会减少客户端修改；仍应为应用使用的每个响应字段补上契约测试。
02
需要图片输入，或希望在自己的硬件上运行。
OpenJev 支持这些选项它接受图像输入并支持本地部署，但仍受文档中的硬件和选项上限约束。
03
置信度会控制阈值判断或升级策略。
切换前重新校准置信度的生成机制不同。实际触发动作前，应在留出数据上重新拟合阈值。
切换接口后，哪些东西也变了？
保留请求形态，重新评估围绕它的全部假设。
Jev · 托管 API
服务提供方负责容量与模型版本
应用发送文本或结构化文本，并从托管生产服务中获得类型化答案。
- 无需运维 GPU、推理服务器或本地模型升级。
- Jev 只处理文本，choice 问题最多支持 255 个选项。
OpenJev · 自托管或经 Codiv 使用
更多部署控制权，也意味着服务责任
OpenJev 围绕 DiffusionGemma 构建，支持 vLLM 或 MLX。部署位置由你决定，资源容量和更新周期也由你负责。
- 当前 vLLM 镜像调整了上游 token 限制；可用选项数应以所选后端和模型配置为准。
- 公开部署建议为 24GB GPU，或至少预留约 16GB 的 Apple Silicon 内存。
修改 Base URL 之前
针对 SDK 兼容切换的一份回归检查单。
- 请求格式
- JevPOST /v1/systemone
- OpenJev请求格式兼容，并接受 Jev 别名
- Choice 选项
- Jev最多 255 个
- OpenJev按所选后端和模型配置确认
- 置信度
- JevJevBench 校准分数 82.7
- OpenJev基于熵计算；JevBench 校准分数 64.8
- 托管方式
- Jev托管 API
- OpenJev通过 vLLM 或 MLX 自托管；也可经 Codiv 使用
数据来源与范围
这里的 OpenJev 指 razorback16 基于 DiffusionGemma 的项目，与 TypeSafe 无关联。JevBench 分数对应榜单中的发布配置；迁移前请再次核对仓库和部署要求。