TensorSharp 新增结构化决策接口，基于 DiffusionGemma 直接读取 logits

TensorSharp 开发者宣布在该推理框架中新增并优化了原生 /v1/systemone 接口，用于基于 DiffusionGemma GGUF 权重的「Jev 风格」结构化决策。这里的「Jev 风格」指 API 与决策工作流模式，而非特定模型。其主要实现差异在于：TensorSharp 直接读取请求标签对应的 logits，而不是要求模型先以 JSON 形式输出概率。作者在小型基准上将其与原始 LocalJev 引擎做了对比。

基准对比概览

测试覆盖 12 个用例 × 3 次重复，每次请求 3 项决策，即每个实现各执行 36 次请求、108 个期望决策。延迟统计仅包含成功请求，因此不同列的样本子集并不完全一致。下面 3.345× 这一比值，来自配对成功请求的中位数之比，并非简单用聚合均值或中位数相除。

TensorSharp 原生 /v1/systemone：36/36 请求成功，0 失败，108/108 决策正确。
原始 LocalJev 引擎：27/36 请求成功，9 次因 schema 校验失败返回 HTTP 422，81/108 决策正确（其中有效响应下 81/81 正确）。
在两次都成功的 27 对配对请求中，LocalJev 延迟中位数与 TensorSharp 延迟中位数之比为 3.345×。

关键延迟数据：

p50：TensorSharp 2.877 秒，LocalJev 10.479 秒。
p95：TensorSharp 3.165 秒，LocalJev 26.167 秒。
均值：TensorSharp 2.917 秒，LocalJev 12.548 秒。

需要指出的是，平均输入长度差异明显：TensorSharp 端为 192.7 tokens，LocalJev 有效请求为 589.6 tokens，原因是后者需要构造更大的对话提示并让模型生成概率 JSON，因此该比较属于端到端方案对比，而非同提示、同内核的纯粹性能测试。

逐用例表现

下列延迟为 3 次重复的中位数，LocalJev 仅列出有效请求的数据。

billing-calm：TensorSharp 3.051 秒，LocalJev 8.135 秒，0/3 失败。
outage-angry：TensorSharp 3.152 秒，LocalJev 3/3 失败（HTTP 422）。
sales-polite：TensorSharp 3.142 秒，LocalJev 10.479 秒，0/3 失败。
payment-immediate：TensorSharp 3.117 秒，LocalJev 8.060 秒，0/3 失败。
bug-calm：TensorSharp 3.164 秒，LocalJev 11.624 秒，0/3 失败。
sales-angry：TensorSharp 3.118 秒，LocalJev 10.347 秒，0/3 失败。
red-small-circle：TensorSharp 2.686 秒，LocalJev 3/3 失败。
blue-large-square：TensorSharp 2.745 秒，LocalJev 3/3 失败。
green-medium-circle：TensorSharp 2.692 秒，LocalJev 7.657 秒，0/3 失败。
red-large-square：TensorSharp 2.697 秒，LocalJev 26.182 秒，0/3 失败。
blue-medium-circle：TensorSharp 2.723 秒，LocalJev 14.564 秒，0/3 失败。
green-small-square：TensorSharp 2.742 秒，LocalJev 15.782 秒，0/3 失败。

LocalJev 在 outage-angry、red-small-circle、blue-large-square 三个用例的三次重复中均失败，原因为生成内容不满足所请求的 JSON schema。服务端配置的 256 token 输出上限未被触发，有效响应大约只用到 60 个输出 token，因此不存在因长度限制截断的情况。

使用方式

按照常规方式加载 DiffusionGemma GGUF 模型并启动 TensorSharp.Server.Host 之后，可向 POST http://127.0.0.1:5000/v1/systemone 发送 Jev 格式请求。仓库根目录的 docs/examples/jev-ticket.json 提供了示例请求体，可通过 curl 调用；同时也支持直接通过 .NET 端的 ModelService.JevAsync 在进程内调用。该方式的作者认为意义在于：用本地模型做有界决策时，不必先让模型写出 JSON 答案，从而在该工作负载上同时获得速度提升并规避生成式方案的结构化失败。