JoyFox 把 JEV 装进了 0.8B 千问：一个值得自己部署的决策模型

一张客服工单进来，系统要决定交给谁、是否涉及退款、紧急程度有多高。为了这三个判断，让大模型先写一段话，再从文字里抠出答案，并不总是合适。

JoyFox 发布的 Qwen3.5-0.8B-JEV，做的是另一种取舍：保留千问的小模型文本骨干，把输出端换成专门的决策头，直接返回候选项的概率。它值得推荐的地方，是让这种决策能力变成了可以下载、检查和自行部署的模型，而不只是一个远程接口。[1][2]

JoyFox Qwen3.5-0.8B-JEV：从文本状态到候选决策

它学的是 JEV 的判断方式，不是聊天口吻

这个模型的底座是 Qwen3.5-0.8B，评测所对照的教师版本是 typesafe/jev-1.13-20260917。它是 JoyFox 发布的独立衍生模型，模型卡明确说明，与 TypeSafe、JEV 和千问团队没有隶属或背书关系。[1]

输入分成三部分：当前状态、要问的问题、允许选择的候选项。比如“客户说被重复扣款”，问题是“交给哪个团队”，候选项可以是账务、账号、技术支持。候选项由业务在调用时提供，不必提前把所有标签固定在一个分类器里。[2]

输出支持三类问题。choice 在候选项中做选择；noul 给出真假两项的概率；score 对有序等级给出概率分布，同时计算期望分数和最可能等级。它不负责写回复，也不直接执行退款。[2]

这一区别很实用：业务拿到的是明确的选项 ID 和数值，可以接路由、排序、分流和人工复核。至于这个选择对不对，仍然需要另外验证。格式正确和判断正确，是两件事。

小模型真正改动的地方，在输出端

普通语言模型的输出围绕“下一个 token”展开。JoyFox 的推理实现读取问题末尾与候选项末尾的隐藏状态，分别投影成 query 和 key，以点积计算各候选项的分数，再经 softmax 变成概率。[2]

配置中的文本隐藏维度为 1,024，决策投影维度为 128。按代码里的两个线性层计算，决策头共有 262,400 个参数。增加候选项，增加的是待编码的文本，不是为每个新业务标签添一套分类权重。[2][3]

文本骨干与决策头的计算路径

模型按问题拆成独立的行执行。每一行都包含状态、问题和该问题的候选项，不读取其他问题的候选内容。这让多问题调用的边界清楚，但共享状态也会被重复计算；“一次提交多个问题”不等于“状态只算一次”。当前实现关闭 KV cache。[2]

发布物移除了原先的语言生成头、视觉塔和 MTP 组件。因此，它不是完整千问聊天模型的另一个名字，也不能因为底座曾有视觉能力，就说这个版本会看图。当前发布物只处理文本。[1]

蒸馏的价值，是把“犹豫程度”也学下来

只学习硬标签时，学生看到的是“选账务”。学习软分布时，它还能看到教师对几个候选项的相对偏好。两个问题即使最终都选账务，一个非常明确、另一个存在歧义，训练信号也可以不同。

JoyFox 的模型卡把目标描述为学习完整概率分布，并给出交叉熵与 Brier 距离两种参考目标：前者关注目标分布下的对数损失，后者度量两个概率向量的平方差。[1]

这里有一个重要的公开边界：模型卡没有给出完整训练集规模、学习率、训练步数、训练 GPU 型号、训练总时长，也没有交代两种目标在实际训练中的组合权重。公开推理仓库不是完整训练流水线。可以解释蒸馏机制，不能据此编出一套已经复现的训练配方。[1][2]

如果团队要沿着这条路线继续训练，我建议把数据准备分成两条线：一条收集教师的完整概率分布，用于学习决策；另一条保留真实业务结果和人工标签，专门检验错误、校准概率、选择拒答阈值。模型选择也不要反复使用最终测试集。这是复现与改进建议，不是对 JoyFox 已执行步骤的推断。

90.40% 到底证明了什么

作者披露的评测包含 30,612 条记录、52,664 个问题。模型与教师最高概率选项的一致率为 90.40%。平均 KL 散度是 0.07373，Brier 距离是 0.03520，等级期望分数 MAE 是 0.16246。[1]

这些数值衡量的是“学生有多像教师”。它们没有回答“谁更接近真实业务答案”。评测数据由教师生成，而且参与过模型选择，没有人工核验的硬标签，不能当作独立的真实任务测试集。[1]

三类问题与教师最高概率选项的一致率

分类型看，差别比总分更有用：

• 真假判断 noul：20,912 个问题，一致率 95.84%。
• 等级评分 score：11,026 个问题，一致率 90.06%。
• 动态多选 choice：20,726 个问题，一致率 85.08%。

三项都是作者报告的教师一致率。模型卡还指出，包含 8—10 个候选项的动态选择存在较大的拟合差距。[1]

所以，我会把真假分流列为优先试验场景，把复杂多选列为重点压力测试场景。这是依据已披露差异做出的部署建议，不是对真实准确率的承诺。尤其不能把 90.40% 写成“准确率”，再拿它证明学生全面超过教师。

和原版 JEV 比，哪些优势已经看得见

发布时间与训练耗时不能混在一起。TypeSafe 在 2026 年 9 月 15 日宣布 Jev 开放早期访问，9 月 20 日的官网公告宣布取消等待名单。JoyFox 权重仓库创建于 9 月 24 日 15:52:51，北京时间，距 Jev 公开亮相九天。蒸馏评测对照的教师版本名称带有 9 月 17 日，与 JoyFox 发布日期相隔七天；这两段间隔都不是训练耗时。[1][3][5]

推理时间则是另一组证据。JoyFox 披露单 GPU、BF16、热模型、每次一个问题的平均延迟为 78.25 毫秒，P50 为 73.70 毫秒，P95 为 97.26 毫秒；batch size 为 8 时，吞吐为每秒 70.22 个问题、40.82 条记录。记录可以含多个问题，两种吞吐单位不能混用。[1]

这些数字不包含加载时间，模型卡没有注明 GPU 型号。原版 Jev 的发布材料给出的端到端响应范围是 70—500 毫秒，并说明公开评测通常从美国西海岸的笔记本访问服务；JoyFox 披露的则是本地热模型数据。把 78.25 毫秒和这个服务区间并排，可以了解各自报告的量级，不能算速度倍数，也不能推导手机或 CPU 的速度。[1][5]

训练路线也不同。TypeSafe 将原版 Jev 描述为新架构、并行采样器与 RLCD（面向校准决策的强化学习）的组合。JoyFox 公开的是 Qwen 文本骨干加 query/key 头，以及对教师分布的学习。模仿输出不意味着复现了教师的架构或 RLCD 训练，更不能自动继承教师关于校准的所有主张。[1][2][5]

数据层面，公开的是蒸馏结果，不是胜负榜。JoyFox 给出了三个任务类型的一致率和分布距离，这比只放演示更容易判断下一步该测什么。但它没有提供一套人类标注、双方同场作答的独立比较；训练数据的完整构成也尚未披露。[1]

能力层面，它把常见的概率决策形式放进了千问小模型。动态候选、真假判断、有序评分，都有公开实现。模型卡标注多语言，并不等于已经证明中文判断优于原版 JEV；公开评测也没有按语言拆分。中文使用者仍应单独测术语、否定、金额、上下文省略和歧义。[1][2]

部署层面，确定的收益是控制权。JoyFox 发布了完整文本骨干、分词器和决策头，模型卡标注 Apache-2.0，推理包支持 CUDA 和 CPU。按 Hugging Face 文件元数据相加，两个 safetensors 权重文件合计约 1.505 GB，采用十进制 GB；这不是运行内存，也不是最终手机安装包大小。[2][3]

原版 Jev 的公开接入重点是托管服务；JoyFox 这里拿到的是可自行运行的权重和封装。前者省掉模型运维，后者把推理环境与版本控制交给开发者。私有化场景下，我更愿意从 JoyFox 开始试；只想最快接上现成服务，原版接口反而可能省事。[1][2][5]

还有一个容易被忽略的能力边界：原版 Jev 的发布材料说明，单次选择支持最多 255 个候选；JoyFox 当前输入校验将每个问题限制为 128 个候选，并且仍须满足 1,024 tokens 的长度限制。它并非所有维度都更宽裕。[2][5]

JoyFox 让开发者能够固定版本、自行保存权重、检查概率计算过程，把业务文本留在自己的推理环境。对在意可审查与私有化的团队，这些价值不需要等一个“全面碾压”的标题来成立。

部署之前，要绕开三个容易踩的坑

不能把权重直接交给 Ollama、常规 GGUF 加载器、vLLM 或 AutoModelForCausalLM，就指望得到同样的决策输出。它们不会自动暴露这里的专用决策头。应该使用 JoyFox 的 DecisionEngine 封装。[1][2]

推理包要求 Python 3.11 及以上，依赖中固定了 transformers==5.5.3，并要求 PyTorch 2.6 及以上版本。基础安装路径是克隆 joyfoxai/jev-inference 仓库后，在独立虚拟环境执行 pip install -e .。[2]

加载入口可以保持很短：

from jev_inference import DecisionEngine

engine = DecisionEngine.load(
    "joyfox/Qwen3.5-0.8B-JEV",
    device="cuda",
    dtype="bfloat16",
)

之后把 state 和 questions 组成记录交给 engine.predict(record)；多条记录用 engine.predict_batch(records)。CPU 路径可显式指定 device="cpu"、dtype="float32"。这段是按官方接口整理的调用入口，不是一次本地性能复测。[2]

第二个坑是长度。这个发布物支持的输入上限为 1,024 tokens，计算的是每个问题对应的“状态＋问题＋候选项”序列，不是只算用户文本。超过上限会报错，而不是悄悄截断。不要拿底座配置里的长上下文数字替代这个决策模型的实际支持范围。[1][2]

第三个坑是把最大概率当作可靠性证明。代码里的 confidence 就是该问题最大候选概率，并没有另一个独立的正确性验证器。候选项写得不完整，即使某项得到很高概率，也可能只是从一组不合适的选项里选出了最像的那个。增加或改写候选项，也会改变分布。[1][2]

我推荐它，是为了把决策这件事做得更可控

如果团队正在做客服分流、内容归类、任务路由或模型路由，我愿意把 JoyFox 的这个版本放进候选清单。理由很具体：体量处在适合试验的小模型档位；标签可以随请求定义；代码与权重可以检查；输出能直接接业务逻辑；作者没有把蒸馏一致率包装成真实准确率。[1][2][3]

但我不建议一上来就把它放在支付、账户封禁或其他不可逆操作的最终决策位。更稳妥的起点，是让它在后台影子运行：与现有流程并行打分，不执行动作，记录分歧，再由人工或已发生的业务结果核验。

我的验收清单会包括真实标签准确率、概率校准、候选项顺序与改写的稳定性、长输入拒绝率，以及目标设备上的 P95 延迟、内存和每千次决策成本。阈值应根据错误成本选择，不能因为输出了 0.9 就直接放行。

我推荐的是一个值得部署和验证的开源决策模型，不是一项尚未被证明的“全面超越”。下一步最有价值的数据，是把它和原版 JEV 放到同一批真实工单上，看看那些不同意教师的答案，究竟是新的错误，还是学生做对了。

资料与版本

[1] JoyFox 模型卡：Qwen3.5-0.8B-JEV；权重版本 ae7b7040aeff7802f6f2bcfdd27f08a72d5cd969。https://huggingface.co/joyfox/Qwen3.5-0.8B-JEV

[2] JoyFox 推理仓库：README、model.py、engine.py、pyproject.toml；代码版本 2677b5a3714489847668175de793e2d92fe183f0。https://github.com/joyfoxai/jev-inference

[3] Hugging Face 仓库文件元数据、backbone/config.json 与 decision_config.json。https://huggingface.co/joyfox/Qwen3.5-0.8B-JEV/tree/main

[4] 千问底座模型。https://huggingface.co/Qwen/Qwen3.5-0.8B

[5] TypeSafe：2026 年 9 月 15 日的 Jev 发布说明及官网公告。https://typesafe.ai/blog/introducing-system-one-models-and-jev

资料核验截至 2026 年 9 月 24 日。数值评测为作者披露；未将其表述为独立复测。