不想听我讲大道理的话这段可以直接跳过。做AI工程落地这些年我最大的感受是真正卡住人的地方从来不是某个模型效果差几个点而是从模型训练完到稳定跑起来这条链路坑多得能让人怀疑人生。今天想系统性整理一下AI infra和agent这块的技能树覆盖vllm、sglang、torch这几个绕不开的组件外加agent开发里的框架、记忆、安全、评估这些实操要点。这整套东西适合正在做大模型应用落地、推理服务部署、agent工程的读者也适合刚入行想建立完整技能地图的朋友。看完你至少能搞清楚推理引擎内部到底在忙什么、部署一个开源大模型要踩哪些坑、torch环境为什么总装不上、agent项目从框架选型到上线要过哪些关。1. AI infra技能栈总览先搞清楚自己在学什么1.1 推理引擎为什么成了兵家必争之地现在聊AI infra绕不开vllm和sglang这两个推理引擎。原因很简单模型参数量越来越大GPU价格一直坚挺推理侧的吞吐和延迟直接决定业务成本。同样的显卡同一个模型vllm和sglang能比裸用transformers的吞吐高出数倍到数十倍。这个差距来自continuous batching连续批处理、paged attention分页注意力、RadixAttention这类系统级优化而不是模型本身。很多人一开始不理解觉得推理由框架代劳就好。但实际做部署就会发现一套生产级推理服务要考虑的东西非常多KV Cache怎么管理、显存不够时怎么抢占、并发请求怎么调度、多卡怎么并行、量化版本怎么加载、OpenAI接口怎么兼容。这些全部是推理引擎的活。vllm和sglang能流行就是它们把这些极其复杂的问题收敛成了几个启动参数。1.2 技能树拆解从算子到底层再到上层应用我习惯把AI infra技能栈分成四层。最底层是算子与内核优化比如FlashAttention、量化算子、CUDA Kernel这一层Torch直接相关也是性能的天花板。第二层是引擎与运行时包括vllm、sglang、TensorRT-LLM这些它们负责把模型结构和底层算子组织成高效的推理服务。第三层是服务化与编排涉及Docker、Kubernetes、OpenAI协议兼容、负载均衡公司里真正跑生产的人大部分时间都在这一层。最上层才是Agent框架与应用比如LangGraph、AutoGen、MetaGPT负责把模型能力组装成能自主决策的智能体。1.3 torch、vllm、sglang三者的边界很多新手会把torch和vllm搞混。简单说torch是深度学习框架是模型训练和推理的基础计算库提供张量运算、自动求导、神经网络模块。vllm和sglang是建立在torch之上的推理引擎它们用torch做底层计算但在调度、显存管理、批处理策略上做了大量创新。transformers和datasets属于HuggingFace生态负责模型结构定义和数据加载训练和微调阶段高频使用推理引擎则会调用transformers的模型定义做权重加载。# 日常里三者关系大致是这样 import torch # 基础计算库 from datasets import Dataset # 数据侧 from transformers import AutoModel # 模型定义 # vllm/sglang 内部会自动把上面的模型结构转成自己的推理图搞清楚边界之后再去看那些“vllm部署DeepSeek”“sglang和vllm对比”“安装torch报错”之类的问题就有清晰的地图了。下面逐个拆解。2. vllm核心机制拆解Engine、Scheduler、Executor的三角关系2.1 从一次推理请求看vllm内部流程vllm最常被问到的就是“EngineCore与Scheduler、Executor交互流程”。这个名字里的EngineCore是vllm分布式架构下的核心进程组件在vllm3.x里尤其重要。一条请求进来大致要经过API Server收到HTTP请求转成Engine的输入Engine把请求拆解成Sequence序列Scheduler决定哪些Sequence进入本轮的running列表Executor负责真正调用模型做前向计算算完的结果回传给Scheduler再由Engine汇总输出。理解这条链路的关键是vllm不是同步地一条请求一条请求处理而是维护一个巨大的状态机。Scheduling是整个系统的心脏每执行完一次forward都会重新调度一次这一步如果设计不好GPU就一直在空转等待。2.2 Scheduler的核心逻辑连续批处理与抢占vllm吞吐高的秘诀是连续批处理。传统批处理是等batch满了才跑连续批处理则是只要有空闲显存就立刻把新请求塞进当前正在执行的batch。请求有长有短短的先结束结束后立刻补充新请求进来GPU永远不会闲着。但显存是有限的当running序列太多塞不下时Scheduler必须做抢占。vllm的抢占分为两种swapped把被抢占序列的KV Cache换到CPU内存和recomputed丢弃KV Cache之后重新计算。默认策略优先swap因为recompute太浪费算力。这里有个工程细节swap走的是CPU内存和PCIe带宽速度远低于显存如果频繁抢占整体延迟反而会恶化。所以生产环境里应该通过max-num-seqs和gpu-memory-utilization参数控制并发度宁可让batch小一点也不要让Scheduler频繁做swap。2.3 Executor的并行策略PP、TP、EP怎么选Executor是真正把模型跑起来的角色。单卡放不下模型或需要提升吞吐时就得做分布式并行。vllm里最常见的是Tensor ParallelTP把注意力头或矩阵分到多张卡每张卡算一部分再合并。PPPipeline Parallel把模型按层切分每张卡负责连续的若干层适合超大模型。EPExpert Parallel是MoE模型专用的比如DeepSeek-V3这类混合专家模型把不同的专家分散到不同GPU上。选择依据很简单TP通信量大但负载均衡好实现单机多卡带宽高时优先PP通信量小但存在流水线气泡适合跨节点MoE模型优先考虑EP避免单卡专家负载不均。实际部署DeepSeek这类大模型时vllm官方经常建议4卡起步用TP4或TP8配合vLLM的自动调度才能把吞吐拉起来。2.4 Engine与Scheduler、Executor的协作细节完整的交互大致可以画成这样Engine接收请求转换token ids初始化Sequence状态把新Sequence加入Scheduler的waiting队列Scheduler每次step会从waiting中挑选能放下的序列结合running序列一起生成调度批次Executor拿到调度批次后执行模型前向、采样、KV Cache读写结果返给Scheduler序列状态变更结束的序列送回Engine输出这个循环以毫秒级频率不断重复。性能排查时如果GPU利用率上不去优先检查Scheduler生成batch的频率和batch大小而不是去优化算子。很多时候吞吐低不是因为模型慢而是因为batch太小GPU没喂饱。3. vllm部署实战DeepSeek部署、Docker镜像与参数调优3.1 镜像选择不要下错layer部署vllm最省心的方式是直接用官方Docker镜像。vllm/vllm-openai是带OpenAI兼容API的版本日常业务对接最方便还有vllm/vllm-app等变体。网上搜到“docker vllm/vllm-openai:v0.27.1加载qwen3-embedding-0.6b”这类需求对应的就是指定老版本镜像跑embedding模型。一个关键认知vllm Docker镜像默认不包含模型权重。镜像里只有推理引擎的代码和依赖模型要单独通过volume挂载或者用HF Hub下载。很多人以为pull了镜像就能直接跑结果启动时报模型找不到其实就是没挂载模型目录。# 常见做法把本地模型目录挂进容器 docker run --gpus all \ -v /data/models:/models \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:latest \ --model /models/deepseek-chat \ --served-model-name deepseek-chat \ --gpu-memory-utilization 0.85 \ --max-model-len 81923.2 vllm部署DeepSeek的完整流程DeepSeek系列模型家族很大有Dense版也有MoE版有fp8量化版也有GGUF量化版。部署前先确认模型格式vllm原生支持fp8和bf16权重如果下载的是GGUF量化文件需要确认vllm版本是否已支持对应格式或者先用工具转换再部署。完整流程我一般这样走确认环境驱动版本、CUDA版本vllm要求CUDA 12.1选择镜像推荐vllm/vllm-openai:latest注意版本稳定性不要追最新小版本下载模型hf-hub或ModelScope国内直接用ModelScope更稳启动服务指定模型路径、张量并行度、显存利用率、最大序列长度验证接口curl /v1/chat/completions先跑通再压测接入业务配置限流、超时、模型路由参数上最重要的三个gpu-memory-utilization控制KV Cache可用显存比例默认0.9但在多任务共卡时建议降到0.7-0.8max-model-len决定能处理的最长上下文同时直接决定KV Cache大小tensor-parallel-size决定用几张卡跑TP要求显存能容纳模型权重。3.3 新版本性能下降怎么排查热搜里“vllm新版本性能下降”是很真实的问题。vllm迭代极快版本升级偶尔会引入性能回退或行为变化。我遇到过vllm 0.6.x到0.7.x某个版本吞吐掉了三成的情况最后发现是新的scheduler策略在长序列场景触发了更频繁的抢占。排查方法论是先用同一模型同一压测脚本跑两个版本对比然后看GPU利用率、吞吐、平均TTFT和TPOT指标再看日志里的schedule次数、preempt次数最终缩小到是不是调度策略变化、KV Cache管理器变化还是算子回退。如果只是部署需求不追新特性就锁定一个经过验证的稳定版本不要频繁升。# 压测用简单脚本看核心指标 python vllm/benchmarks/benchmark_serving.py \ --backend vllm \ --model deepseek-chat \ --tokenizer deepseek-chat \ --host 127.0.0.1 --port 8000 \ --num-prompts 200 --request-rate 103.4 小模型和Embedding模型的部署细节很多人忽略Embedding模型的部署。qwen3-embedding-0.6b这类小模型用vllm跑主要问题是吞吐上限低并发高时延迟飙升。vllm对Embedding请求会走同样的调度管线但因为没有生成式采样逻辑上更轻。部署时要注意vllm对Embedding模型的served-model-name要和接入方约定好API路径是/v1/embeddings。另外有网友问“vllm部署大模型chatbox怎么接”Chatbox这类桌面客户端通常只支持OpenAI格式接口vllm的/v1/chat/completions天然兼容把客户端里的base_url改成http://ip:8000/v1模型名改成服务里配置的served-model-name就能连上。这是vllm生态一个很大的优势协议兼容让工具链直接复用。4. sglang和vllm对比选型逻辑与源码阅读路线4.1 同一目标下的不同取舍sglang和vllm被放在一起比已经两年了。两者都是高性能推理引擎核心区别在调度和缓存策略。vllm的强项是生态成熟、参数丰富、对各类模型支持最全、文档和社区资料最多。sglang的强项是RadixAttention前缀缓存在处理共享前缀的长对话、多轮agent场景里优势非常明显官方benchmark的领先也主要来自这个机制。生产选型我给个经验如果只是标准对话和常规LLM服务闭眼选vllm生态少踩坑如果主要场景是超长上下文、多轮工具调用、大量相同系统前缀的请求sglang的缓存收益值得尝试。注意sglang对部分模型的算子兼容没有vllm那么全上生产前一定要跑基准benchmark别只看网上数据。4.2 sglang的RadixAttention与请求调度sglang源码解析最值得看的三个模块RadixAttention缓存、Scheduler、TokenizerManager。RadixAttention把KV Cache组织成一棵基数树相同前缀的请求共享缓存新的请求无需重复计算系统提示词或历史对话。这对agent场景的信息量极大因为agent每一轮都会把整个对话历史重新喂给模型前缀缓存直接砍掉重复计算。sglang的Scheduler设计思路和vllm类似但实现不同它更强调缓存命中的调度偏向既要满足连续批处理又要尽量聚合相同前缀的请求。工程上一个有趣的现象是sglang在cache hit高的场景TTFT特别低但cache miss时不一定比vllm快。选型评估时一定要用自己的真实流量分布测。4.3 源码阅读路线图读这两个引擎的源码我建议按“入口→调度→执行”这条线走。vllm先从llm.py的LLMEngine开始然后跟scheduler.py的schedule()方法再进worker/model_runner.py的execute_model()。核心不变量是KV Cache由block管理请求以block为单位分配显存。# vllm的调度核心长这样伪代码 def schedule(self): # 1. 从waiting队列取请求能塞进剩余KV Cache就加入running # 2. 如果显存不够对running里的序列做preempt # 3. copy-on-write处理beam search等场景 # 4. 返回新的scheduling batchsglang源码则重点看scheduler.py中的RadixCache相关数据结构和tokenizer_manager.py的消息流转。读源码不要从最底层算子开始会被细节淹没。先从顶层控制流建立心智模型再在遇到性能热点时下钻效率最高。5. torch环境配置避坑指南AI infra的地基5.1 安装torch最常见的报错和处理“error: could not find a version that satisfies the requirement torch”是我见过次数最多的报错没有之一。这个报错绝大多数时候不是torch不存在而是pip在当前的Python版本和源里找不到匹配的wheel。原因有三类Python版本过新或过旧超出torch官方wheel覆盖范围pip源是内网镜像但同步不及时在macOS/ARM或Jetson这类非标准平台装x86版wheel。解决办法按顺序排查先看Python版本torch稳定支持一般滞后于最新Python一个大版本再指定PyTorch官方源安装最后看是否平台架构不匹配。# 常规安装指定CUDA版本的torch pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 # 老版本专属1.8.2的经典配置 pip install torch1.8.2 torchvision0.9.2 torchaudio0.8.2 --extra-index-url https://download.pytorch.org/whl/cpu5.2 CUDA版本、驱动版本、torch版本三角匹配Jetson设备配置torch是另一个典型场景。Jetson用的是aarch64架构官方PyPI上的x86 wheel装不了只能用NVIDIA为JetPack定制发布的torch wheel或者从源码编译。搜索引擎里“jetson 配置torch”相关搜索多说明这个问题确实普遍。实测过一个笨办法也有效在Jetson上用容器跑NGC的PyTorch镜像镜像里torch和JetPack的CUDA环境是打包好的避免了自己配CUDA的灾难。需要强调的是torch看的不是驱动版本而是CUDA runtime版本。驱动大版本够新时不同CUDA runtime可以共存这也是装错版本时不用重装系统、重建conda环境即可的原因。5.3 torch在机器人和仿真中的延伸热词里出现“mujoco torch机械狗”说明torch的应用远不止大模型。MuJoCo是物理仿真器机械狗这类强化学习任务通过torch做策略网络计算再用MuJoCo做环境模拟。这类任务对torch的要求是CPU推理延迟低、支持批量环境并行还要能跟C仿真器高效交换数据。我给做机器人的读者一个建议不要在这类场景用最新的torch稳定版优先。强化学习训练收敛一次成本很高torch版本升级带来的非确定性变化有时候会让人误判算法效果。锁定版本甚至锁定cuDNN版本是这类task里减少变量的关键操作。6. agent开发体系框架、记忆、安全、评估一条龙6.1 agent框架与编排harness、skill、agent到底什么关系agent方向的热度丝毫不比推理引擎低。“agent框架”“agent开发学习路线”“agent架构”这些关键词背后是大量想进入agent开发的开发者。但很多人一开始就被“agent、skill、harness、workflow”这些概念绕晕。我的理解是这样agent是能自主感知、决策、行动的系统核心闭环是“观察→规划→行动→反思”。skill是agent能调用的具体能力单元比如查天气、发邮件、计算器是对工具和流程的封装。harness是承载agent运行的控制循环和运行时环境负责管理工具调用、上下文传递、执行约束、错误恢复。workflow则是预定义好的步骤编排agent在其中自由发挥的空间较小。说白了workflow是“铁轨上的火车”agent是“有方向盘的车”skill是“这辆车能跑的技能”harness是“驾驶舱和仪表盘”。生产系统经常两者结合关键路径用workflow保证稳定分支决策交给agent自主判断。6.2 记忆机制为什么agent的记忆这么难做“agent记忆”“agent记忆安全”在热搜里反复出现说明记忆确实是agent落地的硬骨头。Agent记忆大致分三层短期记忆当前对话上下文、长期记忆跨会话的任务知识和用户偏好、工作记忆当前任务中间状态。vllm/sglang这类引擎的前缀缓存正好能加速带长记忆的agent——历史对话作为公共前缀多轮交互时缓存命中率极高这也是sglang在agent场景有优势的底层原因。但记忆还有个安全维度。搜索结果里“A-MemGuard: a proactive defense framework for LLM-based agent memory”是学术界的最新方向。大意是攻击者可以通过诱导agent把恶意内容写进长期记忆之后每次调用记忆都会被污染相当于“记忆投毒”。防御思路包括记忆内容过滤、写前校验、记忆隔离和权限控制。做agent生产的团队如果涉及长期记忆建议认真关注这个方向。6.3 常见报错与运行稳定性“agent execution terminated due to error”这类报错几乎每个做过agent的都见过。它本质是agent在循环执行过程中某一步工具调用或模型响应出现异常控制系统强制终止。典型原因包括模型返回非法JSON导致工具参数解析失败工具返回超时被harness判定为失败上下文超过模型窗口API触发了限流和配额错误。解决方案是系统性的第一所有模型输出都要做容错解析不能指望大模型次次都输出合法JSON要写一个tolerant parser。第二工具调用必须有timeout和重试机制。第三agent循环要设最大步数上限避免死循环烧钱。第四要记录每一步的执行轨迹terminated之后能从状态快照恢复。这些细节才是agent工程和demo的分水岭。# 一个简易的思考-行动-观察循环骨架 import json def run_agent_step(model, messages, tools): try: resp model.chat(messagesmessages, toolstools) tool_calls json.loads(resp.tool_calls) # 别裸json.loads except json.JSONDecodeError: # 实际工程里要做容错重试比如提示模型修正输出 return retry return tool_calls6.4 agent学习路线与框架选型吴恩达讲agent时归纳了四种设计模式Reflection自我反思、Tool Use工具调用、Planning任务规划、Multi-Agent Collaboration多智能体协作。这四点基本就是agent能力的骨架。学习路线上我建议先掌握Tool Use把“用模型调用外部工具”这个闭环跑通然后做Reflection让模型学会审自己的输出再上Planning拆解复杂任务最后才有必要研究多Agent协作。框架选型上主流的LangGraph适合生产级可控流程编排AutoGen适合多Agent对话研究MetaGPT擅长软件公司式角色分工pi agent这类新框架在特定任务上也有独特优势。我的建议是不要一开始就锁定某个框架先用最朴素的循环写一个能调工具的agent把每个环节的问题都经历一遍再用框架解决规模化痛点。框架不是银弹理解了底层的循环控制用什么框架都是手到擒来。7. 常见问题速查表与排查方法论7.1 部署与版本匹配类问题现象常见原因排查顺序pip装torch提示找不到版本Python版本/源/平台不匹配查Python版本→换官方源→看平台架构vllm启动报CUDA error驱动过旧或镜像CUDA版本不对更新驱动→换新镜像→确认torch的CUDA版本Docker容器内看不到GPU没加--gpus all或者nvidia-container-toolkit未装检查运行时参数→检查nvidia-container-toolkitsglang跑不起来某个新模型算子兼容性落后于vllm换vllm→插自定义算子→等官方适配GLM系列用vllm镜像选择困难不同版本对模型支持差异大读官方文档对应模型版本要求7.2 性能与显存类性能排查我一般按这个顺序走先看GPU利用率如果低于80%大概率是batch太小或调度频率不够再看显存占用如果KV Cache耗尽触发preempt就调低并发或调高gpu-memory-utilization再看TTFT和TPOT如果TTFT高优先怀疑前缀缓存未命中或调度排队最后看CPU和GPU之间有没有数据瓶颈比如swap太频繁。“minimax-h3 vllm部署在L20”这类问题的关键参数是L20有48GB显存单卡能跑大概13B-32B的量化模型MoE大模型通常要TP并行才能跑得舒服。上线前建议用benchmark脚本压测记录80%、90%分位的延迟而不是只看平均。在线业务的P95稳定性往往比平均吞吐更重要。7.3 业务接入类有个高频问题是“vllm部署大模型怎么接现有服务”。记住一点vllm的OpenAI兼容接口让接入成本极低Chatbox、OpenAI SDK、LangChain、各类客户端都可以直接用。接入时注意served-model-name要和调用方设的model参数一致否则会报model not found。Embedding模型的接入路径是/v1/embeddings别按chat接口传参。多模态模型部署时vllm会把图像转成token参与KV Cache管理部署时显存消耗会比纯文本大很多max-model-len要适当缩小。比如部署一个支持视觉的模型如果输入图像常带1024分辨率单图可能对应上千tokenmax-model-len设得太小会导致图片处理失败设得太大又占显存。这里需要实测统计数据后权衡。最后再分享一个习惯做这一行几年我一直坚持一个习惯所有框架、版本、参数、踩坑记录都写成笔记哪怕短短一句话也行。原因很简单AI infra的细节太多版本迭代又太快大脑根本记不住所有组合。很多问题当时解决了过了三个月再碰到还是得重新搜。把“vllm哪个版本加载qwen3-embedding正常”“sglang源码哪一行是RadixCache的insert逻辑”“torch 1.8.2在Jetson上装哪个wheel”这些信息沉淀下来就是你最值钱的个人知识库。我个人在实际操作中的体会是不要迷恋“最新版本”在一个项目中锁定经过验证的版本组合把性能、特性、稳定性量化记录下来效果远比追逐新版本好。这个行业的复杂度已经高到没人能只靠记忆搞定但正因为这样系统化的技能整理本身就是一种稀缺能力。希望这份整理对你有用也欢迎你有自己的实战经验后回过头来交流补充。
