TensorSharp 支持 Jev 模式了：一次去噪，直接读出决策 - 张善友
内容提要
TensorSharp 合并 PR #225，其纯 .NET 推理引擎新增 Jev 结构化读取模式，可运行 Google DiffusionGemma-26B-A4B 文本扩散模型。Jev 仅处理是/否、多选、评分等有边界问题，返回概率与置信度，不做开放式生成。相比 LocalJev 的 JSON 生成加校验重试，该方案直接从扩散模型 logits 读取答案，同硬件下快 4–5 倍，支持 HTTP 与进程内调用。
延伸解读
Jev 模式与 LocalJev 的本质差异
LocalJev 依赖普通 chat 模型生成 JSON 文本，再校验解析，格式错误则重试，延迟和不确定性被放大。TensorSharp 的 Jev 模式则利用 DiffusionGemma 的扩散特性，将答案位置固定为单 token 槽位，仅做一步去噪，直接从 logits 读取概率，不采样、不生成 JSON、不重试。这种结构差异是速度提升 4–5 倍的根本原因，而非某种优化技巧。
性能对比的适用边界
官方文档明确提醒，vLLM 原型在 DGX Spark 上、LocalJev 在 M5 Max 上公布的数据不能直接作为同硬件对比。TensorSharp 的 4–5 倍加速来自特定硬件（16GB 级 CUDA GPU、Q4_K_M 量化）和特定负载。量化位数、问题措辞、答案顺序、读取次数都会影响结果，读者需结合自身环境评估。
API 别名与模型来源的澄清
jev-latest 和 jev-preview 只是所加载 DiffusionGemma 模型的 API 别名，并非独立 checkpoint，也不是 Typesafe 的托管 Jev 模型。模板逻辑参考了 LocalJev（Apache-2.0，NOTICE 已署名），但数值上不承诺与任何实现对齐。调用方应理解这些别名仅代表本地加载的模型配置。
工程化错误处理与调用方式
服务层对错误状态码做了明确区分：schema 非法返回 422，未知模型 404，模型不可用 503，排队超限 529，请求体超限 413，避免挂起等待超时。调用既可通过 HTTP 的 /v1/systemone 接口，也可在进程内直接使用 JevAsync，后者省去网络开销。更底层还可调用 ReadStructured 自行控制 canvas，但一般无需下沉至此层级。
Q&A
TensorSharp 新增的 Jev 模式是什么？
Jev 模式是 TensorSharp 纯 .NET 推理引擎新增的一种结构化读取模式，可运行 Google DiffusionGemma-26B-A4B 文本扩散模型。它只处理有边界的结构化问题（是/否、多选、评分），返回每个答案的概率和置信度，不做开放式生成。
Jev 模式相比 LocalJev 有什么优势？
Jev 模式直接从扩散模型的 logits 读取答案，不采样、不生成 JSON、不重试，因此同硬件下比 LocalJev 快 4–5 倍。LocalJev 需要让普通 chat 模型把概率值当 JSON 文本生成，然后校验、解析，格式不对就重试，开销大且延迟高。
Jev 模式支持哪些类型的问题？
Jev 模式支持有边界的结构化问题：是/否（noul）、多选（choice）、评分（score）。调用方提供一段状态（state）和一组带类型的问题，模型返回每个答案的概率和置信度。
如何在 TensorSharp 中调用 Jev 模式？
可以通过 HTTP 或进程内调用。HTTP 方式：向 /v1/systemone 发送 POST 请求，请求体包含 model、state、questions 等字段。进程内方式：使用 TensorSharp.Chat 的 JevAsync 方法，加载模型后调用 service.JevAsync(JevRequest.Parse(...))。
Jev 模式返回的结果包含哪些信息？
返回结果中，每个问题的答案以概率和置信度形式给出。例如对于是/否问题，answers.billing.noul 就是“是计费问题”的概率。
Jev 模式有哪些错误处理机制？
Jev 模式提供了工程化的错误处理：schema 非法返回 422，未知模型返回 404，模型不可用返回 503，排队超限返回 529，请求体超限返回 413，不会出现挂着等超时的情况。
