智东西 作者 | 王涵 编辑 | 漠影 近期，大模型行业掀起一股 开源自研推理引擎 的浪潮。 10月20日，DeepSeek正式开源生产环境实际使用的推理框架DeepInfer。几乎同时，10月22日，国内AI创业团队 StartLux原点星辉 也对外开源了其 自研推理引擎Prism 。 同样是自研推理系统，DeepSeek的DeepInfer服务于自家通用大模型的云端大规模业务；而Prism则聚焦“决策模型”，据公开资料，其也是 首款专门面向决策模型打造并对外开源的推理引擎 。 决策模型是近段时间快速走红的大模型新赛道。不同于主打对话、内容创作的生成式大模型，决策模型不需要输出大段文本，在读取材料之后， 直接输出判断结果 ，给出是/否、选项选择、风险等级打分这类概率化结论。 自今年9月Jev模型爆火之后，决策模型迅速成为行业焦点，微软、AWS、Cloudflare等企业也相继入局布局。 在国内决策模型赛道，成立尚不足五个月的StartLux原点星辉已经跑出了不错的成绩。10月16日，该团队推出新一代决策模型 StartLux‑Decision-v1.1 ，以 69.1分 登上Hugging Face的Decision Index 0.3.2榜单首位， 在173个公开可复现模型中排名第一 。 截至目前，StartLux决策模型累计下载量 超18万 ，决策模型API已累计响应来自全球 超300万次 决策请求。 Github 推理引擎： https://github.com/StartLuxLabs/StartLux-Prism Github 决策模型： https://github.com/StartLuxLabs/StartLux-Decision Github 决策模型榜： https://github.com/StartLuxLabs/DecisionPivot Huggingface 决策模型： https://huggingface.co/papers/2610.17309 Huggingface 决策模型榜： https://huggingface.co/papers/2610.28522 不过，即便模型能力实现突破，落地环节仍存在现实瓶颈。 在此之前，StartLux-Decision-v1.1运行在基于vLLM 0.31的通用推理框架之上。然而，vLLM这类主流框架原生面向聊天、续写文本这类逐token生成场景设计，并不适配决策模型，模型的实际能力很难充分释放。 Prism就是StartLux给出的解法： 按决策模型的需求重写推理引擎。 实测其在单张H200显卡上，Prism处理单个短问题比原方案 快2.8倍 ，同一份材料连问三个问题， 最快可提速5.3倍 。 这套专为决策模型重构的推理引擎，到底做了哪些关键改动？各项性能数据的实测结果如何？为何越来越多AI企业选择自研推理框架，而非直接使用社区通用方案？本文将围绕以上问题展开解读。 一、StartLux用四大创新，破解推理效率难题 想要看懂Prism的优化思路，首先要厘清决策模型的运行逻辑。 例如有一位客户投诉：“订单被扣了两次钱，App里却还显示未付款。”接到这个投诉，系统需要同时判断：工单交给哪个部门、今天是否必须回复、问题有多严重。决策模型需要读完材料，分别给每道题的备选答案打分，返回各选项的概率。 反观vLLM、SGLang等通用推理框架，其设计初衷服务于文本生成任务。如果用它们跑决策模型，每一道问题都要被拆解成独立请求，分别完成网络请求、分词、调度，并且重复执行庞大输出层的计算。 Prism的全部优化，都围绕一个核心目标：完成一次决策，只执行必不可少的计算。 优化一：收敛输出计算范围 以27B参数量的 StartLux‑Decision 模型为例，它的输出层包含12.7亿权重，通用引擎需要对24.8万个候选词做完整打分，但决策任务只用到A‑Z共26个字母作为输出选项。 Prism将输出层计算范围压缩至原先的 0.01% ，模型依旧完整完成材料理解，只是在输出判断结果阶段，跳过大量无关候选词的计算。 优化二：“森林式”计算 业务场景中经常出现同一份材料对应多项判断需求。比如一份客户工单，需要同时判定归属处理团队、是否需要当日回复、故障严重等级。传统框架每解答一道题目，就要重新完整处理一遍工单材料。 Prism创新性地将批量任务构建成 “森林式”计算结构 ：通用指令作为树根，共用的参考材料作为树干，各个独立问题作为分支树枝。 树根、树干对应的计算只执行一次，不同问题仅处理自身新增部分。针对同一份材料的多轮追问同样可以复用已有计算结果。 优化三：采用整数运算 在和大语言模型互动的时候，我们常常会遇到一个问题：同一个问题，大模型每次给出的答案都不尽相同，有时候甚至完全相反。 这一点在决策模型上是十分致命的，因为决策模型输出的概率值会直接指导业务系统执行后续动作。 Prism通过 整数运算 ，解决结果漂移问题： 相关矩阵运算全部使用int8精度 ，在int32精度下完成累加。因为整数加法不受计算顺序影响，计算结果不会受批大小、调度顺序干扰。 优化四：混排调度 StartLux‑Decision-v1.1支持 AutoThink自动思考模式 ，模型把握充足时直接输出答案，把握不足则先生成最长4096 token的推理思考过程。 但这也带来了调度层面的难题：如果简短请求和长思考请求进入同一个任务队列，简单任务就会被长耗时请求阻塞。 Prism为此设计了一套 混合调度机制 ：思考类任务的提示词并入直接输出批次完成预处理，后续解码步骤 预编译为CUDA图 ，最多支持 64条 思考任务与直接输出任务分时占用显卡资源。新接入的简单请求最多等待 1‑2个解码步骤 就可以插队执行。 二、推理最高快5.3倍，231 题均速仅41毫秒 这样优化后，性能有着怎样的提升呢？StartLux对此进行了一系列对比测试。 （注：以下数据来自StartLux在不同模型版本及测试条件下的实测结果。其中，5.3倍加速测试使用StartLux-Decision-v1.1-27B AutoThink模型；231题跨引擎性能对比及吞吐量测试使用StartLux-Decision-v1-27B模型。具体测试配置与结果均已在GitHub公开。） 第一题：单请求延迟 测试结果显示，单道短问题场景下，Prism耗时 19毫秒 ，原方案为53.1毫秒，提速2.8倍。针对同一份材料连续处理三道问题，Prism仅 需17.4毫秒 ，原方案则要92.9毫秒， 提速幅度达到5.3倍 。 如果在三道问题基础上开启思考模式，Prism耗时 785毫秒 ，原方案为1296毫秒，提速1.7倍。面对单条约8192 token的长问题，二者的性能差距收窄至1.2倍。 在更加直观的视频理解测试中，StartLux-Prime的速度比vllm快3.38倍，且输出的概率基本一致。 第二题：跨引擎延迟 研究团队选取JevBench测试集共 231道题目 ，将Prism与vLLM、SGLang、llama.cpp等主流开源推理框架做横向对标。 结果显示，Prism 单题平均延迟41毫秒 ，在所有参测框架中 排名第一 。紧随其后的decider编译版为66.8毫秒，SGLang为75.6毫秒，vLLM达到112.7毫秒，llama.cpp耗时最长，单题平均589毫秒。在同为8位精度的同等条件下， Prism的延迟比次快的框架低约40% 。 这里有两点测试前提需要说明：decider和JevK5两款引擎无法直接搭载StartLux原生模型，测试使用了结构一致的替代模型，仅对比速度不考核准确率；另有部分框架不支持8位量化，只能以更高精度运行。 第三题：吞吐量 高并发吞吐测试中，64路并发跑满显卡时，Prism相对竞品的优势收窄到 17%到22% 。这一阶段瓶颈出在硬件算力层面，双方都已经将H200的性能拉满，软件优化很难再带来明显提升。 但决策类业务最常见的并非极限满载场景，而是高频出现的小型请求。在这种日常典型负载下， Prism每秒可以处理100道请求 ，表现最优的竞品为每秒38道，Prism领先2.6倍。 换言之，Prism的性能优势恰好落在企业真实高频使用的业务区间，这也是专用推理引擎最核心的价值。 第四题：多卡部署灵活适配 多卡部署层面，Prism 支持数据并行与张量并行 两种模式，也可以组合使用，适配不同的业务需求。 以27B版本模型为例，四张H200采用数据并行模式，各自独立接收请求，合计 每秒可处理121个请求 ，约为 单卡吞吐的3.92倍 。如果四张卡采用张量并行模式合力计算同一道题，单题延迟可以从41毫秒降到 29毫秒 。 两组双卡混合部署则可以兼顾吞吐与延迟，实现 每秒86道请求、单题36毫秒 的表现。无论采用哪种部署方式，输出结果都与单卡运行时逐位一致。 第五题：精度与部署门槛 提速之外，模型的推理精度并未出现折损。 在覆盖七个评测集、共12351个决策样本的带思考测试中，Prism int8版本的 平均准确率为92.94% ，原引擎FP8版本为92.83%，未做量化的BF16原版为92.97%。Prism量化版本与满血原版的准确率差距仅0.03个百分点，甚至略优于原有引擎的量化版本。 部署门槛也比预想中更低。该模型有16.55GB的压缩版本， 单块32GB显存的RTX 5090消费级显卡就可以运行，输出效果对标专业级显卡H200 。在这个压缩版本上，Prism比主流开源框架llama.cpp 快3.9 倍 。 三、推理系统拉开身位，模型企业开始