Arganzheng's Blog

stay hungry, stay foolish

反射、元编程与插件化机制:Python 在 AI-Infra 中的动态扩展能力

Python Reflection, Metaprogramming, and Plugin Architecture in AI Infrastructure

在 AI-Infra 系统中,很多核心能力并不是通过一组固定的 if/elif 分支实现的。 模型类型可以动态注册,后端可以按名称加载,算子可以通过配置发现,调度器可以根据任务类型选择执行器,监控系统可以自动收集组件暴露的指标。 这些能力背后,通常依赖三类 Python 机制: 反射(Reflection):运行时检查和操作对象; 元编程(Metaprogramming):编写能够生成、修改或控制代码结构的代码; 插件化(Plugin Architecture):让系统在不修改核心代码的情况下发现和加载扩展组件。 它们共同构成了 Python 框架“动态性”的基础。 但动态性也意味着风险。过度依赖字符串、隐式注册和运行时修改,可能让系统变得...

Python 内存管理与优化

Python Memory Management and Optimization

在 AI-Infra 系统中,Python 通常不是执行密集计算的主体。模型推理、张量运算和部分数据处理,往往由 C、C++、CUDA 或其他原生运行时完成。 Python 更多承担以下职责: 组织请求、任务和配置对象; 管理数据结构与生命周期; 调用 NumPy、PyTorch 等原生库; 连接 CPU 内存、GPU 显存和外部服务; 协调模型、缓存、队列及资源句柄。 因此,Python 性能问题不一定表现为某段 Python 代码“计算得很慢”。很多时候,真正的问题来自: 创建了过多 Python 对象; 临时对象存活时间过长; 容器或缓存无限增长; 不小心进行了复制; Python 对象与原生数据之间发生了...

Python 并发、异步与任务协作

Python Concurrency, Asynchrony, and Task Collaboration in AI Systems

在 AI-Infra 系统中,Python 往往并不直接承担最重的数值计算。真正消耗算力的部分,通常由 CUDA、C++、通信库或专用推理引擎完成。 但这并不意味着 Python 不需要并发。 恰恰相反,模型服务、任务调度、数据预处理、资源监控和流水线编排,通常都由 Python 负责。系统的吞吐量、尾延迟和资源利用率,很大程度上取决于 Python 是否能够正确组织并发任务。 常见场景包括: 同时处理大量模型推理请求; 并发访问对象存储、数据库和远程 RPC 服务; 在多个模型节点之间转发流式数据; 调度训练任务并持续监控任务状态; 让 CPU 预处理、GPU 推理和结果后处理形成流水线; 在请求高峰期通过队列和背压保护系统资源。...

Python 核心机制与工程基础

Python 常被认为是一门“简单易学”的语言,但在 AI-Infra、深度学习框架、推理服务和分布式系统中,真正需要掌握的并不只是语法。 很多看似简单的代码,背后都依赖 Python 的运行时机制: import 可能触发注册、插件发现或 CUDA 扩展加载; model(x) 实际上可能调用了对象的 __call__; with torch.inference_mode() 背后是上下文管理协议; for batch in loader 依赖迭代器和生成器; super() 并不简单等于“调用父类方法”; 一个装饰器可能改变函数的执行逻辑、类型签名和异常栈; 一个异常是否被捕获,可能决定整个 Worker 是否退出; 一个模...

Python 类型系统完全指南

导言:Python 类型系统的两层架构 Python 是动态类型语言,但这不意味着”无类型”。自 Python 3.5 引入 typing 模块以来,类型注解已经从”可选装饰”演变为大型项目的工程标配。PyTorch、vLLM、FastAPI 等 AI Infra 项目大量依赖类型系统的高级特性。 与 Java 把类型声明、编译检查、.class 文件携带类型信息、运行时反射合为一体不同,Python 的类型系统由两个协作层构成——类型信息提供层和类型信息消费层: 类型信息提供层 ┌──────────────────────────────────────────────┐ │ 类型表达 ...

Python中如何定义POJO

在 Python 编程中,我们经常需要定义各种数据结构(如用户信息、配置项、API 请求体)。传统的写法不仅伴随着大量重复的模板代码,还面临着数据校验繁琐的痛点。 本文将带你梳理从原生 init、标准库 @dataclass 到 Pydantic 的演进过程,带你看看现代 Python 是如何优雅地处理数据建模与校验的。同时为了方便Java程序员快速上手,我们也横向对比了Java 生态(Record / Lombok / Bean Validation) 的实现差异 。 一、 Python 语法的演进:三种数据模型的构建方式 1. 传统流派:原生的 init 构造方法 在最传统的面向对象写法中,我们通过显式定义构造函数来接收并赋值属性。 class Use...

大模型推理系统揭秘:从 vLLM 看 LLM Serving Infra 核心技术(总纲)

内容简介 《大模型推理系统揭秘:从 vLLM 看 LLM Serving Infra 核心技术》以 vLLM v0.27.1 为主要分析对象,从 LLM Serving 的问题本质出发,系统讲解请求生命周期、性能指标、调度、KV Cache、GPU 执行、多卡并行、模型适配、硬件抽象、Prefill/Decode 分离与集群化部署。 本书不局限于算子优化,也不止于源码解读,而是试图回答一个更完整的问题: 一个文本生成请求,为什么会逐渐演化成一个涉及计算、显存、调度、通信与状态管理的复杂系统? 在这个视角下,LLM Serving 不再只是“把模型跑起来”,而是一个持续协调请求、Token、计算资源、中间状态和网络通信的动态系统。 文章将按照以下主线...

大模型推理系统揭秘(12):回到源码:一次请求在 vLLM 内部的真实旅程

NOTE 本文基于 vLLM v0.27.1(tag 6e448d0, 2026-08-11)源码深度剖析。文中所有文件路径、类名和行号均以该版本为准;vLLM 迭代很快,阅读时请以你手上的版本对照。 前九章回答了「是什么」和「为什么」,这一章回答「怎么实现」。 现在你已经知道 Scheduler 为什么要按 token 预算调度、KV Cache 为什么要分块、Attention Backend 为什么要按 batch 形态分派。带着这些「为什么」回头看数据结构,它们就不再是需要背的字段列表,而是每一个都能对应到一个设计约束。 这一章刻意放在最后:如果它出现在第二章,你只会看到一堆 class;出现在这里,你会看到设计决策留下的痕迹。 1....

大模型推理系统揭秘(11):Serving Infra 的下一站:从模型执行器到分布式智能操作系统

NOTE 本文基于 vLLM v0.27.1(tag 6e448d0, 2026-08-11)源码深度剖析。文中所有文件路径、类名和行号均以该版本为准;vLLM 迭代很快,阅读时请以你手上的版本对照。 在前面的章节中,我们围绕 vLLM 的核心机制展开了讨论:模型如何加载,算子如何执行,请求如何调度,以及 KV Cache 如何管理。 这些机制解决的是一个核心问题: 如何让一次模型推理更高效? 但在真实生产环境中,请求正在变得越来越复杂。一个请求可能包含超长上下文、多轮对话、工具调用、Session 状态,以及图像、音频或视频输入。它不再是一次短暂的函数调用,而可能是一个持续数分钟甚至数小时的分布式任务。 因此,Serving 系统需要管理...

大模型推理系统揭秘(10):PD 分离:从资源混部走向计算解耦

NOTE 本文基于 vLLM v0.27.1(tag 6e448d0, 2026-08-11)源码深度剖析。文中所有文件路径、类名和行号均以该版本为准;vLLM 迭代很快,阅读时请以你手上的版本对照。 前九章主要讨论的是: 如何在一台机器或一组共享设备上,把请求高效地运行起来? 这一章进一步追问: 如果 Prefill 和 Decode 不再共享同一批 GPU, 它们如何协作完成同一个请求? 这就是 PD 分离,也就是 Prefill/Decode Disaggregation。 PD 分离表面上是把 GPU 分成两个池子: Prefill Pool → 负责处理输入 Prompt Decode Pool → 负责逐 Token 生成...

×