目录先说 Jev 是什么TensorSharp 里是怎么落地的怎么调HTTP原生 .NET接口能干什么为什么快 4–5 倍哪些事它明确不做相关链接2026年9月22日 vLLM 合并了 PR #57250给 DiffusionGemma 加了一种 Jev 风格的结构化读取模式。我们跟得很快TensorSharp PR #225 今天也合并了纯 .NET 原生推理引擎现在可以直接跑 Jev 模式模型用的是 Google 的 DiffusionGemma-26B-A4B26B 总参数、约 3.8B 激活的 MoE 文本扩散模型。HTTP 和原生 .NET 代码都能调接口兼容 Jev 的 systemone 协议同硬件对比 LocalJev 快了 4–5 倍。先说 Jev 是什么Jev 是 Typesafe.ai 提的一条决策模型路线不做开放式生成只回答有边界的结构化问题是/否Jev 里叫 noul、多选、评分。调用方给一段状态state加一组带类型的问题模型返回每个答案的概率和置信度。本地能跑的开源实现是 GitHub Next 的 LocalJev。它的做法是让普通 chat 模型把概率值当 JSON 文本生成出来然后校验、解析格式不对就重试。能跑通但为几个数字要扛下整条生成管线的开销——逐 token 自回归、JSON 语法风险、解析失败重试延迟和不确定性都被放大了。DiffusionGemma 这类文本扩散模型给了另一条路它的输出本来就是一个可以预先固定住大部分 token 的 canvas。vLLM PR #57250 的思路很直接——把答案位置留成单 token 的槽位只做一步去噪从收敛步的 logits 里读出各候选标签的概率。不采样不生成 JSON不重试。PR 作者的原话是DiffusionGemma 可以被当成一台经过校准的选择题机器。TensorSharp 里是怎么落地的PR #225 一次提交了 40 个文件、4173 行核心几块TensorSharp.Chat/Jev/请求解析校验JevRequest、模板编译JevCompiler、并发门控JevExecutionGate、推理调度JevInferencePOST /v1/systemoneHTTP 端点Jev 兼容协议适配器和同一服务器上的普通 chat 端点共存DiffusionGemmaModel.ReadStructured(...)低层 API构造答案 canvas单步读取指定标签的 logits稀疏输出投影只算答案位置和请求词汇行的 logits不再分配完整的 canvas×词表张量一整套基准和对比工具eng/jev-benchmark.py、eng/jev-localjev-compare.ts等外加 293 行的文档docs/models/jev.md。两点澄清jev-latest/jev-preview只是所加载 DiffusionGemma 模型的 API 别名不是独立 checkpoint更不是 Typesafe 的托管 Jev 模型模板逻辑参考了 LocalJevApache-2.0NOTICE 里已署名但数值上和谁都不承诺对齐。怎么调HTTP启动Q4_K_M 量化 CUDA 为例$env:TENSORSHARP_MODELS C:/Works/models $env:DIFFUSION_VRAM_HEADROOM_MB 4096 $env:MAX_CONTEXT 4096 dotnet run --project TensorSharp.Server.Host -c Release ----config config/jev-diffusiongemma-q4.json一条 curl 就行curl http://127.0.0.1:5000/v1/systemone \ -HContent-Type: application/json\ --data-binary docs/examples/jev-ticket.json最小请求{ model:jev-latest, state:I was charged twice for the same subscription this month., questions:{ billing:{ type:noul,instructions:Is this a billing issue? } }, samples:1, seed:42 }返回里answers.billing.noul就是是计费问题的概率。原生 .NET引用TensorSharp.Chat进程内直接调不过 HTTPusingSystem.Text.Json; usingTensorSharp.Server; usingTensorSharp.Server.Jev; usingvar service newModelService(); service.LoadModel(C:/Works/models/diffusiongemma-26B-A4B-it-Q4_K_M.gguf, mmProjPath:null,backendStr:ggml_cuda); usingvar json JsonDocument.Parse(File.ReadAllText(docs/examples/jev-ticket.json)); object response await service.JevAsync(JevRequest.Parse(json.RootElement)); Console.WriteLine(JsonSerializer.Serialize(response));想再底层一点可以直接用DiffusionGemmaModel.ReadStructured(promptTokens, seedCanvas, positions, tokenIds)自己控制 canvas服务层帮你处理分词、模板渲染、上下文检查、canvas 构造、序列化和生命周期安全一般用不着下沉到这个层级。接口能干什么能力说明问题类型noul布尔、choice多选、score评分返回概率加权期望规模上限单请求最多 64 个问题每题 2–26 个候选项多次读取samples1–32 次独立 seeded 读取取平均auto模式下条件熵超阈值自动追加读取上限 32分块超出 canvas 宽度的 schema 按chunk_rows分块多题共享一次 transformer 前向复用多次读取复用同一份 prompt K/VGGML CUDA / Metal 开启 prompt cache 时错误处理比较工程化schema 非法返回 422未知模型 404模型不可用 503排队超限 529请求体超限 413不会出现挂着等超时的情况。为什么快 4–5 倍和 LocalJev 的对照测试里相同 state、相同问题集对比工具会把 LocalJev 的提示词构造、推理、JSON 校验和重试全部计入耗时TensorSharp 快了大约 4–5 倍。这个差距是结构带来的不是某个黑科技不做生成只做读取。LocalJev 让模型把概率 JSON 写出来TensorSharp 在一步去噪后从 logits 里直接读——数学上等价于从完整词表分布里取出相同标签再归一化但整条解码循环省掉了。稀疏输出投影。输出头只算请求的标签行显存和算力都花在刀刃上。无解析、无重试。LocalJev 要为格式错误的 JSON 付重试成本这条路径上没有这个故障模式。prompt K/V 复用。自适应多次读取共享同一份前缀缓存追加读取的边际成本很低。前提也要交代清楚数字来自特定硬件16GB 级 CUDA GPU、Q4_K_M 量化和特定负载。官方文档专门提醒过vLLM 原型在 DGX Spark 上公布的数据、LocalJev 在 M5 Max 上公布的数据都不能直接拿来当同硬件对比。量化位数、问题措辞、答案顺序、读取次数都会影响结果。哪些事它明确不做只支持单 token 标签。候选项必须映射到单 tokenmoderation_spam → A 这种变换由编译器自动完成并校验多 token 候选项、图片输入、问题间依赖链、多步去噪、think 模式一律显式拒绝。置信度不是校准过的正确率。返回的是条件概率和熵诊断建议在自己的留出样本上评估后再定阈值。可复现性以运行时为界。seed 保证同一 .NET 运行时/后端下可重复不承诺和 Python 噪声逐位一致。普通 chat 端点不受影响。Jev 请求和普通扩散 chat 共享模型执行锁串行调度同机混部是安全的。相关链接TensorSharp PRhttps://github.com/zhongkaifu/TensorSharp/pull/225完整文档docs/models/jev.md请求字段表、概率语义、基准方法都在里面模型 checkpointgoogle/diffusiongemma-26B-A4B-itApache-2.0社区 Q4_K_M GGUF 首次启动自动下载灵感来源vLLM PR #57250https://github.com/vllm-project/vllm/pull/57250 从让模型写 JSON到从 logits 里读答案Jev 模式做的事其实就一件把决策问题还原成它本来的样子——有边界的概率读取。vLLM 开了头TensorSharp 把这条路在 .NET 生态里走通了。本来就在用 C# 做本地推理的同学现在一条 HTTP 请求或者一个JevAsync调用就能在本地放一台毫秒级响应的决策引擎。引入地址 TensorSharp 支持 Jev 模式了：一次去噪，直接读出决策
目录先说 Jev 是什么TensorSharp 里是怎么落地的怎么调HTTP原生 .NET接口能干什么为什么快 4–5 倍哪些事它明确不做相关链接2026年9月22日 vLLM 合并了 PR #57250给 DiffusionGemma 加了一种 Jev 风格的结构化读取模式。我们跟得很快TensorSharp PR #225 今天也合并了纯 .NET 原生推理引擎现在可以直接跑 Jev 模式模型用的是 Google 的 DiffusionGemma-26B-A4B26B 总参数、约 3.8B 激活的 MoE 文本扩散模型。HTTP 和原生 .NET 代码都能调接口兼容 Jev 的 systemone 协议同硬件对比 LocalJev 快了 4–5 倍。先说 Jev 是什么Jev 是 Typesafe.ai 提的一条决策模型路线不做开放式生成只回答有边界的结构化问题是/否Jev 里叫 noul、多选、评分。调用方给一段状态state加一组带类型的问题模型返回每个答案的概率和置信度。本地能跑的开源实现是 GitHub Next 的 LocalJev。它的做法是让普通 chat 模型把概率值当 JSON 文本生成出来然后校验、解析格式不对就重试。能跑通但为几个数字要扛下整条生成管线的开销——逐 token 自回归、JSON 语法风险、解析失败重试延迟和不确定性都被放大了。DiffusionGemma 这类文本扩散模型给了另一条路它的输出本来就是一个可以预先固定住大部分 token 的 canvas。vLLM PR #57250 的思路很直接——把答案位置留成单 token 的槽位只做一步去噪从收敛步的 logits 里读出各候选标签的概率。不采样不生成 JSON不重试。PR 作者的原话是DiffusionGemma 可以被当成一台经过校准的选择题机器。TensorSharp 里是怎么落地的PR #225 一次提交了 40 个文件、4173 行核心几块TensorSharp.Chat/Jev/请求解析校验JevRequest、模板编译JevCompiler、并发门控JevExecutionGate、推理调度JevInferencePOST /v1/systemoneHTTP 端点Jev 兼容协议适配器和同一服务器上的普通 chat 端点共存DiffusionGemmaModel.ReadStructured(...)低层 API构造答案 canvas单步读取指定标签的 logits稀疏输出投影只算答案位置和请求词汇行的 logits不再分配完整的 canvas×词表张量一整套基准和对比工具eng/jev-benchmark.py、eng/jev-localjev-compare.ts等外加 293 行的文档docs/models/jev.md。两点澄清jev-latest/jev-preview只是所加载 DiffusionGemma 模型的 API 别名不是独立 checkpoint更不是 Typesafe 的托管 Jev 模型模板逻辑参考了 LocalJevApache-2.0NOTICE 里已署名但数值上和谁都不承诺对齐。怎么调HTTP启动Q4_K_M 量化 CUDA 为例$env:TENSORSHARP_MODELS C:/Works/models $env:DIFFUSION_VRAM_HEADROOM_MB 4096 $env:MAX_CONTEXT 4096 dotnet run --project TensorSharp.Server.Host -c Release ----config config/jev-diffusiongemma-q4.json一条 curl 就行curl http://127.0.0.1:5000/v1/systemone \ -HContent-Type: application/json\ --data-binary docs/examples/jev-ticket.json最小请求{ model:jev-latest, state:I was charged twice for the same subscription this month., questions:{ billing:{ type:noul,instructions:Is this a billing issue? } }, samples:1, seed:42 }返回里answers.billing.noul就是是计费问题的概率。原生 .NET引用TensorSharp.Chat进程内直接调不过 HTTPusingSystem.Text.Json; usingTensorSharp.Server; usingTensorSharp.Server.Jev; usingvar service newModelService(); service.LoadModel(C:/Works/models/diffusiongemma-26B-A4B-it-Q4_K_M.gguf, mmProjPath:null,backendStr:ggml_cuda); usingvar json JsonDocument.Parse(File.ReadAllText(docs/examples/jev-ticket.json)); object response await service.JevAsync(JevRequest.Parse(json.RootElement)); Console.WriteLine(JsonSerializer.Serialize(response));想再底层一点可以直接用DiffusionGemmaModel.ReadStructured(promptTokens, seedCanvas, positions, tokenIds)自己控制 canvas服务层帮你处理分词、模板渲染、上下文检查、canvas 构造、序列化和生命周期安全一般用不着下沉到这个层级。接口能干什么能力说明问题类型noul布尔、choice多选、score评分返回概率加权期望规模上限单请求最多 64 个问题每题 2–26 个候选项多次读取samples1–32 次独立 seeded 读取取平均auto模式下条件熵超阈值自动追加读取上限 32分块超出 canvas 宽度的 schema 按chunk_rows分块多题共享一次 transformer 前向复用多次读取复用同一份 prompt K/VGGML CUDA / Metal 开启 prompt cache 时错误处理比较工程化schema 非法返回 422未知模型 404模型不可用 503排队超限 529请求体超限 413不会出现挂着等超时的情况。为什么快 4–5 倍和 LocalJev 的对照测试里相同 state、相同问题集对比工具会把 LocalJev 的提示词构造、推理、JSON 校验和重试全部计入耗时TensorSharp 快了大约 4–5 倍。这个差距是结构带来的不是某个黑科技不做生成只做读取。LocalJev 让模型把概率 JSON 写出来TensorSharp 在一步去噪后从 logits 里直接读——数学上等价于从完整词表分布里取出相同标签再归一化但整条解码循环省掉了。稀疏输出投影。输出头只算请求的标签行显存和算力都花在刀刃上。无解析、无重试。LocalJev 要为格式错误的 JSON 付重试成本这条路径上没有这个故障模式。prompt K/V 复用。自适应多次读取共享同一份前缀缓存追加读取的边际成本很低。前提也要交代清楚数字来自特定硬件16GB 级 CUDA GPU、Q4_K_M 量化和特定负载。官方文档专门提醒过vLLM 原型在 DGX Spark 上公布的数据、LocalJev 在 M5 Max 上公布的数据都不能直接拿来当同硬件对比。量化位数、问题措辞、答案顺序、读取次数都会影响结果。哪些事它明确不做只支持单 token 标签。候选项必须映射到单 tokenmoderation_spam → A 这种变换由编译器自动完成并校验多 token 候选项、图片输入、问题间依赖链、多步去噪、think 模式一律显式拒绝。置信度不是校准过的正确率。返回的是条件概率和熵诊断建议在自己的留出样本上评估后再定阈值。可复现性以运行时为界。seed 保证同一 .NET 运行时/后端下可重复不承诺和 Python 噪声逐位一致。普通 chat 端点不受影响。Jev 请求和普通扩散 chat 共享模型执行锁串行调度同机混部是安全的。相关链接TensorSharp PRhttps://github.com/zhongkaifu/TensorSharp/pull/225完整文档docs/models/jev.md请求字段表、概率语义、基准方法都在里面模型 checkpointgoogle/diffusiongemma-26B-A4B-itApache-2.0社区 Q4_K_M GGUF 首次启动自动下载灵感来源vLLM PR #57250https://github.com/vllm-project/vllm/pull/57250 从让模型写 JSON到从 logits 里读答案Jev 模式做的事其实就一件把决策问题还原成它本来的样子——有边界的概率读取。vLLM 开了头TensorSharp 把这条路在 .NET 生态里走通了。本来就在用 C# 做本地推理的同学现在一条 HTTP 请求或者一个JevAsync调用就能在本地放一台毫秒级响应的决策引擎。引入地址