1. AI infra到底在解决什么问题说实话这两年AI行业最不缺的就是模型缺的是能把模型老老实实跑起来、跑得稳的人。你去看各大厂的招聘岗位AI infra方向的薪资一路走高但真正懂行的人依然稀缺。所谓AI infra落到日常工作中其实就是三个字部署、优化、运维——把训练好的模型塞进GPU让它以最快的速度、最低的成本响应线上请求并且在流量波动、显存不足、并发暴涨的时候不崩。这个方向的门槛在于它既要求你懂模型结构哪怕不训练也要知道Transformer每一层在干嘛又要求你懂系统进程、内存、CUDA、GPU架构还要懂一点网络和分布式。我个人觉得AI infra最核心的思维方式和普通后端不太一样——普通后端关注的是吞吐和延迟AI infra额外要面对一个更麻烦的东西KV Cache的显存管理。而最近这一年Agent的热潮又把AI infra推向了一个新高度。为什么因为Agent应用对推理引擎的要求完全变了不再是“用户问一句、模型答一句”的单轮模式而是模型自己在一个循环里反复调用自己——思考、调工具、看结果、再思考。这个过程中每次调用都带着很长的历史上下文而且频繁触发函数调用、结构化输出。传统推理框架在支撑这种场景时表现往往不如人意。所以这篇内容我把平时工作里围绕vLLM、SGLang、PyTorch以及Agent框架沉淀下来的技能点集中整理了一遍。既讲原理也讲实操还包含大量我自己踩过的坑。适合以下人群阅读正在做或打算转行做AI infra的工程师已经在用vLLM/SGLang部署模型但只停留在“会用”层面的人做Agent开发经常抱怨“模型调用太慢、上下文太长就崩”的人想搞懂推理引擎内部原理但被源码劝退的同学。内容会比较长建议收藏后分几次看完。我尽量用说人话的方式把每个知识点讲透。2. vLLM大规模推理的事实标准2.1 为什么vLLM能成为标配三张王牌现在但凡提到大模型部署vLLM几乎是默认选项。它之所以能火不是因为名字好听也不是因为文档写得全而是因为它真正解决了大模型推理中的几个致命痛点。第一张王牌是PagedAttention。这个机制借鉴了操作系统的虚拟内存分页思想。传统推理框架在生成过程中需要为每个请求的KV Cache预先分配连续显存但“未来会生成多长”这件事在请求进来的时候是未知的——预分配多了浪费预分配少了爆显存。PagedAttention把KV Cache切成固定大小的块block按需分配不要求物理连续类似操作系统里一页页的虚拟内存。这个机制直接让显存利用率飙到90%以上之前很多框架只能用到60%左右。第二张王牌是Continuous Batching。传统做批处理是静态的攒够一批请求统一跑跑完再接收下一批。问题是不同请求的长度差很远短的跑完了也得等着长的GPU空转浪费严重。vLLM的做法是动态的一个请求生成完一个token如果它已经到达终止条件立刻离开batch新的请求马上补进来。每一步推理的batch都是实时拼出来的GPU始终满负荷运转。第三张王牌是Prefix Caching。Agent场景下尤其关键——同一个system prompt会被反复使用很多框架每次都要从头计算vLLM会自动缓存前缀的KV状态命中后直接复用。实测下来多轮对话场景有这一项就能省一半以上的首token延迟。这三项加起来就是vLLM吞吐量远高于TGI、FasterTransformer等老牌方案的底层原因。需要留意的是PagedAttention属于论文级别的创新而Continuous Batching和Prefix Caching很多框架也都在做vLLM的优势在于整合得最干净、社区最活跃、迭代最快。2.2 EngineCore与Scheduler、Executor的交互流程vLLM的源码尤其是0.6.0之后重构出的EngineCore架构是很多人想读懂但被劝退的部分。我自己当时也是啃了很久才理清头绪。这里画一条主线vLLM的推理循环本质上由三个角色协作完成。Scheduler负责“决策”。它维护一个等待队列waiting、一个运行集合running可能还有一个swap集合swap。每步推理开始前Scheduler根据显存剩余情况判断哪些请求能从waiting进入running哪些running状态的请求要抢占或继续跑。一句话总结Scheduler不碰GPU它只做记账和排队。Executor负责“执行”。它真正调用GPU kernel完成prefill和decode。Executor层管理着实际的GPU显存分配、CUDA stream等底层资源把所有计算任务落到实处。SGLang里也有类似的分层但细节略有不同。EngineCore则是0.6版本之后的异步引擎核心。它把Scheduler和Executor整体封装起来通过队列与外部通信。外部比如FastAPI server只需要把请求丢进输入队列EngineCore在内部的循环里完成调度和计算再把结果塞进输出队列。这样做的好处是请求处理和推理循环彻底解耦EngineCore可以独立跑在单独的进程里IO不会阻塞计算。我给一个非常简化的数据流帮助理解外部请求 → input queue → EngineCore ├── Scheduler: 决定本step跑哪些请求看显存预算、优先级、抢占策略 ├── Executor: 真正跑模型的前向计算prefill/decode └── 生成结果 → output queue → 返回给调用方如果你要读源码建议按这个顺序切入先读vllm/engine/async_llm_engine.py理解EngineCore对外暴露的接口再读vllm/core/scheduler.py重点看_schedule方法——这是整个推理调度策略的核心也就两三百行最后读vllm/worker/model_runner.py看Executor怎么把张量搬运到GPU、怎么调用attention backend。不要一上来就看executor层那些CUDA kernel那不是看源码该走的路。2.3 vLLM部署大模型从镜像选择到参数匹配部署这块我直接给一套可复用的流程以Docker方式部署Qwen系列这类开源模型为例这也是目前最主流的姿势。第一步是选镜像。官方仓库里维护的镜像通常命名类似vllm/vllm-openai版本号对应vLLM的版本。我的习惯是先用最新稳定版等踩过坑再根据实际场景锁定版本。比如需要跑Qwen3.8-27b的Q8_0量化版就注意在镜像中确认是否内置了对应量化格式的支持——镜像本身不一定带模型模型文件是通过挂载目录或者从HuggingFace拉取的。第二步是启动服务核心参数逐个说清楚--model模型路径或HuggingFace的repo名--tensor-parallel-size跨多少张卡做张量并行。显存够的情况下优先提高这个值单卡吞吐会明显改善--gpu-memory-utilization控制最多占用多少比例显存做KV Cache。我一般设0.9剩下的留给CUDA context和临时张量--max-model-len最大上下文长度太大会导致显存不够太小会截断长上下文Agent请求--enforce-eager关掉CUDA Graph加速如果模型不兼容CUDA Graph时的兜底选项牺牲一点速度换稳定性。一个比较稳妥的部署命令长这样这里给出的是bash命令模板具体参数按你的环境调整docker run --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/qwen3-27b \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 \ --served-model-name qwen启动之后用OpenAI兼容接口访问http://localhost:8000/v1/chat/completions接Chatbox之类的客户端也走这个接口非常方便。2.4 vLLM新版本性能下降的排查经验之前遇到过一个很典型的案例公司内部把一个服务从vLLM 0.4升级到0.6之后吞吐量反而掉了一截。当时排查的结果是——新版本默认开启了某些特性比如更激进的前缀缓存策略和额外的日志采集在短请求高并发的场景下反而拖慢了速度。这类问题我总结出一套排查流程先确认是不是配置问题新旧版本的默认值可能完全不同比如max_num_batched_tokens、max_num_seqs、enable_prefix_caching逐个对齐对比再用profiler说话不要靠感觉用vllm自带的--profiler参数抓性能数据或者用py-spy看一下进程在哪个函数里耗时最长查版本changelog看新版本有没有引入已知的性能回退GitHub issues里搜版本号加“performance regression”关键词通常能找到别人的反馈实在不行就回退生产环境追求稳定如果新版本没有你需要的功能回退到旧版本不丢人。另外还有一个常见现象新版本CUDA Graph默认开启如果你的模型里有一些自定义算子不支持图捕获就会反复fallback到eager模式性能暴跌。这种情况在日志里找“CUDA graph”相关警告就能定位。3. SGLangAgent场景下的另一块拼图3.1 SGLang和vLLM的定位差异SGLang这两年风头很劲很多人问我和vLLM到底选哪个。我的回答是不要把它们看作是替代关系而要看场景。vLLM的强项是高并发、大规模、通用对话场景——你起一个服务成千上万个用户同时访问vLLM的调度和显存管理能做到很高的吞吐。SGLang的强项则在于结构化场景下的极致优化尤其适合Agent这种“模型频繁调用工具、要求输出严格符合JSON schema、上下文大量复用”的负载。它用一套名为RadixAttention的机制把KV Cache组织成树状结构任何请求只要前缀或中缀命中过就能复用对应的KV块而不是从头重新计算。这句话的含金量在Agent场景中非常高——你想一个Agent循环里十次模型调用可能共享同一个system prompt和工具定义命中了就是几倍的延迟节省。3.2 RadixAttention和结构化生成的核心逻辑RadixAttention这个名字听起来高大上其实思路很朴素把prompt的前缀看成字符串前缀用类似基数树radix tree的结构管理所有请求历史的KV Cache。每次有新请求进来先在树里匹配最长公共前缀命中的部分直接复用只计算没命中的新内容。比如一个多轮Agent对话System prompt工具定义 → 第一轮用户问题 → 模型回复 → 调用工具结果 → 第二轮用户问题...如果系统提示词特别长比如20个工具定义好几千token而每个请求都包含这串内容传统方式每轮都要重新计算这几千token的KV。用RadixAttention第二次请求时这一整段直接命中缓存相当于白嫖了前一轮的计算结果。SGLang还在语言层做了很多针对性设计——它支持给输出加约束解码可以规定“必须以JSON格式输出且字段必须是xxx”这类硬性规则生成的每一步都检查是否满足schema不满足的思路直接剪掉。对于Agent场景的function calling这个能力比vLLM原生支持更精细实测错误率能降一个量级。3.3 源码解析该从哪几个模块入手想读懂SGLang源码我建议抓三条线。第一是前端语言层看sglang/lang目录理解它怎么把Python代码转换成可执行的有向图类似把一段“思维链”编译成计算图。第二是运行时调度层看sglang/srt/managers/scheduler.py。这里实现了RadixAttention相关的缓存管理逻辑也就是RadixCache类。重点关注cache_finished_req和cache_miss这两个路径——一个负责把算完的结果写进树一个负责计算有多少前缀可以命中。第三是后端执行层看sglang/srt/models目录下的各种模型实现。SGLang的模型代码写得比vLLM更容易读每个模型文件就是一个完整的Transformer实现适合理解推理时每一层的张量形状变化。我的经验是不需要把SGLang全部源码读完才有资格用——你只需要知道哪些场景适合它能在出问题时定位到特定模块就已经超过了90%的使用者。4. PyTorch所有推理引擎的地基4.1 安装PyTorch最容易踩的几个坑vLLM和SGLang的底层都是PyTorch所以一切推理性能优化的前提是PyTorch本身装对、跑稳。先说安装。很多人在这一步就被卡住pip install torch默认装的是CPU版本装上之后发现GPU根本用不了。这个坑太经典了——PyTorch官方从2.0开始默认的PyPI包就只包含CPU实现你要装GPU版本必须通过额外索引指定CUDA版本。最常见的报错是ERROR: Could not find a version that satisfies the requirement torch这种情况绝大多数是因为本机Python版本和PyTorch要求的版本区间不匹配或者pip源里没有对应平台的轮子。解决办法也很简单先到PyTorch官网的安装页pytorch.org/get-started/locally选好你的CUDA版本它会直接生成命令如果是CUDA 12.1就用pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121装完务必验证一下python -c import torch; print(torch.__version__, torch.cuda.is_available())cuda.is_available()必须返回True否则就是白装了。4.2 边缘设备和特殊平台的配置经验在边缘设备上配PyTorch又是另一套折腾。Jetson系列尤其典型——它用的CUDA是L4TLinux for Tegra定制的不能直接pip安装普通x86的torch轮子。我第一次在Jetson Orin上配torch的时候也是被各种依赖项折磨了很久。给一条已知可行的路线JetPack SDK里预装了对应版本的PyTorch直接通过pip install指定官方为NVIDIA提供的whl地址即可注意torchvision的版本必须和torch严格对应。装完之后用上面的验证代码快速检查。还有一类场景是“机械狗 MuJoCo torch”这种机器人仿真。核心坑点在于CUDA版本的strict匹配MuJoCo有自己的GPU加速支持如果torch用的CUDA版本和MuJoCo编译时的版本不一致轻则警告重则直接段错误。我的建议是物理仿真类和深度学习类代码分进程跑通过共享内存或socket通信避免把两套CUDA runtime塞进一个进程。4.3 torch在推理引擎中的真实角色很多人有个误解觉得vLLM把PyTorch“替代”了。实际上vLLM的模型权重管理、前向计算、自动微分虽然推理不需要梯度都跑在PyTorch之上。vLLM做的是在PyTorch外面加了一层调度和显存管理但真正执行算子的还是PyTorch的nn.Module和CUDA kernel。这带来一个很实用的推论你的模型如果能在vLLM/SGLang里跑那它也一定能用原生PyTorch跑。所以当你怀疑推理引擎有问题时最直接的对照实验就是用纯PyTorch加载同样的权重跑同一个prompt对比输出和性能。这个“二分法”能帮你迅速判断瓶颈是在引擎层还是模型层。另外torch.compile这两个字最近出现频率很高。它是PyTorch 2.0引入的即时编译技术能把模型里的算子融合、减少内核启动开销。vLLM在部分后端里也用了类似思路但深度定制过。你自己做推理服务时如果直接用原生torch可以试试torch.compile(model, modereduce-overhead)——在一些小模型上能有20%~40%的延迟提升代价是首次编译要等几十秒。5. Agent框架与编排从skill到harness5.1 skill和agent到底有什么区别这个区分值得写一笔。Agent的文档里到处是skill这个词但很多人把skill理解成“一个功能模块”这个理解太浅了。我的定义是skill是能力原子agent是决策主体。skill解决的是“怎么做”的问题是对外部世界的操作封装——比如调用搜索引擎、读写文件、执行SQL、画一张图。agent解决的是“做什么、什么时候做”的问题——它内部有个循环反复思考当前状态、决定调用哪个skill、解读skill返回的结果。举个具体的例子一个数据分析Agent可以拆成skill1写Python代码并执行能力原子skill2读取CSV/Database能力原子skill3生成图表能力原子agent解读用户意图 → 决定先调skill2还是skill1 → 根据中间结果决定下一步同样一套skill配上不同的agent循环能解决完全不同的问题。这就是为什么很多Agent框架把skill设计成插件——它们希望你的能力库和决策逻辑解耦这样两种都可以独立演进。5.2 harness和agent的边界“harness”这个词在Agent圈子里也频繁出现但和agent的关系经常被搞混。用一句直白的话概括harness是套在agent外面的控制器它负责执行循环、管理运行环境、统一处理输入输出让agent只专注于“思考和调用skill”。如果你写过一个Agent循环你会发现它其实就三件事观察环境、决定动作、执行动作。harness把这套循环抽象成通用框架你只需要提供一个agent核心逻辑可能就是一个模型调用函数调用解析harness负责跑起来。好处是标准化日志、重试、超时、安全策略这些通用问题都在harness层解决不用每个项目都重写一套。在调试Agent项目时如果遇到Agent execution terminated due to error.这类信息不要先去怀疑agent的判断逻辑而应该先看harness的日志——是不是某个skill抛了异常、是不是超时的阈值设太短、是不是工具返回了非预期的格式。经验法则先查harness再查agent最后才查模型。5.3 Agent开发学习路线入门到能干活经常有人问我Agent开发的学习路线我会给一条相对务实的路径先手动写一个不依赖框架的Agent循环用原生OpenAI SDK或任何模型API自己写一个100行左右的函数实现“模型请求 → 解析函数调用 → 执行工具 → 把结果拼回上下文 → 再次请求”的循环。目的是建立对Agent本质的肌肉记忆再看一个主流框架的源码选一个轻量的Agent框架看它怎么组织message历史、怎么管理工具注册、怎么处理多轮调用的上下文膨胀接着上手vLLM/SGLang自托管模型因为生产环境不可能每次都调用商业API必须学会本地部署模型并让Agent框架指向本地服务最后做性能优化和可观测性给Agent加日志、加trace、加超时熔断学会在真实运行数据里找到瓶颈——是模型慢、工具慢、还是上下文太长。关于吴恩达的Agent教程我建议新人可以看它把Agent的四个核心模式讲得很清楚反思Reflection、工具使用Tool Use、规划Planning、多智能体协作Multi-Agent Collaboration。内容不算深但作为体系化入门足够。6. 排查清单与个人沉淀经验6.1 高频问题速查表整理一些我在日常开发中最常遇到的问题和处理方案做成一张表方便对照症状常见原因解决办法pip install torch报找不到版本Python版本不兼容 或 源里没有对应平台轮子去官网按CUDA版本生成安装命令不要裸装torch装完后cuda.is_available()为False装了CPU版 或 CUDA驱动/运行时版本不匹配确认镜像或索引地址正确检查nvidia-smivLLM启动时OOMmax-model-len设太大 或 没有限制gpu-memory-utilization降低max-model-len、设gpu-memory-utilization0.85起步vLLM/Qwen量化模型加载失败镜像内置代码不支持特定量化格式换vLLM较新版本镜像或改用官方量化格式Agent循环频繁报工具调用失败模型输出格式与约定不一致改用SGLang的约束解码在harness层加格式修复兜底新版本vLLM吞吐反而下降默认配置变化或CUDA Graph不兼容比对配置、抓profiler必要时回退版本Docker容器内看不到GPU容器没加--gpus all或缺NVIDIA Container Toolkit加--gpus all并确认宿主机装了nvidia-container-toolkitSGLang首token延迟高RadixCache未命中检查请求是否带了可复用的公共前缀或系统提示词是否一致6.2 三个值得重复阅读的核心源码位置我再给一个很值的“精读”名单这三处吃透了你对推理引擎的理解会提升一个档次vLLM的scheduler.py里的_schedule()所有调度策略的核心读3遍都不夸张SGLang的RadixCache理解前缀缓存和树结构的精华所在PyTorch的torch.compile编译栈文档搞清楚inductor和dynamo各管什么你就知道为什么编译能加速。这三块内容我每隔一段时间重读一次每次都有新体会。源码不用全读但核心逻辑树必须建立起拓扑结构。6.3 关于技能沉淀和长期成长最后说点个人体会。AI infra这个方向知识迭代太快了今天文章里写的版本明天可能就有新版本替代。但底层能力是稳定的系统思维、显存管理意识、源码阅读能力、排查问题的二分法。与其追着每个新特性跑不如把核心机制的“为什么”吃透这样无论框架怎么变你看到的都是同一套底层规律在换皮。我自己的习惯是每研究一个新框架或新版本都会写一份“三句话笔记”——一句总结它解决什么问题一句说它和竞品的本质差异一句写一个踩坑经验。长期积累下来这份笔记比任何教程都值钱。希望这篇整理也能成为你的起步参考之一后续遇到具体问题欢迎回到这些基础原理上来找答案。