2026年8月8日，HeteroFlow v2推理服务正式发布，支持11种GPU品牌、5种推理引擎的统一调度。
在此之前，做聚合API服务的团队面临一个尴尬局面：国产芯片（昇腾、寒武纪、海光DCU）推理性能已经能打到H100的80%以上，价格只有后者的60%-70%，但没人敢用。
不是因为性能差，是因为没法混着用。英伟达跑CUDA，昇腾跑CANN，寒武纪跑MagicMind——三套东西互不兼容。同一份PyTorch代码，要在不同芯片上跑通，得分别移植、分别调优、分别维护。算算人力成本，省下来的显卡钱全贴进去了。
HeteroFlow解决的就是这个问题：在调度层统一纳管多品牌GPU，上层应用一套代码，底层自动分配到对应的芯片上执行。
下面从技术实现角度拆解这套调度层是怎么设计的。
一、架构概览
把HeteroFlow放在整个技术栈里看，位置是这样的：
向下：对接11种GPU（NVIDIA、华为昇腾、海光DCU、寒武纪、摩尔线程、壁仞、AMD、昆仑芯、燧原、沐曦、天数智芯），每种芯片有自己的驱动、SDK、推理引擎
向上：提供一套OpenAI兼容的API，应用层无需关心底层跑在哪块卡上
中间这一层做两件事：硬件抽象 + 智能路由。接到一个推理请求，判断它适合跑在哪种芯片上，调用对应runtime执行，返回结果。
对API服务商来说，收益很直接：不用为每种芯片维护一套部署环境，一套代码、一套配置，按策略把流量分配到不同算力池里。
二、硬件纳管层：11种GPU的统一接入
异构调度的第一步是“能认出来”。HeteroFlow的Agent部署在每个算力节点上，启动后自动检测节点的GPU类型、型号、显存容量、驱动版本。
检测方式：
NVIDIA：nvidia-smi
华为昇腾：npu-smi
寒武纪：cnmon
摩尔线程：mthreads-gmi
海光DCU：hy-smi
壁仞：birensmi
所有硬件资源被抽象成统一模型——显存大小、算力比例、拓扑结构（NVLink/HCCS）都被标准化，上层调度器不再感知底层差异。一个混合了NVIDIA A100和华为昇腾910的集群，在调度视图里就是一个统一的资源池。
三、推理引擎路由：不同GPU配不同的“翻译官”
硬件纳管之后，下一个问题：即使同一份PyTorch代码能跑在不同芯片上，推理引擎也各不相同。vLLM（NVIDIA主流）、SGLang、llama.cpp、MINDIE（华为昇腾专用）、vLLM-MTT（摩尔线程专用），每家引擎有不同的启动参数和优化策略。
HeteroFlow的策略是根据硬件自动选择最优引擎：
GPU类型 推荐引擎 原因
NVIDIA CC≥8.0（A100/H100） vLLM PagedAttention，吞吐最高
NVIDIA CC≥7.5（T4） SGLang RadixAttention，continuous batching
NVIDIA CC=6.0（P100） llama.cpp vLLM不支持老卡
华为昇腾910 MINDIE 厂商专用引擎，性能最优
摩尔线程MTT vLLM-MTT 厂商专用
其他 Transformers（兜底） device_map='auto'
这套机制的价值：API服务商部署时只需要指定模型，平台自动为每张卡选好引擎并启动，不需要运维熟悉每一种引擎的细节。
四、调度引擎：任务怎么分到最合适的卡
调度是HeteroFlow最核心的模块。插件化设计，采用五阶段流水线处理每个调度决策：PreScore → Filter → Score → PostScore → Bind。
内置调度插件：
BinPack（装箱）：优先把任务塞到已使用的节点，最大化单节点利用率
Spread（分散）：把任务均匀分散到各节点，提升容错性
Topology（拓扑感知）：感知NVLink/NUMA拓扑，优化多卡通信效率
GPU Filter（型号过滤）：指定某些任务只能跑在特定型号上
Resource Filter（资源过滤）：根据显存、GPU数量等硬约束过滤节点
实际API服务场景里最常用的是“规则路由”——通过YAML配置匹配规则，决定什么任务走哪类芯片：
yaml #低延迟小请求 → 英伟达
match:
batch_size: "<=4"
latency_sla: "<=150ms"
target: "nvidia"
大批量离线任务 → 国产芯片
match:
batch_size: ">=32"
latency_sla: ">=3s"
target: "huawei_ascend"
手动配置规则的方式，对生产环境更可靠——运维能明确知道流量走向，故障时快速定位。同时支持按流量权重做灰度发布，新版本模型先接10%流量验证，再逐步放量。
五、GPU分片与弹性：让每张卡物尽其用
GPU卡贵，能不能一张卡同时跑多个任务？
HeteroFlow实现三级QoS分片：
等级 隔离方式 适用场景
Gold 硬件隔离（MIG/vNPU/vMLU/vGPU） 高性能推理、独占训练
Silver 驱动虚拟化（MPS/HAMi） 共享推理，中等隔离需求
Bronze 软件分片（显存记账） 开发测试、离线批处理
Gold级利用NVIDIA MIG、昇腾vNPU、寒武纪vMLU等硬件虚拟化技术，实现显存和算力的物 理隔离。
Bronze级通过显存记账和环境变量注入实现逻辑分片，适合开发测试。
弹性方面支持模型热加载和休眠唤醒：
模型空闲超阈值（默认30分钟）自动休眠，释放GPU显存
新请求到达时毫秒级唤醒，重新加载到显存
滚动更新支持零停机切换
API服务流量通常有5-10倍峰谷差，这套机制的价值：低谷期自动释放闲置显存，高峰期自动扩容，不需要人工干预。
六、两个技术拓展方向
HeteroFlow的“异构”在向外延伸，两个值得关注的方向：
- CPU+GPU协同调度
英特尔基于HeteroFlow框架构建了“CPU+GPU”异构LLM服务方案，将MoE（混合专家）模型中内存密集型的专家路由任务卸载到至强6 CPU上执行，GPU专注Attention和Dense MLP部分。
实测在单张24G显存显卡上可运行671B大模型，支持5并发51 Token/秒。核心突破是打破了“推理必须全量驻留GPU显存”的限制，把CPU的大内存优势用起来了。
得益于至强6 CPU内置的AMX（高级矩阵扩展）技术加速，MoE任务的卸载效率得到进一步提升。
- 量子/原子算力调度
HeteroFlow路线图中包含对量子计算和原子计算资源的调度支持，目标是实现“经典GPU+量子硬件+原子计算”的混合工作流编排。
目前仍处于路线图阶段，但说明“异构”的内涵正从“多品牌GPU”扩展到“多种计算范式”。在HeteroFlow的规划中，量子电路执行任务可以通过Qiskit、OpenQASM等标准格式提交，平台自动选择IBM Quantum、本源量子或国盾量子等后端，支持失败时自动降级到GPU模拟器重试。
七、总结
HeteroFlow这类异构调度层的设计，核心就是三件事：
硬件纳管：Agent自动识别11种GPU，把不同厂商的硬件抽象成统一资源模型
引擎路由：根据GPU型号自动匹配最优推理引擎，一套配置覆盖全型号
调度策略：插件化调度引擎支持规则配置，让API服务商自己决定什么任务跑什么卡
对聚合API平台和模型推理团队来说，解决了一个实际问题：不用在“高价英伟达”和“低价但没法混用”之间二选一了。异构算力混部这件事，从自己搭架子变成了开箱即用。
。