ML Serving/编排工具

将开源协议纳入考量后，选型逻辑会发生本质变化。技术能力决定“能不能用”，而许可证决定“敢不敢用、能用多久”。尤其在企业商业化、云托管服务、或涉及供应链合规的场景下，协议风险可能直接否决一个技术上最优的方案。

以下是将所有主流 ML Serving/编排工具在模型支持、Scalable、开源协议三个维度的全景对比与风险分析。

1. 📊 全景对比矩阵（含协议）

2. ⚖️ 开源协议风险分级详解

🟢 安全区：Apache 2.0 / MIT / BSD

• 代表： Kubeflow, KServe, Triton, BentoML, Ray, vLLM, SGLang, MLflow, FastAPI
• 允许： 商用、修改、分发、专利使用、闭源衍生
• 义务： 保留版权声明、NOTICE 文件、状态变更说明
• 企业建议： ✅ 可直接用于生产、云托管服务、内部平台，无需法务额外审批

🟡 注意区：BUSL / SSPL / Elastic License

• 代表： Seldon Core v1.x (BUSL-1.1), MongoDB (SSPL), Elasticsearch (Elastic License)
• 核心限制： 禁止提供竞争性云服务。即你不能基于该工具搭建一个“Seldon-as-a-Service”来卖钱，但内部使用通常允许。
• 变更条款： BUSL 通常在 4 年后自动转为 Apache 2.0（Seldon v1.x 已部分转换，但旧版本仍需审查）
• 企业建议： ⚠️ 内部自用一般安全；若计划对外提供托管服务或嵌入商业产品，必须法务审核。优先选用已转 Apache 的新版本（如 Seldon v2）。

🔴 高危区：专有 EULA / 硬件绑定许可

• 代表： TensorRT-LLM (NVIDIA EULA), CUDA Toolkit
• 核心限制：
  • 仅限指定硬件（NVIDIA GPU）
  • 禁止逆向工程、反编译
  • 禁止公开基准测试结果（除非获书面授权）
  • 不可转让、不可再许可
• 企业建议： 🔴 使用前必须签署正式许可协议。多云/异构硬件战略下存在严重锁定风险。避免将其作为唯一推理后端，应保留 ONNX/vLLM 等开放替代路径。

3. 🎯 协议感知型选型决策树

graph TD
    A[你的部署场景?] --> B{是否对外提供<br/>ML Serving 云服务?}
    B -- 是 --> C{目标工具协议?}
    B -- 否 --> D[内部使用/私有化交付]
    
    C -- Apache/MIT/BSD --> E[✅ 安全可用]
    C -- BUSL/SSPL --> F[🔴 禁止!<br/>选 Apache 替代品]
    C -- NVIDIA EULA --> G[⚠️ 仅限 NVIDIA 硬件<br/>且不可公开 benchmark]
    
    D --> H{是否嵌入<br/>商业产品分发?}
    H -- 是 --> I{协议兼容性?}
    H -- 否 --> J[✅ 所有协议基本安全]
    
    I -- Apache/MIT/BSD --> K[✅ 安全]
    I -- BUSL --> L[⚠️ 需法务确认<br/>是否构成竞争]
    I -- NVIDIA EULA --> M[🔴 通常禁止再分发<br/>需单独商务谈判]

4. 💡 关键避坑指南（协议专项）

1. Seldon 版本陷阱： Seldon Core v1.x 是 BUSL-1.1，许多教程/博客仍引用此版本。务必确认使用的是 v2.x (Apache 2.0)。若存量系统用 v1.x 且计划商用，立即评估迁移或购买商业许可。
2. TensorRT-LLM 的 Benchmark 禁令： 其 EULA 明确禁止未经授权公开性能数据。若在技术博客/论文中对比 TRT-LLM vs vLLM，可能面临法律风险。解决方案：使用 vLLM/TGI 等 Apache 协议工具作为公开基准，TRT-LLM 仅内部评估。
3. “Open Core” 模式的隐性成本： BentoML/Ray/MLflow 核心开源，但企业级功能（SSO、审计、高级监控）仅在商业版。评估时需区分开源版能力边界，避免后期被迫升级。
4. Apache 2.0 ≠ 完全无忧： 仍需遵守 NOTICE 文件要求。若修改了代码并分发，必须在 NOTICE 中声明变更。大型企业应有自动化合规扫描工具（如 FOSSA, Black Duck）。
5. 云厂商托管服务的协议差异： AWS SageMaker 托管的 Triton 与自建 Triton 协议相同，但计费模式和服务条款不同。自建时关注开源协议，上云时关注云服务协议（SLA、数据隐私、出口管制）。
6. 中国特殊合规考量： 若涉及国产芯片（昇腾/寒武纪），TensorRT-LLM 完全不适用。应优先选择 Apache 协议且支持多后端的工具（KServe + ONNX Runtime/MindSpore Lite），避免供应链断供风险。

5. 📌 最终推荐（协议安全 + 技术匹配）

终极建议： 在技术选型评审表中，将“开源协议”列为与“性能”“功能”并列的一票否决项。对于 BUSL/EULA 类工具，即使技术领先，也应要求供应商提供书面商用授权或准备 Apache 协议的 Plan B。在 LLM 时代，vLLM/SGLang 等 Apache 协议工具的性能已足够接近专有方案，协议风险往往不值得承担。

如您能说明具体的商业模式（内部/对外/SaaS）、硬件栈（NVIDIA/国产/混合）、合规要求（等保/GDPR/出口管制），我可进一步细化协议风险评估和替代方案设计。

Kubeflow

https://www.kubeflow.org/docs/started/architecture/#kubeflow-landscape-in-the-ai-lifecycle

https://github.com/kubeflow/kubeflow

根据您提供的 Kubeflow 官方介绍页面，以下是关于 Kubeflow 的核心信息总结：

🤔 什么是 Kubeflow？

Kubeflow 是一个云原生 AI 平台，它由一系列模块化的开源项目组成，旨在为数据和 AI 工作负载提供一个 Kubernetes 原生的技术栈。无论是 AI 从业者、平台管理员还是决策者，Kubeflow 都提供了模块化、可扩展且可定制的工具来支持数据、AI/ML 和高性能计算（HPC）等用例。

🎯 使命与核心原则

Kubeflow 的使命是连接数据、AI 和云原生生态系统，帮助团队将更多的模型、智能体和 AI 应用投入生产。

其核心原则包括：

• 简单 (Simple)：无需成为 Kubernetes 专家即可在任何规模上运行工作负载。
• 可移植 (Portable)：在本地笔记本、本地数据中心或任何云上使用相同的代码。
• 可扩展 (Scalable)：管理超大规模的训练任务和高吞吐量的 AI 智能体。
• 可组合 (Composable)：在 AI 生命周期的各个阶段混合搭配使用工具。

🧩 项目构成

Kubeflow 的生态系统主要由以下几个部分构成：

1. Kubeflow 子项目 (Subprojects)
   这些是 Kubeflow 的核心组件，既可以独立使用，也可以作为 Kubeflow 发行版的一部分。它们为数据处理、模型训练等特定功能提供支持。

2. Kubeflow 生态系统 (Ecosystem)
   包含由社区支持的、与 Kubeflow 子项目集成或互补的成熟项目，例如 Feast、KServe 等。

3. Kubeflow 发行版 (Distribution)
   由供应商提供支持，针对特定基础设施或平台环境部署的 Kubeflow 子项目和集成方案。其中，Kubeflow 社区发行版 (KCD) 是一个由社区维护的、与供应商无关的参考部署包。

📜 历史背景

Kubeflow 起源于 Google 内部运行 TensorFlow 的方式（基于一个名为 TensorFlow Extended 的管道）。它最初只是一个在 Kubernetes 上运行 TensorFlow 任务的简化方法，但后来已发展成为一个在 Kubernetes 上运行 AI 工作负载的基础工具集。

kserve

https://github.com/kserve/kserve

KServe is a standardized distributed generative and predictive AI inference platform for scalable, multi-framework deployment on Kubernetes.

KServe is being used by many organizations and is a Cloud Native Computing Foundation (CNCF) incubating project.

For more details, visit the KServe website.

Single platform that unifies Generative and Predictive AI inference on Kubernetes. Simple enough for quick deployments, yet powerful enough to handle enterprise-scale AI workloads with advanced features.

Generative AI

• 🧮 Optimized Backends: Support for vLLM and llm-d for optimized performance for serving LLMs
• 📌 Standardization: OpenAI-compatible inference protocol for seamless integration with LLMs
• 🚅 GPU Acceleration: High-performance serving with GPU support and optimized memory management for large models
• 💾 Model Caching: Intelligent model caching to reduce loading times and improve response latency for frequently used models
• 🗂️ KV Cache Offloading: Advanced memory management with KV cache offloading to CPU/disk for handling longer sequences efficiently
• 📈 Autoscaling: Request-based autoscaling capabilities optimized for generative workload patterns
• 🔧 Hugging Face Ready: Native support for Hugging Face models with streamlined deployment workflows

Predictive AI

• 🧮 Multi-Framework: Support for TensorFlow, PyTorch, scikit-learn, XGBoost, ONNX, and more
• 🔀 Intelligent Routing: Seamless request routing between predictor, transformer, and explainer components with automatic traffic management
• 🔄 Advanced Deployments: Canary rollouts, inference pipelines, and ensembles with InferenceGraph
• ⚡ Autoscaling: Request-based autoscaling with scale-to-zero for predictive workloads
• 🔍 Model Explainability: Built-in support for model explanations and feature attribution to understand prediction reasoning
• 📊 Advanced Monitoring: Enables payload logging, outlier detection, adversarial detection, and drift detection
• 💰 Cost Efficient: Scale-to-zero on expensive resources when not in use, reducing infrastructure costs