- Anyscale 与 Lila Sciences 报告了 64 张 NVIDIA B200 图形处理器上的 GLM-5.3-Flash 训练结果。真实数据让最繁忙专家的负载接近平均值的 4 倍，而且随机 token 基准能够运行的配置可能在真实数据上耗尽显存。
- Together AI 把持续编译连接到真实生产流量，并且 Together AI 报告了最高 2.6 倍的吞吐提升。该结果属于厂商研究，而且该结果依赖具体模型、硬件、基线和服务目标。
- Supermicro、IBM 与 NVIDIA 把键值缓存扩展到共享存储，Buoyant 则把缓存感知、队列感知和租户策略放入 Kubernetes 路由。两组材料都要求企业把性能、隔离、故障和版本成熟度放进同一套验收条件。
真实输入分布改变了训练容量的计算方式
Anyscale 在 11 月 5 日公布了 Lila Sciences 团队扩展 GLM-5.3-Flash 训练的工程记录。该团队使用 64 张 NVIDIA B200 图形处理器处理最长 100 万 token 的序列，并且该团队报告了 100 万 token 序列下每秒 13,700 token 和 25.6 万 token 序列下每秒 24,900 token 的吞吐。该团队还报告了基因组数据在 80 个训练步骤后的留出损失改善 4.8%。这些数字来自团队测试，而不是独立测试。
真实训练数据改变了容量压力的分布。该团队观察到最繁忙图形处理器上的专家负载接近平均专家负载的 4 倍，而且随机 token 基准能够容纳的 51.2 万 token 配置会在真实数据上耗尽显存。该团队估算，100 万 token 序列在上下文并行之前会让每个图形处理器的一层输入接近 180 GB，并且 8 张图形处理器节点的总量会超过 1 TB。该团队使用完整重新计算、中央处理器卸载和上下文并行控制峰值显存，但是这些方法分别增加了计算、传输或通信成本。
对企业落地而言，模型参数量和合成基准无法单独确定训练集群的可用容量。企业需要使用自身序列长度、专家路由、样本分布和批量条件重放容量测试，并且企业需要同时记录峰值显存、通信、每步时间、失败率和收敛变化。Anyscale 与 Lila Sciences 的结果说明了真实数据可能改变瓶颈位置，但是该结果不能证明其他模型、数据或集群会得到相同数字。
真实服务流量推动编译器持续调整推理引擎
Together AI 在 11 月 4 日发布了 Together Compiler 论文。Together AI 把编译过程拆成持续实验、候选验证和受控部署，并且 Together AI 使用真实生产流量保持输入形状、请求组合和服务目标的代表性。Together AI 表示，固定一次的离线优化会随着模型、硬件、框架和流量变化而失效，因此持续编译需要在引擎运行期间不断比较候选配置。
Together AI 报告了平均 1.7 倍和最高 2.6 倍的吞吐提升，并且 Together AI 报告了最高 252 倍的实验吞吐提升。论文同时列出了具体模型、加速器、推理框架和对比基线，因此这些数字只描述论文中的测试范围。Together AI 在候选引擎进入生产之前运行正确性和性能检查，但是公开论文没有替代目标企业对精度、尾延迟、失败恢复和成本的独立验收。
对企业落地而言，推理优化正在从一次性的部署参数转成持续变化的运行过程。企业需要为每次候选配置保存模型版本、编译器版本、流量样本、精度结果、延迟分布、回退条件和批准记录，并且企业需要防止实验流量影响生产租户。Together AI 的结果支持真实流量能够改善优化代表性这一方向，但是厂商研究不能证明所有负载都会获得相同收益。
长提示让键值缓存成为共享基础设施
Supermicro 在 11 月 5 日公布了与 IBM 和 NVIDIA 联合构建的键值缓存方案。该方案把 Supermicro Petascale 全闪存服务器、IBM Storage Scale、NVIDIA Dynamo 和 NVIDIA Spectrum-X 连接起来，并且该方案把长提示的键值缓存从单个推理节点扩展到共享存储。联合团队使用 openai/gpt-oss-120b、4 张 NVIDIA RTX PRO 6000 图形处理器、8 个存储节点、vLLM v0.14.1 和 NVIDIA Dynamo v0.9.0 以上版本开展测试。
IBM Redbooks 文档说明了联合测试的范围。联合团队发送了 200 个请求、使用了 28 个并发连接和 100 个唯一提示，并且联合团队处理了约 2,400 万 token 和 825 GB 缓存。联合团队把冷启动计入测试，并且联合团队在 13 万 token 提示下报告了最高 56 倍的首 token 时间改善和从每秒 0.19 个请求到每秒 4.26 个请求的变化。联合团队还在噪声邻居条件下报告了最高 18 倍的改善。所有结果都来自联合厂商测试，而且结果没有证明其他网络、存储、模型或请求组合会获得相同表现。
对企业落地而言，长上下文推理会把存储吞吐、网络路径、缓存命中、租户隔离和故障恢复带入模型服务的关键路径。企业需要在真实提示重复率和并发条件下分别测试冷缓存、热缓存、存储故障、网络拥塞和噪声邻居，并且企业需要核对缓存中的敏感上下文如何加密、隔离、过期和审计。联合方案已经提供了可复核的测试边界，但是联合方案没有提供独立测试、统一价格、完整供货清单或所有地区的支持条件。
策略路由把性能目标连接到租户治理
Buoyant 在 11 月 4 日宣布 Kinference 可供一般使用，并且 Buoyant 把 Kinference 描述为面向 Kubernetes 的开源推理服务平台。Kinference 建立在 vLLM 之上，并且 Kinference 使用缓存感知、队列感知和请求特征选择端点。Buoyant 表示，Kinference 还支持按租户记录使用量、执行策略并把请求扩展到云端资源。
产品公告与公开文档提供了不同的成熟度信号。Buoyant 的公告使用了可供一般使用的表述，但是 Kinference 的公开文档把当前版本标为 v0.1.0-alpha.7。公开材料没有提供统一价格、完整兼容矩阵、长期支持期限或独立生产基准，因此企业仍需单独验证版本稳定性、升级方式、云端扩展边界和故障条件。
对企业落地而言，路由器不能只追求较高缓存命中率或较短队列。企业需要让路由决策同时遵守数据驻留、租户隔离、模型许可、成本预算、服务等级和人工审批规则，并且企业需要保存每次路由选择及其结果。Kinference 的开源形态可以提供可检查的实现入口，但是公告中的可用状态与文档中的预发布版本标记要求企业把软件成熟度和支持责任写入验收范围。
后续观察
- Anyscale 与 Lila Sciences 能否公布更多真实数据分布下的收敛、通信、能耗和训练失败结果。
- Together AI 能否提供更多独立复现材料，并且 Together AI 能否说明持续实验如何限制生产流量风险和配置回退时间。
- Supermicro、IBM、NVIDIA 与 Buoyant 能否公布统一价格、供货地区、长期支持期限、租户隔离验证和独立生产基准。
来源与核验
本文由英科铸数基于所列公开资料编辑撰写。事实与数据以原始来源为准；“对企业落地意味着什么”为英科铸数结合企业客户场景所作的编辑分析，不构成对第三方产品的背书。
← 返回每日观察