1. AI Infra 与 Agent 技能全景拆解搞 AI Infra 和 Agent 开发这几年我最大的感受就是技能栈的广度比深度更让人头疼。你可能花了两周把 vLLM 的 PagedAttention 原理啃透了结果一上手发现连 Docker 镜像里带不带模型权重都搞不清楚你刚把 SGLang 的 RadixAttention 调通转头又遇到 Agent 执行到一半报execution terminated due to error。这不是你能力不行而是这个领域本身就横跨了推理引擎、模型服务、Agent 编排、环境配置、性能调优好几个层面每个层面都有自己的坑。这篇内容我打算把自己从零搭建 AI Infra 和 Agent 系统过程中积累的技能点做一次系统整理。核心覆盖 vLLM、SGLang、PyTorch 三大推理与训练基座同时延伸到 Agent 框架选型、部署实操、性能排查这些实际工作中绕不开的环节。不管你是刚接触 AI Infra 的新手还是已经能跑通 vLLM 部署但想深入理解 EngineCore 与 Scheduler 交互流程的老手都能从里面找到对自己有用的东西。我会尽量把每个技术点的“为什么”讲清楚而不是只丢一堆命令让你复制粘贴。1.1 为什么这三个东西总是被放在一起聊vLLM、SGLang、PyTorch 这三个名字经常出现在同一个技术讨论里但它们的定位其实完全不同。PyTorch 是地基负责张量计算、自动求导、GPU 调度这些底层能力vLLM 和 SGLang 是建在地基上的推理服务框架负责把训练好的模型高效地跑起来对外提供服务。很多人搞混是因为它们都涉及“跑模型”这件事但 PyTorch 更偏向训练和实验vLLM/SGLang 更偏向生产环境的高吞吐推理。我见过不少团队在选型时纠结“到底用 vLLM 还是 SGLang”其实这个问题本身就问错了。正确的问法是你的业务场景对吞吐、延迟、并发、模型架构的支持需求是什么。vLLM 的强项在于 PagedAttention 带来的显存利用率和连续批处理能力适合高并发在线服务SGLang 的 RadixAttention 在前缀共享场景下优势明显适合多轮对话、Agent 这类有大量重复前缀的负载。两者不是替代关系而是互补关系。1.2 技能整理的逻辑框架我把整个技能体系分成四层来梳理从下往上依次是层级覆盖内容核心技能点基础环境层PyTorch 安装、CUDA 配置、Docker 环境torch 版本匹配、CUDA 兼容性、镜像构建推理引擎层vLLM、SGLang 部署与调优引擎架构、调度策略、显存管理Agent 编排层Agent 框架、工具调用、记忆管理框架选型、执行流程、错误处理运维排查层性能监控、问题定位、版本管理日志分析、性能回归、版本锁定这个分层不是绝对的实际工作中经常需要跨层排查问题。比如 Agent 执行报错可能是 Agent 框架的逻辑问题也可能是 vLLM 推理超时导致的还可能是 PyTorch 版本和 CUDA 不匹配引发的底层异常。跨层排查能力才是真正拉开差距的地方。2. PyTorch 环境配置与版本管理实战PyTorch 的安装看起来简单pip install torch一行命令的事但实际踩过的坑能写满一页纸。我见过太多人卡在torch.cuda.__init__.py报错上也见过因为 torch 版本和 CUDA 版本不匹配导致 GPU 完全用不了的案例。这一章把 PyTorch 环境配置的核心要点拆开讲。2.1 版本匹配的底层逻辑PyTorch 的版本选择不是“越新越好”而是要跟你的 CUDA 驱动版本、GPU 型号、Python 版本三者对齐。核心逻辑是这样的NVIDIA 驱动决定支持的 CUDA 最高版本CUDA 版本决定能装哪个 PyTorch 构建版本PyTorch 版本又决定了支持的 Python 版本范围。举个例子你机器上的 NVIDIA 驱动是 525 版本它最高支持 CUDA 12.0。那你就不能装需要 CUDA 12.1 的 PyTorch 构建。这时候你有两个选择升级驱动或者降级 PyTorch 到支持 CUDA 12.0 的版本。我一般建议优先升级驱动因为新驱动向下兼容旧 CUDA 版本灵活性更高。具体版本对应关系可以这样查# 查看当前驱动支持的 CUDA 版本 nvidia-smi # 输出右上角会显示 CUDA Version: 12.x # 这个版本是驱动支持的最高 CUDA 版本不是已安装的 CUDA 版本然后去 PyTorch 官网的 previous versions 页面找对应构建。比如你要装 torch 2.1.0 CUDA 12.1 的组合pip3 install torch2.1.0 torchvision0.16.0 torchaudio2.1.0 --index-url https://download.pytorch.org/whl/cu121注意--index-url后面的 cu121 必须和你的 CUDA 版本严格对应写错了会装成 CPU 版本或者直接报找不到包。2.2 常见安装报错与排查d:\comfyui_image\python\lib\site-packages\torch\cuda\__init__.py:180: UserWarning这个报错我见过太多次了。这个警告通常出现在 Windows 环境下核心原因是PyTorch 找不到可用的 CUDA 运行时。可能的情况有三种一是装成了 CPU 版本的 torch二是 CUDA 版本和 torch 构建不匹配三是环境变量里 CUDA_PATH 指向了错误的目录。排查步骤我一般按这个顺序来先确认装的是不是 GPU 版本python -c import torch; print(torch.cuda.is_available())返回 False 就是有问题检查 torch 版本和 CUDA 版本python -c import torch; print(torch.version.cuda)如果输出 None 说明是 CPU 版本检查 CUDA 安装nvcc --version如果命令不存在说明 CUDA Toolkit 没装或者没加到 PATH检查环境变量echo $CUDA_PATHLinux或echo %CUDA_PATH%Windows还有一个容易被忽略的点conda 环境和 pip 环境的冲突。如果你用 conda 装了 pytorch又用 pip 装了另一个版本两个版本会打架。我建议统一用一个包管理器要么全 conda要么全 pip别混着来。2.3 多版本共存与隔离方案实际工作中经常需要同时维护多个项目每个项目依赖不同的 torch 版本。这时候虚拟环境隔离是必须的但光靠 venv 或 conda 还不够因为 CUDA 版本是系统级的虚拟环境管不了。我的做法是用 conda 管理 Python 层面的隔离用 Docker 管理 CUDA 层面的隔离。具体来说日常开发用 conda 创建独立环境每个环境装对应版本的 torch需要严格隔离 CUDA 版本时用 Docker 镜像每个镜像固定一个 CUDA torch 组合。# conda 环境创建示例 conda create -n project_a python3.10 conda activate project_a pip install torch2.1.0 --index-url https://download.pytorch.org/whl/cu121 # 另一个项目用不同版本 conda create -n project_b python3.11 conda activate project_b pip install torch2.4.0 --index-url https://download.pytorch.org/whl/cu124实操心得conda 环境切换后一定要重新验证torch.cuda.is_available()因为有时候环境变量会残留上一个环境的配置导致看起来切换了实际没生效。3. vLLM 推理引擎深度解析与部署实操vLLM 是目前最主流的开源推理引擎之一核心卖点是 PagedAttention 和连续批处理。但很多人只停留在“能跑起来”的层面对内部的 EngineCore、Scheduler、Executor 交互流程一知半解。这一章我把 vLLM 的架构拆开讲同时给出可直接复现的部署方案。3.1 vLLM 核心架构EngineCore 与 Scheduler 交互流程vLLM 的架构可以类比成一个餐厅的运作模式。EngineCore 是餐厅经理负责整体协调Scheduler 是调度员决定哪些请求先做、哪些排队Executor 是后厨团队实际执行计算任务。三者之间的交互流程决定了整个系统的吞吐和延迟表现。具体来说当一个请求进来时流程是这样的请求到达 EngineCoreEngineCore 接收来自 API Server 的请求做初步的格式校验和 tokenizationScheduler 介入调度Scheduler 根据当前 GPU 显存状态、正在处理的序列数量、请求优先级决定这个请求是立即执行还是排队等待Executor 执行计算被调度的请求进入 ExecutorExecutor 负责实际的模型前向计算包括 attention 计算、KV Cache 读写结果返回 EngineCore计算完成后结果回传 EngineCore再通过 API Server 返回给客户端这个流程里最关键的是Scheduler 的调度策略。vLLM 默认用的是连续批处理Continuous Batching跟传统的静态批处理不同它不需要等一个批次的所有请求都完成才处理下一批而是每生成一个 token 就重新评估一次批次组成。这样做的好处是短请求不会被长请求拖累GPU 利用率更高。Scheduler 在做决策时会考虑几个核心因素显存水位当前 KV Cache 占用了多少显存还剩多少可以分配给新请求序列长度请求的 prompt 长度和预期生成长度决定需要多少 KV Cache 空间抢占策略显存不够时是拒绝新请求还是抢占低优先级请求的资源注意vLLM 新版本在调度策略上有调整部分版本出现了性能下降的情况。如果你从旧版本升级后发现吞吐下降可以先回退到稳定版本或者调整--max-num-seqs和--max-num-batched-tokens参数来适配新调度逻辑。3.2 Docker 部署 vLLM 完整流程Docker 部署是目前最推荐的方式环境隔离干净迁移方便。我以部署 Qwen 系列模型为例把完整流程走一遍。首先拉取镜像。vLLM 官方镜像的命名规则是vllm/vllm-openai:版本号比如vllm/vllm-openai:v0.27.1。这个镜像不包含模型权重模型需要在启动时挂载或者从网络下载。# 拉取指定版本镜像 docker pull vllm/vllm-openai:v0.27.1 # 启动容器挂载本地模型目录 docker run --runtime nvidia --gpus all \ -v /path/to/your/models:/models \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:v0.27.1 \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen2.5-7b \ --max-model-len 8192 \ --gpu-memory-utilization 0.9几个关键参数的解释--ipchost共享主机 IPC 命名空间vLLM 多进程通信需要不加可能报共享内存错误--max-model-len最大序列长度根据模型支持的长度和显存大小调整--gpu-memory-utilizationGPU 显存利用率上限默认 0.9显存紧张时可以降到 0.8--served-model-name对外暴露的模型名称调用 API 时用这个名字如果模型不大也可以让 vLLM 自动从 HuggingFace 下载但生产环境我强烈建议提前下载好模型挂载进去避免容器启动时因为网络问题卡住。3.3 部署 Qwen3-Embedding 与 DeepSeek 的差异化配置不同模型对推理引擎的要求不一样。Embedding 模型和生成式模型的部署配置差异很大不能一套参数走天下。Qwen3-Embedding-0.6B 这类 Embedding 模型特点是模型小、吞吐要求高、不需要生成长文本。部署时重点调这几个参数docker run --runtime nvidia --gpus all \ -v /models:/models \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:v0.27.1 \ --model /models/Qwen3-Embedding-0.6B \ --task embedding \ --max-model-len 512 \ --gpu-memory-utilization 0.5--task embedding是关键告诉 vLLM 这是 Embedding 任务走不同的处理路径。--max-model-len可以设小一点Embedding 输入通常不会太长。DeepSeek 这类大模型部署时显存是主要瓶颈。以 DeepSeek-V2-Lite 为例FP16 精度下大概需要 32GB 显存如果显存不够可以考虑量化版本docker run --runtime nvidia --gpus all \ -v /models:/models \ -p 8000:8000 \ --ipchost \ vllm/vllm-openai:v0.27.1 \ --model /models/DeepSeek-V2-Lite-Chat \ --tensor-parallel-size 2 \ --max-model-len 4096 \ --gpu-memory-utilization 0.95 \ --enforce-eager--tensor-parallel-size 2表示用两张卡做张量并行适合单卡显存不够的情况。--enforce-eager关闭 CUDA Graph省一点显存但会牺牲一些性能显存极度紧张时可以用。3.4 vLLM 性能调优与版本选择vLLM 的版本迭代很快不同版本之间的性能表现可能有明显差异。我整理了一个版本选择的参考思路场景推荐版本策略原因生产环境稳定优先锁定已知稳定版本不追新新版本可能引入性能回归新模型支持用最新版本新模型架构需要新版本支持显存紧张尝试较新版本新版本通常有显存优化多卡部署选择社区验证过的版本多卡并行的问题更多性能调优的核心参数就那几个但每个都值得反复调--max-num-seqs最大并发序列数调大吞吐上升但延迟可能增加--max-num-batched-tokens单批次最大 token 数影响批处理效率--gpu-memory-utilization显存利用率0.9 是默认值可以微调到 0.95--enable-chunked-prefill开启分块预填充长 prompt 场景下能降低首 token 延迟实操心得调参时一次只改一个参数改完跑一轮基准测试记录吞吐和延迟变化。同时改多个参数你根本不知道是哪个起了作用。4. SGLang 与 vLLM 的选型对比与实战SGLang 和 vLLM 经常被拿来比较但我觉得与其争论谁更好不如搞清楚什么场景该用谁。这一章从架构差异、性能表现、适用场景三个维度做对比并给出 SGLang 的部署实操。4.1 RadixAttention 与 PagedAttention 的本质差异vLLM 的 PagedAttention 解决的是KV Cache 显存碎片化问题。传统方式下每个请求的 KV Cache 需要连续显存空间浪费严重PagedAttention 把 KV Cache 分成固定大小的块像操作系统管理内存页一样管理显存利用率大幅提升。SGLang 的 RadixAttention 解决的是前缀重复计算问题。在多轮对话、Agent 工具调用这类场景下不同请求往往有大量相同的前缀比如 system prompt、历史对话。RadixAttention 用基数树Radix Tree来组织 KV Cache相同前缀只计算一次后续请求直接复用。打个比方PagedAttention 像是一个高效的仓库管理员把货物KV Cache分门别类放好不浪费货架空间RadixAttention 像是一个聪明的图书管理员发现很多人借同一本书的前几章干脆把前几章复印好放在前台谁来都直接给复印件。这两个机制不是互斥的理论上可以结合但目前两个框架各走各的路线。选型的核心判断标准是你的负载有没有大量重复前缀。有选 SGLang没有或者前缀重复率低选 vLLM。4.2 SGLang 部署实操与参数配置SGLang 的部署方式和 vLLM 类似也支持 Docker 和 pip 两种方式。我用 pip 方式演示因为 SGLang 的 Docker 镜像更新频率不如 vLLM 高。# 安装 SGLang pip install sglang[all] # 启动服务 python -m sglang.launch_server \ --model-path /models/Qwen2.5-7B-Instruct \ --port 30000 \ --host 0.0.0.0 \ --tp-size 1 \ --mem-fraction-static 0.85 \ --max-running-requests 128关键参数说明--tp-size张量并行大小跟 vLLM 的--tensor-parallel-size对应--mem-fraction-static静态显存分配比例SGLang 会预留一部分显存给 KV Cache--max-running-requests最大并发请求数类似 vLLM 的--max-num-seqsSGLang 还支持一些 vLLM 没有的特性比如RadixAttention 的前缀缓存默认开启以及结构化输出的原生支持。如果你的 Agent 需要模型输出严格的 JSON 格式SGLang 的结构化输出比 vLLM 的 guided decoding 用起来更顺手。4.3 什么场景该选 SGLang 而不是 vLLM根据我的实际使用经验这几个场景 SGLang 优势明显多轮对话系统。每轮对话都包含之前的完整历史前缀重复率极高。SGLang 的 RadixAttention 能把首 token 延迟降低 50% 以上这个提升在用户体验上是质变的。Agent 工具调用。Agent 在执行任务时system prompt 和工具定义部分是完全固定的每次调用都重复。SGLang 能缓存这部分前缀减少重复计算。批量推理任务。如果一批请求共享相同的 prompt 模板只是变量部分不同SGLang 的前缀复用能大幅提升吞吐。反过来这几个场景 vLLM 更合适单轮问答。没有前缀复用空间vLLM 的 PagedAttention 在显存管理上更成熟。高并发短请求。vLLM 的连续批处理在短请求场景下调优空间更大。生态兼容性要求高。vLLM 的社区更大跟其他工具的集成更完善遇到问题更容易找到解决方案。4.4 两个框架的混合部署思路实际生产环境中不一定非要二选一。我见过一些团队的做法是用 vLLM 做通用推理服务用 SGLang 专门服务 Agent 和多轮对话场景。两个服务独立部署通过路由层根据请求特征分发。这种混合架构的好处是各取所长坏处是运维复杂度上升。如果团队人手有限建议先聚焦一个框架把它的性能调优做到极致再考虑引入第二个。5. Agent 开发核心技能与框架选型Agent 是这两年最热的方向之一但很多人在框架选型上就卡住了。LangChain、AutoGPT、Hermes Agent、Pi Agent……名字一大堆到底该用哪个这一章我把 Agent 开发的核心技能点拆开讲同时给出框架选型的判断框架。5.1 Agent 架构的核心组件不管用什么框架一个 Agent 系统的核心组件就那几个规划模块。Agent 需要把用户的高层指令拆解成可执行的步骤。比如用户说“帮我分析这份销售数据并生成报告”Agent 需要拆成“读取数据→清洗数据→计算指标→生成图表→撰写报告”这几步。工具调用模块。Agent 需要调用外部工具来完成任务比如搜索引擎、代码执行器、API 接口。工具调用的核心是函数签名定义和参数解析这部分做不好 Agent 就会频繁调错工具。记忆模块。Agent 需要记住之前的对话和操作历史。短期记忆通常放在上下文里长期记忆需要向量数据库或者结构化存储。记忆管理做不好Agent 要么“失忆”要么上下文爆炸。执行循环。Agent 的核心是一个循环观察当前状态→规划下一步→执行动作→观察结果→判断是否完成。这个循环的终止条件设计很关键设计不好要么死循环要么提前退出。5.2 主流 Agent 框架对比与选型建议框架核心特点适合场景学习曲线LangChain生态最全组件丰富快速原型、复杂编排中等Hermes Agent桌面端友好配置简单个人助手、本地部署低Pi Agent轻量专注核心循环学习原理、定制开发低AutoGPT自主性强适合探索研究、实验高选型的核心判断标准是你的 Agent 需要多复杂的编排。如果只是简单的“调用模型→解析输出→调用工具”循环用 Pi Agent 或者自己写一个循环就够了引入 LangChain 反而增加复杂度。如果需要复杂的多 Agent 协作、条件分支、循环嵌套LangChain 的 LangGraph 会更合适。注意Agent 框架的版本迭代非常快API 经常变。选型时不要只看功能列表要看最近三个月的更新频率和社区活跃度。一个半年没更新的框架即使功能再全也不建议用在生产环境。5.3 Agent 记忆管理与安全防护Agent 记忆管理是实际开发中最容易出问题的环节。我踩过的坑包括上下文太长导致推理变慢、记忆检索不准确导致 Agent 答非所问、记忆写入冲突导致数据不一致。我的做法是分层管理记忆工作记忆当前对话的上下文放在 prompt 里控制在模型上下文窗口的 70% 以内短期记忆最近几轮对话的摘要用向量数据库存储按相关性检索长期记忆用户偏好、历史任务结果等结构化数据用关系数据库存储安全方面Agent 的记忆系统是一个容易被忽视的攻击面。如果 Agent 的记忆可以被外部输入污染攻击者就能通过注入恶意记忆来操控 Agent 行为。A-MemGuard 这类主动防御框架的思路值得参考对写入记忆的内容做来源验证和内容过滤对读取记忆的操作做权限控制。5.4 Agent 执行报错排查实录agent execution terminated due to error这个报错太常见了但它的信息量几乎为零。我一般按这个顺序排查看完整日志。这个报错通常只是最外层的包装真正的错误信息在更下面的日志里。找Traceback或者Caused by关键字。检查工具调用。Agent 执行失败最常见的原因是工具调用出错。检查工具的参数格式、返回值格式是否符合预期。检查推理服务。如果 Agent 依赖 vLLM 或 SGLang 做推理确认推理服务是否正常响应。推理超时也会导致 Agent 报这个错。检查上下文长度。上下文超长会导致模型输出异常进而让 Agent 解析失败。打印一下实际发送给模型的 prompt 长度。检查循环终止条件。如果 Agent 陷入死循环最终会因为达到最大步数而终止报错信息可能就是这个。我整理了一个速查表报错现象可能原因排查方法执行立即终止工具定义格式错误检查工具 schema 是否符合框架要求执行到一半终止推理服务超时查看推理服务日志检查超时配置间歇性终止上下文超长打印 prompt 长度检查截断逻辑特定任务终止工具返回值解析失败打印工具原始返回值检查解析代码6. 跨层问题排查与性能优化经验前面几章分别讲了 PyTorch、vLLM、SGLang、Agent但实际工作中遇到的问题往往是跨层的。这一章分享几个典型的跨层问题排查案例以及我总结的性能优化经验。6.1 推理服务性能下降的排查思路vLLM 新版本性能下降是社区经常讨论的问题。遇到这种情况我按这个顺序排查第一步确认基准。用相同的模型、相同的请求负载在旧版本和新版本上各跑一轮基准测试。不要凭感觉说“变慢了”要有数据。第二步检查调度参数。新版本可能改了默认的调度参数。对比新旧版本的--max-num-seqs、--max-num-batched-tokens默认值看是否有变化。第三步检查 CUDA Graph。vLLM 默认开启 CUDA Graph 来加速推理但某些模型或某些版本下 CUDA Graph 可能导致性能下降。试试加--enforce-eager关闭它看性能是否恢复。第四步检查显存管理。新版本的显存管理策略可能变了。用nvidia-smi观察推理过程中的显存占用曲线看是否有异常波动。第五步回退版本。如果以上都排查不出问题回退到已知稳定的版本等新版本修复后再升级。6.2 多卡部署的常见坑多卡部署张量并行能解决单卡显存不够的问题但引入的复杂度也不小。我踩过的坑包括NCCL 通信超时。多卡之间通过 NCCL 通信如果网络配置有问题或者某张卡负载过高会报 NCCL timeout。解决办法是调整NCCL_TIMEOUT环境变量或者检查是否有其他进程占用了 GPU。负载不均衡。张量并行下如果模型层分配不均匀会出现一张卡忙死、另一张卡闲死的情况。vLLM 和 SGLang 都会自动做层分配但某些模型架构下自动分配效果不好需要手动调整。显存碎片化。多卡环境下显存碎片化问题更严重因为每张卡都要维护自己的 KV Cache。开启 PagedAttention 能缓解但不能完全解决。定期重启推理服务是个简单有效的办法。6.3 版本锁定与升级策略AI Infra 领域的版本管理是个头疼问题。我的策略是生产环境锁定版本开发环境跟进最新。生产环境用 Docker 镜像锁定所有依赖版本包括 vLLM、PyTorch、CUDA、Python。镜像打好标签记录每个版本的组合。升级时先在开发环境验证确认没问题再更新生产镜像。开发环境可以激进一些跟进最新版本提前发现兼容性问题。但要注意不要在生产环境直接 pip install --upgrade这个操作的风险太高了。我维护了一个版本兼容性表格记录每个验证过的版本组合vLLM 版本PyTorch 版本CUDA 版本验证状态备注v0.27.12.4.012.4稳定当前生产使用v0.28.02.5.012.4测试中新模型支持更好v0.26.02.3.012.1稳定旧项目使用实操心得每次升级前用相同的基准测试跑一轮记录吞吐、延迟、显存占用三个指标。只有三个指标都不劣于旧版本才考虑升级。6.4 监控与告警体系搭建生产环境的推理服务需要监控不然出了问题只能等用户反馈。我一般监控这几个指标请求延迟P50、P95、P99 分位数看长尾延迟吞吐量每秒处理的 token 数或请求数GPU 利用率计算利用率和显存利用率错误率请求失败的比例按错误类型分类队列长度等待处理的请求数反映系统压力监控工具用 Prometheus Grafana 就够了vLLM 和 SGLang 都暴露了 Prometheus 格式的指标。告警规则根据业务需求设我一般设这几个P99 延迟超过阈值持续 5 分钟错误率超过 1% 持续 3 分钟GPU 显存利用率超过 95% 持续 10 分钟队列长度超过阈值持续 5 分钟告警不是越多越好太多告警会导致告警疲劳真正重要的问题反而被忽略。每个告警都要有明确的处理动作没有处理动作的告警不如不设。7. 学习路线与技能进阶建议最后聊一下学习路线。AI Infra 和 Agent 这个领域变化太快没有一劳永逸的学习方案但有一些原则性的东西可以分享。7.1 从使用者到贡献者的进阶路径我观察到的进阶路径大概是这样的第一阶段会用。能按照文档把 vLLM 或 SGLang 跑起来能部署一个简单的 Agent遇到常见报错能自己排查。这个阶段重点是动手不要只看文档要实际跑起来。第二阶段会调。能根据业务场景调整推理参数能优化 Agent 的 prompt 和工具定义能定位性能瓶颈。这个阶段重点是理解原理知道每个参数背后的逻辑。第三阶段会改。能修改推理引擎的源码来适配特殊需求能自己实现 Agent 框架的核心组件能贡献代码到开源社区。这个阶段重点是读源码从 issue 和 PR 里学习。第四阶段会设计。能设计整个 AI Infra 架构能做技术选型和容量规划能预判技术趋势。这个阶段重点是积累经验多跟同行交流多复盘项目。7.2 值得深入的方向如果你已经过了“会用”的阶段这几个方向值得深入推理引擎的调度算法。vLLM 和 SGLang 的调度策略还有很多优化空间特别是在异构负载场景下。理解调度算法不仅能帮你调优还能让你在选型时更有判断力。Agent 的记忆与规划。这是 Agent 领域最核心也最难的问题。如何让 Agent 记住关键信息、如何让 Agent 做出合理的规划目前还没有特别成熟的方案值得深入研究。多模态推理。随着多模态模型越来越普及如何高效地做多模态推理是个新问题。vLLM 和 SGLang 都在跟进但成熟度还不如纯文本推理。推理服务的成本优化。GPU 成本是 AI 应用的大头如何在保证性能的前提下降低成本是每个团队都关心的问题。量化、蒸馏、投机采样这些技术都值得研究。7.3 我个人的一些体会搞 AI Infra 这几年我最大的体会是不要追求把所有东西都学会要追求把关键东西学透。vLLM、SGLang、PyTorch、Agent 框架每个都深不见底你不可能全部精通。找到你业务最依赖的那一两个深入下去其他的了解基本用法就够了。另一个体会是动手比看文档重要一百倍。我见过太多人把 vLLM 的论文读了好几遍但连最基本的部署都没跑过。文档和论文能帮你理解原理但真正的经验只能从动手实践中来。遇到报错不要怕每个报错都是学习的机会。最后一个体会是保持跟进但不要焦虑。这个领域每天都有新东西出来你不可能全部跟上。我的做法是关注几个核心项目的更新其他的等用到的时候再学。技术是学不完的但核心原理是相通的把基础打牢学新东西就快。最后分享一个小技巧建一个自己的知识库记录每次踩坑和解决方案。我用的是 Obsidian每次遇到问题解决后就记一条标注日期、环境、问题现象、排查过程、解决方案。半年下来积累了上百条再遇到类似问题直接搜知识库效率高很多。