James的成长之路

123456789101112title: 'Mini-Infer (19): 内置算子导入实战 — Conv, ReLU, Pooling 与 Flatten'tags: - AI Infracategories: - AI Infra - Mini-Infercover: 'https://imgs.james-blog.top/imgs/dd34fa5844ac016d966f0adde655cee7.png'toc: truemathjax: trueabbrlink: 112date: 2025-12-03 22:40:00description: 'Mini-Infer (19): 内置算子导入实战 — Conv, ReLU, Pooling 与 Flatten' Mini-Infer (19): 内置算子导入实战 — Conv, ReLU, Pooling 与 Flatten 1. 核心逻辑：OperatorImporter 的标准范式 在实现具体算子之前，我们总结出一套标准的导入流程（范式）： 解析 ...

环境：华为刀片服务器，操作系统 CentOS Linux 7.9 (Core) x86_64，内网无外网访问，只能通过 U 盘等方式离线安装软件。 这次的目标很简单，但过程不算短： 在 完全离线的 CentOS 7.9 上安装 ipmitool； 用 ipmitool 查出华为刀片的 BMC（管理口）IP； 把原本 DHCP 获取的管理口 IP 固定下来（保持不变，但改为静态配置）； 顺带解决 “跳板机 ping 不到管理口”、“ipmitool timeout” 等一系列小坑。 下面按时间线把过程梳理一下。 一、确认系统版本和架构：别一上来就装错包 在离线环境下安装 RPM 包，第一步必须搞清楚系统版本和架构，否则 100% 会装错。 在服务器上执行： 12cat /etc/centos-releaseuname -m 得到结果： 12CentOS Linux release 7.9.2009 (Core)x86_64 这两个信息非常关键： 说明这是 CentOS 7 系列，而不是 Stream 9； 架构是 x86_64，所以必须找 ...x86_64.rpm 的包。 ...

概述 本文深入分析 Mini-SGLang 的模型加载架构，对比传统方式（如 HuggingFace Transformers）与 Mini-SGLang 的设计差异，理解结构与权重分离的设计哲学及其带来的优势。 核心发现：Mini-SGLang 不是通过解析配置文件动态构建模型，而是先手动定义网络结构，再加载权重。这种设计使得框架具有极高的可定制性和优化空间。 1. 支持的模型 1.1 当前支持 Mini-SGLang 目前支持 2 个模型系列： 1. Llama 系列 Llama-2 (7B, 13B, 70B) Llama-3 (8B, 70B) Llama-3.1 (8B, 70B, 405B) Llama-3.2 其他 Llama 架构变体（Mistral、Yi 等） 2. Qwen3 系列 Qwen3-0.6B Qwen3-14B Qwen3-32B 1.2 模型判断逻辑 1234567891011# models/__init__.pydef create_model(model_path: str, model_config: ModelConfig) ...

概述 阶段八学习 Mini-SGLang 的高级特性，主要是自定义 CUDA Kernels。这些 Kernels 通过 C++/CUDA 实现，提供比 PyTorch 更高的性能。 核心问题：为什么需要自定义 CUDA Kernels？ 答案： 性能优化：PyTorch 的通用实现有额外开销 内存效率：直接操作 GPU 内存，避免中间拷贝 并行优化：针对特定场景优化并行策略 内存对齐：利用 GPU 缓存行对齐提高带宽 1. Radix 树操作：kernel/radix.py 1.1 核心思想 问题：在 Radix Tree 中，需要频繁比较两个 token 序列是否相等。Python 的比较很慢。 解决方案：用 C++ 实现快速比较，通过 TVM FFI 调用。 1.2 关键代码 1234567@lru_cache(maxsize=None)def _load_radix_module() -> Module: return load_aot("radix", cpp_files=["radix.cpp"])def fast_compare_key(x: t ...

学习文件：distributed/info.py, distributed/impl.py, layers/linear.py, message/backend.py 1. 为什么需要分布式推理？ 挑战1：模型太大 大模型参数量巨大（例如 Llama-70B 有 700 亿参数） 单个 GPU 显存不够（例如 A100 只有 80GB） 需要多 GPU 并行 挑战2：推理速度慢 单 GPU 计算速度有限 需要并行计算提高吞吐量 解决方案：Tensor Parallelism（TP） 核心思想： 将模型的张量（权重、激活）切分到多个 GPU 每个 GPU 计算一部分 通过通信合并结果 类比： 就像一个大任务分给多个工人 每个工人负责一部分 最后汇总结果 2. DistributedInfo：分布式信息 2.1 核心概念 12345678910@dataclass(frozen=True)class DistributedInfo: rank: int # 当前进程的编号（0, 1, 2, ...） size: int # 总进程数（例如 4 ...

学习文件：kvcache/base.py, kvcache/mha_pool.py, kvcache/naive_manager.py, kvcache/radix_manager.py 1. 为什么需要 KV Cache 管理？ 在阶段一我们学习了 KV Cache 的基本概念：缓存已计算的 Key 和 Value，避免重复计算。 但在实际系统中，KV Cache 管理面临更多挑战： 挑战1：内存有限 GPU 内存有限（例如 24GB） 每个请求的 KV Cache 可能很大（长文本、长对话） 需要驱逐策略来释放空间 挑战2：前缀复用 多个请求可能有相同的前缀（例如 System Prompt） 重复存储浪费内存 需要前缀共享机制 挑战3：并发安全 多个请求同时访问缓存 驱逐时不能删除正在使用的缓存 需要锁机制 2. KV Cache 系统架构 Mini-SGLang 的 KV Cache 系统分为两层： 123456789┌─────────────────────────────────────────┐│ BaseCacheManage ...

学习文件：attention/base.py (66 行), attention/fa.py (187 行), attention/fi.py (279 行) 1. Attention Backend 的核心职责 Attention Backend 是整个推理系统的计算核心，负责执行 Attention 计算： 1.1 职责定位 输入：Q (Query)、K (Key)、V (Value) 三个矩阵 输出：Attention 输出（加权求和后的结果） 核心：实现高效的 Attention 计算 1.2 为什么需要抽象基类？ Mini-SGLang 支持多种 Attention 实现： FlashAttention：适合 Prefill 阶段（计算密集） FlashInfer：适合 Decode 阶段（访存密集） 但 Engine 只需要调用 attn_backend.forward()，不关心具体实现。 123456789# engine.pyclass Engine: def __init__(self, config): self.attn_ba ...

学习文件：engine/engine.py (209 行), engine/graph.py (145 行), engine/sample.py (76 行), models/base.py (15 行), models/llama.py (86 行) 1. Engine 的核心职责 Engine 是整个推理系统的数据平面，负责实际执行 GPU 计算： 1.1 职责定位 Scheduler：控制平面，决定"做什么"（调度哪些请求） Engine：数据平面，执行"怎么做"（前向传播 + 采样） 1.2 核心功能 模型加载和权重管理 KV Cache 内存分配 前向传播执行 Token 采样 CUDA Graph 优化 跨 Stream 异步同步 2. Engine 初始化流程 2.1 初始化的 6 个步骤 12345678910111213141516171819202122232425262728def __init__(self, config: EngineConfig): # 1. 设置设备和通信 self.device = torch.devi ...

学习目标 深入理解 Mini-SGLang 的调度系统,包括: Scheduler 主调度器的核心逻辑 PrefillManager 的 Chunked Prefill 实现 DecodeManager 的请求管理 重叠调度 (Overlap Scheduling) 的原理 1. 调度系统整体架构 1.1 核心组件 调度系统由 5 个核心组件组成: 123456Scheduler (主调度器) ├─→ PrefillManager (Prefill 阶段调度) ├─→ DecodeManager (Decode 阶段调度) ├─→ CacheManager (缓存管理) ├─→ TableManager (页表管理) └─→ Engine (GPU 计算引擎) 1.2 数据流概览 123456789101112131415用户请求 (UserMsg) ↓PrefillManager.pending_list (待处理队列) ↓Scheduler._schedule_next_batch() (调度批次) ↓Scheduler._prepare_batch( ...

本文深入分析 Mini-SGLang 的完整推理流程，探讨多进程架构、ZMQ 消息传递、流式反分词和重叠调度等核心技术。 环境：Mini-SGLang v0.1.0 | Python 3.10+ | PyTorch 2.0+ 源码位置：python/minisgl/server/, python/minisgl/scheduler/, python/minisgl/tokenizer/ 1. 背景：推理系统的架构挑战 LLM 推理系统需要平衡三个关键目标： 低延迟：用户体验要求快速响应（首 token 延迟 < 100ms） 高吞吐：服务端需要同时处理大量请求（> 1000 QPS） 资源利用：GPU 利用率需要保持在 80% 以上 Mini-SGLang 通过多进程架构 + 异步消息传递实现了这些目标。 2. 系统架构：3 进程模型 2.1 架构全景 1234567┌─────────────┐ ZMQ ┌─────────────┐ ZMQ ┌─────────────┐│ Frontend │ ────→ │ Tokenizer ...

本文深入分析 Mini-SGLang 的核心数据结构设计，探讨 LLM 推理系统的关键优化技术。 环境：Mini-SGLang v0.1.0 | Python 3.10+ | PyTorch 2.0+ 源码位置：python/minisgl/core.py 1. 背景：LLM 推理的性能瓶颈 大语言模型推理面临两个核心挑战： 计算密集：Transformer 的自注意力机制复杂度为 O(n²) 内存密集：KV Cache 占用大量显存，成为推理瓶颈 Mini-SGLang 通过精心设计的数据结构和调度策略，在保持代码简洁（~5000 行）的同时，实现了接近 vLLM 的性能。 2. KV Cache：从 O(n²) 到 O(n) 的优化 2.1 问题定义 在自回归生成中，每生成一个新 token，都需要计算注意力： 123456# 标准 Transformer 注意力Q = x @ W_q # Query: [batch, seq_len, d_model]K = x @ W_k # Key: [batch, seq_len, d_model]V = x @ W_ ...

Mini-Infer (35): 插件架构实战 — 从旧架构到新架构的迁移 1. 迁移策略概述 从旧的 Operator + Kernel 架构迁移到新的 Plugin 架构，我们采用以下策略： A. 保留底层原语 底层计算原语（im2col、gemm、bias、transpose）保持不变，它们是设备无关的数学操作： 1234567保留：├── kernels/cpu/gemm.cpp├── kernels/cpu/im2col.cpp├── kernels/cpu/bias.cpp├── kernels/cuda/gemm.cu├── kernels/cuda/im2col.cu└── kernels/cuda/bias.cu B. 删除旧 Kernel 实现 旧的算子级 Kernel（如 Conv2DKernel、ReLUKernel）被删除，其逻辑移入 Plugin： 12345删除：├── kernels/cpu/conv2d_kernel.cpp → 移入 Conv2DCPUPlugin├── kernels/cpu/relu_kernel.cpp → 移入 ...

Mini-Infer (34): 插件架构 (下) — PluginRegistry 与自动注册 1. 问题背景：双层注册的痛点 在旧架构中，我们有两个独立的注册表： 1234// 旧架构OperatorFactory::register_operator("Conv2D", Conv2DOperatorCreator);KernelRegistry::register_kernel("Conv2D", CPU, Conv2DCPUKernel);KernelRegistry::register_kernel("Conv2D", CUDA, Conv2DCUDAKernel); 问题： 维护成本高：添加新算子需要修改两个地方。 一致性问题：Operator 和 Kernel 的注册可能不同步。 查找开销：执行时需要先查 Operator，再查 Kernel。 新架构：统一的 PluginRegistry，一次注册，直接使用。 2. PluginKey 设计 A. 二元组 Key 12345678910// mini_infer/operators/plugin_regis ...

Mini-Infer (33): 插件架构 (中) — CRTP 基类与静态多态 1. CRTP 模式回顾 CRTP（Curiously Recurring Template Pattern，奇异递归模板模式）是 C++ 中一种强大的设计模式，用于实现静态多态。 A. 基本形式 1234567891011121314template <typename Derived>class Base {public: void interface() { static_cast<Derived*>(this)->implementation(); }};class Derived : public Base<Derived> {public: void implementation() { // 具体实现 }}; B. 静态多态 vs 动态多态 特性 动态多态 (virtual) 静态多态 (CRTP) 绑定时机 运行时 编译时 虚函数表 需要 不需要 性能开销 有（间接调 ...

Mini-Infer (32): 插件架构 (上) — IPlugin 接口设计 1. 问题背景：为什么需要插件架构？ 在之前的 Mini-Infer 实现中，我们使用了 Operator + Kernel 双层抽象： Operator：定义算子的元数据（输入/输出数量、形状推理）。 Kernel：实现具体的计算逻辑（CPU/CUDA）。 这种设计在早期工作良好，但随着功能增加，问题逐渐暴露： A. 双层抽象的问题 12345Operator (元数据) ↓KernelRegistry (查找) ↓Kernel (计算) 维护成本高：添加新算子需要修改两个地方。 一致性问题：Operator 和 Kernel 的参数可能不同步。 查找开销：每次执行都需要从 Registry 查找 Kernel。 B. 多后端支持的复杂性 123// 旧架构：需要为每个后端注册 KernelREGISTER_KERNEL(Conv2D, CPU, Conv2DCPUKernel);REGISTER_KERNEL(Conv2D, CUDA, Conv2DCUDAKernel); ...

Mini-Infer (31): CUDA 后端支持 (下) — TensorRT 风格权重预加载 1. 问题背景：权重拷贝的性能瓶颈 在 GPU 推理中，一个常见的性能问题是权重拷贝开销。 A. PCIe 带宽限制 CPU 和 GPU 之间通过 PCIe 总线通信。即使是 PCIe 4.0 x16，理论带宽也只有约 32 GB/s，远低于 GPU 显存带宽（如 A100 的 2 TB/s）。 123CPU Memory ──PCIe──► GPU Memory ↑ 瓶颈所在 B. 首次推理延迟 如果每次推理都从 CPU 拷贝权重到 GPU： 123推理请求 → 拷贝权重 → 执行计算 → 返回结果 ↑ 额外延迟 对于一个 100MB 的模型，PCIe 拷贝可能需要 3-5ms，而实际计算可能只需要 1ms。 C. TensorRT 的解决方案 TensorRT 在 Build-Time 将权重加载到 GPU，Run-Time 直接使用： 12Build-Time: 解析模型 → 优化图 → ...