无题
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 的标准范式
在实现具体算子之前,我们总结出一套标准的导入流程(范式):
解析 ...
在华为刀片服务器上:离线安装 ipmitool 并固定 BMC 管理口 IP 的完整记录
环境:华为刀片服务器,操作系统 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 源码解析(九):模型加载架构与设计哲学
概述
本文深入分析 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
概述
阶段八学习 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 ...
Mini-SGLang 源码解析(七):分布式推理系统
学习文件: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 ...
Mini-SGLang 源码解析(六):KV Cache 管理系统
学习文件: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 ...
Mini-SGLang 源码解析(五):注意力机制系统
学习文件: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 ...
Mini-SGLang 源码解析(四):GPU 计算引擎系统
学习文件: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 源码解析(三):调度系统详细实现
学习目标
深入理解 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 源码解析(二):推理流程与多进程架构
本文深入分析 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 源码解析(一):核心数据结构与设计模式
本文深入分析 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): 插件架构实战 — 从旧架构到新架构的迁移
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 与自动注册
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 基类与静态多态
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 接口设计
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 风格权重预加载
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: 解析模型 → 优化图 → ...



