开源判断模型实测：为什么它中文只有20分却值得部署

有个开源判断模型把最难看的数字直接挂在首页最显眼的位置——中文能力 20 分（满分 64），按常理这种分数该藏起来，它却当成卖点。这背后其实是一种被误解的产品定位：它压根不是拿来聊天写作的大模型，而是一个专门做「判断」的架构组件。本文不吹它，只讲三件事：它凭什么快、装它要付什么代价、以及它到底解决什么问题。全程附实测数据，最后一段是把它部署到 Cloudflare 边缘时踩的坑。

它到底是什么：判断层，不是生成层

这个模型是一个非自回归的判断模型。这句话里最关键的词是「判断」。

普通大模型的工作方式是：你给它一段话，它一个字一个字往外吐，像打字机一样。而这个模型不吐字，它只回答你给出的结构化问题，且只认三种题型：

• 选择题：这条告警该不该惊动人？回你一个选项加一个置信度
• 打分题：这封邮件优先级几分？回你一个 0 到 100 的分数
• 是否题：直接给二元判断加概率

这带来两个技术上的直接后果。第一，它的输出 token 为零，因为它不生成文本，只回概率——这在计费和延迟上都是质变。第二，它给出的置信度是校准过的：当它说「七成把握」时，真实正确率大概就是七成。这是用强化学习配合严格评分规则训出来的，而大模型的「自信」通常是嘴硬。

代价也很清楚：它只能回答你已经想到的问题。你想让它自己发现点什么，它做不到。它是判断层，不是生成层。

校准置信度（Calibrated Confidence） 是概率输出质量的核心指标，值得单独解释。一个模型「说七成把握就真有七成正确率」，听起来简单，实际上极难做到。普通大模型经过海量文本训练后往往呈现「过度自信」现象——即便答错，也倾向于给出高置信度的措辞。校准过的模型则不同：它的输出概率与实际准确率在统计上是对齐的，可以直接当阈值使用，比如「置信度低于 0.6 的判断自动转人工复核」。强化学习在这里的作用是：通过奖惩信号持续修正模型对自身输出的「自我评估」，而不仅仅是让答案更准确。这种校准特性使判断模型的输出可以直接接入自动化流水线，而无需额外加一层「可信度过滤」逻辑。

它凭什么快：常数级延迟

大模型慢的根本原因是自回归——每吐一个字都要把前面所有字重新读一遍算一遍，800 字的回答就是 800 次前向计算。

这个模型用的是双向注意力编码器，一次前向就算完，没有逐字的循环依赖，所以延迟是常数级的，不随内容长度线性增长。

官方给的数字是：在一块入门级显卡上，10 个问题一起问，总共 72 毫秒，摊到每个问题约 7 毫秒。而且它支持并行提问，一次请求塞多个问题一次算完。这才是判断层该有的样子，而不是一问一答的模式。

双向注意力编码器（Bidirectional Attention Encoder） 与大模型使用的单向（因果）注意力机制有根本差异。GPT 系列等自回归模型在生成第 N 个 token 时，注意力只能看到前 N-1 个 token，这是为了保证生成顺序的合法性。而双向编码器（BERT 架构的核心）在做一次前向计算时，序列中每个位置都能同时看到左侧和右侧的所有上下文，信息利用率更高，但代价是无法逐字生成文本。这正好契合判断任务的需求：输入是完整的、输出是固定结构的，不需要逐步生成。BERT 最初就是为分类、匹配、抽取等「理解型」任务设计的，后来被广泛用于搜索排序、情感分析等场景。判断模型复用了这一架构，并针对置信度校准做了专项训练。

实测：我在小主机上被 OOM 杀了两次

跑之前先量三个数：容器内存上限 3096 MB，系统基线占用 1372 MB，模型全重 643 MB。看起来放得下，实际加载过程连续两次被系统强杀，退出码 137——就是内存不够被杀的那个码。

根因不在模型大小，而在加载方式。它建模型时先按全精度建了一个约 1.29 GB 的空壳，再把全重读进去，等于同一份东西在内存里放了两遍，643 MB 的全重峰值直接干到 3400 MB，超过了 3096 MB 的天花板。

第一句实用结论：这东西的内存门槛不在全重，在加载方式。

三档精度对应三档内存

同一个小模型，三种精度对应三档占用：

• 全精度：约 1.6～1.8 GB，低配机器肯定装不下
• 半精度：约 1～1.2 GB，太紧
• 动态量化后：约 600～750 MB，这才是能长期跑的档位

建议是先算账再动手：如果内存超过 600 MB 或单次判断超过 2 秒，就别在低配机器上硬上，换个方案更省事。

三个必踩的坑

坑一，环境。 用国产芯片或没显卡的机器，装依赖时必须显式指定 CPU 版框架。默认原装会拉回来一整套带显卡驱动的东西，光缓存就 3.3 GB，装了十几分钟发现根本用不上。换官方 CPU 源，一次就过。

坑二，下载。 从模型站直接拉只有 200 多 KB/s，一个多 GB 要等一小时。换成带加速的下载库能跑到 2 MB/s 以上，快了约 8 倍。

坑三，也是最重要的——内存账要提前算。 还有一条部署经验：不要把它塞进正在跑主业务的那个进程里。它加载瞬间内存会翻倍，如果和重要服务在同一个容器里抢内存，一次加载就可能把主业务一起带走。单独一个容器、单独一个内存上限，这是底线。

退出码 137 是 Linux 系统中容器或进程被强制终止时的标准信号。Linux 信号编号 9（SIGKILL）加上 128 的基准偏移，得到用户空间可见的退出码 137。SIGKILL 是无法被程序捕获或忽略的强制终止信号，通常由内核的 OOM Killer（Out-Of-Memory Killer）在系统内存耗尽时触发。OOM Killer 会根据各进程的内存占用、运行时长等因素打分，选择「最应该被杀掉」的进程终止。在容器环境（如 Docker）中，cgroup 内存上限触发的强杀同样会产生 137 退出码。遇到这个退出码，排查方向明确：先看 /var/log/kern.log 或 dmesg 里的 OOM 日志，确认是哪个进程触发了 OOM，以及触发时的实际内存水位。

和智能体框架配合：省的不是钱

三种典型解法：一是门控，智能体决定下一步前先用便宜模型过一遍；二是结果质检，贵模型产出后用便宜模型检查有没有跑题；三是路由，判断这个任务值不值得升级到深度思考。

关键的账要算清楚。如果你的框架已经开了提示缓存，判断带来的成本节省其实很有限——每次往返重读的上下文大多命中缓存，缓存单价只有新输入的 1/50。作者的真实记账：一次调用输入 56 万 token，其中 55 万命中缓存，加 2000 缓存写入和 2000 输出，合计约 0.003 美元。

所以判断量不大时，省的根本不是钱。真正的收益在另外三处：延迟快一到两个数量级；结构化概率天生不会格式错，置信度还能拿来设阈值门控；数据本地部署可以完全不联网。

第三方实测很能说明问题：1000 封邮件做分类，判断模型用时 15.6 秒、成本 1.77，大模型用时 48.9 秒、成本 2.07。注意——成本只低了约 15%，速度却快了三倍。这就是判断层的真实收益结构：先拿速度和确定性，成本是顺带的。

Cloudflare 边缘部署：一个有代表性的坑

先纠正一个流传的错误说法：网上说 Cloudflare 已经支持这个判断模型。作者把模型目录翻了一遍，搜项目名、搜厂商名都没命中——它没有。而且就算有也跑不了：边缘运行环境的内存上限是 128 MB，模型本体装不下，免费版付费版一样，升级也解决不了。

所以在边缘部署的正确形态是做网关，不是搬模型。这个网关干四件事：

1. 密钥隔离：判断服务的密钥只存在边缘一侧，客户端拿不到
2. 边缘缓存（重点）：模型是确定性的，同一份输入加同一组问题返回的概率分布一模一样，天生可缓存。把输入规范化后取哈希当缓存键，命中就不碰上游——零调用、零成本、毫秒即返
3. 客户端鉴权：防止别人蹭额度
4. 协议对齐：让本地模型和云端服务靠改一个地址互相替换

边缘缓存的价值在于：判断层最常见的负债恰恰是重复——同一类告警反复出现、同一个候选池每小时重判、同一份报告反复质检。把重复判断的成本压到零，比优化单次调用划算得多。

500 错误背后的真凶

网关传上去、路由也开了，但每个请求都返回 500 加错误码 1101。作者先怀疑自己，传了个最简测试脚本上去，同样报错；压测 30 次全挂，别的账号服务正常——说明是账号问题。查用量、查兼容日期、查账号状态都正常。

真相在邮箱里：服务商自己发的告警邮件排成一条线，前几天用量到 8～9 成、超出额度、重置后又超。真凶是免费版每天的请求额度被打满。

这里有两个值得记住的点：

第一，同一个原因两幅面孔。 程序里看到的是配额超限附带重置时间，浏览器里看到的却是脚本抛异常式的错误码。你要只看后者，第一反应必然去查代码，而它跟代码毫无关系。

第二，用量统计会骗人。 查后台当天只有 19000 多次，远低于 10 万上限，但这数字恰恰不能证明没超——配额打满后被拒的请求根本不会被这个口径记上。判断这件事，看告警邮件比看统计面板可靠得多。

谁该用，谁别碰

适合三类场景：需要在便宜硬件上做大量重复判断；需要毫秒级延迟；或数据敏感必须本地跑。

不适合的场景同样清楚：指望它说中文；指望它自己发现新东西；或一天判断量只有几十次。

最后一句实话：判断层不是降本工具，它是把「判断」从「生成」里拆出来的架构调整。 收益顺序是先拿速度和确定性，再谈合规，成本排最后。量不够大的时候，用手上现成的模型就够了，别为它建任何基础设施。

背景补充

判断模型的确定性（Determinism） 是它天然适合缓存的技术基础。自回归大模型通常有「温度（temperature）」参数控制随机性，同一输入多次调用可能得到不同输出。判断模型没有生成过程，给定相同输入和相同问题集，概率输出是完全固定的——这使得以输入哈希作为缓存键在语义上完全正确，不存在「缓存命中但答案过期」的问题。实现时需要注意输入规范化：空格、标点、字段顺序的细微差异都会导致哈希不同、缓存失效。常见做法是在取哈希前先对输入做 JSON 序列化并排序字段，确保语义相同的请求生成相同的缓存键。Cloudflare Workers KV 或 Cache API 都可以承载这类缓存，TTL 可以设得较长——只要上游模型版本不变，缓存永远有效。