我将 Qwen3.8-27B Q2_64 + llama.cpp 转换为一个完全 TypeSafe AI 兼容的 Jev 风格系统。OpenAI API 仍然完整！全球首个支持视觉的 Jev 风格模型！显存占用低于 10 GB，在 RTX 3090 上延迟 170 毫秒，聊天速度约 140 tok/s。在包含 22,000 个请求的多样化类型决策基准测试中，准确率为 76%，而 Jev-1.13 为 88%。

昨天我发布了 Bonsai-Llama-Jev——一个用于本地操作、自主 AI 的 Jev 风格类型决策推理系统。在我的新类型决策基准测试中，涵盖 175 个用例的超过 22,000 个决策，它目前是我测试过的最强开源系统，软准确率约为 76%，而 Jev-1.13 约为 88%，超越了 Von-1.1、Laya 甚至 Qwen3.5-4B（最佳 OpenJev 变体）。完整基准测试结果可在此处查看。同时，Bonsai-Llama-Jev 在我看来是帕累托最优的，考虑显存使用和延迟：<10 GB 显存，包括 KV 缓存和视觉投影器，中位延迟约 171 毫秒，相比 Jev 的 716 毫秒中位延迟快约 4 倍——同时在本地运行。在我测试的开源系统中，它还实现了最低的校准误差（ECE-15）——仅 13%，而 Jev 为 8.4%！这来自我发现的新的事后模型校准方法，使用我的 VAE 自动研究工具。它发现了这个数学技巧，然后我立即想理解并应用它。我提出了 `calibration.json` 标准，用于对在 Jev 风格推理设置中使用的开源模型进行事后校准。我将所有内容——校准方法、实验结果以及其原理——写入了我的校准论文中。与开源模型竞争对手的一些对比数据：比 Laya 高 +29.8 个百分点（它速度快，但在多样化基准测试中表现不佳，且校准很差）比 Von-1.1 高 +27.9 个百分点（在多样化基准测试中比 Laya 好 2%，校准也非常差）比 OpenJev / SemIf-Qwen3.5-4B 高 +2.3 个百分点（它是一个好模型！校准也很好！但不适合在单个本地 GPU 上与 27B 模型并行运行！）现在 Bonsai-Llama-Jev 能做所有事情，并且做得很好！在准确率上仅比 Jev-1.13 落后 11.6 个百分点！据我所知，这也是首个具有多模态类型决策的开源 Jev 风格设置：你可以不仅从文本/JSON，还可以直接从图像 + 文本/JSON 做出结构化决策。为此，我在保持完全兼容性的同时扩展了 System One API 标准（参见我的仓库和深度链接；我尽量不重新发明轮子。"state" 字段在这里变为 JSON，并适应了 llama.cpp/OpenAI 标准用于 base64 和基于 URL 的图像传输）。最让我感兴趣的部分——可能对这里的许多人最相关——是这个 llama.cpp 分支的统一架构：本地上，我们通常无法并行运行许多不同的 AI 模型，对吧？所以我取了 PrismLM 的 llama.cpp 分支作为推理引擎，并直接在其中实现了 TypeSafe AI 的 OpenAPI 指定的 System One API。具体来说，我只添加了端点及其背后的推理数学：POST /v1/systemone，以及现有的 OpenAI 兼容和 llama.cpp 原生端点。结果现在通过所有官方 TypeSafe Python 和 JavaScript SDK 进行端到端测试，并且它只是工作！顺便说一下，typed-decisions-bench 是最好的测试——它以大规模并行方式对端点发送 22k 请求，从未崩溃！延迟包括我测量的 HTTP 网络延迟。所以，与其本地操作几个专用模型，你现在可以运行一个统一且相对小但功能强大的模型！在 RTX 5090 上，它仍然提供约 143 tok/s 的聊天完成速度，同时作为一个强大的类型决策引擎并支持视觉。关于历史：为了实现这一点，我尝试了不同的骨干方法，从上周末的周五开始。首先，我构建了一个基于 mmBERT 的模型，使用自己的微调，达到了约 55% 的软准确率——比 Laya 好一点，但比 Von-1.1 差。老实说，不是很好。然后我尝试了 Spark-X2.5——它也包含在我的基准测试中。那已经比 Laya 和 Von-1.1 强，但仍然比 Qwen3.5-4B（OpenJev 等）弱。最终，我尝试了 PrismML 的 Bonsai-2-27B 作为语言模型骨干，并被震撼了。校准好得多。准确率稍高。对于一个 27B 的稠密模型来说非常快！并且显存占用仅 9250 MB，超小！它实际上是 PrismML 的 Q2_64 量化下的 Qwen3.8-27B。PrismML 使用了一些黑魔法 QAT 与专有数据集，保留了未量化 Qwen3.8-27B 稠密模型约 98% 的性能。在我的 RTX 3090 上，它仍然能以 100+ tok/s 的峰值速度运行。所以我认为这对我们的所有本地部署都非常有效！我还发表了两篇论文，涵盖了我所学的内容（是的，AI 帮助我处理公式和证明，但我是手动完成艰苦工作的！这里没有幻觉胡说，即使这些论文超级长。如果我犯了错误或夸大其词，请纠正我。我追求知识诚实！我做这些很多是为了学习并与大家分享）：如何将现有推理引擎转变为类型决策引擎基准测试、事后校准方法及其原理所以你们现在都可以重现并反驳我的工作！我目前在做的下一件事是微调这些模型（我有一个巨大的未发布数据集，因为一个突然的想法，关于一种新的确定性迁移数据集生成方法（我可能会在 HF 发布后几天发帖）。仅 700k 的样本就大幅提升了我微小的 mmBERT，我相信这几乎是自切片面包以来最酷的技巧；)... 顺便说一点。RLCD 被高估了，伙计们！使用 CE 作为主要损失，同时关注 Brier+NLL；它更便宜也更有效！此外，MiCA 有帮助，但仅在模型已经饱和时。在校准方面，我们可以大幅改进我的事后校准。我们只需要使基准测试更大，并且不仅看 Qtype 分层，还要看更细微的箱！当推理引擎应用针对生成的 `calibration.json` 数据的温度缩放时，这将改进我们所有开源模型的校准！推理引擎应该实现这个——我已经实现的简单变体已经帮助提高了几个百分点！然后还有我想到的无数其他想法...这将是迷人的时代！我们目前看到另一场 AI 革命的开始！我甚至无法再睡觉了..所以请伙计们，试试我的推理引擎！告诉我它对你效果如何。我目前只在 Linux/CUDA 上测试过。我还没有时间优化 ROCm 和 MLX。请帮助我让这对每个人都完美运行！也对使用 Windows 的人！请帮助我改进基准测试！大多数为类型决策模型发布的基准测试适用于非常不多样化的小能力集，样本很少（统计上不相关！），或者通过应用已建立的基准测试在回复中测试——这基本上意味着测试大量的技术指标，大多数人在现实世界用例中很少会觉得有用。但我的基准测试专注于真实世界的现实用例。它是合成的，但我使用 GPT-6 Astra 在 Pro 模式下深入研究了能力集，并用我的经验（20 多年在这个领域）进行了检查。我相信这不是一个愚蠢的回形针基准测试；但这里也..请纠正我并帮助我改进！我们需要更多真实用例。这对事后校准也很重要！（让 Jev 风格的模型不要那么过度自信或不自信——但是针对真实世界用例！）最后但同样重要的是..请，有人能用这个做一个如此酷的 DOOM 视频吗？:D 我承诺我会到处分享！链接 Bonsai-Llama-Jev: kyr0/Bonsai-Llama-Jev typed-decision-bench: kyr0/typed-decision-bench 基准测试结果：https://kyr0.github.io/typed-decision-bench/ 类型决策引擎论文：https://kyr0.github.io/Bonsai-Llama-Jev/ 校准论文：https://kyr0.github.io/typed-decision-bench/paper/ 设置基本上是：git clone https://github.com/kyr0/Bonsai-Llama-Jev cd Bonsai-Llama-Jev make setup 然后它就运行了。声明：AI 帮助我格式化了这个帖子（我不是母语为英语的人），但这里没有任何幻觉