All Tags
JS/TS (14) DevOps (17) 软件设计 (13) Java (7) Others (5) Kubernetes (7) Golang (2) IoT (3) 分布式系统 (6) C# (3) Database (2) 管理学 (7) AI (2)

为什么Tensor Fusion能够颠覆GPU虚拟化 ​

背景 ​

最近在搞公司的云成本治理，大多数云资源成本控制思路很明确，但贵到离谱的GPU费用，一直是头疼的问题。

十月跟一位好友叙旧，碰巧他正在研究GPU虚拟化，看完他的原型演示，直觉告诉我这是个颠覆性技术，甚至有机会创造出独角兽级别的企业。

我们一拍即合，业余时间支棱起来，项目名为Tensor Fusion。

随着对GPU虚拟化的研究深入，我整理了一些干货，既回答我们自己为什么要投身这件事，也回答用户和投资者我们的产品价值在哪。

在展开技术讨论之前，可以先看下Demo，了解Tensor Fusion是什么，使用文档在这里：https://docs.tensor-fusion.ai/，欢迎试用、反馈。

读完这篇文章，下面几个问题你也会有答案。

  • 为什么需要GPU虚拟化？
  • 实现GPU虚拟化有哪些技术，核心原理分别是什么？
  • 这些GPU虚拟化技术的优缺点是什么？
  • 为什么业界至今没有出现一个完美的GPU虚拟化和池化方案？
  • 凭什么说我们有机会颠覆这个领域，哪来的勇气和自信？

为什么需要虚拟化GPU ​

在调查公司的GPU成本问题时，我看到每个服务实例独占GPU，虽然每个GPU在业务高峰期使用率能达到70%，但整个GPU集群的综合使用率却从来没有超过20%。

这个例子充分说明了为什么需要GPU虚拟化。如果不做虚拟化，就没法安全地共享GPU，也就是浪费了80%的资源，给云厂商多付了400%的钱！

用专业语言说，GPU虚拟化作用在于：

  1. 虚拟化是共享底层物理资源的手段，可以避免浪费昂贵的GPU资源
  2. 虚拟化能够隔离故障、内存地址、控制配额，这是安全实现多租户的前提
  3. 虚拟化是弹性扩缩容的基础，能够在业务高并发时，减小尾部延迟，提升吞吐量

IaaS发展这么多年，CPU虚拟化已经近乎完美了，但GPU竟然还在挂载调用物理设备，明显不合常理。

那GPU能虚拟化么？可以，业界有哪些方案，分别存在什么问题呢？

四种GPU虚拟化技术 ​

目前业界有四类解决方案，我们按照抽象层次从低到高逐个展开：

  1. 硬件和驱动层自带的共享机制，严格意义上不属于虚拟化
  2. 分出虚拟设备实现半虚拟化
  3. 共置任务调度的仿虚拟化
  4. 基于计算库API转发的算力虚拟化

硬件和驱动层的共享机制 ​

GPU硬件和驱动层，一般会自带多用户的隔离和共享机制，每个GPU厂商的做法都不一样。

以NVIDIA为例，自带的共享机制主要有3类：

  1. Multi-instance GPU (MIG) ，多实例GPU。类似切蛋糕，把显卡切成完全隔离的几份。但跟葫芦娃一样，最多只能变出来7个，显存隔离是GB级起步，只有2020年的Ampere架构之后才支持MIG。
  2. Time-slicing，时间片轮转。本质上是显卡默认的多进程共享模式，没有内存隔离、故障隔离。NVIDIA在Kubernetes中的实现也很简单粗暴，假装有多个GPU，背后就是同一个设备，塞给多个Pod用而已，其实没法限制每个Pod内再启动N个进程抢更多的时间片。Time-slicing就好比聚餐时轮流捞火锅，谁真要一勺子捞走一锅肉也没办法。
  3. Multi-process Service (MPS), 多进程GPU服务。MPS是Time-slicing的变体，大致原理是让多进程共享CUDA Context，MPS调度器就能见缝插针，让多个任务在有闲置资源时并行，而不是Time-slicing的并发+CUDA上下文切换。在2017年之前，NVIDIA提供了mps-server在软件层调度，2017年之后的Volta架构GPU，引入了Hyper-Q硬件调度，MPS模式同时使用GPU的进程数数也扩大到了48个，显存地址空间隔离也做了，但没有内存OOM保护和故障隔离，大多数情况效率高于Time-slicing。MPS可以通俗理解成餐厅叫号，只要桌子空出来就能进去吃了。

总结一下，MIG是空分复用（Space division multiplexing），Time-slicing和MPS是时分复用（Time division multiplexing），详细的对比可以参考这篇文档。

MIG和Time-slicing/MPS结合，可以实现类似GPU虚拟化的效果，但粒度太粗，无法从根本上提高GPU使用率，也都不可能做到显存超卖，如果用了Time-slicing，还会带来降低可用性、增加延迟的风险。

在实际应用中，虽然这种方案做不到对GPU的细粒度资源控制，但好在简单易行，搭配上Kubernetes集群自带的池化调度能力，能满足最基本的业务需求。

社区有个开源项目Nebuly NOS，基于NVIDIA的MIG+MPS在Kubernetes中动态切分GPU设备，比NVIDIA提供的原生Kubernetes方案更自动化、调度效果更好。

用虚拟设备实现半虚拟化 ​

1. 虚拟设备是什么？ ​

虚拟I/O设备在IaaS领域发展多年了，这条路算是”原教旨主义GPU虚拟化”。

实现时虚拟设备，为了尽可能避免性能损失，一般不会用纯软件模拟设备做全虚拟化，而是采用兼顾性能和安全的半虚拟化。

大体思路是：把危险的设备控制层隔离在Hypervisor、把设备的数据和功能层直通(Passthrough)到虚拟机中。

虚拟设备在技术层面比较复杂，比如用IOMMU隔离内存页表，隔离驱动函数指针等等，这里不再展开。

2. 实现虚拟设备的3种变体 ​

实现GPU虚拟设备的技术有3种变体，VFIO + SR-IOV, GRID vGPU, VirtIO。

  1. VFIO + SR-IOV。VFIO怎么理解呢？我们把VFIO拆成“VF”和“IO”，VF就是虚拟函数(Virtual Function)，虚机调用VF，设备再映射成PF(Physical Function)。那VF是怎么实现呢，答案就是后面的SR-IOV。SR-IOV这是一种PCIe设备虚拟化标准，硬件厂商支持了这种标准，Hypervisor就能按这个标准来管理“设备分身”了，GPU虚拟化用VFIO+SR-IOV的主要是AMD，性能损失在4%以下。
  2. GRID vGPU。GRID vGPU是NVIDIA独有的商业化虚拟设备方案。NVIDIA很久之前就搞出了GRID vGPU，不仅不开源，还单独收费，License挺贵的，逼的云厂商也得想办法自研NVIDIA显卡的虚拟化。技术细节不展开，大体上是用Mediated Device (mdev)和修改设备驱动，实现了类似VFIO + SR-IOV的效果。毕竟NVIDIA已经世界第一市值了，还遵循什么标准，他自己就是标准。除了NVIDIA, Intel显卡虚拟化技术Intel GVT实现思路类似。
  3. VirtIO。在SRV标准推广之前，VirtIO技术就存在了。实现思路很简单，是给虚拟机注入一个“假的驱动”，Hypervisor再从Host-Guest共享内存中读取I/O请求，转发到宿主上“真的驱动”，最后通过共享内存返回给Guest VM，完成一次设备I/O。VirtIO引入了“驱动前端”和“驱动后端”两个概念，在VM中看到的只是一个可以灵活修改的驱动前端，性能损失比前两者稍高一些，但灵活性强。在GPU虚拟化方面，社区有一个qCUDA 玩具级项目用的是VirtIO。

在应用方面，卖GPU虚机的云厂商最需要传统的虚拟设备技术方案，因此各大云厂也自研出各种类似的方案，比如 阿里云cGPU 、华为云xGPU。

3. 为什么虚拟设备不是终解 ​

虚拟设备看起来已经不错了，对单个GPU设备的显存控制能到MB级别，算力能控制到1%/10%级别，在OS内核态运行，安全性也有成熟技术的保障。

GPU虚拟化到此为止了吗？

当然没有。

我们只要问一个问题：用户需要什么？

用户是要一台带GPU的虚机吗？是GPU上的6912个CUDA core，4200MB VRAM吗？

都不是，我们从第一性原理思考。

用户要的是：能够进行各类神经网络模型的训练/推理，完成业务目标。所以，要有一种“东西”，帮Ta完成以每秒万亿浮点数计的张量计算。

那有没有办法，在有限的GPU资源池中，尽可能又快、又多、又安全的完成多个租户提交的计算任务呢？

思考到这个维度，GPU设备本身的虚拟化就不再重要了，设备提供算力，算力的隔离和共享 -- 算力的虚拟化，才能从根本上满足用户需求。

再从业务角度看，虚拟设备这条路有什么局限性呢？

  1. 虚拟设备的资源配额是固定的，不能跟随业务峰谷自动调整，导致动态调度空间不大，整体资源利用率还是上不去
  2. 能超卖CUDA Core，但一般没法超卖显存(VRAM)，二者比例失衡，VRAM极有可能成为超卖瓶颈，业务调度不上去
  3. 物理GPU设备必须挂在宿主机上，还必须要在业务运行环境设备挂载、安全驱动，影响弹性、增加管理复杂度
  4. 不可能做到跨机多卡共同加速一组计算任务，没办法降低业务延迟
  5. 过于依赖硬件厂商，没办法构建多个厂商GPU设备混一起的异构集群，业务还是很容易被GPU厂商锁定

共置任务调度的仿虚拟化 ​

在虚拟设备的局限性中，第一条最严重：当业务有明显峰谷时，GPU利用率还是上不去。

因此，市面上还有第三类方案，专注于解决GPU利用率问题，这类方案的关键创新在于：把调度粒度从粗的设备级别，下钻到了细的计算任务级别。

相当于在设备之上，抽象出了一个“算力中介”，用户只要告诉这个中介自己要算什么，至于用哪些GPU上的哪些StreamMultiprocessor去算，由中介统一调度。也就是说，虚拟化的对象，从GPU设备，升维成算力。

就像盖房子，一般会去找包工头，包工头可以同时接多个项目，按事情的最优顺序一件一件分给施工队，对于施工队来说，抽象出“包工头”后，整体效率远高于让客户直接雇佣工人。因为，调度粒度从”工人“变成了“任务”。

具体怎么实现呢？首先系统允许多个应用并发使用GPU执行计算任务，这些任务叫共置任务（Co-location tasks），应用层会调用用户态计算库，比如NVIDIA libcuda和AMD HIP SDK，那么，在这里横切一刀，截面上加一个限流器，控制这些共置任务如何流进物理设备，就能实现精准的资源配额。

这个截面，通常是用LD_LIBRARY_PATH / LD_PRELOAD两把刀切开的，完全在用户态处理，性能损失极低。 限流器一般用令牌桶算法，桶里剩多少，是异步线程调用nvml库获取的GPU实时监控数据判断的。

调度器上层，再通过Kubernetes Device Plugin暴露算力配额接口给用户，让用户在resources中写上类似"nvidia.com/vgpu: 1%" 的requests/limits，搭配原生的或定制的Kubernetes调度器，实现集群级别的池化算力分配。

这样实现效果很像虚拟设备，但并没有做内存地址隔离和故障隔离，不能算严格意义的虚拟化，我们姑且叫共置任务调度的仿虚拟化。

下面是学界和业界比较典型的几个实现：

  • Gaia GPU：这篇2018年腾讯和北大发的论文的实现方案，论文有43次引用，其他近几年类似研究大多是GaiaGPU的后续优化
  • KubeShare & Kernel Burst：引入Kernel burst概念和预测任务执行机制，进一步提升了调度效率，实现了单GPU卡上的Auto Scale
  • Ark GPU：引入了负载预测模型提升任务调度效率，并且区分LC(Latency-Critical)和BE(Best-Effort)两种不同的QoS，控制调度优先级
  • Project HAMI：多个云厂商共建的CNCF Sandbox项目，以前叫k8s-vGPU-scheduler，侧重于在业界落地，支持了更多GPU设备厂商，关键的拦截和调度控制代码在HAMi-core，和GaiaGPU底层代码几乎一模一样
  • RUN AI：一家已经融资了**$1.18亿**的以色列创业公司产品，从Demo看，很有可能也是借鉴了GaiaGPU，但做了更多的企业级功能，比如动态调度、GPU集群控制台。

还有一个有意思的项目是HuggingFace ZeroGPU，是HuggingFace CEO Clem Delangue在今年刚投了一千万刀，建设了免费使用的A100推理集群，降低AI开发者门槛，半公益半商业化性质。

HuggingFace ZeroGPU关键代码在Gradio SDK，从源码看，这个项目Hook的是更高层的Pytorch API，而不是底层的NVIDIA Driver API，搭配Gradio SDK中实现的@space.GPU装饰器，拦截Python推理函数，让调度器对GPU资源进行配额判断，配额不足就让任务等待，足够就本地8xA100选择GPU执行推理，当函数冷却后，把显存从GPU中置换出来，放入NVMe盘。

ZeroGPU这种Hook高层API也能做到GPU分时复用和QoS，但没法细粒度控制每个应用能使用多少VRAM，比如ZeroGPU就允许每个应用最多占据一个完整的A100-40G VRAM。

总结一下，第三类共置任务调度的算力虚拟化方案，已经把虚拟化的对象做到了算力这一层，对AI底层计算库加装限流器，再配合Kubernetes自带的池化静态调度，实现了相对灵活的资源控制和多租户共享。

但这还不够，为什么呢？

除了上述虚拟设备路线的问题2/3/4/5没有解决，从整个GPU池的角度看，还有这几个新问题没有解决：

  • 仍然没有脱离GPU设备的桎梏，CPU部分和GPU部分的调度耦合在一起，无法独立扩缩容，做不到GPU部分的Scale to Zero再亚秒级Warm-up。
  • 拉远视角看整个GPU集群，虽然借助Kubernetes的分布式调度器部分实现了池化，但没有做主动碎片整理、GPU池本身的扩缩容，调度效率提升不到下一个Level，运维成本仍然很高（上面提到的方案只有 run.ai 做了主动调度和碎片整理）
  • 都没有做故障隔离、内存地址隔离，在多个不可信租户共享的场景下不够安全。

那是否可以沿着这条路再往后想一层，彻底解决这些问题呢？

基于计算库API远程转发的算力虚拟化 ​

我们回到第一性原理继续思考下去，找根本解。

既然要极致的共享GPU算力，就得想办法把所有算力集中到一个大池，对整池进行细粒度调度。

就像解决IaaS层的存储效率问题，分布式的NFS/ObjectStorage已经成了事实标准。NFS把硬盘变成远端存储服务，实现了存算分离架构。

以此类推，如果把GPU变成远端算力服务，实现GPU-CPU分离，就能把整个GPU集群实现算力融合+细粒度调度控制的架构，就像把GPU当成NFS用。

GPU独立池化后的极致状态是，每个应用都可以用到所有的GPU资源。这种AI算力融合的架构，也是我们把产品名定为Tensor Fusion的原因。

举个通俗的例子，大家是否想过，为什么鸟类脑子那么小，却跟哺乳动物有同级别的智能？

下图是人类大脑结构，处理每种感觉都有独立的脑区，相当于为每个AI模型分配了独立的GPU/vGPU。

而鸟类的大脑结构是不分脑区的，下图是鸟类大脑的截面图，每种感觉都可以利用全脑做神经计算，这就是Tensor Fusion的效果。

生物演化很难“撤回”，哺乳动物的大脑只能继续“大力砖飞”了，而人为设计的软件，不妨借鉴下鸟类的大脑。实现GPU-CPU分离架构后，融合了GPU计算池，上面提到的所有问题都能从更高维度彻底解决：

  • GPU利用率问题：GPU as service后，造出了一个跟业务解耦的控制面，能够实现复杂的调度策略、资源碎片整理、甚至是业务无感的Scale to Zero、GPU物理池的自动扩缩容。这种对GPU池使用率极致的整形能力，产生了GPU利用率的质变。
  • 超卖资源短板问题：GPU-GPU解耦，宿主上的CPU/Memory不再成为GPU超卖瓶颈。最关键的显存不够问题也能轻松解决，很容易实现内存/NVMe找补显存，这些慢一点的“假显存”分配给低QoS的业务使用，收到推理请求时，在毫秒/亚秒级置换到真显存中，打破显存超卖瓶颈。
  • 业务和GPU设备耦合问题：GPU远程池化后，AI Infra和AI App的关注点分离，允许AI业务跑在没有驱动、没有GPU的CPU机器上，系统只需要自动注入一个KB级别的libcuda stub，就能在不侵入业务的情况下让任意CUDA程序跑起来。而动辄3-6GB的Pytorch/CUDA/CUDA-cudnn镜像，也能瘦身到MB级别。解耦后对业务还有一个惊喜，远程GPU池化架构很容易做到跨机多卡的计算加速，降低业务延迟，增加吞吐量。
  • GPU厂商锁定问题：当业务不再依赖底层驱动库和CUDA Runtime，就有办法借助类似ZLUDA的技术，构建多个厂商GPU设备混在一起的异构集群，对业务层提供一致的CUDA API。而不用像现在一样，换一种GPU要把整个业务和Pytorch改一遍。
  • 虚拟化的安全问题：算力虚拟化的实现在远端，业务侧只有一个Stub，那么故障隔离、内存地址隔离都更容易实现，让多个不互信租户共享GPU池。

既然基于计算库API远程转发做算力虚拟化和池化看上去很完美，可行性如何呢？

其实学术界在很早之前就探索过这条路，先驱是2010年发表的、已被引用400多次的rCUDA论文，大致原理是，通过LD_LIBRARY_PATH或LD_PRELOAD拦截CUDA API，进行网络转发，到有实际GPU设备的服务端创建一个影子线程或进程，重放客户端的CUDA调用。

然而，命运的馈赠早已暗中标好了价格。

算力虚拟化看上去架构很完美，但要拦截和实现所有的计算库API，还要做大量的底层优化来避免网络转发带来的性能影响，技术难度、工作量都远高于前三种。

rCUDA在4年前停止更新了；GPULess只实现了60多个CUDA函数的Stub；商业产品BitFusion被VMWare收购后去年也停止维护了。

前辈们验证了可行性，后浪推前浪，现在仍然有一群极客在这条路上继续探索。为了做竞品分析，我整理了所有类似的现存产品：

  • 趋动科技Virt AI：没开源，从产品介绍中推测可能用的是Remote CUDA API转发方案，或是组合了几类技术。Virt AI在2020/2021年拿到了拿到了$30M融资。市场主要在国内，做多个国产GPU厂商的CUDA适配，没有看到出海的意愿，因此和我们Tensor Fusion的目标市场不一样
  • Project scuda：两个月前刚出现的开源项目，看源码离我们Tensor Fusion的成熟度还差的非常多，但仅2个月就已经550多Star了，可见业界有很多人在等一个真正能用的rCUDA方案。
  • ThunderCompute：5个月之前刚拿到YC/AWS/GCP/NVIDIA的Pre Seed轮$500K的融资，目前方向是卖算力，允许客户端通过本地机器走互联网用远程GPU池。其实我们也尝试过走互联网，测试发现对AI推理业务延迟影响很大；而且从商业视角看，自建GPU池卖算力我认为不是最优商业模式，这家初创公司的技术应该也很强，但商业战略错了，迟早会撞南墙的。
  • JuiceLabs: 4年前融资的，目前没看到广泛使用的产品，也没看到近年的融资记录。

总结一下，目前在CUDA API网络转发做GPU大池调度路线上，能产生商业影响力的，只有VirtAI和ThunderCompute两家公司，现存的几家公司，恰恰证明了这条路的可行性和商业价值。

这是一条少有人走的路，难，且正确。

Tensor Fusion的机会在哪里？ ​

既然有个别创业公司在做类似的事情，我们做Tensor Fusion的机会在哪呢？

从调研结果看，我们和这第四类技术路线的几家公司目标市场不重合；而跟前三种技术路线产品的正面交锋，除了上面分析的架构优势，我们从市场、产品、团队、技术方面看，都有足够的底气。

市场 ​

  • 从市场规模看，GPU硬件市场在2024年已经达到了615.8亿美元，年复合增长率28.6%，在2032年预计年营收达到4610.2亿美元，这个市场前景让95%市场份额的NVIDIA成为了世界第一市值公司。那么，GPU管理和优化的SaaS，哪怕只占硬件市场规模的1%，仅看2024年，也至少有6.1亿美元的潜在市场规模，而目前只有极个别AI Infra公司在做这个细分领域，市场一片蓝海。
  • 从目标市场看，Tensor Fusion面向海外云厂商、拥有GPU集群的AI SaaS，和国内相对较为成熟的趋动科技(Virt AI)错开生态位。因此，目标市场有重叠的，主要是选择第三种技术路线的Run.AI，超越这家公司只是时间问题。
  • 从市场细分看，我们会先从中小型云厂商、AI SaaS开始，做方案验证，等落地成熟后，逐步向HuggingFace、AWS这些中大型云厂商/AI SaaS推广方案。

产品 ​

产品成熟度上，目前市面上没有任何产品能做到远程GPU池 + 虚拟显存扩充 + 动态调度，Tensor Fusion不仅是独一份，而且已经在一家公司落地验证了。

这家公司有个AI动手实验室产品，用户购买后能得到一个ComfyUI/SD环境学习AI绘图，用户可以自定义绘图流，选择不同的AI模型。

用了Tensor Fusion之后，ComfyUI/SD部署在廉价的纯CPU-based VM上，仅当用户执行绘图动作时，按需调度远程GPU池进行模型推理，绘图完成后10秒不活跃后将显存置换出去，GPU再共享给其他用户用。

系统上线后，为这家公司至少降低了AI Hands-on Lab产品90%的成本，顺便解决了云厂商GPU库存不足购买失败问题。

产品形态上，Tensor Fusion提供端到端的GPU效率管理方案，把调度效率、可见性、稳定性做到极致，专注于服务云厂商、AI SaaS。

产品战略上，我们不会去自建算力池跟客户抢蛋糕，而是与云厂商/AI SaaS合作双赢，为他们提供更多的AI Infra产品、技术咨询服务，在长期形成产品壁垒和渠道壁垒。

团队 ​

Tensor Fusion原型产品，是我前同事和老朋友Andy开发的，Andy是连续创业者，Tensor Fusion的创始人，也是手撸虚拟机的极客，创造力和底层编码能力非常强。

作为创始人之一，我在IaaS/PaaS领域有一些技术见解，工作过程也积累了不少海外云厂商资源。这些年在公司内算是连续创业，产品、技术、营销、管理都有涉及，有信心做好公司运营、团队管理。

第三位创始团队研发骨干是Carl, 在工作之余，Carl贡献过一些顶级开源项目，比如Golang, Kubernetes, TiKV, Supabase，写过RISCV模拟器和WASM Runtime，对底层系统级编程轻车熟路。

我们计划融资后，再正式邀请2-3位有强烈创业意向的优秀研发。

目前创始团队的销售和运营负责人虚位以待，我正在想办法在海外寻找这位潜在的Co-founder。

技术 ​

除了上面分析的架构优势，具体到技术细节，我们有三个关键优势。

  • 首先是底层优化，凭借团队对CUDA的深入理解和算力虚拟化落地经验，Tensor Fusion实现了内存补显存、launchKernel函数的底层优化、高性能通信协议等等，这些技术壁垒短期不太可能被超越。
  • 其次是调度器，我们正在开发GPU上下文热迁移 + 基于AI预测的动态算力调度器，让每个推理业务能够跨机利用大池中的GPU资源。JIT主动调度，相比于传统的Kubernetes Scheduler Plugin的AOT被动分配，会跟业界现有方案形成代差。
  • 最后是无缝接入能力，基于Kubernetes生态和一些“跨界技术”，实现了业务0侵入接入、0配置迁移，极大降低了用户的迁移和采纳成本，这个技术是任何现有方案找不到的。

总结 ​

本文介绍了GPU虚拟化的背景和目的，展开讲解了学界和业界四种GPU虚拟化技术路线。

通过层层递进的分析，回答了为什么Tensor Fusion选择了计算库API远程转发的算力虚拟化这条路，以及在AI Infra的GPU集群效率管理这个赛道上，Tensor Fusion的机会在哪，为什么是我们能做成这件事。

我自己坚信Tensor Fusion的价值，源自对云计算的理解：不管是IaaS/PaaS/SaaS，云的根本价值是共享带来的效能质变。

在IaaS领域，这种抽象、隔离、调度实现共享的机制，就叫虚拟化。

而虚拟化的本质，或者说IaaS中共享的本质，是把高边际成本的物理资源，抽象、封装成极低边际成本的逻辑资源，通过对逻辑资源的隔离和调度，共享了物理资源，提升了效能。

逻辑资源的抽象越接近用户需求，物理资源的调度越细致，云的能效比就越高。

因此，我们相信Tensor Fusion有机会成为AI Infra领域新星，助力AI浪潮改变世界。

目前我们也在寻找能够理解硬核技术创新、具有全球化市场资源的投资机构，欢迎有投资意向的大咖垂询。

Reference ​

  • Duato, José, et al. "rCUDA: Reducing the number of GPU-based accelerators in high performance clusters." 2010 International Conference on High Performance Computing & Simulation. IEEE, 2010.
  • Reaño, Carlos, and Federico Silla. "Redesigning the rCUDA communication layer for a better adaptation to the underlying hardware." Concurrency and Computation: Practice and Experience 33.14 (2021): e5481.
  • Tobler, Lukas. Gpuless–serverless gpu functions. Diss. Master’s thesis. ETH, 2022.
  • Gu, Jing, et al. "GaiaGPU: Sharing GPUs in container clouds." 2018 IEEE Intl Conf on Parallel & Distributed Processing with Applications, Ubiquitous Computing & Communications, Big Data & Cloud Computing, Social Computing & Networking, Sustainable Computing & Communications (ISPA/IUCC/BDCloud/SocialCom/SustainCom). IEEE, 2018.
  • Song, Shengbo, et al. "Gaia scheduler: A kubernetes-based scheduler framework." 2018 IEEE Intl Conf on Parallel & Distributed Processing with Applications, Ubiquitous Computing & Communications, Big Data & Cloud Computing, Social Computing & Networking, Sustainable Computing & Communications (ISPA/IUCC/BDCloud/SocialCom/SustainCom). IEEE, 2018.
  • Liu, Zijie, et al. "KubFBS: A fine‐grained and balance‐aware scheduling system for deep learning tasks based on kubernetes." Concurrency and Computation: Practice and Experience 34.11 (2022): e6836.
  • Yeh, Ting-An, Hung-Hsin Chen, and Jerry Chou. "KubeShare: A framework to manage GPUs as first-class and shared resources in container cloud." Proceedings of the 29th international symposium on high-performance parallel and distributed computing. 2020.
  • Chen, Hung-Hsin, et al. "Gemini: Enabling multi-tenant gpu sharing based on kernel burst estimation." IEEE Transactions on Cloud Computing 11.1 (2021): 854-867.
  • Lou, Jie, et al. "ArkGPU: enabling applications’ high-goodput co-location execution on multitasking GPUs." CCF Transactions on High Performance Computing 5.3 (2023): 304-321.
  • Hong, Cheol-Ho, Ivor Spence, and Dimitrios S. Nikolopoulos. "GPU virtualization and scheduling methods: A comprehensive survey." ACM Computing Surveys (CSUR) 50.3 (2017): 1-37.
  • A Closer Look at VirtIO and GPU Virtualisation | Blog | Linaro. www.linaro.org/blog/a-closer-look-at-virtio-and-gpu-virtualisation
  • Brief Introduction of GPU Virtualization | Blog | Aliyun. developer.aliyun.com/article/590916
  • Run TorchServe with Nvidia MPS | Blog | Github. github.com/pytorch/serve/blob/master/docs/nvidia_mps.md