当研发效率撞上算力天花板
高并发算力缺口，混合调度、成本可控是EDA混合云研发平台的三大痛点。
AI芯片设计公司X，一家通用AI芯片公司，重点打造高性能云端AI加速芯片。
X公司的发展蒸蒸向上，除了目前手上的项目，即将又有3个新项目上线，而且新项目架构复杂、规模大比原来项目大5倍以上，本就捉襟见肘的本地集群将更加吃力，面对多项目并行研发，项目高峰时对算力波峰较大的挑战，X公司首先想到的就是本地+云的解决方案。
混合云的两难困境
"直接扩容公有云不行吗？"，技术团队心知肚明——
- 海量仿真数据集迁移成本高
- 本地和公有云是两套集群，不改变现有研发的使用流程情况下两套集群如何统一调度
- 云端按需采购虽灵活，但突发性需求可能导致月度账单失控波动
这种困境恰似"量子纠缠"：本地集群与公有云明明都是算力载体，却因调度壁垒形成两个孤立宇宙。
所以，X公司需要的一个新的EDA混合云研发平台——
- 统一调度本地与云端资源：打破本地集群与公有云的割裂，实现算力池化，研发人员无需切换平台即可调用混合资源。
- 无缝兼容现有工作流程：支持LSF调度系统集成，保持研发人员的使用习惯。
- 动态扩缩容与成本优化：根据项目需求智能匹配资源，避免过度采购或闲置浪费。
MemVerge的解决方案
引入MemVerge后，X公司新的EDA混合云研发平台更像一个智能AI，研发工程师每天只需要按照原有的LSF调度系统的使用习惯，提交job即可，剩下的操作Mem Verge平台可以自动完成。
- 优先使用本地2500核集群资源
- 通过历史任务建模预测云上负载
- 在本地资源占用达85%阈值时预热云资源池
- job运行数据及时采集分析优化新的调度策略
（以下基于真实场景改编，已做技术细节脱敏，在本案例中假设单job单核）
01
我需要做前端回归验证，先提交3000个job，但我们本地只有2500核的集群，现在应该还有部分任务在跑，我要怎么拆分这3000个job？
{thinking……}
嗯，用户现在需要做前端回归验证，提交了3000个job，已知目前本地LSF集群只有2500核，可能还有部分任务在运行。首先，我弄清楚了当前本地集群中有500核被小A的任务占用了，那么就只剩下2000核可用。我需要确保所有任务能高效运行，同时避免资源过载。
接下来，用户面临的是资源不足的问题。可能的解决方案为，我需要拆分这3000个job，根据本地空闲资源量和历史数据分析，第一批我将选择其中2000个job优先分配到本地集群队列fe中。
现在的问题是剩下的1000个job，根据用户任务紧急程度，我的解决方案是burst到云上集群，解决本地资源不足同时不想排队等待的问题。
已执行，其中2000个job优先在本地集群队列fe运行，另外1000个job自动burst到云上集群运行。
02
我提交到云上的1000个job，job所需要的算力有大有小，我要如何匹配机型？
{thinking……}
嗯，用户需要知道如何为云上1000个job寻找合适机型，根据这些job历史运行数据分析得知，我知道其中部分800个job需要800核资源，另外200个需要使用200核资源。
接下来，我会在云上映射一个虚拟队列fe，其中包含了8c16g机器100台（800核）；8c64g机器25台（200核）。
已知我在单任务的启动开机时间上，较业界同类主流调度平台，能缩短40%-50%，因此我将在短时间内迅速拉起大规模集群投入作业。
已执行，云上启动8c16g机器100台；8c64g机器25台。
03
我的新项目中有1500个job，比较紧急，新项目不清楚算力用多少，怎么办？
{thinking……}
嗯，用户提交了1500个紧急job，已知今天本地集群已满，目前40台机器都在满负荷运行中，我需要将用户的任务放到云上运行。
现在的问题是：这1500个job来自新项目，我的数据库中没有历史数据支持，无法准确判断这需要的算力资源有多大。
接下来，我的解决方案是将1500个任务分配到云上队列sim，先选择队列sim的默认机型32c256g，那么我需要47台。
最重要的是，我需要收集本次运行数据作为后续调度机型的参考标准。
已执行，您的1500个job将在云上队列sim中运行，需要47台。我将在任务运行结束后收集本次运行数据——所需要核实和运行时长等，当您后续提交该类型job时会第一时间优选最匹配机型。
“并发性能提升10倍以上、任务排队等待时间减少90%左右。”X公司的研发工程师感叹平台带来的效果，而且不改变原来的代码使用习惯，完全无感知体验这种智能化的调度。项目运行一个月后，云上算力成本投入比原来直接上云还节省30%。
