前后不过两分钟，大会议室便清空了，只留下韩路一和江松然两人。
视频里，赵文渊开口问道：“韩总，是因为算力的事儿？我刚才听老江的意思，进度好像不太够吧？”
江松然点了点头，确实不够。
眼下是巧妇难为无米之炊：调度架构做得再好，计算卡总量就这么多，也很难再腾挪出更多算力。
韩路一说道：“留下二位，就是想聊这件事。老江，上次咱们做的调度优化，你先给文渊讲一讲。”
韩路一指的是汤圆1.0模型API正式发售前，基础设施部门在任务调度上做的一些新优化架构。
那段时间的难题是：每个推理任务进来，服务器端都判断不了任务复杂程度，也就没法分配合适资源。大任务分给小资源池，任务完不成，就要重试；反过来，小任务分到大资源池，实际用不上那么多算力，又会造成浪费。
在韩路一建议下，江松然引入汤圆自身来做调度判断。这类判断任务都是小任务，初次判断后就能规避很多失败场景。于是，在相同算力下，起源推理集群能支持的并发量直接增加了三分之一。
但这只是江松然他们在应用端对汤圆的一种用法。现在韩路一把赵文渊叫来，是想看看模型层面还能不能再做些优化，把性能再提一提。
没办法。如果起源也能像谷歌、OpenAI那样算力富裕，甚至能有鼎盛那么多算力，这些软件层面的优化并不急迫，甚至不做也行。
可眼下硬件算力捉襟见肘，就只能从软件层面想办法。
江松然点了点头，把困扰基础设施部门许久的问题说了出来：“用汤圆做初次调度判断，确实极大地提高了资源分配效率，但我们也逐渐发现了两个问题。”
“什么问题？”赵文渊问。
“速度太慢。”江松然说道。当初韩路一提出用汤圆模型做路由时，他就想到了这个问题：每秒钟数万的并发请求，如果每个请求都要提前过一遍汤圆，相当于把请求数直接翻倍。还是韩路一提出了折中方案——对于多步骤请求，只对第一步估算任务难度。
可即便这样，一次估算也要消耗数百毫秒。可别觉得几百毫秒很短：在高并发场景下，这点延迟就可能引发雪崩效应——延迟导致请求超时，超时又引发重试，无效请求增多，甚至让整个服务不可用。
“赵总，汤圆本身是大参数模型，即便采用稀疏架构，一次几百毫秒的用时也不是调度层承受得起的。慢是第一个问题；还有因慢导致的第二个问题：汤圆做任务预测精度虽高，但延迟太长，我们只敢在任务链开始时加上，之后只能依赖第一次的预测结果。可有些用户请求会在交互过程中突然增加复杂度，若还沿用第一次的测算结果，就会不准。”江松然说道。
韩路一在旁边也听懂了：江松然虽说了两个问题，本质却还是速度慢——因为慢，不敢每次调度都调用一次，精度便随之漂移。
“文渊，这就是我专门把你叫过来的原因。”韩路一开口道，“上次我们聊过，给汤圆做一个轻量版，你觉得能不能解决这个问题？”
专业旗舰版验证过性能后，再推出参数更小、能力稍弱但成本低很多的轻量版，本来就是业内通行做法。
这类轻量版一般通过蒸馏原始旗舰模型后训练出来。所谓蒸馏，是把一些高难度问题输入旗舰模型，让它给出答案，再用这些问题和答案作为训练集，给轻量模型做后训练。这样能以较低成本让轻量模型拥有旗舰模型70%到80%的能力，算是比较有性价比的做法。
当然，也不一定非蒸馏自家旗舰模型，用同样方法蒸馏别家旗舰模型也可以。自汤圆API开放以来，起源集团已经发现并捕捉了不少试图蒸馏汤圆1.0的行为，很多请求来自美国。
听完韩路一的话，赵文渊沉吟片刻。
轻量模型在这方面确实有帮助，甚至可以像当初的汤圆0.1那样，用一个极小模型来预测任务复杂度——只要保证预测精度别掉得太离谱。
但是——
赵文渊开口道：“你们有没有听说过系统一和系统二？”
韩路一和江松然对视一眼，同时点头。
系统一（System 1）和系统二（System 2）的概念源自诺贝尔经济学奖得主丹尼尔·卡尼曼的研究，在他的科普畅销书《思考，快与慢》中有过详细阐述。
人的大脑在思考时有两套系统：一种运转极快，善于快速判断，但因没有激发深度思考，也容易被噪音干扰，这叫系统一；另一种叫系统二，需要人主动花费精力仔细思考，耗时更长，最终结论也更准确。
这本书当然不是计算机领域著作，但它足够畅销、足够有名，两人恰好都读过。
其实，赵文渊和研究者同行们当初提出思维链（CoT，Chain of Thought）的概念，正是借鉴了人脑系统二。
只是不知道他突然提这个做什么？
韩路一说道：“这和我们讨论的内容有什么关系？你是想说，我们可以借助系统一来快速估算任务复杂程度？”
说到这儿，韩路一突然意识到什么，问道：“我们刚才讨论的用轻量模型做路由，不就是系统一的思路吗？”
哪知赵文渊摇了摇头，说道：“韩总，您说得对，但还不够。您知道在人脑的决策系统里，系统一之所以能比系统二更快，还有一个重要原因是什么吗？”