机器学习平台技术栈之 Label Studio：打通数据飞轮与大模型 RLHF 的标注中枢在整个机器学习工程（MLOps）生命周期中，“数据准备”往往是最耗时、最昂贵，却又最决定模型上限的基础环节。正如业界名言所述：“Garbage in, garbage out”。在早期的作坊式 AI 团队中，数据标注通常是外包零散进行的：CV（计算机视觉）团队用开源的 LabelImg 画框，NLP（自然语言处理）团队用 Brat 标实体，甚至通过 Excel 和 CSV 来回传递极其混乱的标注结果。当平台规模扩大，多模态（图文音视混合）需求爆发，尤其是进入大语言模型（LLM）的 RLHF（基于人类反馈的强化学习）时代后，割裂的标注工具直接成了阻碍业务迭代的瓶颈。 Label Studio 作为目前全球最火热的开源多模态数据标注平台，凭借其极其灵活的极客级配置引擎、原生的机器学习后端（ML Backend）联动以及与 MLOps 工作流（Webhooks/Cloud Storage）体系的深度缝合，成为了云原生机器学习平台技术栈中不可或缺的“数据燃料加工厂”。 本文将极度深入地为您剖析 Label ...

机器学习平台技术栈之 Jupyter：构建云原生环境下的交互式计算基石在现代机器学习和数据科学领域，Jupyter 已经成为不可替代的绝对统治者。无论是算法工程师进行数据的 EDA（探索性数据分析）、特征工程验证，还是模型结构的微调（Fine-tuning）和推理调试，Jupyter 提供的那种输入一段代码、立刻获得文本/图表反馈的“交互式计算（Interactive Computing）”体验，深刻地重塑了 AI 研发的工作流。 然而，当我们要在一个包含几百上千张 GPU、支撑数百位算法工程师的云原生机器学习平台（MLOps，如 Kubeflow）中引入 Jupyter 时，事情就不再是仅仅运行一个 jupyter notebook 命令那么简单了。我们需要解决多用户隔离、资源（CPU/MEM/GPU）的动态调度、单点登录认证（SSO）、运行环境镜像管理分离、内核远程执行等一系列超乎想象的工程挑战。 本文将极度深入地解构 Jupyter 生态系统。从底层核心概念的通信机制（ZeroMQ 协议），到面向企业级的 JupyterHub 架构设计，再到更高阶的 Jupyter Enterp ...

机器学习平台技术栈之 Harbor：构建安全高效的云原生 AI 制品中心当我们谈论构建庞大且复杂的机器学习平台（如基于 Kubernetes 的 MLOps 平台）时，大家往往热衷于讨论如何榨干 GPU 算力、如何设计极速的网络通信。然而，有一个常常被忽视却又在每天的日常开发中卡住系统脖子的重灾区——AI 镜像与制品的分发。 在传统的 Web 微服务时代，一个 Java 或 Go 业务镜像的大小通常在几百 MB 以内。但在 AI 领域，包含完整 CUDA Toolkit、cuDNN、PyTorch 以及海量 Python 依赖的基础镜像动辄 15GB 到 20GB 起步。当千卡集群并发启动一个分布式训练任务，上千个节点同时向中心服务器拉取几十 GB 的镜像，瞬时产生的几十 Tbps 流量能在几秒钟内彻底击穿普通网络交换机和存储的极限（拉取风暴 / Pull Storm）。 此外，算法团队有极具敏感性的商业模型需要隔离（多租户权限），有严格的开源协议漏洞需要审查（CVE 扫描），而且我们不仅要存镜像，渐渐地还要利用 OCI 标准来存储 Helm Charts 和大模型权重本身。 作为首个 ...

机器学习平台技术栈之 Ceph：筑牢 AI 时代的统一数据底座在构建企业级机器学习平台（Machine Learning Platform）的宏大工程中，我们谈论了计算调度（Volcano）、网络网关（Envoy）、以及 GPU 管理（Device Plugin 等）。然而，在 AI 的世界里，如果没有“数据”，再强悍的算力也只是无源之水。 无论是拥有数十亿张图片的自动驾驶视觉训练集，还是需要频繁保存重启的大语言模型（LLM）几百 GB 的 Checkpoint，亦或是算法端到端流水线（Pipeline）中不同步骤之间需要共享的临时特征文件，存储系统面临着吞吐量、并发度、持久性和云原生兼容性极其苛刻的挑战。 传统的 NAS 或单机文件系统早已无法支撑。在这个背景下，开源分布式存储的无冕之王——Ceph，凭借其“一套系统，三种接口（块、文件、对象）”的高度统一架构，以及无需中心元数据节点的去中心化高可用设计，成为了当今算力中心和 Kubernetes 机器学习平台最为主流的基础数据底座。 本文将极其硬核地深入解构 Ceph。从核心底层组件，到神级路由算法 CRUSH，再到它在 Kuber ...

机器学习平台技术栈之 Envoy Gateway：云原生 AI 流量调度的全能守门人在构建现代大规模机器学习平台（Machine Learning Platform）时，人们通常将目光聚焦在底层的算力调度（如 Volcano）、GPU 资源管理（如 Device Plugin）、或是高性能推理引擎（如 vLLM, TensorRT-LLM）上。然而，当一个优秀的模型被成功加载到显存并开始提供服务后，它将面临现实世界中最复杂的挑战——网络流量。 如何将内部的推理微服务安全、稳定、高性能地暴露给外部用户？如何平滑地进行新老版本模型的 A/B 测试和灰度发布？对于极其昂贵的 LLM（大语言模型）API，如何进行精准的并发控制与全局限流（Rate Limiting）？遇到需要维持长连接的 gRPC 流量（例如 Triton Inference Server）或者是流式响应（Server-Sent Events），网关能否扛住压力？ 过去，我们大量使用 NGINX Ingress 来解决这些问题，但在面对 AI 推理时代复杂的协议栈和动态拉起的异构服务时，传统 Ingress 显得捉襟见肘。因此 ...

机器学习平台技术栈之 DCGM Exporter：AI 集群可观测性的基石在现代机器学习平台（如 Kubeflow、Volcano 搭建的 AI 中台）的建设中，构建庞大的 GPU 算力池需要高昂的硬件投资。动辄数千张的 NVIDIA A100 / H100 显卡构成了整个基础设施的物理底座。 然而，“买得起”和“用得好”之间存在着巨大的鸿沟。如果无法精确掌握每一张 GPU 的运行健康状态、实时利用率（SM 单元、Tensor Cores）、显存带宽乃至 NVLink 的通信状态，整个计算集群就如同盲人瞎马： 算法工程师抱怨训练奇慢无比，但平台由于缺乏监控数据无法定位是 I/O 瓶颈还是代码死锁。 集群频繁出现 OOM 崩溃或是掉卡，SRE（系统可靠性工程师）却只能被动重启，无法预防硬件故障（如 ECC 错误或 XID 异常）。 为解决这一问题，云原生 AI 领域引入了 DCGM Exporter。作为构筑 GPU 集群无死角“可观测性（Observability）”的绝对核心，本文将带你极其硬核地深入解构 DCGM Exporter：从底层监控概念的界定、架构设计、Kub ...

机器学习平台技术栈之 NVIDIA Device Plugin：打通云原生与 AI 算力的任督二脉对于现代机器学习平台（如 Kubeflow、PAI 等）而言，Kubernetes (K8s) 几乎已经是事实上的底层控制平面标准。然而，原生的 Kubernetes 调度器在设计之初，主要关注的是 CPU 和内存（Memory）这类可以任意切分的标准化资源。 随着深度学习的爆发，AI 训练和推理对 GPU、TPU 甚至 NPU 等异构加速硬件的依赖达到了前所未有的高度。Kubernetes 如何能够“看见”、“管理”并“分配”这些长在物理机 PCIe 插槽上的昂贵显卡？容器中的进程又是如何越过操作系统的层层隔离，直接调用底层 GPU 驱动的？ 这背后最大的功臣，就是 NVIDIA Device Plugin 以及与其配套的容器工具链。本文将为你极其硬核地拆解 NVIDIA Device Plugin 以及底层 GPU 透传的技术栈，从 K8s 异构资源抽象模型，到 gRPC 交互的源码级工作流，再到 GPU 共享（Time-slicing/MIG）的高阶玩法，带你全面看透 AI 基础设施 ...

机器学习平台技术栈之 vLLM：重新定义大模型推理的高性能引擎随着 ChatGPT 的横空出世，生成式 AI 进入了“百模大战”的时代。各大企业和研究院不仅关注如何训练出更聪明的基座模型（如 Llama 3, Qwen, ChatGLM），更将目光聚焦在了大规模部署与推理成本上。 在大语言模型（LLM）的生命周期中，训练是一次性的密集投资，而推理（Inference）则是持续不断的开销。传统的深度学习推理框架（如原生 PyTorch 或 HuggingFace Transformers）在处理 LLM 的自回归生成任务时，面临着极低的 GPU 利用率和极其昂贵的显存开销。 为了推倒这堵“推理显存墙”，来自加州大学伯克利分校（UC Berkeley）的研究团队推出了 vLLM。它不仅霸榜了各大开源推理吞吐量榜单，更成为了当下机器学习平台（ML Platform）技术栈中不可或缺的基石组件。 本文将剥茧抽丝，深度剖析 vLLM 的核心概念、架构设计、以及它是如何通过 PagedAttention 技术彻底重塑大语言模型推理引擎的。 1. 痛点解析：为什么 LLM 推理如此艰难？要理解 ...

机器学习平台技术栈之 RDMA Device Plugin在大语言模型（LLM）狂飙突进的时代，训练一个千亿参数的模型动辄需要上千张甚至上万张 GPU。在这个规模下，单节点的算力早已不是唯一的瓶颈，节点间的网络通信能力往往决定了整个集群的计算效率上限。 在分布式训练（如基于 NCCL 的 AllReduce 集合通信）中，GPU 之间需要极其频繁地交换几十甚至上百 GB 的梯度数据。传统的 TCP/IP 协议栈由于其内核态到用户态的内存拷贝（Copy）、上下文切换（Context Switch）开销，导致了极高的延迟和严重的 CPU 负担。为了突破这道网络墙，RDMA（Remote Direct Memory Access，远程直接内存访问） 成为了现代 AI 集群的标配。 而在云原生（Kubernetes）体系下，如何将物理机上的 RDMA 高性能网卡无损地、安全地透传给容器（Pod）使用，是构建 AI 基础设施的关键挑战。这正是 RDMA Device Plugin 的核心使命。 本文将剥茧抽丝，从 TCP/IP 的痛点出发，详细解读 RDMA 的核心概念、K8s 设备插件机制，以 ...

机器学习平台技术栈之 Training Operator随着深度学习模型参数量的爆炸式增长（从千万级别到千亿级别的 LLM），单机单卡的训练模式早已成为历史。现代机器学习（ML）基础设施的核心诉求是如何高效、稳定、可扩展地在 Kubernetes 集群上运行分布式训练任务。 虽然 Kubernetes 提供了原生的 Job 资源来处理批处理任务，但这对于复杂的分布式机器学习训练（如 TensorFlow 的 Parameter Server 模式，或 PyTorch 的 DDP 模式）来说远远不够。分布式 ML 训练涉及多个角色的协同、复杂的网络拓扑发现、特定的环境变量注入，以及对集群调度器（避免死锁）的特殊要求。 为了解决这些痛点，Kubeflow 核心组件之一 Training Operator 应运而生。本文将带你深入剖析 Training Operator，从核心概念、架构设计，到控制面实现细节、网络注入原理以及 Gang Scheduling（群组调度）等关键技术细节，为你呈现云原生机器学习训练架构的全貌。 1. 核心概念解析要理解 Training Operator，我 ...