本文记录了我们近期 LLM 数据蒸馏（Distillation）项目的开源软件选型过程。选型覆盖从底层计算调度、数据治理，到数据处理、训练推理、效果评测的完整技术栈，共对比 59 个候选方案，按「采用 / 候选 / 不采用」三档给出结论。
阅读前先说明几点：
- 本结论为当前阶段的讨论结果，会随项目条件（PoC 实施范围）的确定而持续更新；
- 「候选」多数集中在 AI 处理运行时层，实际落地时多个组件会组合并用（例如离线训练中 PyTorch + Transformers + PEFT + TRL 是同时采用的）；
- 基础架构层（计算 / 治理）以业界成熟方案为基础，结论相对稳定；运行时层则会因蒸馏方式、训练方式的选择而大幅变动，因此保留了较多候选供后续对比。
结论图例：✅ 采用（本次正式选定）｜🟡 候选（保留 / 对比验证中）｜❌ 不采用（对比后排除）
一、计算与调度层（Compute）
负责 GPU 集群的容器编排、Pod 调度、弹性伸缩与分布式计算运行。这是整个蒸馏项目算力底座，优先选择业界标准与生态成熟的方案。
1.1 容器编排（Container Orchestration）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| Kubernetes | 动态资源管理；声明式配置管理；业界标准、生态极广 | 无明显短板 | ✅ 采用 |
| VM（虚拟机直跑） | 架构简单；运维经验丰富 | 资源管理粗放；动态扩缩容弱；GPU 利用率易偏低 | ❌ 不采用 |
决策说明：Kubernetes 的动态资源管理最适合 GPU 集群的弹性运行，是蒸馏训练/推理规模化运营的必然底座。
1.2 Pod 调度（Gang Scheduling）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| Apache Yunikorn | 支持 Gang Scheduling；与 Spark / Ray 亲和性高 | 相比 K8s 内置调度器增加运维要素 | ✅ 采用 |
| K8s 内置 kube-scheduler | 无需额外部署；配置简单 | 不支持 Gang Scheduling 等高级控制；对需要异构角色（Rollout/Trainer 等）的强化学习训练不友好 | ❌ 不采用 |
| Volcano | Gang Scheduling 能力与 Yunikorn 基本同级；K8s 原生批处理调度器、落地案例多 | 无现成使用经验，需重新验证 | 🟡 比较候选 |
决策说明：GPU 集群中，学习用 / 推理用等异构角色的 Pod 需要一次性全部就绪（Gang Scheduling），后续做在线强化学习时几乎是必需品。Yunikorn 与 Volcano 功能基本对等，故以经验更成熟的 Yunikorn 为主，同时持续对比 Volcano 的最新进展。
1.3 节点弹性伸缩（Auto Scale Out）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| Karpenter | 可灵活配置多条节点扩容规则；可配合预热（Warmup）配置 | GPU 节点冷启动可能耗时较长，需单独验证 | ✅ 采用 |
| K8s Cluster Autoscaler | K8s 标准功能，实现成熟稳定 | 节点池设计的灵活性不如 Karpenter | ❌ 不采用 |
决策说明：Karpenter 支持多条独立扩容规则，灵活性高，因此持续采用；GPU 节点冷启动耗时作为已知风险单独安排验证。
1.4 分布式计算运行（Compute Run）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| Ray | 分布式训练 / 强化学习的事实标准；Ray Train/Tune 原生支持与 MLflow 联动 | 超大规模数据处理的沉淀不如 Spark | ✅ 采用（新引入；PoC 阶段暂不使用） |
| Apache Spark | 大数据处理经验丰富、生态成熟（Databricks 亦采用） | 面向训练/推理负载并不合适（专精数据处理） | ✅ 采用（延续，用于数据处理） |
| Apache Flink | 流式处理能力强 | 本项目以批处理为主，优先级低 | ❌ 不采用 |
1.5 分布式算力纳管（Distributed：K8s Operator）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| KubeRay | 以 K8s 原生方式运维 Ray 集群（RayCluster / RayJob） | 常驻集群 vs 按需拉起需做设计取舍（成本与启动速度的权衡） | ✅ 采用（新引入；PoC 阶段暂不使用） |
| Spark Operator | 以 K8s 原生方式运行 Spark，使用经验成熟 | 不适用于 Ray 系工作负载 | ✅ 采用（延续） |
| Flink Operator | 以 K8s 原生方式运行 Flink | 本项目不采用 Flink，故不需要 | ❌ 不采用 |
决策说明：对应 Compute Run 层的选型（Ray / Spark），分别配套 K8s 原生 Operator（KubeRay / Spark Operator），两者按用途明确分工：Ray 面向 AI 训练/推理，Spark 面向大数据处理。
二、数据治理与平台层（Governance）
负责数据目录、实验追踪、存储格式与作业编排，保证整个 AI 流程「可管、可溯、可复现」。
2.1 数据目录（Data Catalog）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| Unity Catalog | 表 / 文件（Volume）/ 模型统一管理，Databricks 亦采用 | 开源版部分高级功能（如自动深层血缘追踪）弱于托管版 | ✅ 采用 |
决策说明：与 Databricks「用 Unity Catalog 统一管理表、文件与模型」的设计思想一致，用于打通数据、特征与模型资产。
2.2 实验追踪与评测监控（Experiment Monitor）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| MLflow | 实验追踪 + GenAI 评测（Tracing / Prompt Registry）一体化；Databricks 亦采用 | 开源版缺少少数托管版功能（如评测数据集强制版本固定等） | ✅ 采用 |
| Weights & Biases | 实验管理 UI 出色；常被 Ray / NeMo-RL 等 RL 框架默认集成 | 开源版功能受限；易与 MLflow 形成双重管理 | ❌ 不采用 |
| Kubeflow（实验管理部分） | 面向 K8s 原生的流水线管理 | 实验管理能力与 MLflow 相当，可被 MLflow 替代 | ❌ 不采用 |
| ClearML | 覆盖到 GPU 基础设施管理的集成功能 | 任务分发必须引入 Agent，有厂商锁定风险；开源版功能限制较多 | ❌ 不采用 |
决策说明：参照 Databricks「用 MLflow 统一管理训练数据与可视化」的设计。Kubeflow 与 MLflow 功能重叠；Weights & Biases 与 ClearML 则因开源版功能限制及厂商锁定风险排除，最终延续使用 MLflow。
2.3 大数据存储格式（Big Data Format）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| Delta Lake | 与 Databricks 系（Unity Catalog）兼容性好 | 多引擎互操作性略逊于 Iceberg | ✅ 采用 |
| Apache Iceberg | 多引擎支持好；业界采用快速扩大 | 与 Unity Catalog 的集成不如 Delta Lake 成熟 | ❌ 不采用 |
| Apache Hudi | 增量处理 / Upsert / CDC 能力强，擅长记录级更新 | 与 Delta Lake / Iceberg 用途重叠，缺乏既有资产积累 | ❌ 不采用 |
决策说明：基于与 Databricks（Unity Catalog）的兼容性，存储格式延续 Delta Lake。
2.4 作业编排（Job Orchestration）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| Apache Airflow | 数据处理流水线管理使用最广；也可编排 Ray Job | 不适合实时性要求高的 workflow | ✅ 采用 |
| Argo Workflows | K8s 原生，适合容器化执行 | 无使用经验，学习成本高 | ❌ 不采用 |
决策说明：Airflow 在数据处理流水线管理上使用最广、也能执行 Ray Job，因此延续采用。
三、运行时 · 数据处理层（Data Processing）
对应蒸馏的「数据准备与清洗」环节：把语料加工成可用于训练的干净数据集。
3.1 数据准备与清洗（Data Preparation / Cleaning）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| Apache Spark | SQL / DataFrame / Join / Aggregation / Filter 等大规模数据处理非常成熟 | 不面向 LLM 特有的数据清洗与 GPU 推理 | ✅ 采用 |
| HojiChar | 面向日语的专用过滤工具集；SB Intuitions（Sarashina 团队）实际采用（CCNet → HojiChar → MinHashLSH） | 主要面向网页抓取类数据，企业文档等场景需单独验证 | ✅ 采用（日语场景） |
| Ray Data | 与 Ray 亲和、可统一处理分布式任务 | 超大规模批处理经验尚不如 Spark | 🟡 比较候选（AI 处理用途） |
| Data-Juicer | 多语言、灵活；100+ 算子可组合成 Recipe；与 Ray / HuggingFace Datasets 集成强；社区活跃 | GPU 加速不如 NeMo Curator | 🟡 候选（评估中） |
| NeMo Curator | GPU 加速（RAPIDS），可支撑 100PB+ 超大规模处理 | 依赖 NVIDIA GPU 技术栈；LLM 生成类算子集成弱于 Data-Juicer | 🟡 候选（仅超大规模场景） |
| Deequ | 跑在 Spark 上，可验证大规模数据集质量 | 依赖 Spark / Scala；并非 LLM 特有的质量评估 | 🟡 候选（评估中） |
| HuggingFace Datasets | 与 HF 生态亲和，可直接衔接既有训练代码 | 不适合超大规模分布式处理（面向小/中规模） | 🟡 候选（评估中） |
决策说明：大规模基础处理沿用 Spark，日语文本清洗以 HojiChar 为核心；Data-Juicer 与 NeMo Curator 作为不同规模/用途下的候选继续对比评估，其余工具按需补充。
四、运行时 · AI 处理层（AI Processing）
蒸馏项目的核心运行时：教师模型推理与数据生成、离线训练（SFT/LoRA）、在线/On-Policy 蒸馏、效果评测、模型服务与导出。此层组件组合使用的情况最多，故候选保留也最多。
4.1 教师模型推理与数据生成（Teacher Inference / Data Generation）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| vLLM | 推理吞吐高（PagedAttention）；业界落地多；训练中 Rollout 生成亦可复用 | 个别新模型的支持时效有波动 | ✅ 采用 |
| SGLang | 结构化生成、多轮对话处理强 | 生态成熟度略逊于 vLLM | 🟡 候选 |
| TensorRT-LLM | NVIDIA GPU 环境下推理优化性能高 | 强依赖 NVIDIA 环境 | 🟡 候选（NVIDIA 环境限定） |
| Commercial API（商用模型 API） | 无需自建基础设施；可即时访问最新 SOTA 模型 | 需成本管理；无法完全自主掌控模型 | 🟡 候选 |
决策说明：教师模型推理以 vLLM 为核心；若需外部 SOTA 模型，商用 API 也是备选；SGLang / TensorRT-LLM 按环境需求保留。
4.2 离线训练（SFT / LoRA 等）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| PyTorch | 训练框架基石，业界标准 | 偏底层 API，单独使用开发效率低 | ✅ 采用 |
| Transformers | LLM 训练事实标准库，模型覆盖面广 | 大规模分布式优化不如 DeepSpeed / Megatron | ✅ 采用 |
| TRL | SFT / DPO 等训练循环实现简洁 | RL 系（PPO/GRPO）大规模分布式不如 verl / NeMo-RL | ✅ 采用 |
| PEFT | LoRA / QLoRA 等参数高效微调，本项目核心技术 | 全参数训练的高效化仍需 DeepSpeed 等配合 | ✅ 采用 |
| DeepSpeed | ZeRO 等内存优化，可训练超大规模模型 | 配置与调优复杂度高 | 🟡 候选（大规模模型时） |
| Megatron-Core | 张量并行 + 流水线并行，支撑超大模型训练 | 对本项目模型规模而言投入偏重 | 🟡 候选（大规模模型时） |
| Axolotl | SFT / DPO / LoRA 以配置驱动、易于快速搭建 PoC | 依赖框架自带的配置与抽象，长期标准化基座角色有限 | 🟡 候选（将来扩展） |
| FSDP2（PyTorch 原生） | PyTorch 原生内存优化，解决与 DeepSpeed 同类问题 | 不支持张量并行（需与 Megatron 分工） | 🟡 候选（将来扩展） |
| LLaMA-Factory | 低代码跑训练实验，提供 GUI | 生产级扩展性弱于直接用 TRL / PEFT | 🟡 候选（验证 / 演示用途） |
决策说明：本项目核心技术路线为黑箱 SFT + LoRA，因此标准组合采用 PyTorch + Transformers + PEFT + TRL；DeepSpeed、Megatron-Core、FSDP2 作为「大规模模型 / 分布式并行」候选保留；Axolotl、LLaMA-Factory 作为「低代码验证 / 短期 PoC」候选保留。
4.3 在线 / On-Policy 蒸馏（Online / On-Policy Distillation）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| verl | 字节跳动开源；支持 PPO / GRPO 等大规模分布式 RL；社区采用扩大中 | 需编排 Ray / vLLM 复杂异构角色，引入成本高 | 🟡 候选（将来扩展） |
| NeMo-RL | NVIDIA 出品；支持 On-Policy Distillation；与 Megatron-Core 集成强 | 强依赖 NVIDIA 技术栈；需管理专属容器镜像 | 🟡 候选（将来扩展） |
| OpenRLHF | 支持 RLHF / 在线 RL（PPO / GRPO / DPO 等）；基于 Ray + vLLM 扩展，社区采用扩大中 | 与 verl 类似，异构角色编排引入成本高；当前路线非必需 | 🟡 候选（将来扩展） |
决策说明：本项目技术选型以离线蒸馏（SFT 路线、完全离线预计算）为主，当前阶段并不需要在线 / On-Policy 蒸馏；但为将来扩展 RFT / 偏好优化（On-Policy）预留，将 verl / NeMo-RL / OpenRLHF 整理保留为候选。将来扩展时可复用已引入的 Ray（KubeRay）底座。
4.4 评测与回归（Evaluation / Regression）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| lm-eval-harness | 模型级通用基准评测的黄金标准；内置标准任务丰富 | 不适合应用层（RAG / Agent）评测 | ✅ 采用（通用基准） |
| FlexEval | SB Intuitions 自研并开源的日语 LLM 评测框架，Sarashina 系列评测实战验证 | 日语以外的通用性可能弱于其他工具 | ✅ 采用（日语评测第一候选） |
| OpenCompass | 覆盖数据集 / 模型范围最广；支持金融 / 医疗 / 法律等领域评测 | 与 lm-eval-harness 评测任务重叠较多 | 🟡 候选 |
| LightEval | HuggingFace 出品；基于 lm-eval-harness、后端无关且轻量 | 与 lm-eval-harness 差异化不大 | 🟡 候选 |
| Ragas | RAG 专项评测中配置最少即可上手 | 不含 RAG 的评测场景适用面窄 | 🟡 候选 |
| DeepEval | 涵盖 Ragas 功能；支持 Agent / 聊天机器人评测；pytest 风格易接入 CI/CD | 深度评测逻辑有时需自行实现 Judge Prompt | 🟡 候选 |
| HELM | 斯坦福大学综合评测套件；多任务 / 多指标横向对比与榜单经验丰富 | 与 lm-eval-harness 任务重叠多；更适合持续运营综合榜单 | 🟡 候选 |
决策说明：通用性能评测以 lm-eval-harness 为核心，日语 / 领域专属评测以 FlexEval 为核心；OpenCompass / LightEval 作补充候选，Ragas / DeepEval 在需要 RAG / Agent 评测扩展时启用。
4.5 模型服务与导出（Model Serving / Export）
| 方案 | 主要优势 | 主要局限 | 结论 |
|---|---|---|---|
| vLLM | 高吞吐、业界标准推理引擎；与训练 Rollout 生成共用 | 对边缘 / 小规模私有化环境可能偏重 | ✅ 采用 |
| SGLang | 结构化输出、多轮对话负载强 | 落地案例与生态略小于 vLLM | 🟡 候选 |
| KServe | K8s 原生模型发布基座，易与自动伸缩集成 | 需另行搭配推理引擎（如 vLLM） | 🟡 候选（K8s 原生运维时） |
| Triton | NVIDIA 出品；多框架推理服务器；吞吐优化强 | 强依赖 NVIDIA 环境 | 🟡 候选（NVIDIA 环境优化时） |
| llama.cpp | CPU / 边缘环境轻量推理强 | 不属于本项目服务端运营场景 | ❌ 不采用 |
| GGUF（模型格式） | llama.cpp 系轻量模型格式，适合边缘分发 | 同上，不在本项目服务端运营范围 | ❌ 不采用 |
决策说明：服务层与教师模型推理共用 vLLM；SGLang / KServe / Triton 按环境需求保留；llama.cpp / GGUF 属边缘场景，本项目不做服务端部署，故排除。
五、决策速览
5.1 采用清单（✅）
| 层级 | 用途 | 方案 |
|---|---|---|
| 计算与调度 | 容器编排 | Kubernetes |
| 计算与调度 | Pod 调度 | Apache Yunikorn（Volcano 持续对比） |
| 计算与调度 | 弹性伸缩 | Karpenter |
| 计算与调度 | 分布式计算运行 | Ray（新）+ Apache Spark（数据处理） |
| 计算与调度 | K8s 算力纳管 | KubeRay（新）+ Spark Operator |
| 数据治理 | 数据目录 | Unity Catalog |
| 数据治理 | 实验追踪 | MLflow |
| 数据治理 | 存储格式 | Delta Lake |
| 数据治理 | 作业编排 | Apache Airflow |
| 数据处理 | 大规模清洗 | Apache Spark |
| 数据处理 | 日语文本清洗 | HojiChar |
| AI 处理 | 教师推理 / 数据生成 | vLLM |
| AI 处理 | 离线训练（SFT/LoRA） | PyTorch + Transformers + PEFT + TRL |
| AI 处理 | 通用评测 | lm-eval-harness |
| AI 处理 | 日语评测 | FlexEval |
| AI 处理 | 模型服务 | vLLM |
5.2 待定 / 候选要点（🟡）
- 调度：Volcano（与 Yunikorn 平行对比）；
- 数据处理：Ray Data、Data-Juicer、NeMo Curator（超大规模）、Deequ、HF Datasets；
- 推理：SGLang、TensorRT-LLM（NVIDIA 限定）、商用模型 API；
- 离线训练：DeepSpeed / Megatron-Core / FSDP2（大规模化时）、Axolotl / LLaMA-Factory（验证与演示）；
- 在线蒸馏（将来扩展）：verl、NeMo-RL、OpenRLHF；
- 评测：OpenCompass、LightEval、Ragas、DeepEval、HELM；
- 服务：SGLang、KServe、Triton。
5.3 明确排除（❌）
- 计算层：VM 直跑、kube-scheduler（Gang Scheduling 不足）、K8s Cluster Autoscaler、Flink、Flink Operator；
- 数据治理：Weights & Biases、Kubeflow（实验管理）、ClearML、Iceberg、Hudi、Argo Workflows；
- AI 处理：llama.cpp、GGUF（边缘场景，非本项目范围）。
六、写在最后
这次选型没有追求「全家桶」，而是尽量让每一层都选择业界验证最充分、生态最开放的组件，并为将来可能的在线强化学习（RFT / On-Policy 蒸馏）预留好 Ray 底座与相关候选。选型结论会随 PoC 的推进继续迭代，欢迎交流指正。