Jev 对比 Kev
Kev 是一系列讲相同 /v1/systemone 契约的小型决策模型家族，Apache-2.0 — 由你托管。Jev 是托管的。相同的请求形态，权重与运维的归属不同。独立托管网关；非 TypeSafe 官方网站。
Kev 是什么
Kev 出自 Jared Palmer，把 Qwen 基础模型微调成具备相同问题类型的决策模型。已公布的尺寸从能在 Apple Silicon Mac 上运行的 0.8B 到更大的 GPU 检查点，且每个检查点都附一个拟合好的 temperature。其服务端讲 System One 请求形态，所以现有客户端只需换 base URL、负载原样保留。
相同的请求，你的机器
请求体可以一模一样：一个 state，加上 choice、score 与 yes/no 问题，返回的是一个分布。变的是它周围的一切：你要钉住并打补丁的模型版本、你要保持温热的 GPU、每次升级都要复核的校准，以及绝不离开你辖区的数据路径。这是真实的控制，也伴随一张真实的运维账单。
成本与规模
硬件跑起来之后，自托管 Kev 几乎是每次调用免费；它赢在高而平稳的量、物理隔离要求或纯 Mac 机队。托管路径则按用量 — 1 积分 = 1,000 输入 token，$10 得 100,000 永不过期的积分 — 并把版本、容量与故障行为交给 Optio。你的 bug 清单换了形状：不再与服务栈较劲，而是打磨 criteria 与阈值。
何时选哪个
当“自己控制的硬件上跑这种请求形态”就是需求本身时，选 Kev。当你想对着托管 Jev 使用同一种请求形态 — key、预付积分、零 GPU — 且宁愿把工程时间花在决定 criteria 写什么、而不是让决策服务器活着时，通过 Optio 选 Jev。
优势与诚实的局限
Jev 的诚实局限：你无法改它的权重、也无法把它跑在自己的机器上 — 这是产品约束，不是技术约束。Kev 的另一面：钉住一个检查点也是冻结它。决定你更愿意承担哪种风险 — 依赖一个托管端点，还是依赖自己的服务栈保持校准。
快速对比
| 对比项 | Jev | Jev 对比 Kev |
|---|---|---|
| 权重 | 专有，经 Optio 端点 | Apache-2.0 检查点，0.8B 起 |
| 硬件 | 无 | Apple Silicon 或你的 GPU |
| 运维 | 无 — 端点、key、积分 | 部署、版本、校准核查 |
| 成本形态 | 按用量：1 积分 ≈ 1,000 输入 token | 硬件 + 你的时间；边际成本近零 |
常见问题
- 能把现有的 Jev 客户端指向 Kev 吗？
- 通常可以 — Kev 讲相同的 /v1/systemone 请求契约，负载基本原样可用。但答案会不同，因为权重不同：在信任它之前，先在你的案例上重新验证、重新拟合阈值。
- Kev 和 Jev 质量相当吗？
- 不一定 — 不同模型、不同训练。0.8B 的 Kev 用质量换硬件成本；用你自己十案例的验证集评判两者，而不是听任何一方网站上的说法。
- 按一整年算哪个更便宜？
- 高且平稳的量选 Kev — 摊销它的 GPU 和你的运维时间。低量或抖动量、或团队里没人愿意运维模型时，用积分付 Jev。
- 这是 Jev 官方网站吗？
- 不是。Optio 是一个独立运营的 Jev 调用网关，与 TypeSafe 无关联、未经其认可，也不是其官方产品，亦与本页提到的任何替代模型无关联。