Sarvam Prism：44 毫秒做一个判断，企业自动化缺的正是这种“诚实”的模型

2026 年 11 月 3 日，印度公司 Sarvam AI 发布了一个名字很直白的模型：Prism。它不写文章、不画图、不聊天，它只做一件事——在给定的几个选项里选出一个，并给出每个选项的概率。这个定位听起来很窄，但 Sarvam 认为它恰恰是企业工作里最常见的环节：客服该把工单转给谁、文档属于哪一类、一段智能体运行记录是否需要人工复核、一次提示是不是越狱尝试。这些问题都不需要模型长篇大论，只需要一个又快、又准、又敢为自己的把握程度负责的判断。Prism 就是为这种“系统一”式快速判断设计的模型，而它的发布方式也很符合这个定位：权重开源、企业可以在自己的数据上继续训练、在自己的基础设施上运行。

先把 Prism 的核心数字讲清楚，因为整篇公告几乎都围绕这几个数字展开。Sarvam 称，Prism 基于 Sarvam 105B 模型，经过 LoRA 微调得到，平均分为 71.8 分，在一块英伟达 B200 GPU 上的中位响应时间只有 44 毫秒。在 Sarvam 自己测试的 25 个决策模型里，它是 100 毫秒以内得分最高的模型。这个“100 毫秒以内最高分”的表述很关键：Sarvam 并没有宣称 Prism 是所有模型里分数最高的，而是宣称它在速度和准确率的权衡曲线上占据了一个新的位置。公告里也承认，有少数模型分数更高，但需要两到六倍的时间。换句话说，Prism 的竞争策略不是“最聪明”，而是“够聪明，而且快到可以塞进每一次请求的链路里”。

这 71.8 分是怎么来的，需要拆开看。Sarvam 用了三个指数取平均：第一个是 Jev 决策指数，包含 37 个公开基准，Prism 得 67.0 分；第二个是 Sarvam 自己复现的人工分析决策指数，其中私有的知识测试被替换为带“我不知道”选项的精选难题，Prism 得 65.9 分；第三个是内部的印度语言基准，Prism 得 82.5 分。对照组里，Perplexity Decider v1.2 平均 68.0 分、117 毫秒，Jev 1.14 平均 64.5 分、196 毫秒，Clef 平均 62.6 分、222 毫秒，微软的 Microsoft-Decision-1 平均 61.1 分、85 毫秒。这里有一个必须注意的细节：Jev 1.14 和 Microsoft-Decision-1 只能通过 API 调用，Sarvam 用的是它们公开报告的时间，而从 Sarvam 自己的集群实测，这两个模型的耗时分别是 431 毫秒和 533 毫秒。如果按实测时间算，Prism 的速度优势会更大；但如果按厂商报告时间算，对照也更公平。Sarvam 把两种口径都写出来了，这一点值得肯定，读者在引用 44 毫秒这个数字时，也应该同时说明它是在单块 B200 上、一次一个请求的条件下测得的中位数。

Prism 的工作原理是理解它为什么能这么快的关键。它不是一个生成式模型：输入状态、问题和选项后，它在一次前向传播里完成判断，由一个小型打分头为每个选项返回概率，完全不做逐 token 生成。这个设计决定了它的适用范围：它适合“选项已经给定”的任务，不适合需要自由发挥、开放回答的任务。训练上，Sarvam 用了两个等权重的损失项：带 5% 标签平滑的交叉熵损失，以及衡量概率平方误差的 Brier 损失。Sarvam 把 Prism 良好的校准表现归因于这两个选择。注意力机制上也有一个巧妙的设计：状态和问题组成一个可以双向读取的块，每个选项只能看到这个块和它自己、看不到其他选项，而只有答案 token 能看到全部内容。Sarvam 称，这种隔离让每个判断相互独立，双向读取则在 Jev 决策指数上带来了约 3 分的提升。工程实现上，Sarvam 把大块的计算交给无需掩码的快速核，只对选项和答案行使用自定义掩码，使 2048 token 以上的请求注意力计算快了 2.6 倍，而 FP8 量化只让 Jev 分数变化了 0.01 分。

从 664 毫秒到 44 毫秒的加速过程，本身就是一篇很好的工程案例。Prism 最初以 16 位精度跑在两块 B200 上，中位请求耗时 664 毫秒。Sarvam 把权重转为 FP8，让模型可以装进单块 GPU，又把 128 个专家合并进一个分组核，把前向传播捕获为 CUDA 图，把 FP8 转换折叠进专家核，并把微调适配器合并进模型权重。合起来，速度提升了 15.1 倍，而准确率没有下降。这个链条说明，Prism 的快不只是模型小，而是系统层面的优化堆出来的。对于想要自己部署的企业来说，这里还有一个硬性门槛：Prism 以 FP8 运行时需要一块至少 120GB 显存的 GPU。这不是一台普通服务器能随便满足的条件，它的“可以在自己的基础设施上运行”是有硬件前提的。同时，单次问题最多可以处理 131072 个 token，这让很长的智能体运行记录可以一次读完，而不用切块。

如果只看分数和速度，Prism 很容易被当成又一个基准刷榜模型。真正让它与众不同的是校准，也就是模型对自己把握程度的诚实度。企业要把一个判断自动化，前提是只有在置信度高于某个阈值时才自动执行，低于阈值时转人工。这个机制只有在置信度本身可信时才安全。Sarvam 的测试覆盖了从 50% 到 95% 的所有阈值，结果是 Prism 在英语和印度语言里犯的错误都少于它自己预测的错误。具体到 90% 及以上置信度的回答，英语方面 Prism 预测错误率为 3.3%，实际为 2.2%；印度语言方面预测为 5.4%，实际为 4.4%。对照组则普遍低估了自己的错误：Perplexity Decider、微软模型和 Jev 1.14 在英语上的低估倍数分别为 1.5、1.8 和 2.7 倍，在印度语言上对照组犯的错误是其预测值的 2.7 到 4.8 倍。英语测试基于 37 个公开基准的 226088 道题，印度语言测试则是同样基准在 10 种印度语言和印式英语中的 20108 道题。这个差距的实际意义很直观：一个过度自信的模型会把本该转人工的case悄悄自动放行，而一个校准良好的模型会把不确定的case留给人。

顺序不变性是另一个容易被忽视、但在真实系统里经常踩坑的细节。很多模型在选项顺序打乱后会改变答案，这意味着同一个问题换个排列就可能得到不同的结论。Sarvam 在 2000 道题上做了测试：每道题按四种打乱顺序各跑一次，再按原顺序重复四次。Prism 在固定选项顺序后再打分的做法下，2000 道题的答案没有一道发生变化。而如果不做这一步、直接按送达顺序读取选项，Prism 在打乱后会改变 4.0% 的答案。对照组的情况更明显：Perplexity Decider、GLiDE 1.2 和 mammoth-1 在原顺序重复时答案不变，但打乱后会改变 9% 到 10% 的答案；Jev 1.14 即使什么都不变也会改变 5.6% 的答案，打乱后更是达到 12.3%。Sarvam 的做法并不复杂：先把选项排成一个固定顺序再打分，最后再把概率对应回原始选项名。这个小步骤没有增加计算量，也没有损失准确率，却解决了一个会让自动化系统行为飘忽不定的问题。

智能体运行记录评测是 Prism 最贴近当前开发痛点的一组实验。智能体的工作需要被检查：任务有没有成功、这段运行要不要人复核、如果失败了是哪一个智能体造成的。Sarvam 用了三组已标注的运行记录，包括专家标注的网页智能体运行、按任务完成情况标注的客服对话，以及标注了失败步骤和责任智能体的失败运行，共 700 段运行、1770 道题。结果是 Prism 在“任务是否成功”上准确率为 75.0%，在“是否需要人工复核”上为 86.4%，在“哪个智能体导致失败”上为 69.6%，全部问题综合为 78.5%，均高于 Clef、Jev 1.14、微软模型和 Claude Haiku 5.5。速度和成本的对比同样鲜明：Prism 在单块 GPU 上约半秒就能给一整段运行打分，而通过 API 调用的 Claude Haiku 5.5 中位耗时 2.5 秒，每 1000 段运行成本为 0.64 美元。这里的判断标准来自人工标注或环境自身的自动检查，而不是另一个 AI 模型的打分，这让结果的可信度高了一些。但 700 段运行的规模仍然有限，能不能推广到更复杂、更长的真实生产记录，还需要更多验证。

安全防护场景的数字则需要更谨慎地读。Sarvam 用了一个内部网络安全基准，包含 5517 道题、覆盖 9 类任务，素材来自 2026 年 7 月以来公开的漏洞。模型需要判断一段内容是否属于钓鱼活动、一次输入是否在尝试越狱，以及把攻击类型归入 MITRE 框架。Prism 得分为 89.0%，高于 Clef 的 84.5%、Jev 1.14 的 78.6% 和微软模型的 76.1%。但 Sarvam 自己也说明，这个评测集尚未公开，计划在未来几周内扩充并公开发布。在它公开之前，外界无法独立复现这个 89.0% 的数字，也无法判断它对不同类型攻击的覆盖是否均衡。把它当作一个方向性信号是合理的，把它当作定论则为时过早。同样，Prism 在语音转语音测试、轨迹评测、提示注入防护、客服意图路由、模型路由和文档智能等真实场景上的表现，Sarvam 表示已在内部测试，更多基准会在未来陆续发布。

把 Prism 放到更大的图景里看，它的出现标志着“决策模型”这个品类正在从一个概念变成一条赛道。Sarvam 在公告里承认，这个品类是 TypeSafe 上个月创造的，名字取自卡尼曼的系统一思维，也就是快速、直觉式的判断方式。短短一个月内，已经有 Perplexity、TypeSafe、微软等多家厂商的模型同场竞技。Sarvam 的打法很清晰：不拼通用聊天的广度，而是拼一个狭窄任务上的速度、校准和可部署性，并且用开源权重降低企业的采用门槛。权重以 Apache 2.0 协议发布在 Hugging Face 上，同时也可以通过 Sarvam API 在 Sarvam Indus 上调用。这个组合对企业的吸引力在于，它既可以先通过 API 快速验证效果，也可以在验证通过后把模型搬进自己的基础设施，用自己的数据继续训练。

当然，Prism 的局限同样应该说清楚。第一，它只解决“选项给定”的判断问题，不能替代需要生成、推理和长篇写作的通用模型；把它用在不适合的任务上，速度再快也没有意义。第二，它的三个指数里有一个是 Sarvam 自己的内部印度语言基准，安全基准也是内部的，这些数字在独立复现之前都只能算厂商自报。第三，它的部署门槛并不低，120GB 显存的单卡要求意味着中小团队可能还是先走 API 路线。第四，44 毫秒是在特定硬件和特定测试条件下的中位数，真实生产环境里的延迟会受到批量、并发、上下文长度和基础设施差异的影响。把这些限定都算进去之后，Prism 仍然是一个值得关注的发布：它不是在讲一个更大的模型故事，而是在讲一个更务实的工程故事——当智能体开始大规模跑起来之后，检查它们、路由它们、为它们设防的判断层，本身就需要一个又快、又准、又诚实的模型。

再往前看一步，Prism 的定位其实提出了一个更普遍的问题：当通用大模型越来越强的时候，为什么还需要一个专门做判断的模型？答案藏在成本结构和责任边界里。通用模型擅长开放任务，但每一次判断都要生成一串 token，既慢又贵，而且它的置信度往往只是语言上的自信，不是一个可以用来做自动化阈值的概率。决策模型反其道而行之：它放弃了开放生成，换来一次前向传播就能给出的概率分布。企业真正需要的自动化，往往不是“让模型自由发挥”，而是“在明确的选项里选一个，并且为这个选择承担可度量的风险”。从这个角度看，Prism 不是通用模型的缩小版，而是一个不同分工的产品：通用模型负责理解和生成，决策模型负责在关键节点上拍板和分流。

这种分工在智能体大规模落地的背景下会越来越重要。智能体每跑一步都可能产生需要判断的节点：这一步做得对不对、要不要继续、要不要叫人、这段对话是不是攻击、这份文档该归到哪一类。如果每个节点都调用一次通用大模型，成本和延迟都会迅速累积，而且每一次调用的输出格式和稳定性都难以保证。Prism 的打法是把这些节点统一成“状态加问题加选项”的标准输入，用同一个快速、可校准的模型批量处理。它的 131072 token 上下文在这里也显得很关键：一段很长的智能体运行记录不需要切块，可以一次读完再打分，这减少了切块带来的信息丢失和边界错误。当然，这并不意味着通用模型会被取代，而是意味着未来的系统里会同时存在两种模型：一种负责做事，一种负责检查做事的结果。

从竞争格局来看，决策模型这个品类还处在非常早期的阶段，标准远没有定型。Sarvam 自己也承认，品类是 TypeSafe 上个月才提出来的，而参与对比的模型在评测口径、部署方式和时间统计上并不完全一致。Perplexity 的 Decider、TypeSafe 的 Jev、微软的决策模型和 Sarvam 的 Prism，各自的优势并不相同：有的在某个指数上更高，有的在速度上更接近，有的在特定语言上更强。Prism 目前的领先主要体现在综合平均分、100 毫秒以内的速度和校准表现上，但这些优势都建立在 Sarvam 自己的评测体系里。接下来最值得观察的，是会不会出现一个独立的、公开的决策模型基准，让不同厂商的模型可以在同一套题目、同一套硬件口径下直接比较。在那之前，任何“第一名”的说法都应该加上“在某家厂商自己的测试里”这个限定。

最后给想试用 Prism 的团队列一份落地检查清单。第一，先定义选项：决策模型只能在给定选项里选，如果你的任务本身选项就不清晰，应该先把选项设计好，而不是指望模型替你发明选项。第二，设定阈值并留出人工回路：根据 Prism 的校准曲线，选择一个置信度阈值，高于阈值自动执行，低于阈值转人工，并且定期复核被转人工的案例，看看阈值是否需要调整。第三，测试顺序稳定性：在自己的数据上打乱选项顺序跑一遍，确认答案不会随顺序漂移，这对客服路由、分类和风控这类场景尤其重要。第四，评估部署成本：如果你打算本地运行，先确认自己有没有 120GB 显存的单卡条件；如果没有，先走 API 路线验证效果，再决定是否投入硬件。第五，关注内部基准的公开进度：安全基准和更多真实场景基准发布后，再用自己的数据做一次独立验证。把这五步走完，Prism 才算真正从一篇博客里的模型，变成你系统里一个可以信赖的判断层。

还有一个值得单独提醒的点：不要把“厂商自报的第一名”直接当成“行业的标准答案”。Prism 的分数、速度和校准表现，都是在 Sarvam 自己搭建的评测体系里得到的，而对照模型的部署方式和时间统计口径并不完全一致。真正有说服力的验证，往往来自独立基准的复测、开源社区的实际部署反馈，以及企业在生产环境里跑出来的阈值表现和故障分布。在这些数据出现之前，最稳妥的阅读方式是把 Sarvam 的公告当作一份“厂商主张清单”，逐项去验证，而不是当作一份已经盖棺定论的成绩单。这种态度不是对 Sarvam 的不信任，而是对所有模型发布都应该保持的基本审慎。