我们做整合调度，常被人问，散在各处的显卡，真能当成一个池子用吗。我们的答案是能，而且这件事的价值被很多人低估了。
闲置显卡的数量大得超出直觉
地球上闲置的显卡数量大得超出直觉。有人买了高端卡挖矿或者跑项目，用一阵就闲置了，机器还通电，卡还好的，就是没活干。这些卡单个看不值一提，聚起来是一张覆盖全球的网。我们估算过，光是个人和中小机房手里的闲置高端卡，总量就够支撑相当一部分推理需求，只是它们从来没有被组织起来。
难点在异构、网络、可用性
问题从来不是卡不够，是这些卡没有被组织起来。它们分散、型号杂、网络条件不一。第一是异构，不同型号、不同驱动的卡，要能在同一套调度下被正确使用。第二是网络，卡在地球另一端，数据怎么过去，延迟能不能接受，实时推理就别想跨洲了。第三是可用性，闲置卡随时可能下线，平台得能预判、能切换。
给这张网加一层预测
我们做的方式，是给这张网加一层预测。根据历史规律，大概知道哪个区域的哪类卡接下来会空闲，提前把可能来的任务往那边引流，而不是等请求到了再临时找。这能明显减少冷启动和排队。我们实测过，预判调度相比临时找卡，平均等待时间能降一大截，尤其是冷门机型，临时找经常要等几分钟，预测引流后基本秒级到位。预测也帮我们避开快下线的机器，在它真关之前就把任务挪走。一次有个冷门卡机型突然大面积下线，因为预测提前把任务导出了，用户那头一个超时都没遇到。
路由策略：不是所有任务都该往最便宜的卡送
延迟敏感的任务，就近优先，哪怕贵一点，用户感知的是速度不是价钱。算力密集的任务，往大卡集中，小卡跑大任务纯属折磨。平台得在成本、速度、稳定性之间替用户做权衡，同一个模型，做实时问答和做离线批处理，走的卡可能完全不同。我们给一个做翻译的用户，实时那路走就近的中卡，批量那路丢到远处的便宜大卡，两端都满意。
代价：平台自己要够聪明
这套打法的好处是弹性近乎无限，也没有资产包袱。代价是平台自己要够聪明，整合得上万家机器的状态，实时算路由，出错能秒级切换。这套调度能力本身就是壁垒。我们见过想学这套打法的，卡接进来了，路由算不明白，结果用户任务一会儿卡在这家一会儿卡在那家，最后客户还是回流到大平台。整合不是把机器列表摆出来，是让它们像一个整体那样干活。我们为了把路由算准，光各区域的网络延迟画像就建了几个月。
一次路由决策里发生了什么
一个做翻译的用户提交任务，我们的路由层在毫秒内做了几件事：看任务类型是实时还是批量，实时就就近挑一张中卡，批量就丢到远处便宜的大卡；看那张卡的预测可用率，低于阈值就换备选；看网络延迟画像，确认不会跨洲跑实时。用户完全不知道背后这几步，他只看到实时那路回得快，批量那路成本低。
预测本身不是玄学。我们按区域、按机型建了历史空闲曲线，大概知道哪个时段的哪类卡会空闲，提前把可能来的任务往那边引流。冷门机型临时找经常要等几分钟，预测引流后基本秒级到位。预测也帮我们避开快下线的机器，在它真关之前就把任务挪走。一次冷门机型突然大面积下线，因为预测提前导出，用户一个超时都没遇到。
路由算得准不准，用户感知不到，但他提交任务后等多久、花多少钱，这两项骗不了人。我们把这两项和稳定率一起做成对外可见的体验指标，而不是内部 KPI，因为整合得漂不漂亮，最终得用用户的等待和账单来打分。
我们走的整合路线，本质上和这件事同源。把分散的、异构的资源变成用户眼里一个干净统一的池子。衡量这张网好不好，不是它有多少卡，是用户提交任务后等多久、花多少钱、稳不稳。这三件事做到了，卡从哪来他根本不会问。卡可以永远是别人的，但把别人的卡变成用户眼里一个干净池子的能力，得是自己的。