【润建股份：Token产能提升700%，GPU到底卡在哪儿？】700%。这是润建股份给五象云谷Token工厂报出的产能提升幅度。公司还披露，五象云谷目前每小时具备约2000亿Token的吞吐能力。这个数字有意思的地方，在于润建股份公布的优化清单。除了GPU，它连显存怎么分配、请求怎么排队、服务器之间怎么传数据，甚至机房怎么供电、怎么散热，都纳入了优化范围。一张GPU的计算能力，出厂时基本就定下来了。可装进数据中心以后，它能处理多少AI请求，还得看周围一整套系统怎么配合。不过，700%是公司披露的总体提升，公开资料没有给出完整的对比基线。不能直接理解为GPU数量不变，靠软件就多生产了700%的Token。想弄清这套技术，先看一个普通的AI请求，怎么把昂贵的GPU拖慢。一、三个请求，把GPU堵住了上午九点，一家企业的AI助手开始忙起来。客服问了一个简单问题，法务上传一份上百页的合同，市场部还让AI生成一篇两千字的方案。三个请求同时进入机房。客服的问题很短，几句话就能回答。法务的合同却有上百页，模型光是处理输入，就要完成大量计算。大模型推理通常分成两个阶段。第一个叫Prefill，负责处理输入。第二个叫Decode，负责一个Token接着一个Token生成回答。两个阶段的工作特点差别很大。Prefill通常需要密集计算。Decode在不少部署场景下，更容易受到显存带宽限制。麻烦来了。模型正在给客服生成回答，突然进来一份很长的合同。如果系统安排得不好，大量输入计算就可能干扰正在运行的生成任务。屏幕上的回答停住了。GPU没坏，只是几种不同的任务挤在一起抢资源。润建股份披露的五象云谷技术方案里，有一项叫P/D分离。说白了，就是把处理输入和生成回答的任务，安排到不同的GPU资源上。一批负责读取、计算输入，另一批负责持续生成。听起来不复杂，做起来却有个问题。前面的GPU处理完输入，还得把已经算好的缓存传给后面的GPU。如果网络太慢，后面的机器还是要等。把任务分开，只解决了第一道拥堵。二、显存满了，GPU却还没算够还有一种情况更让人头疼。GPU明明还有计算余力，却接不进新的长文本请求。问题可能出在KV Cache上。AI生成回答时，需要不断参考前面的上下文。如果每生成一个Token，都把之前的中间计算重新做一遍，效率会非常低。于是，模型把已经计算出来的部分注意力结果保存起来，后面直接复用。这份缓存就叫KV Cache。它保存的是计算过程中形成的Key和Value，并非简单存一份聊天记录。用户对话越长、同时在线的人越多，缓存通常就占用越多显存。偏偏显存还要放模型权重和其他运行数据。空间被占满，新请求就可能排队。早在2023年，vLLM团队就提出了PagedAttention技术。它借鉴操作系统管理内存的办法，把KV Cache分块管理，减少内存碎片和不必要的空间浪费。在当时的特定测试中，vLLM相较对照系统实现过约2至4倍的吞吐量提升。这个成绩属于vLLM团队，不能算成润建股份的成果。但它说明，GPU和显存都没增加，换一种缓存管理方式，系统就可能同时处理更多请求。五象云谷公开资料中也提到了KV Cache优化。旗下润道星算平台披露集成了vLLM、SGLang等推理框架。具体采用哪种缓存配置、在生产环境中提高了多少吞吐量，公司还没有公布足够完整的测试数据。三、让一万个用户同时问AI，怎么排队？缓存管理做好了，请求还得有人安排。假设一万个用户同时调用模型。有人只问一句话，有人要分析一整份财报，还有人要求连续生成几千字。如果一批任务必须等最后一个请求结束，才能安排下一批，那些提前完成的任务就可能留下空闲资源。为了解决这个问题，推理系统可以使用连续批处理（Continuous Batching）。一个请求完成，就腾出资源；有新请求进来，再根据显存和计算资源情况安排进去。整批任务不必一直绑在一起。润建股份2026年半年报还提到了队列抢占机制和异构算卡细粒度虚拟化。简单理解，系统需要决定哪个请求先运行、哪个暂时等待，以及不同类型的算卡该分配什么任务。另一个技术叫推测解码。正常情况下，大模型逐个生成Token。推测解码会尝试提前生成一批候选Token，再让目标模型集中验证。猜得准，就能减少一部分连续生成的等待；猜得不准，额外计算也可能白费。因此，它在不同模型和负载下的加速效果并不相同。这些技术都在处理同一个问题：怎么减少GPU花在排队、等待和重复计算上的时间。但请求安排得再好，GPU之间还得传数据。模型分布在多张算卡上运行时，计算过程中需要不断交换中间结果。通信跟不上，GPU就可能停下来等别的设备。五象云谷公开技术资料还提到了万卡级集群网络调优，以及800G、1600G高速网络相关能力。十张GPU放在一起，实际处理能力未必就是单张的十倍。GPU越多，集群内部如何通信、如何调度，越难绕开。四、润建股份为什么连供电都要改？再看五象云谷披露的五层优化体系。基础设施、服务器、网络、调度、模型。前面讲的缓存、批处理、推测解码和集群通信，主要集中在后面几层。最底下一层，是供电和散热。五象云谷公开介绍的技术包括220千伏变电站、800伏高压直流和微通道间接液冷。高密度GPU机房需要持续供电。大量服务器同时运行，热量也必须及时排出去。电压、配电方式和冷却系统，都会影响机房运行成本与可靠性。不过，供电效率提高，并不意味着GPU每秒就能多生成同样比例的Token。电力和冷却解决的是稳定运行及能耗问题。缓存管理、推理调度和模型优化，则更直接影响Token吞吐效率。集群网络负责减少不同计算设备之间的数据传输等待。润建股份把这些环节放进同一套优化体系，思路并不难理解。机房得先跑得稳，数据传得快，请求安排得合理，GPU的计算能力才有机会被充分用起来。至于700%的整体产能提升，有多少来自硬件配置变化，有多少来自模型和软件优化，目前还缺少分项数据。五、每小时2000亿Token，究竟算什么水平？10月，润建股份全资子公司五象云谷签订了一份2亿美元跨境Token服务合同。客户通过海外API调用部署在中国境内的大模型，再按Token消耗量结算。服务器留在国内，海外客户使用的是实际交付的推理服务。这也意味着，五象云谷需要长期面对真实客户的调用需求。公司披露的每小时约2000亿Token吞吐能力，已经是一个很大的数字。但要判断这座工厂的技术水平，还得继续往下看。2000亿里，有多少输入Token、多少输出Token？测试时运行的是什么模型？用户发出请求后，要等多久才能看到第一个Token？如果每天持续面对大量请求，吞吐量和响应速度能不能保持稳定？这些问题非常具体。同样的每秒Token产量，一套系统可能回答得很流畅，另一套却让用户排队很久。更何况，生产Token还要承担GPU折旧、电费、冷却、网络和维护成本。公司披露了700%的总体提升和多项技术方案，但完整的测试条件、分项贡献以及单位Token成本，还有待进一步明确。这也是我认为后面最该跟踪的部分。六、贵的GPU，不能总在等假设两座AI工厂用同样的GPU，运行同一个模型。一家显存管理得不好，长文本不断挤占其他任务，GPU之间经常等待数据。另一家能合理管理缓存、安排请求，减少跨服务器通信造成的等待。它们的最终吞吐量和响应速度，完全可能不一样。至于相差多少倍，必须在相同条件下测试。润建股份披露的700%提升，目前还无法直接归因于某项技术，也不能据此断言五象云谷已经比同业领先多少。不过，五象云谷公开的P/D分离、KV Cache优化、推测解码、资源调度和集群网络方案，已经把值得研究的技术问题摆了出来。GPU买回来只是第一步。后面怎么排任务、怎么管理显存、怎么减少数据传输等待，都会影响它到底能干多少活。五象云谷接下来最有说服力的成绩单，应该是同样的硬件和模型、同样的任务压力下，优化前后能稳定交付多少Token，用户需要等待多久。如果这份成绩单能够公开，700%的提升究竟意味着什么，就能看得更清楚。一座AI工厂拥有多少GPU，数一数就知道。那些GPU到底有多少时间在计算，又有多少时间耗在排队和等待上，才是这门技术生意值得继续研究的地方。