阿甘的博客 | Arganzheng's Blog

Python 在 AI-Infra：从语言机制到生产交付（总纲）

Python for AI-Infra, from Language Mechanisms to Production Delivery (Overview)

内容简介《Python 在 AI-Infra：从语言机制到生产交付》是一组共七篇的系列文章，面向有后端工程经验（尤其是 Java 背景）、准备转向 AI-Infra 方向的工程师，系统梳理这个方向真正需要的 Python 能力：语言核心机制、类型系统与数据契约、并发与异步、反射与元编程、内存管理、测试与调试、以及工程化交付。这个系列不是 Python 语法教程，也不是技巧集合，而是试图回答一个问题：在 AI-Infra 系统里，Python 并不承担最重的计算，那它到底承担什么？为此需要掌握它的哪些机制？答案是：真正吃算力的部分由 CUDA、C++、通信库和专用推理引擎完成，Python 承担的是组织、调度、扩展、观测和交付——它是整个系统的...

Posted by arganzheng | August 30, 2026

Python 在 AI-Infra（07）：项目工程化与生产交付

Python Project Engineering and Production Delivery

前面几篇讨论的都是”代码本身”：语言机制、类型与数据契约、并发、元编程、内存、测试与调试。这一篇讨论一件不同的事——怎么把这些代码变成一个可以交付的东西。对 Java 开发者来说，这套东西是现成的：关注点 Java Python 依赖管理与构建 Maven / Gradle pyproject.toml + pip / uv / Poetry 环境隔离 JVM + classpath 天然隔离 venv / conda（必须显式创建）应用框架与依赖注...

Posted by arganzheng | August 30, 2026

Python 在 AI-Infra（06）：单元测试、问题定位与调试实践

Python Unit Testing, Troubleshooting, and Debugging

在 AI-Infra 系统中，代码的正确性往往不能只靠阅读来判断。一个推理服务可能涉及异步调度、动态 batch、多后端切换、插件加载和资源生命周期管理。在这些场景下，逻辑正确但时序错误、类型匹配但运行时值不符、代码不报错但内存持续增长——这些问题在 code review 中很难发现，必须依赖测试和调试工具来定位。常见的工程挑战包括：异步代码中的超时、取消和资源泄漏难以用肉眼确认； Mock 不到位导致测试通过但上线失败；插件和装饰器改变了运行时行为，但调用方看到的仍是旧签名； Python 层内存增长缓慢，直到 OOM 时才被发现；进程卡死但没有崩溃，无法从日志判断阻塞位置。本文不展开完整的测试体系，也不讨论大规模监控...

Posted by arganzheng | August 29, 2026

Python 在 AI-Infra（05）：内存管理与优化

Python Memory Management and Optimization

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

Posted by arganzheng | August 28, 2026

Python 在 AI-Infra（04）：反射、元编程与插件化机制

Python Reflection, Metaprogramming, and Plugin Architecture in AI Infrastructure

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

Posted by arganzheng | August 27, 2026

Python 在 AI-Infra（03）：并发、异步与任务协作

Python Concurrency, Asynchrony, and Task Collaboration in AI Systems

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

Posted by arganzheng | August 26, 2026

Python 在 AI-Infra（02）：类型系统与数据契约设计

Python Type System and Data Contract Design

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

Posted by arganzheng | August 25, 2026

Python 在 AI-Infra（01）：语言机制与运行时原理

Python Language Mechanisms and Runtime Internals

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

Posted by arganzheng | August 24, 2026

大模型推理系统揭秘：从 vLLM 看 LLM Serving Infra 核心技术（总纲）

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

Posted by arganzheng | August 15, 2026

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

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