最近，两家中国 AI 公司相继开源针对自家模型优化的推理系统。 10 月 20 日，DeepSeek 开源面向自家模型的推理框架 DeepInfer；随后，StartLux 也宣布开源为 StartLux-Decision 设计的专用推理引擎 StartLux-Prism。
两家公司的技术路线虽然不同，但都将优化重点从模型本身进一步延伸到推理系统。根据 StartLux 公布的测试数据，在单张 NVIDIA H200 GPU 上，使用 StartLux-Decision v1.1 27B 模型，Prism 在测试场景中的推理速度达到原有 vLLM 方案的 1.2 至 5.3 倍。
其中，针对同一份材料回答三个问题时，处理时间从 92.9 毫秒缩短至 17.4 毫秒，达到 5.3 倍加速；短问题场景下则实现了约 2.8 倍加速。除了性能优化，Prism 还支持张量并行（TP）和数据并行（DP）组合部署。
TP 主要用于缩短单个请求的处理时间，DP 则用于提高整体吞吐量，两者可以根据部署需求组合使用。 Prism 还重点优化了推理结果的确定性。
StartLux 表示，在其支持的运行配置下，相同请求不受并发量、批处理方式及 GPU 数量变化影响，可以得到逐位一致的输出概率。在覆盖 7 个评测集、共 12,351 次决策的测试中，Prism 的平均准确率为 92.94%，与 BF16 原始精度下的 92.97% 基本持平。
决策模型的特殊需求：只需要几个选项的概率 vLLM、SGLang 等通用推理引擎主要围绕大语言模型的生成式推理需求进行优化，而 StartLux-Decision 的核心任务有所不同：它需要读取输入材料，并对有限候选选项计算概率，而不一定需要逐 Token 生成长文本。这种差异为专用推理优化提供了空间。
以同一份材料回答多个问题为例，如果每个问题都作为独立请求处理，系统就可能重复执行分词、调度以及公共上下文计算等步骤。对于只需要少量候选概率的决策任务，完整词表计算也可能带来额外开销。
在 StartLux 公布的使用示例中，模型需要根据同一份材料连续回答三个问题。对于每道题，决策模型只需进行一次前向计算，就可以在提示词末尾得到 A、B、C 等候选选项对应的概率，而无需生成完整的自然语言回答。
但在原有推理方案中，这些问题仍然作为独立请求处理。即使多个问题共享同一份背景材料，也可能产生重复的计算和调度开销。
StartLux-Prism 针对这些特点重新设计了计算流程，主要包括四个方面。创新点一：只计算候选答案需要的输出分数 决策模型通常只需要在有限选项中作出判断，但通用语言模型的输出层需要面向完整词表计算分数。
以 StartLux-Decision 27B 模型为例，其词表规模约为 24.8 万个 Token。按照常规推理流程，模型需要通过 LM Head 为词表中的候选 Token 计算 Logits，再经过相应处理得到输出概率。
但对于一道只有 A、B、C 等少数候选答案的决策题，真正需要比较的可能只是其中几个 Token。 Prism 围绕这一特点重新设计了最后的输出计算环节。
模型仍然需要完整处理输入材料，但在计算最终选项概率时，只针对有效候选计算对应的输出分数，无需为完整词表中的所有 Token 计算 Logits。如果决策任务要求的是候选选项之间归一化后的概率分布，那么这种计算方式可以得到与完整词表打分后再对候选集合重新归一化相同的数学结果，同时减少输出层的计算量。
按照 StartLux 的介绍，Prism 不仅缩小了 LM Head 的计算范围，还对最后一层的计算进行了针对性优化，仅在需要输出结果的位置执行完整计算。在一个约 256 Token 的短问题测试中，Prism 将处理时间从原有推理方案的 53.1 毫秒缩短至 19 毫秒，处理速度达到原方案的约 2.8 倍。
创新点二：同一份材料回答多个问题，减少重复计算 Prism 的另一项优化针对多个问题共享同一份输入材料的场景。例如，一张客户工单可能需要同时判断负责团队、回复时限和问题严重程度。
如果将三个问题分别作为独立请求处理，系统可能需要多次读取相同材料，并重复执行部分前向计算。 Prism 将一批具有公共上下文的任务组织成类似“森林”的结构：公共指令构成树根，共同材料构成树干，不同问题则作为分支。
通过这种组织方式，模型可以复用公共上下文的计算结果，再分别处理不同问题，减少重复计算。这一机制结合 Tree Attention，使多个问题能够在共享前缀的基础上完成推理。
在 StartLux 公布的单张 H200 测试中，针对同一份材料回答三个问题，原有基于 vLLM 的 FP8 推理方案需要 92.9 毫秒，而 Prism 将处理时间缩短至 17.4 毫秒，处理速度达到原方案的 5.3 倍。这是本次公布的测试中最明显的性能提升之一。
不过，这一加速效果与多个问题之间共享的上下文比例有关。当问题之间缺乏可复用内容，或者输入材料、任务结构发生变化时，实际收益也可能不同。
对于需要围绕同一份文档进行多项判断的业务场景，例如工单分类、风险评估和文档审核，公共上下文复用可以减少重复计算，也为降低单位任务的推理成本提供空间。创新点三：确定性计算，减少不同并发条件下的数值差异 对于输出概率的决策模型而言，推理结果的稳定性同样重要。
在动态批处理和不同并发配置下，底层计算顺序可能发生变化。由于浮点运算并不满足严格的结合律，即使模型权重和输入完全相同，最终概率也可能出现微小差异。
如果判断结果恰好处于决策阈值附近，这种差异就可能影响最终选择。 Prism 为此引入了确定性计算设计。
按照 StartLux 的介绍，Prism 将相关 Projection 计算放在 INT8 Tensor Core 上执行，并采用 INT32 累加，以减少浮点计算顺序变化带来的数值差异。 StartLux 表示，在其支持的运行配置下，同一请求无论与哪些请求共同处理、系统并发量如何变化、是否命中缓存，以及采用单卡还是多卡部署，输出概率都可以保持逐位一致。
这种设计对需要复现决策结果的业务场景具有实际意义。例如，在金融风控、自动化审核或其他基于概率阈值执行后续操作的系统中，推理结果的可复现性有助于测试、审计和问题排查。
与此同时，Prism 采用 INT8 计算也需要考虑量化对模型判断能力的影响。在覆盖 7 个评测集、共 12,351 次决策的测试中，Prism 的平均准确率为 92.94%，而同一模型采用 BF16 原始精度运行时的平均准确率为 92.97%，两者相差 0.03 个百分点。
从这组测试结果来看，Prism 在降低计算开销的同时，基本保持了原模型的平均判断准确率。不过，这一结果仍取决于具体评测集和模型配置。
创新点四：思考任务与直接回答共享 GPU，避免长推理阻塞短请求 StartLux-Decision v1.1 提供 AutoThink 模式：对于模型能够直接判断的问题，可以快速输出结果；对于不确定的问题，则进一步生成思考过程，最长可达 4096 个 Token。这使推理系统需要同时处理两类运行特点不同的任务。
直接输出的请求通常只需要较短的计算时间，而需要思考的请求则可能持续生成大量 Token。如果两类请求采用简单的串行调度，长时间运行的思考任务就可能增加短请求的等待时间。
Prism 没有为思考任务单独部署一套生成服务，而是让思考请求和直接输出请求共享同一个 Scheduler 和 GPU 显存。具体而言，思考任务的提示词可以与下一批直接输出请求一起完成 Prefill；随后，思考过程中的 Decode 步骤通过 CUDA Graph 执行，最多支持 64 条思考任务同时运行。
思考任务与直接输出任务交替使用 GPU。按照 StartLux 的设计，新到达的短请求通常只需等待一到两个 Decode Step，而不必排在完整的长思考过程之后。
为了保证采样结果的确定性，Prism 还采用 Counter-based RNG，使随机数由请求本身决定，减少批处理组合变化带来的影响。 StartLux 表示，在并发 16 和并发 64 的测试中，思考内容与最终概率均能够和单请求运行时保持逐位一致。
性能方面，在单张 H200 上，Prism INT8 运行单条思考任务时，生成速度约为每秒 95 Token；当 64 条思考任务同时执行时，总生成吞吐量达到每秒 3832 Token。除了混合调度，Prism 还支持 Prefix Cache，以减少连续追问同一份材料时的重复计算。
例如，模型已经读取过一份较长的文档，用户随后提出新的问题，系统可以复用此前的公共上下文计算结果，只处理新增部分。在 StartLux 公布的长材料追问测试中，这一机制将单次追问的处理时间从 48 毫秒缩短至 5.4 毫秒。
单张 H200 测试：最高提速 5.3 倍，高并发吞吐提升 17% 为了评估 Prism 的性能，StartLux 使用单张 NVIDIA H200 GPU、相同的 StartLux-Decision v1.1 27B AutoThink 模型、相同请求及测试程序，对比 Prism INT8 与基于 vLLM 的原有 FP8 推理方案。测试覆盖短问题、共享材料的多问题请求、需要思考的问题、长上下文及高并发吞吐等场景。
从公布的数据来看，Prism 在不同场景中的收益存在明显差异。其中，短问题和共享上下文的多问题请求受益最明显。
约 256 Token 的短问题处理时间从 53.1 毫秒缩短至 19 毫秒；同一份材料回答三个问题的处理时间则从 92.9 毫秒缩短至 17.4 毫秒。对于较长的输入材料，由于模型仍然需要完成大量输入计算，专用输出优化所占的性能收益比例会下降，因此整体加速幅度相对收窄。
在高并发场景下，Prism 也改善了系统吞吐量。根据 StartLux 公布的 JevBench 并发 64 测试数据，每秒处理请求数从 26.3 提升至 30.7，增幅约为 17%。
这也意味着，最高 5.3 倍的加速主要来自特定请求场景下的延迟优化，不能直接等同于所有工作负载的吞吐量提升。除了推理流程优化，StartLux 团队还针对常用计算形状开发了专用 INT8 GEMM 内核。
在 H200 上的指定矩阵计算测试中，该内核的计算性能达到每秒 1240 至 1420 万亿次 INT8 运算，为 NVIDIA cuBLASLt 对应实现的 1.3 至 2.0 倍。这一结果反映了针对特定计算形状进行内核优化的潜力，但并不意味着自研内核在所有矩阵规模和硬件配置下都能取得同样的性能优势。
从模型到推理引擎，专用优化正在成为新的竞争方向 DeepSeek 和 StartLux 最近的动作，反映出模型厂商正在更加重视推理系统与模型架构之间的协同优化。 DeepSeek 的 DeepInfer 面向自家模型进行针对性优化，StartLux-Prism 则围绕决策模型的运行特点，减少不必要的输出层计算、复用公共上下文，并优化不同类型请求的调度方式。
两者的具体实现存在差异，但都试图利用模型结构和工作负载的已知特征，进一步提升推理效率。相比需要兼容大量模型架构和任务类型的通用推理框架，专用推理引擎能够针对特定模型和业务场景进行更深入的优化。
不过，这也意味着其适用范围相对有限，性能收益往往取决于模型结构、输入长度、并发规模以及具体硬件条件。从 StartLux 公布的数据来看，Prism 在短问题和共享上下文的多问题场景中获得了较明显的延迟改善，而在高并发吞吐场景下，提升幅度则相对有限。
这说明专用推理优化的收益并非均匀分布，仍需要结合实际工作负载评估。随着越来越多模型开始面向特定任务设计，推理系统也可能进一步分化。
对于模型厂商而言，开源模型权重只是交付的一部分，如何提供与模型特性匹配、具备稳定性和部署效率的推理方案，正在成为另一个需要持续投入的工程问题。