1. AI Infra与Agent技能栈全景拆解先聊一个现象。这两年面试也好、做项目也罢你会发现真正拉开差距的不是谁会用大模型API而是谁能把模型跑起来、跑得稳、跑得快并且让Agent真的在业务场景里落地。围绕这个标题——AI infra / agentvllm / sglang / torch 等skills 整理——我把自己从做推理引擎调优到搭Agent系统的实战经验做了个系统梳理这篇内容适合三类人看准备转AI工程方向的开发者、已经在用vllm/sglang部署模型但没深究过原理的算法工程师、以及想搞清Agent和skill/RAG/记忆这些概念到底怎么落地的架构师。先说结论AI infra的技能树大致分四层——环境层PyTorch/CUDA/容器、推理引擎层vllm、sglang及两者背后的调度与执行机制、服务化层vLLM OpenAI兼容接口、TensorRT-LLM对比、性能调优、应用编排层Agent框架、工具调用、记忆与规划。绝大多数人卡在第二层和第四层也就是只会跑起来但不懂为什么这样跑出问题不会排。在我看来这个技能栈最核心的两个攻坚点一是吃透vllm和sglang的调度逻辑与显存管理这是所有推理性能问题的根源二是搞清楚Agent框架里工程实现和模型能力的边界——哪些问题该用harness/框架解决哪些该换模型或改Prompt这直接决定项目能否稳定运行。下面我把每一层的技术要点、实操命令、踩坑记录全部摊开讲。2. 推理引擎选型vllm与sglang的路线分歧2.1 选型背后的核心差异vllm和sglang是目前开源社区部署大模型的两大主力。这两个项目都解决了生成慢、显存不够、并发上不去的问题但走的技术路线有明显分歧。vllm的核心创新是PagedAttention分页注意力机制。它的思路类似操作系统里的虚拟内存分页——把KV Cache拆成固定大小的块不再要求物理连续按需分配、按需释放。这解决了传统预分配显存导致的碎片化浪费问题显存利用率大幅提升。配合上Continuous Batching连续动态批处理模型可以做到来一个请求就塞进当前batch生成完了立刻移出而不是等整个batch全部结束再处理下一批。这两个机制结合在一起就保证了高并发场景下的吞吐量。sglang则换了一条路它核心打的是RadixAttention基数树注意力和结构化生成。RadixAttention的思路是复用跨请求的KV Cache如果两个请求的Prompt前缀一样那前面这部分算出来的KV Cache直接复用。比如多轮对话场景历史消息就是公共前缀Batch里不同请求共享这些算好的缓存前几轮算过的内容就不必重新过一遍模型。sglang的官方数据里在共享前缀密集的场景如多轮对话、自回归式Agent工具调用下它的吞吐量可以做到比vllm快数倍。2.2 实际选型建议与适配场景基于我的使用经验选型不要盲目跟风而是看你的实际流量特征场景特征首选引擎理由单轮问答、文档解析、批量离线推理vllm社区生态最成熟OpenAI兼容API最稳部署资料多多轮对话、Agent多步工具调用、前缀高度重叠sglangRadixAttention复用KV Cache收益显著超长上下文 复杂结构化输出JSON模式等sglang对结构化生成有编译层优化约束解码效率更高国产卡/非NVIDIA生态先查两家的兼容列表vllm对异构卡支持更多但sglang社区也在快速跟上需要深度定制调度策略优先vllm代码结构清晰scheduler/executor解耦二次开发门槛相对低如果你做的是Agent类应用我强烈建议你至少把sglang作为一个候选。我做过一组对比测试同一个Qwen模型同样的并发压测脚本纯单轮对话两者吞吐量差距不大但一旦跑那种模型需要连续调用5次工具、中间穿插多轮推理的Agent工作流sglang的延迟明显更低原因就是每次工具返回后重新传入的历史消息里大量前缀Cache直接命中根本不用重新计算。3. vllm部署与核心调度机制拆解3.1 vllm部署实操从Docker到裸机命令vllm的部署方式主要有三种pip安装、Docker镜像、源码编译。对绝大多数生产环境我的建议是优先Docker因为vllm的依赖主要是CUDA、PyTorch、FlashAttention的版本组合比较敏感pip装很容易因为环境冲突搞出莫名其妙的错误。先看最简单的pip部署流程# 创建虚拟环境避免污染系统Python python3 -m venv vllm_env source vllm_env/bin/activate # 安装vllm会自动带torch但注意版本匹配 pip install vllm # 启动OpenAI兼容服务 python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen3-8B \ --served-model-name Qwen3-8B \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9关键参数逐个解释--tensor-parallel-size是张量并行度显存不够多卡推理时设为卡数--max-model-len直接决定KV Cache的上限设得越大单请求上下文越长但能同时处理的请求数会下降--gpu-memory-utilization是显存利用上限一般0.9比较稳毕竟要留一部分给CUDA context和计算图。但生产环境我建议用Docker部署因为有一个最容易忽略的点vllm对PyTorch和FlashAttention的版本要求很严格pip安装时如果网络源不太干净或者环境里已有其他版本的torch经常出现torch版本冲突导致vllm加载模型时直接Segmentation Fault的惨案。Docker镜像已经把所有依赖锁死出问题的概率小很多。# vllm官方镜像自带模型吗不带模型需要挂载进容器 docker run --runtime nvidia --gpus all \ -v /models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen3-8B \ --served-model-name Qwen3-8B \ --max-model-len 8192一个有价值的建议用镜像之前先确认版本。比如很多朋友问GLM5.3该用哪个vllm镜像版本我的经验是去GitHub Releases页面看Release Note找那个版本发布前后对应的镜像tag。GLM这类模型如果vllm代码里有单独适配通常在某次commit之后才有支持直接用latest有时会踩到新版本性能下降的坑。另外部署完成后测试接口用的是标准的OpenAI SDKfrom openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) response client.chat.completions.create( modelQwen3-8B, messages[{role: user, content: 你好}], temperature0.7 ) print(response.choices[0].message.content)3.2 EngineCore、Scheduler与Executor的交互流程vllm能高效工作的心脏不在API层而在它的执行引擎。很多人只知道vllm serve xxx一键启动却不知道这个命令背后发生了什么。vllm新版本中核心组件被整理成了EngineCore异步引擎核心、Scheduler调度器、**Executor执行器**三大部分。它们的交互流程大致是第一步客户端请求进入LLM Engine的入口队列EngineCore的前端把请求转换成内部的SequenceGroup序列组这个结构包含一条Prompt以及后续要生成的若干条序列比如n2时就同时生成两条候选。第二步Scheduler是大脑负责任务的准入控制。它的核心逻辑是——当前可用的KV Cache块够不够用如果请求的Prompt太长放不下就拒绝如果Batch里还有位置就把它加进去。这块的调度策略包括等待机制等有资源再塞进去、抢占机制长请求生成到一半发现缓存不足先把它换出腾地方给短请求以及Prefix Cache命中检查如果新请求的Prompt前缀已经在缓存里直接复用。第三步Scheduler决定把哪些序列组送到Executor执行这一步会组装成一个Step。Executor负责实际往GPU上发算子调用attention kernels比如FlashAttention、采样kernel。执行完一个Step后把新生成的token回传给Scheduler同时更新KV Cache的引用计数。整个流程里最值得深挖的是调度器和执行器之间的节奏问题。vllm是典型的单调度器 多执行器模型Python层负责调度逻辑真正的计算被下放给异步的CUDA stream。用异步的好处是调度开销和计算粒度分离——GPU在跑当前Step的同时CPU已经为下一个Step准备好了token数据。实际操作中我在压测时遇到过一个很典型的性能问题单机吞吐量不错但一上多路并发首token延迟明显抖动。排查到最后发现是--max-num-seqs最大并发序列数设置太大导致调度器在极端情况下做过多不必要的换入换出。后来调小了并发上限同时配合--max-num-batched-tokens限制单次batch的token数延迟就稳了。3.3 vllm常见部署参数速查很多人部署时就是照着网上的命令一抄参数含义完全不管。这里给一个我觉得实战中最值得关注的参数清单参数作用我的推荐--gpu-memory-utilization控制Warmup后KV Cache可用的显存比例0.85-0.92太低白费显存太高容易OOM--max-model-len模型可处理的最大序列长度依据业务数据分布定不要盲目追求长上下文--max-num-seqs单批最大序列数默认256可能偏高压测后下行调整--tensor-parallel-size多卡张量并行单卡能跑尽量单卡多卡有通信开销--enable-prefix-caching是否开启前缀缓存Agent场景强烈建议开--quantization量化参数awq/gptq/fp8显存紧张时优先AWQ速度损失可控有一个坑vllm新版本有时候性能反而下降。这不是错觉。vllm迭代速度极快有些commit为了支持新模型或新特性会改动调度逻辑如果刚好碰到你用的硬件组合特别是老卡或者非数据中心卡性能可能不如旧版。网上vllm 0.29 WSL2这类帖子也是这个原因——特定版本在特定环境下才有最佳表现。如果生产环境跑得好好的请锁定版本别跟风升级。4. sglang架构亮点与真实使用体验4.1 从源码角度看sglang做了什么sglang的设计理念和vllm有个根本差别vllm更像一个通用的高性能推理服务sglang则更像一个为大模型程序的执行而生的编译器加运行时。sglang的源码核心有几个模块值得细看前端编译器sglang把用户写的Prompt模板、工具调用逻辑、分支控制这些编译成一张执行图。它不太像传统推理引擎那样每次请求独立走一遍模型而是尝试把整个Agent循环/多步流程当作一个程序来执行中间可以插入自定义的Python逻辑。RadixAttention的Cache树vllm的Prefix Cache本质上是线性前缀匹配命中就复用不命中就从头算。sglang的Radix树更灵活——它能复用任意子串级别的公共前缀甚至能把多轮对话中那些中间某轮被修正过的消息之后的部分高效剪枝。从工程角度说这意味着sglang在多轮Agent场景里的Cache复用率远高于vllm。结构化生成sglang提供一个很杀手锏的能力——在解码时做约束解码Constrained Decoding也就是说可以强制输出符合JSON Schema的token序列。我在实际项目里用它做工具的function calling参数抽取效果比让模型自由生成后再用JSON解析靠谱得多——因为模型生成的非法JSON导致的解析失败基本归零。4.2 用sglang部署服务的完整示例sglang的API server用法python -m sglang.launch_server \ --model-path /models/Qwen3-8B \ --host 0.0.0.0 \ --port 30000 \ --mem-fraction-static 0.8 \ --max-total-token-num 40960启动后同样是对OpenAI兼容协议用SDK直接请求即可。我有一个心得如果是在Agent项目里用sglang可以考虑用它的gen机制也就是把结构化生成能力暴露给上层直接在调用时声明输出类型from sglang import function, gen, system, user function def tool_call(s): s system(你是一个工具调用助手严格输出JSON。) s user(查询北京的天气输出JSON{city, date}) s gen(json, max_tokens256)这个gen会走约束解码路径出来的结果天然是合法JSON。上层代码拿到后可以直接json.loads不用再写容错逻辑。对做Agent的工程师来说这一条就能帮你省掉一大部分解析异常处理的代码。4.3 sglang的适用边界与注意事项sglang不是万能药。我注意到的几个实际限制生态成熟度略逊vllm支持的后端硬件、量化格式、模型架构更多一些冷门模型出问题sglang的issue可能还没人回。调度器线程和显存配比sglang把一部分显存预留给静态缓存--mem-fraction-static设太大会导致动态请求的KV Cache不足设太小则起不到缓存复用的效果我一般从0.8起步根据压测数据微调。对Batch内长短请求混合的容忍度如果线上请求长度差异极大比如既有几十token的短问答又有上万token的长文档分析vllm的动态批量处理往往更扛得住sglang的RadixTree在极端混合负载下反而不一定最优。5. PyTorch安装与环境配置踩坑实录5.1 安装torch的核心原则与命令围绕这份技能清单PyTorch这块看似简单实际是无数人浪费半天时间的重灾区。很多人一上来就pip install torch如果网络源不是标准PyPI装出来的版本可能和CUDA完全不匹配——装倒是装上了一跑模型就报CUDA error: no kernel image is available for execution on the device。安装PyTorch的第一原则是从官网的Get Started页面复制命令或者用官方指定的CUDA版本对应安装源。例如# CUDA 12.1版本的torch安装官网推荐的命令之一 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121装完之后必须验证CUDA是否真的可用import torch print(torch.__version__) print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))这里有个容易被忽略的细节torch.cuda.is_available()返回True并不代表你的GPU型号在torch支持的算力列表里。比如一些老显卡开普勒架构的K80、麦克斯韦架构的部分型号在新版本torch里已经不再编译对应的SASS kernel这时需要装特定老版本。网上搜pip3 install torch1.8.2 torchvision0.9.2 torchaudio0.8.2 --extra-index-url这类命令就是因为老卡必须用旧版。5.2 经典报错could not find a version that satisfies the requirement torch这条报错几乎每天都有新手遇到。原因有二一是Python版本过高老版本torch没有对应wheel包二是网络环境问题默认PyPI源里没有你需要的torch版本。解决办法按优先级排列用python -V确认Python版本Python 3.12以上对torch版本门槛较高建议降级Python或换用较新的torch。换源安装比如阿里云镜像或者用官方PyTorch源。如果是指定了--extra-index-url却依然找不到包大概率是源没配对。注意torch1.8.2这样的老版本在官方PyPI源是有的但如果你在内网环境下可以先把wheel下载下来再本地安装。5.3 WSL2、Jetson等特殊环境的配置心得WSL2里跑vllm和torch的人越来越多。我的经验是WSL2里用CUDA需要装Windows侧的NVIDIA驱动不需要装CUDA Toolkit然后在WSL2里正常pip install torch就行。确认一下nvidia-smi能输出信息即代表GPU透传成功。Jetson系列比如Orin Nano是完全不同的路子它的CUDA是JetPack自带的不能直接用pip装的torch因为Jetson的GPU架构Ampere的GA10B需要特殊编译。正确姿势是用官方预编译的torch wheelNVIDIA论坛有提供或者从源码编译同时确保torch和JetPack的CUDA版本匹配。在Jetson上装torch时常见错误是libcudnn和libcublas版本对不上建议装完后先跑一小段矩阵运算做验证再进大模型推理。6. Agent开发技能栈与工程实践梳理6.1 Agent与Skill、Harness的边界问题热搜词里反复出现skill和agent的区别harness和agent区别这类问题。这三者的边界确实值得认真梳理。Agent指的是一个能自主完成任务的智能体——它感知环境读用户输入、读工具返回、做推理决策决定下一步调什么工具、怎么调、执行动作发起API调用、操作数据、评估结果判断是否完成目标。**Skill技能**是Agent可以调用的原子能力单元。比如一个查询天气的Skill内部实现了解析城市名 调用天气API 格式化输出的逻辑。Skill本质上是对工具Tool和指令Prompt的封装把做什么、怎么做、输出什么格式写死成一个可以直接被Agent框架加载的模块。**Harness框架/驾驶舱**则更偏工程层它定义了Agent运行时的整体骨架——怎么读配置、怎么初始化记忆、怎么加载Skills、怎么和模型后端通信、怎么处理多轮循环终止条件。用生活类比来说Harness是汽车的底盘和电控系统Agent是驾驶员Skill是驾驶员的工具箱油门刹车方向盘。底盘决定了车能不能上路驾驶员决定怎么开工具箱决定能做什么操作。6.2 主流的Agent框架选型参考我接触过的Agent项目里框架选型常见的几种框架适合场景特点LangChain快速原型、文档处理、简单Agent生态全但抽象层多改底层逻辑费劲LlamaIndex知识库问答、RAG增强Agent对检索链路优化最好Pydantic AI结构化输出的Agent服务强类型验证与JSON Schema结合得很干净AutoGPT / BabyAGI研究性自主任务实验性质强生产使用不稳定自研框架生产级复杂Agent流程可控性最强但开发量大如果你是做生产级Agent我的建议是不要迷信某个框架天花板先自己写过一遍ReAct循环推理 - 行动 - 观察再回头用框架你会突然明白框架帮你解决了什么、没解决什么。6.3 实操写一个最小可运行的Agent循环很多Agent开发新手一上来就上LangGraph这种重型框架整了一堆节点和状态机结果出了bug自己都看不懂。我的建议是先裸写一个循环感受一下核心机制。下面是一个最小ReAct Agent骨架假设后端是vllm/sglang暴露的OpenAI兼容接口核心就是让模型反复输出行动 行动输入你解析后执行工具把结果喂回去from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) TOOLS { calculator: lambda expr: str(eval(expr)) # 演示用生产环境勿用eval } def run_agent(user_input, max_steps5): messages [ {role: system, content: 你是ReAct Agent。每次输出必须包含Thought、Action字段。当任务完成时输出Final Answer。}, {role: user, content: user_input} ] for step in range(max_steps): resp client.chat.completions.create( modelQwen3-8B, messagesmessages, temperature0.3 ) assistant_msg resp.choices[0].message.content print(f[模型输出] {assistant_msg}) if Final Answer: in assistant_msg: return assistant_msg.split(Final Answer:)[-1].strip() if Action: in assistant_msg: action_line assistant_msg.split(Action:)[-1].split(\n)[0].strip() try: result TOOLS[action_line]() messages.append({role: assistant, content: assistant_msg}) messages.append({role: tool, content: f工具返回{result}}) except Exception as e: messages.append({role: assistant, content: assistant_msg}) messages.append({role: tool, content: f工具报错{e}}) else: break return 达到最大步数未完成 if __name__ __main__: print(run_agent(请帮我计算 123*4567 的结果))这段代码的关键在于每次模型返回后把模型的原话追加到messages里然后把工具返回结果也追加进去。这保证模型能看到它上次说了什么、工具返回了什么从而决定下一步。实际工程里你会遇到输出格式不稳定的问题——模型偶尔生成的Action不是一个合法工具名这时就要在解析层做容错重试、正则匹配、模糊匹配这也是为什么框架要封装解析器的原因。6.4 Agent记忆机制与pi-agent等方向的延伸Agent做复杂任务时记忆是不可或缺的模块。记忆大致分三类短期对话记忆把最近的几轮消息塞进上下文、长期事实记忆向量库存储用户偏好、历史结论按需检索、工作记忆当前任务中的临时状态如待办清单。实现短期记忆最简单的方式就是滑动窗口截断——messages里只保留最近N轮。长期记忆通常会搭配embedding和向量数据库或直接在PG里存向量检索时用相似度阈值过滤无关内容。pi agent这类关键词反映的是市面上不断涌现的Agent项目。我的观察是当前Agent开发有两个明显的技术走向——一是让我Agent具备更强的自我校正能力执行结果不对就反思重试而不是直接失败二是让Agent能编排长链路工具几十个工具之间的依赖关系、失败回退策略。这两个方向都需要infra层的配合更快的推理引擎sglang的缓存复用优势、更稳的结构化输出vllm的guided_json、sglang的约束解码、更可控的工具协议OpenAPI规范描述工具入参出参。7. 高频问题排查与性能调优速查7.1 推理链路踩坑清单结合我自己的线上运维经历和社区反馈整理几个高频出现的问题问题一Agent执行中途报execution terminated due to error这类报错十有八九是工具调用抛异常比如API超时、JSON解析失败、工具不存在的Key。排查思路分三路并行一是看日志里Agent走到哪一步挂的二是看模型的输出是不是满足预定义格式三是给工具调用包一层try-except把异常转换为工具返回了一个错误xxx让模型自行决定补救方案而不是直接杀死整个Agent。问题二部署DeepSeek系列模型显存不够DeepSeek系列特别是V3/R1量级动辄几百B参数单卡根本塞不下。实操建议分三步先用小规模量化AWQ/GPTQ Int4把单卡压到能装再考虑多卡张量并行最后实在不行就上FP8或动态稀疏。vllm对DeepSeek的支持在社区里是比较快的但一定要注意FlashAttention的版本不然推理速度会掉一截。问题三vllm部署后通过Chatbox等客户端连不上Chatbox连vllm时需要在设置里填对Base URL。如果你本机跑http://localhost:8000/v1通常没问题。但要注意有些客户端默认API Key必填vllm默认接受任意值所以在客户端随便填一个别留空。另外跨机器访问时不要只听localhost启动命令要加--host 0.0.0.0。问题四量化模型如Q8_0在vllm里加载报错vllm原生支持的量化格式有限GGUF的Q8_0这种格式在vllm里需要额外依赖llama.cpp的转换层或者干脆直接用llama.cpp系列工具。遇到不支持的格式优先查vllm文档的Supported quantization formats别硬试。7.2 性能指标判断与调优方向判断vllm/sglang性能好不好别只看生成速度多快要看两组数据吞吐量Throughput单位时间内完成的请求数或生成的token数。压测工具可以简单用Python并发脚本也可以用社区的benchmark脚本。这一步重点看--max-num-seqs和--max-num-batched-tokens的组合是否合理。首Token延迟TTFT从请求发出到返回第一个token的间隔。TTFT高主要受两个因素影响一是模型本身计算量prefill阶段二是队列排队等待时间。如果并发高导致TTFT飙升通常是调度器在填满Batch和及时处理新请求之间失衡。调参方向是降低--max-num-seqs让新请求能更快进入计算。还有一个很容易被忽略的优化点把Prompt模板和系统提示词单独处理。很多Agent项目的Prompt里有一段不变的System Prompt如果这段内容很长每次请求都重新计算不划算。vllm和sglang都有前缀缓存能力vllm的--enable-prefix-caching、sglang的RadixAttention开启后这段固定前缀只算一次后续请求直接命中对Agent场景的首token延迟是数量级的改善。7.3 工具链与常用排查命令以下命令和代码是排查阶段我几乎必用的# 查看GPU实时显存和利用率观察batch是否打满 nvidia-smi --query-gpuindex,utilization.gpu,memory.used,memory.total --formatcsv -l 1 # 查看vllm的日志注意scheduler的调度决策信息 # 日志里出现Waiting for batch说明并发没打满出现KV cache blocks说明缓存压力大 # 进程崩溃时查看核心转储 dmesg | tail -20代码层面的验证# 快速验证服务器返回的格式和响应时间 import time, requests url http://localhost:8000/v1/chat/completions payload { model: Qwen3-8B, messages: [{role: user, content: 你好做个自我介绍}], max_tokens: 100, temperature: 0.7 } t0 time.time() r requests.post(url, jsonpayload, timeout60) print(status:, r.status_code, time:, time.time()-t0) print(r.json()[choices][0][message][content][:50])8. 机器狗、机械臂与更广泛的AI Infra应用热搜词里有个Mujoco Torch机械狗很多人会觉得和vllm/sglang不是一个世界的但这类需求恰恰说明了AI Infra技能结构的共性底层计算框架PyTorch 仿真环境MuJoCo 模型推理引擎可以理解为强化学习策略的inference管道。做机械狗控制的工程师同样需要装对torch版本、需要理解GPU显存瓶颈、需要在仿真和实机之间搭出稳定的数据/控制链路。这个案例给我们的启示是AI Infra这些技能本身是跨场景复用的——你在vllm上学到的批处理、缓存、并发控制思想放到强化学习推理、机器人控制上一样适用。从这个角度说整理一份这样的技能清单本质上是在构建一种可迁移的工程方法论——不管模型是语言模型还是策略模型不管场景是聊天机器人还是机械狗底层的那套显存管理、调度优化、环境隔离、链路可观测的思维是通用的。我个人在这轮AI Infra和Agent实践中最深的体会是大规模Agent应用的性能瓶颈往往不在模型推理本身而在链路设计中无处不在的重复计算和串行等待。把sglang的Cache复用思路用在Agent上下文管理上、用结构化生成代替自由文本解析、把工具调用做成可容错可重试的模块——这三个点一旦做好整个系统会从能跑变成扛得住。而支撑这一切的还是你对vllm、sglang、torch这些基础设施的理解深度。
