异构算力编排（CPU/GPU/NPU）

一句话定位：异构算力编排的核心是”按算子画像分类调度”——先识别每个处理环节是 CPU 密集还是 GPU 密集，再把它们分离到对应的资源池，避免互相抢占和资源浪费。

1. 按算子画像分类调度

• CPU 密集型环节：清洗、格式转换、去重（Hash 计算）、Tokenization 等，这些环节用 GPU 资源是浪费。
• GPU 密集型环节：内容打标、质量评分、embedding 生成等依赖模型推理的环节，需要 GPU/NPU 算力。
• 先对整条数据处理流水线做”画像”（每个算子主要消耗什么资源），再决定资源池划分方案，而不是笼统地给整条流水线分配同构资源。

2. 资源池分离与撮合

• 把 CPU 密集型任务和 GPU 密集型任务分别调度到不同的资源池（对应大数据里 YARN/K8s 的资源队列隔离思路），避免 CPU 任务占满节点导致 GPU 任务的 CPU 辅助逻辑（如数据预取、后处理）被拖慢，也避免反过来 GPU 任务空等 CPU 资源。
• 资源撮合还要考虑亲和性（数据本地性、GPU 与其绑定的 CPU/内存的 NUMA 亲和性）以降低跨节点传输开销。

3. 异构卡型的能力抽象与自动降级

• 不同代际、不同厂商的 GPU/NPU 算力和显存差异很大，平台需要对”卡型能力”做抽象（如统一描述算力、显存、支持的精度类型），让上层调度不需要为每种卡型写专门逻辑。
• 自动降级：当高端卡型资源不足时，能自动切换到低端卡型 + 调整 batch size/精度等参数，保证任务仍能跑完（可能慢一些），而不是直接失败。

4. 失败恢复与断点续跑

• 大规模异构任务运行时间长、涉及节点多，故障率不可忽视；需要支持任务级的检查点（定期保存处理进度），故障后从检查点恢复而不是从头重跑，这对百亿级数据处理的成本控制至关重要。

5. 面试落点

• 素材：把 DeepOps 巡检/失败监控 + DAG 编排经验包装成”百亿级数据异构卡型自动化处理”的故事——具体讲清”如何画出算子的资源画像、如何设计资源池隔离、如何做失败恢复”三个层次。
• 可迁移话术：这套”按资源类型分池调度 + 失败恢复”的经验和大数据平台的 YARN 队列隔离、任务失败重试机制是完全同构的能力迁移，唯一新增的是”卡型异构”这个新变量。

参考：无固定单一文献来源，综合自异构计算调度通用实践与本人 DeepOps 平台经验