Tensor Engine | 同思引擎技术细节解析：为什么 GPU 虚拟化不能只停留在“切卡”

“单卡看起来很忙，整个集群却很闲”到底是怎么发生的

这是很多 AI 平台团队都会碰到的悖论。

单看一张卡，业务高峰期利用率可能并不低；但把视角拉到整池资源，整体利用率却始终上不去。原因也不神秘：业务往往按整卡申请、按峰值采购、按项目绑定。最后的结果是，局部很忙，整体很闲；每个人都觉得卡不够，财务又觉得钱花得太快。

继续追问，本质问题不是“GPU 太贵”，而是 GPU 仍然主要被当作硬件设备管理，而不是被当作算力服务管理。

这也是同思引擎（Tensor Engine）为什么要做 GPU 虚拟化和池化。但这里有一个经常被混淆的点：

不是所有“多人共享一张卡”的方案，都等价于真正适合企业场景的 GPU 虚拟化。

如果不把这个问题拆开，很容易把“能切卡”“能共享”“能调度”“能做大池”混成一件事。其实它们不是一回事。

先把概念拆开：GPU 虚拟化至少有四条路线

如果从抽象层次往上看，当前业界常见方案大体可以分成四类。这个分类很重要，因为它直接决定了你最后拿到的是“一个功能”，还是“一套可运营的算力底座”。

第一类：硬件和驱动自带的共享机制

这类方案的优点是最直接、最容易上手。像 MIG、MPS、Time-slicing，本质上都是让一张卡在不同任务之间分着用。

它解决的是最基础的问题：让 GPU 不再只能一任务一整卡。

但继续追问，它的问题也很明显：

• 粒度通常不够细；
• 很难按真实业务负载动态调整；
• 对混合场景的整体利用率提升有限；
• 很难从整池资源角度做统一运营。

换句话说，这类方案更像是“让一张卡更好用一点”，而不是“让整个 GPU 池更聪明”。

第二类：虚拟设备路线

第二类是传统意义上更“正统”的虚拟化路线，也就是把 GPU 做成虚拟设备。这个方向的优势在于隔离能力更强，也更接近 IaaS 时代大家熟悉的虚拟化思路。

它解决的是：如何把一张物理卡，安全地切成几个可交付的虚拟单元。

但问题在于，它依然主要围绕“设备”组织，而不是围绕“业务”组织。

这会带来几个现实约束：

• 配额更像固定切片，动态空间有限；
• 应用仍然容易和具体设备绑定；
• 资源利用率提升常常停在“单卡层面”；
• 一旦你想跨节点、跨池、跨业务类型做统一调度，事情会迅速复杂起来。

所以这条路线适合做“更规范的 GPU 交付”，但不一定适合做“更极致的 GPU 运营”。

第三类：共置任务调度

第三类路线开始把关注点从“设备怎么切”往“任务怎么调”移动。典型做法是在计算库调用层面做拦截和限流，让多个任务能并发使用同一批 GPU 资源，再配合集群调度系统实现更细粒度的共享。

这是一个很关键的进步，因为它第一次把调度粒度从“卡”往“任务”下钻。

它能明显改善的问题是：

• 轻量任务不再必须独占整卡；
• 不同业务可以更灵活地共享同一批资源；
• 平台层开始有机会做更细的资源治理。

但它仍然没有真正摆脱设备思维。

为什么这么说？因为 CPU 和 GPU 的生命周期往往还是耦合的，应用和卡的关系还是太近，整池层面的主动碎片整理、资源池弹性、跨节点统一运营能力也还是受限。对多租户和更强隔离场景来说，这条路也会遇到边界。

第四类：算力虚拟化

同思引擎更看重的，是第四类路线，也就是把虚拟化对象从“GPU 设备”进一步抬升到“GPU 算力服务”。

这里的核心转变只有一句话：

用户真正需要的不是一张卡，而是完成训练和推理任务所需的那部分算力。

这听起来像一句废话，但它会直接改变架构选择。

如果目标只是“交付几张切好的卡”，那前面三类方案很多时候已经够用了。

但如果目标变成：

• 用更少的 GPU 承载更多模型；
• 让推理、训练、实验、课堂、多租户业务共享同一底座；
• 让资源跟着业务波峰波谷动态流动；
• 让平台团队运营的是整池效率，而不是单卡状态；

那你就不得不把思考重心从“设备虚拟化”转向“算力虚拟化”。

为什么同思引擎要从“设备视角”走到“算力视角”

回到最初的问题，本质上企业买单的不是虚拟化本身，而是三件事：

1. 利用率有没有被真正拉起来
2. 业务弹性有没有变得更可控
3. 平台复杂度有没有下降，而不是继续上升

这三件事里，最容易被低估的是第一件。

很多方案看上去能共享 GPU，但共享并不等于高利用率。只要资源仍然围绕设备固定分配，只要应用仍然跟具体卡深度耦合，只要调度视角仍然停留在单机或单卡层，整体利用率就很难跨过一个台阶。

同思引擎选择“算力视角”，背后其实是三个判断。

判断一：真正要优化的是整池效率，不是单卡效率

单卡调优当然重要，但企业真正付费的是整池资源。

如果一张卡切得很好看，但整个集群仍然到处都是碎片，平台价值就没有真正建立起来。对 AI Infra 团队来说，最关键的不是“这张卡被切成了几份”，而是：

• 整个资源池是否还能继续承载更多业务；
• 高峰期是不是能把算力让给最关键的服务；
• 波谷时是不是能把闲置降到最低。

这也是为什么同思引擎强调池化、共享和统一调度，而不是把产品停留在“vGPU 工具”层面。

判断二：应用和 GPU 设备绑得越紧，弹性越差

很多团队做大模型推理或多模型服务时，真正难受的地方不是申请不到卡，而是 业务扩缩容和 GPU 资源扩缩容不是一回事，却被硬绑在一起了。

一旦两者耦合，问题就会连锁出现：

• 业务实例扩容受 GPU 设备限制；
• GPU 资源无法独立整理和复用；
• 应用部署、驱动依赖、镜像体积、节点维护都会被牵进来；
• 整个平台很容易从“可调度”滑向“靠人协调”。

从算力视角设计，就是要尽可能把“业务需要多少算力”和“底层卡插在哪、属于谁、当前怎么分配”这两层问题拆开。

判断三：企业真正需要的是“可运营”，不是“能演示”

做一个 Demo 证明“多人能共用一张卡”并不难。难的是把这件事变成一个长期可运营的平台能力。

所谓可运营，至少意味着：

• 能跟现有业务渐进集成，而不是逼客户一次性重做；
• 能让平台团队看清谁在用、怎么用、哪里在浪费；
• 能在稳定性、隔离和利用率之间做出可解释的取舍；
• 能随着业务规模增长持续复用，而不是每上一个客户重搭一遍。

这也是同思引擎为什么不是只做一个单点技术，而是把池化、调度、统一管理放在一起看。

一个更实用的判断模型：什么场景适合哪条路线

如果把上面四条路线压缩成一个更适合决策的模型，可以这样看：

1. 你只是想快速共享一张卡

如果团队规模小、租户关系简单、工作负载相对稳定，第一类方案往往就够了。它部署快，门槛低，能解决“整卡太浪费”的基础问题。

2. 你主要想更规范地交付 GPU 资源

如果你做的是更标准化的虚拟资源交付，需要更强隔离和更明确的资源边界，第二类路线会更自然。它适合“把 GPU 做成虚拟设备卖出去”。

3. 你要解决的是多任务混跑带来的利用率问题

如果你的核心问题是推理和实验并存、多业务抢同一批卡、希望做更细粒度的调度，第三类路线已经能带来明显收益。

4. 你要的是整池算力运营能力

如果你已经进入下面这些状态：

• 模型数量持续增长；
• 业务峰谷明显；
• 多租户或多团队共享同一批 GPU；
• 希望把算力做成统一底座，而不是继续围绕设备拼系统；

那真正值得考虑的，就是第四类路线，也就是同思引擎更强调的“算力虚拟化”方向。

两个场景，最能看出这条路线的价值

场景一：AI 教育实训

教育场景是一个很典型的“看起来简单，实际上很难靠整卡交付做好”的例子。

每位学员都需要独立的操作环境，但并不是每位学员都需要长期独占整张 GPU。如果平台继续按“一人一卡”建设，结果通常就是：上课高峰期不够用，平时又大面积空转。

站内已经发布的十方融海案例里，在接入相关能力后：

• 实训环境可用率提升到 99.9%
• 显卡有效利用率从 不足 25% 提升到 60% 以上
• 单学员算力成本 降低超 80%

这个案例说明，企业真正需要的不是“更会切卡”，而是 让有限的 GPU 能服务更多独立业务单元，同时还不牺牲体验。

场景二：多区域、多模型推理平台

另一类更复杂的场景，是大型协作平台或企业 AI 中台。

当一个平台同时承载几十到上百个模型，且这些模型还要在多个 Region 重复部署时，问题就不再是某张卡怎么分，而是整池资源怎么承载越来越多的服务。

站内另一篇企业协作平台案例里，一家全球领先企业协作平台在迁移后，实现了 58%–65% 的推理成本优化。这个结果背后的关键，不是单点调优，而是开始从整池角度重新组织 GPU 资源。

这也是为什么同思引擎更关注“算力怎么流动”，而不是只关注“设备怎么切”。

什么时候反而不该上这么重的方案

没有最好的架构，只有更适合当前约束的架构。

如果你的环境满足下面几个条件，就不一定需要一上来就做同思引擎这类方案：

• GPU 数量很少，资源关系清楚；
• 业务负载稳定，没有明显峰谷；
• 租户之间高度可信，对隔离和运营要求不高；
• 团队当前最大的瓶颈不在 GPU 利用率，而在数据、模型或业务本身。

在这种阶段，先用更轻的共享方案，把需求跑出来，通常是更务实的选择。

继续追问，什么时候一定要升级？一个很实用的信号是：

当你们已经不是“缺卡”，而是“卡很多但还是不够用”，说明问题大概率已经从采购问题变成了资源组织问题。

同思引擎想解决的，归根到底不是虚拟化本身

很多人第一次听到同思引擎，会把它理解成“一个更强的 GPU 虚拟化产品”。这不算错，但还不够。

更准确地说，同思引擎要解决的是：如何把企业手里的 GPU，从固定硬件资产，变成可共享、可调度、可运营的算力服务。

回到最初的问题，为什么 GPU 虚拟化不能只停留在“切卡”？

因为企业真正需要的，不是把设备切得更好看，而是让整池算力更高效地服务业务。

这也是同思引擎的核心判断：从设备走向算力，才是 GPU 虚拟化真正进入企业级阶段的开始。