1. 从一堆散乱热词里我看到的AI Infra技能地图先把话说在前头这篇不是教程合集也不是官方文档的搬运。它更像是我自己电脑里那份“AI Infra / Agent 技能清单”的公开版——平时遇到问题就往上记一笔时间久了发现这些零散的点其实能连成一张挺完整的能力地图。标题里那几个词——vllm、sglang、torch再加上agent基本覆盖了现在做 AI 基础设施和智能体开发最核心的几块拼图。热词里冒出来的东西也很有意思有人问vllm enginecore 与 scheduler、executor 交互流程有人卡在torch 安装有人在折腾docker vllm/vllm-openai:v0.27.1 加载 qwen3-embedding-0.6b还有人关心agent 记忆、agent 安全、agent 框架与编排。这些不是孤立的问题它们对应的是同一套技能体系里不同的层。我先把这张地图摊开讲清楚后面再逐层拆。推理引擎层是 vllm 和 sglang 的主场负责把模型高效跑起来框架底座层是 torch几乎所有上层东西都建在它上面智能体层是 agent负责把模型能力编排成能干活的东西工程落地层是 docker、镜像、部署、显存这些脏活累活。四层叠起来才是一个能真正跑起来的 AI 系统。为什么我要强调“技能整理”而不是“知识整理”因为这两者差别很大。知识是你知道 vllm 有个 scheduler技能是当vllm 新版本性能下降时你知道该去看哪几个指标、怎么回滚、怎么对比。知识是你知道 agent 有记忆模块技能是当agent execution terminated due to error时你能顺着调用链把问题定位到是工具调用超时还是上下文溢出。这篇内容就是奔着后者去的。适合谁看如果你刚开始接触vllm 部署大模型这里能帮你少走弯路如果你已经在写 agent但总觉得编排和记忆这块不踏实这里有你需要的结构如果你是被torch 安装折磨过的人那更对味了。我不假设你什么都会但也不打算把每个概念都从零讲一遍——该补的基础我会补重点放在那些真正卡人的地方。下面这张表是我对这四个方向的一个整体定位先给你一个全局感层级代表技术核心职责典型痛点推理引擎层vllm、sglang高吞吐模型推理、批处理调度版本性能波动、显存管理、调度逻辑框架底座层torch张量计算、GPU 加速、模型加载安装版本匹配、CUDA 兼容智能体层agent 框架任务编排、工具调用、记忆管理执行中断、上下文管理、安全工程落地层docker、镜像环境隔离、一键部署镜像是否带模型、版本选择这张表不是让你背的是让你在遇到问题时能快速判断“我现在卡在哪一层”。很多人排查半天没结果就是因为把工程层的问题当成模型层的问题在查。2. vllm 与 sglang推理引擎的调度逻辑和选型判断2.1 vllm 的 enginecore、scheduler、executor 到底怎么串起来热词里有一条特别具体vllm enginecore 与 scheduler、executor 交互流程。这个问题问到了 vllm 的骨架。我用大白话把它讲透因为理解了这条链路后面调优和排错才有方向。vllm 的核心设计是PagedAttention它把 KV Cache 像操作系统管理内存页一样分块管理。围绕这个设计整个推理流程被拆成几个角色。EngineCore是总指挥它持有模型、管理请求的生命周期。Scheduler是调度员决定每一轮哪些请求进入计算、哪些等待。Executor是干活的真正在 GPU 上执行前向计算。三者关系可以类比成餐厅EngineCore 是店长Scheduler 是领班安排哪桌先上菜Executor 是后厨真正炒菜。具体流程是这样的请求进来后先到 EngineCore它把请求交给 Scheduler。Scheduler 看当前显存里 KV Cache 的占用情况决定这一轮能塞进哪些请求——这就是所谓的continuous batching也是 vllm 吞吐高的关键。决定好之后Scheduler 把这一批的元信息交给 ExecutorExecutor 在 GPU 上跑完前向把生成的 token 返回。EngineCore 再判断请求是否结束没结束就回到 Scheduler 等下一轮。理解这条链路的价值在于当你遇到vllm 新版本性能下降你就知道该看哪里。可能是 Scheduler 的批处理策略变了可能是 Executor 的 kernel 实现换了也可能是 EngineCore 的请求管理逻辑调整了。我自己的习惯是升级 vllm 后先跑一个固定长度的压测对比吞吐tokens/s和首 token 延迟TTFT两个指标如果吞吐掉了但延迟没变大概率是调度或批处理的问题如果两个都掉可能是 kernel 或显存管理出了变化。提示不要只看总吞吐。把 TTFT 和 TPOT每 token 输出时间分开看才能判断是调度问题还是计算问题。2.2 sglang 和 vllm 的差异不是谁替代谁sglang 和 vllm经常被放在一起比。我的判断是它们不是替代关系而是针对不同场景的两种取向。vllm 更像通用推理服务器追求的是在广泛模型和请求模式下的稳定高吞吐。sglang 则在结构化生成和前缀复用上下了更多功夫它的 RadixAttention 对多轮对话、共享前缀的场景特别友好。举个实际场景如果你在做 agentagent 的每一轮调用往往带着很长的系统提示和工具定义这些前缀在多轮之间是重复的。sglang 的前缀缓存能直接命中省掉重复计算。而 vllm 虽然也有 prefix caching但在这种高度重复前缀的场景下sglang 的设计更贴合。反过来如果你只是单纯部署一个模型对外提供 API请求之间前缀差异大vllm 的通用性更省心。选型的时候我会问自己三个问题请求之间前缀重复度高不高是否需要复杂的结构化输出约束团队对哪个的运维更熟三个问题答完选型基本就清楚了。不要因为某个 benchmark 数字高就盲目切换迁移成本和稳定性风险往往比那点吞吐差异更值钱。2.3 部署实战docker 镜像、模型加载与版本选择热词里docker vllm/vllm-openai:v0.27.1 加载 qwen3-embedding-0.6b和docker 部署 vllm 模型教程出现频率很高说明这是大家真正在动手做的事。我把关键点讲清楚。第一个常见疑问vllm docker 镜像中带模型吗答案是不带。官方镜像只包含 vllm 和依赖模型需要你挂载进去或者运行时下载。所以正确的做法是把模型文件放在宿主机某个目录启动容器时用-v挂载然后通过--model参数指向容器内的路径。这样镜像可以复用模型可以独立管理。第二个问题是版本选择。热词里有人问glm5.3 使用 vllm 哪个版本的镜像这类问题的通用解法是先看模型官方文档推荐的 vllm 版本再看 vllm 的 release notes 里对应版本支持了哪些模型架构。新模型往往需要较新的 vllm但最新版又可能有性能波动所以我的策略是选模型官方验证过、且不是刚发布一两天的版本。稳定优先。启动命令的骨架大概是这样docker run --gpus all \ -v /your/models:/models \ -p 8000:8000 \ --shm-size 16g \ vllm/vllm-openai:v0.27.1 \ --model /models/Qwen3-Embedding-0.6B \ --served-model-name qwen3-embedding \ --max-model-len 8192这里有几个容易忽略的点。--shm-size一定要给够默认的共享内存太小会导致多进程通信出问题表现为莫名其妙的卡死。--max-model-len要根据实际需求设设太大浪费显存设太小长文本会被截断。还有--gpu-memory-utilization默认 0.9如果你的卡还要跑别的任务得调低。注意embedding 模型和生成模型的部署参数不一样。embedding 模型通常不需要那么大的 max-model-len但可能需要更高的并发--max-num-seqs可以适当调大。3. torch那个让人又爱又恨的底座3.1 安装 torch 为什么总是出问题torch 安装、pip3 install torch1.8.2 torchvision0.9.2 torchaudio0.8.2 --extra-index、安装 torch——这些热词背后是无数人的血泪。torch 安装出问题根子上是版本三角torch 版本、CUDA 版本、Python 版本三者必须匹配。任何一角不对就是各种报错。热词里有个很典型的报错d:\comfyui_image\python\lib\site-packages\torch\cuda\__init__.py:180: userwa。这个路径一看就是 Windows 上 ComfyUI 的内置 Python 环境。这类报错通常是 CUDA 初始化失败原因可能是驱动版本不够、CUDA runtime 和 torch 编译版本不匹配或者环境里装了 CPU 版的 torch。我的排查顺序是这样的先python -c import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())一行命令看清楚 torch 版本、它编译时用的 CUDA 版本、以及能不能用 GPU。如果cuda.is_available()是 False那问题就在驱动或版本匹配上不用往下查了。安装的时候不要直接pip install torch那样很可能装到 CPU 版或者和你的 CUDA 不匹配的版本。正确做法是去 torch 官网的安装选择器选好你的系统和 CUDA 版本它会给你一条带--index-url的命令。比如 CUDA 12.1 的pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu1213.2 版本匹配的实操判断法很多人问“我该装哪个版本的 torch”。这个问题没有统一答案但有一个判断流程。第一步看你的 GPU 驱动支持的最高 CUDA 版本用nvidia-smi右上角那个数字。第二步看你要用的框架比如 vllm、某个 agent 库要求什么 torch 版本。第三步在 torch 官网找同时满足前两个条件的版本。这里有个坑nvidia-smi显示的是驱动支持的最高CUDA 版本不是你必须用的版本。你可以装比它低的 CUDA 版本的 torch只要驱动够新就行。反过来装比它高的一定失败。所以驱动版本是上限不是目标。还有一个常见误区是 conda 和 pip 混用。conda 装的 torch 和 pip 装的 torch 可能来自不同渠道依赖解析结果不同混着用容易出现“明明装了却 import 不到”或者“版本对不上”的问题。我的建议是在一个环境里只用一种包管理器装 torch要么全 conda要么全 pip别混。3.3 torch 在 agent 和机器人场景里的延伸热词里有个挺有意思的mujoco torch 机械狗。这说明 torch 的用途早就超出了纯文本模型。在机器人、强化学习、物理仿真这些场景里torch 同样是底座。mujoco 做物理仿真torch 做策略网络两者结合做机械狗的控制这是很典型的具身智能技术栈。这类场景对 torch 的要求和纯推理不太一样。训练场景需要 autograd、优化器、分布式推理场景更看重算子融合和低精度支持。如果你是从纯 LLM 推理转到这类场景会发现很多在推理里不关心的东西比如梯度、混合精度训练的 scaler在这里是核心。技能树要相应扩展。4. Agent从框架选型到记忆与安全的完整链路4.1 agent 框架与编排别一上来就选最复杂的agent 框架、agent 框架与编排、agent 开发学习路线、agent for beginner——这些词说明很多人正站在 agent 开发的门口。我的建议很直接别一上来就上重型框架。先用最朴素的方式跑通一个 agent 循环理解它到底在干什么再去选框架。一个 agent 的本质循环其实很简单接收任务 → 模型思考 → 决定调用哪个工具 → 执行工具 → 把结果喂回模型 → 继续思考直到任务完成。这个循环用几十行代码就能写出来。热词里吴恩达 agent 教程之所以受欢迎就是因为它把这个循环讲得很清楚没有一上来就堆框架。理解了这个循环你再看各种 agent 框架就会发现它们无非是在几个维度上做增强编排怎么定义多步骤流程、工具管理怎么注册和调用工具、记忆怎么保存和检索历史、可观测性怎么调试和追踪。选框架的时候就看它在你这几个维度上的需求匹配度。我自己的经验是编排复杂度是最容易过度设计的地方。很多人一开始就搞很复杂的多 agent 协作、层级编排结果调试成本极高一个环节出错整条链都断。不如先用单 agent 加几个工具跑通确认价值后再逐步增加复杂度。热词里agent 开发案例和agent 项目值得多看但看的时候要关注它的编排是不是真的必要还是为了炫技。4.2 agent 记忆不是存得越多越好agent 记忆、a-memguard: a proactive defense framework for llm-based agent memory这两个词放在一起看很有意思。前者是需求后者是安全。agent 记忆的核心问题是上下文窗口有限但任务历史可能很长怎么取舍。常见的记忆方案有几类。短期记忆就是当前对话的上下文直接放在 prompt 里。长期记忆通常用向量数据库存需要时检索相关片段。摘要记忆是把历史压缩成摘要牺牲细节换空间。还有结构化记忆把关键信息抽成结构化字段存起来。我的实操心得是记忆的关键不是存而是检索和遗忘。存一堆东西但检索不准等于没存。遗忘机制也很重要过时的信息留在记忆里会干扰模型判断。热词里那个a-memguard提到的“主动防御”本质上是防止记忆被污染或注入恶意内容——这在 agent 安全里是个真问题因为记忆是 agent 的持久状态一旦被污染影响是长期的。具体做法上我会给记忆加来源标记和时效标记。每条记忆记录它来自哪次交互、什么时候产生的。检索时不仅看语义相似度还看时效和来源可信度。这样能过滤掉很多噪声。4.3 agent 执行中断与错误排查agent execution terminated due to error这个报错做过 agent 的人大概率都见过。它本身信息量很低因为它是顶层错误真正的原因被吞掉了。排查这类问题我的方法是分层定位。第一层看是模型调用出错还是工具调用出错。如果是模型 API 返回错误通常是限流、超时或上下文超长。如果是工具执行抛异常那要看具体工具的日志。第二层看是单次调用出错还是循环控制出错。agent 的循环如果没有正确的终止条件可能陷入死循环直到超时。第三层看是不是资源问题比如显存爆了、内存不够、并发太高。热词里codex无法发送消息显示更新 agent 沙盒这类问题往往和沙盒环境的网络或权限配置有关。agent 执行工具时如果被沙盒限制表现就是“发不出去”。这类问题要看沙盒的日志而不是 agent 本身的日志。提示给 agent 的每一步都加上结构化日志记录输入、输出、耗时、错误。出问题时这份日志比任何调试器都好用。4.4 agent 安全被低估的一环agent 安全这个词值得单独拎出来说。agent 和普通模型调用最大的区别是它能执行动作。模型说错话只是说错话agent 调错工具可能真的删了文件、发了请求、改了数据。所以 agent 的安全边界必须比模型更严。我的做法是三层防护。输入层做校验用户的指令不能直接变成危险操作。工具层做权限控制每个工具明确它能碰什么、不能碰什么危险操作要二次确认。输出层做审计所有执行过的动作都有记录可追溯。热词里提到的记忆防御也是其中一环因为记忆会影响 agent 的决策被污染的记忆会导致错误动作。还有一点容易被忽略agent 的权限应该最小化。不要给它一个万能的管理员 token而是按需分配、用完即收。这在多 agent 协作的场景里尤其重要一个 agent 被攻破不应该导致整个系统沦陷。5. 把这些技能串成一条可执行的成长路径5.1 不同起点的切入顺序技能整理到最后要落到“我该先学什么”。这取决于你的起点。如果你是算法背景熟悉 torch 和模型训练那你的短板可能在工程层优先补 docker、部署、推理引擎的调度逻辑。如果你是后端背景熟悉服务和部署那你的短板可能在模型层优先理解 torch 的推理流程和 vllm 的批处理机制。如果你是产品背景想转 agent那从 agent 循环和工具调用入手先跑通再深入。我给一个通用的切入顺序torch 基础 → 推理引擎vllm 或 sglang 选一个→ 部署工程 → agent 开发 → agent 安全与记忆。这个顺序的逻辑是自底向上每一层都建立在前一层之上。当然不是绝对的但按这个顺序走遇到的“看不懂”会少很多。热词里agent 开发学习路线和agent 学习路线出现多次说明大家很需要这个。我的路线建议是第一周跑通一个最小 agent第二周给它加工具和记忆第三周学部署和推理引擎第四周做安全和可观测性。四周下来你对整个链路会有实感比看一个月文档强。5.2 我踩过的几个典型坑第一个坑是过早优化推理引擎。刚开始做的时候我花了很多时间调 vllm 的参数想榨干每一滴性能结果发现瓶颈根本不在推理而在 agent 的编排逻辑和工具调用延迟上。后来我学乖了先用默认参数跑通用 profiling 找到真正的瓶颈再优化。第二个坑是torch 环境混用。我在一个环境里同时装了 conda 和 pip 的 torch结果 import 的时候加载的是错的那个报了一堆莫名其妙的 CUDA 错误。排查了大半天才发现是环境问题。从那以后我一个环境只用一种包管理器。第三个坑是agent 记忆无限增长。早期我没做记忆的淘汰机制跑久了记忆库越来越大检索越来越慢而且旧记忆干扰新决策。后来加了时效和容量限制效果立刻好转。记忆不是越多越好是要精准。第四个坑是忽略 shm-size。docker 部署 vllm 时没设--shm-size容器跑一会儿就卡死日志里也没什么明显错误。查了很久才知道是共享内存不够导致多进程通信失败。这个坑很隐蔽因为报错信息不直接指向原因。5.3 工具链的日常维护习惯最后分享几个我日常维护这套工具链的习惯。版本锁定所有关键依赖torch、vllm、sglang都记录确切版本升级前先在测试环境验证。压测基线维护一个固定的压测脚本每次升级后跑一遍对比吞吐和延迟有异常立刻回滚。日志集中推理引擎、agent、工具调用的日志统一收集出问题时能串起来看。镜像管理docker 镜像打标签时带上日期和版本别用 latest否则回滚时找不到对应版本。这些习惯看起来琐碎但真出事的时候它们能帮你把排查时间从几小时压到几分钟。AI Infra 和 agent 这个领域变化快新版本、新框架层出不穷唯一能让你稳住的就是这套工程习惯。技术会过时习惯不会。我个人在实际操作中的体会是这套东西没有“学完”的一天。vllm 会出新版本sglang 会加新特性agent 框架会迭代torch 会更新。重要的不是记住每个细节而是理解每一层的职责和它们之间的接口。理解了接口上层怎么变你都能快速接上。这份技能清单我会一直更新下去也建议你维护一份自己的——遇到问题记一笔解决完记一笔时间久了它就是你自己最值钱的文档。
AI Infra与Agent技能地图：vllm、sglang、torch与智能体开发实战
1. 从一堆散乱热词里我看到的AI Infra技能地图先把话说在前头这篇不是教程合集也不是官方文档的搬运。它更像是我自己电脑里那份“AI Infra / Agent 技能清单”的公开版——平时遇到问题就往上记一笔时间久了发现这些零散的点其实能连成一张挺完整的能力地图。标题里那几个词——vllm、sglang、torch再加上agent基本覆盖了现在做 AI 基础设施和智能体开发最核心的几块拼图。热词里冒出来的东西也很有意思有人问vllm enginecore 与 scheduler、executor 交互流程有人卡在torch 安装有人在折腾docker vllm/vllm-openai:v0.27.1 加载 qwen3-embedding-0.6b还有人关心agent 记忆、agent 安全、agent 框架与编排。这些不是孤立的问题它们对应的是同一套技能体系里不同的层。我先把这张地图摊开讲清楚后面再逐层拆。推理引擎层是 vllm 和 sglang 的主场负责把模型高效跑起来框架底座层是 torch几乎所有上层东西都建在它上面智能体层是 agent负责把模型能力编排成能干活的东西工程落地层是 docker、镜像、部署、显存这些脏活累活。四层叠起来才是一个能真正跑起来的 AI 系统。为什么我要强调“技能整理”而不是“知识整理”因为这两者差别很大。知识是你知道 vllm 有个 scheduler技能是当vllm 新版本性能下降时你知道该去看哪几个指标、怎么回滚、怎么对比。知识是你知道 agent 有记忆模块技能是当agent execution terminated due to error时你能顺着调用链把问题定位到是工具调用超时还是上下文溢出。这篇内容就是奔着后者去的。适合谁看如果你刚开始接触vllm 部署大模型这里能帮你少走弯路如果你已经在写 agent但总觉得编排和记忆这块不踏实这里有你需要的结构如果你是被torch 安装折磨过的人那更对味了。我不假设你什么都会但也不打算把每个概念都从零讲一遍——该补的基础我会补重点放在那些真正卡人的地方。下面这张表是我对这四个方向的一个整体定位先给你一个全局感层级代表技术核心职责典型痛点推理引擎层vllm、sglang高吞吐模型推理、批处理调度版本性能波动、显存管理、调度逻辑框架底座层torch张量计算、GPU 加速、模型加载安装版本匹配、CUDA 兼容智能体层agent 框架任务编排、工具调用、记忆管理执行中断、上下文管理、安全工程落地层docker、镜像环境隔离、一键部署镜像是否带模型、版本选择这张表不是让你背的是让你在遇到问题时能快速判断“我现在卡在哪一层”。很多人排查半天没结果就是因为把工程层的问题当成模型层的问题在查。2. vllm 与 sglang推理引擎的调度逻辑和选型判断2.1 vllm 的 enginecore、scheduler、executor 到底怎么串起来热词里有一条特别具体vllm enginecore 与 scheduler、executor 交互流程。这个问题问到了 vllm 的骨架。我用大白话把它讲透因为理解了这条链路后面调优和排错才有方向。vllm 的核心设计是PagedAttention它把 KV Cache 像操作系统管理内存页一样分块管理。围绕这个设计整个推理流程被拆成几个角色。EngineCore是总指挥它持有模型、管理请求的生命周期。Scheduler是调度员决定每一轮哪些请求进入计算、哪些等待。Executor是干活的真正在 GPU 上执行前向计算。三者关系可以类比成餐厅EngineCore 是店长Scheduler 是领班安排哪桌先上菜Executor 是后厨真正炒菜。具体流程是这样的请求进来后先到 EngineCore它把请求交给 Scheduler。Scheduler 看当前显存里 KV Cache 的占用情况决定这一轮能塞进哪些请求——这就是所谓的continuous batching也是 vllm 吞吐高的关键。决定好之后Scheduler 把这一批的元信息交给 ExecutorExecutor 在 GPU 上跑完前向把生成的 token 返回。EngineCore 再判断请求是否结束没结束就回到 Scheduler 等下一轮。理解这条链路的价值在于当你遇到vllm 新版本性能下降你就知道该看哪里。可能是 Scheduler 的批处理策略变了可能是 Executor 的 kernel 实现换了也可能是 EngineCore 的请求管理逻辑调整了。我自己的习惯是升级 vllm 后先跑一个固定长度的压测对比吞吐tokens/s和首 token 延迟TTFT两个指标如果吞吐掉了但延迟没变大概率是调度或批处理的问题如果两个都掉可能是 kernel 或显存管理出了变化。提示不要只看总吞吐。把 TTFT 和 TPOT每 token 输出时间分开看才能判断是调度问题还是计算问题。2.2 sglang 和 vllm 的差异不是谁替代谁sglang 和 vllm经常被放在一起比。我的判断是它们不是替代关系而是针对不同场景的两种取向。vllm 更像通用推理服务器追求的是在广泛模型和请求模式下的稳定高吞吐。sglang 则在结构化生成和前缀复用上下了更多功夫它的 RadixAttention 对多轮对话、共享前缀的场景特别友好。举个实际场景如果你在做 agentagent 的每一轮调用往往带着很长的系统提示和工具定义这些前缀在多轮之间是重复的。sglang 的前缀缓存能直接命中省掉重复计算。而 vllm 虽然也有 prefix caching但在这种高度重复前缀的场景下sglang 的设计更贴合。反过来如果你只是单纯部署一个模型对外提供 API请求之间前缀差异大vllm 的通用性更省心。选型的时候我会问自己三个问题请求之间前缀重复度高不高是否需要复杂的结构化输出约束团队对哪个的运维更熟三个问题答完选型基本就清楚了。不要因为某个 benchmark 数字高就盲目切换迁移成本和稳定性风险往往比那点吞吐差异更值钱。2.3 部署实战docker 镜像、模型加载与版本选择热词里docker vllm/vllm-openai:v0.27.1 加载 qwen3-embedding-0.6b和docker 部署 vllm 模型教程出现频率很高说明这是大家真正在动手做的事。我把关键点讲清楚。第一个常见疑问vllm docker 镜像中带模型吗答案是不带。官方镜像只包含 vllm 和依赖模型需要你挂载进去或者运行时下载。所以正确的做法是把模型文件放在宿主机某个目录启动容器时用-v挂载然后通过--model参数指向容器内的路径。这样镜像可以复用模型可以独立管理。第二个问题是版本选择。热词里有人问glm5.3 使用 vllm 哪个版本的镜像这类问题的通用解法是先看模型官方文档推荐的 vllm 版本再看 vllm 的 release notes 里对应版本支持了哪些模型架构。新模型往往需要较新的 vllm但最新版又可能有性能波动所以我的策略是选模型官方验证过、且不是刚发布一两天的版本。稳定优先。启动命令的骨架大概是这样docker run --gpus all \ -v /your/models:/models \ -p 8000:8000 \ --shm-size 16g \ vllm/vllm-openai:v0.27.1 \ --model /models/Qwen3-Embedding-0.6B \ --served-model-name qwen3-embedding \ --max-model-len 8192这里有几个容易忽略的点。--shm-size一定要给够默认的共享内存太小会导致多进程通信出问题表现为莫名其妙的卡死。--max-model-len要根据实际需求设设太大浪费显存设太小长文本会被截断。还有--gpu-memory-utilization默认 0.9如果你的卡还要跑别的任务得调低。注意embedding 模型和生成模型的部署参数不一样。embedding 模型通常不需要那么大的 max-model-len但可能需要更高的并发--max-num-seqs可以适当调大。3. torch那个让人又爱又恨的底座3.1 安装 torch 为什么总是出问题torch 安装、pip3 install torch1.8.2 torchvision0.9.2 torchaudio0.8.2 --extra-index、安装 torch——这些热词背后是无数人的血泪。torch 安装出问题根子上是版本三角torch 版本、CUDA 版本、Python 版本三者必须匹配。任何一角不对就是各种报错。热词里有个很典型的报错d:\comfyui_image\python\lib\site-packages\torch\cuda\__init__.py:180: userwa。这个路径一看就是 Windows 上 ComfyUI 的内置 Python 环境。这类报错通常是 CUDA 初始化失败原因可能是驱动版本不够、CUDA runtime 和 torch 编译版本不匹配或者环境里装了 CPU 版的 torch。我的排查顺序是这样的先python -c import torch; print(torch.__version__, torch.version.cuda, torch.cuda.is_available())一行命令看清楚 torch 版本、它编译时用的 CUDA 版本、以及能不能用 GPU。如果cuda.is_available()是 False那问题就在驱动或版本匹配上不用往下查了。安装的时候不要直接pip install torch那样很可能装到 CPU 版或者和你的 CUDA 不匹配的版本。正确做法是去 torch 官网的安装选择器选好你的系统和 CUDA 版本它会给你一条带--index-url的命令。比如 CUDA 12.1 的pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu1213.2 版本匹配的实操判断法很多人问“我该装哪个版本的 torch”。这个问题没有统一答案但有一个判断流程。第一步看你的 GPU 驱动支持的最高 CUDA 版本用nvidia-smi右上角那个数字。第二步看你要用的框架比如 vllm、某个 agent 库要求什么 torch 版本。第三步在 torch 官网找同时满足前两个条件的版本。这里有个坑nvidia-smi显示的是驱动支持的最高CUDA 版本不是你必须用的版本。你可以装比它低的 CUDA 版本的 torch只要驱动够新就行。反过来装比它高的一定失败。所以驱动版本是上限不是目标。还有一个常见误区是 conda 和 pip 混用。conda 装的 torch 和 pip 装的 torch 可能来自不同渠道依赖解析结果不同混着用容易出现“明明装了却 import 不到”或者“版本对不上”的问题。我的建议是在一个环境里只用一种包管理器装 torch要么全 conda要么全 pip别混。3.3 torch 在 agent 和机器人场景里的延伸热词里有个挺有意思的mujoco torch 机械狗。这说明 torch 的用途早就超出了纯文本模型。在机器人、强化学习、物理仿真这些场景里torch 同样是底座。mujoco 做物理仿真torch 做策略网络两者结合做机械狗的控制这是很典型的具身智能技术栈。这类场景对 torch 的要求和纯推理不太一样。训练场景需要 autograd、优化器、分布式推理场景更看重算子融合和低精度支持。如果你是从纯 LLM 推理转到这类场景会发现很多在推理里不关心的东西比如梯度、混合精度训练的 scaler在这里是核心。技能树要相应扩展。4. Agent从框架选型到记忆与安全的完整链路4.1 agent 框架与编排别一上来就选最复杂的agent 框架、agent 框架与编排、agent 开发学习路线、agent for beginner——这些词说明很多人正站在 agent 开发的门口。我的建议很直接别一上来就上重型框架。先用最朴素的方式跑通一个 agent 循环理解它到底在干什么再去选框架。一个 agent 的本质循环其实很简单接收任务 → 模型思考 → 决定调用哪个工具 → 执行工具 → 把结果喂回模型 → 继续思考直到任务完成。这个循环用几十行代码就能写出来。热词里吴恩达 agent 教程之所以受欢迎就是因为它把这个循环讲得很清楚没有一上来就堆框架。理解了这个循环你再看各种 agent 框架就会发现它们无非是在几个维度上做增强编排怎么定义多步骤流程、工具管理怎么注册和调用工具、记忆怎么保存和检索历史、可观测性怎么调试和追踪。选框架的时候就看它在你这几个维度上的需求匹配度。我自己的经验是编排复杂度是最容易过度设计的地方。很多人一开始就搞很复杂的多 agent 协作、层级编排结果调试成本极高一个环节出错整条链都断。不如先用单 agent 加几个工具跑通确认价值后再逐步增加复杂度。热词里agent 开发案例和agent 项目值得多看但看的时候要关注它的编排是不是真的必要还是为了炫技。4.2 agent 记忆不是存得越多越好agent 记忆、a-memguard: a proactive defense framework for llm-based agent memory这两个词放在一起看很有意思。前者是需求后者是安全。agent 记忆的核心问题是上下文窗口有限但任务历史可能很长怎么取舍。常见的记忆方案有几类。短期记忆就是当前对话的上下文直接放在 prompt 里。长期记忆通常用向量数据库存需要时检索相关片段。摘要记忆是把历史压缩成摘要牺牲细节换空间。还有结构化记忆把关键信息抽成结构化字段存起来。我的实操心得是记忆的关键不是存而是检索和遗忘。存一堆东西但检索不准等于没存。遗忘机制也很重要过时的信息留在记忆里会干扰模型判断。热词里那个a-memguard提到的“主动防御”本质上是防止记忆被污染或注入恶意内容——这在 agent 安全里是个真问题因为记忆是 agent 的持久状态一旦被污染影响是长期的。具体做法上我会给记忆加来源标记和时效标记。每条记忆记录它来自哪次交互、什么时候产生的。检索时不仅看语义相似度还看时效和来源可信度。这样能过滤掉很多噪声。4.3 agent 执行中断与错误排查agent execution terminated due to error这个报错做过 agent 的人大概率都见过。它本身信息量很低因为它是顶层错误真正的原因被吞掉了。排查这类问题我的方法是分层定位。第一层看是模型调用出错还是工具调用出错。如果是模型 API 返回错误通常是限流、超时或上下文超长。如果是工具执行抛异常那要看具体工具的日志。第二层看是单次调用出错还是循环控制出错。agent 的循环如果没有正确的终止条件可能陷入死循环直到超时。第三层看是不是资源问题比如显存爆了、内存不够、并发太高。热词里codex无法发送消息显示更新 agent 沙盒这类问题往往和沙盒环境的网络或权限配置有关。agent 执行工具时如果被沙盒限制表现就是“发不出去”。这类问题要看沙盒的日志而不是 agent 本身的日志。提示给 agent 的每一步都加上结构化日志记录输入、输出、耗时、错误。出问题时这份日志比任何调试器都好用。4.4 agent 安全被低估的一环agent 安全这个词值得单独拎出来说。agent 和普通模型调用最大的区别是它能执行动作。模型说错话只是说错话agent 调错工具可能真的删了文件、发了请求、改了数据。所以 agent 的安全边界必须比模型更严。我的做法是三层防护。输入层做校验用户的指令不能直接变成危险操作。工具层做权限控制每个工具明确它能碰什么、不能碰什么危险操作要二次确认。输出层做审计所有执行过的动作都有记录可追溯。热词里提到的记忆防御也是其中一环因为记忆会影响 agent 的决策被污染的记忆会导致错误动作。还有一点容易被忽略agent 的权限应该最小化。不要给它一个万能的管理员 token而是按需分配、用完即收。这在多 agent 协作的场景里尤其重要一个 agent 被攻破不应该导致整个系统沦陷。5. 把这些技能串成一条可执行的成长路径5.1 不同起点的切入顺序技能整理到最后要落到“我该先学什么”。这取决于你的起点。如果你是算法背景熟悉 torch 和模型训练那你的短板可能在工程层优先补 docker、部署、推理引擎的调度逻辑。如果你是后端背景熟悉服务和部署那你的短板可能在模型层优先理解 torch 的推理流程和 vllm 的批处理机制。如果你是产品背景想转 agent那从 agent 循环和工具调用入手先跑通再深入。我给一个通用的切入顺序torch 基础 → 推理引擎vllm 或 sglang 选一个→ 部署工程 → agent 开发 → agent 安全与记忆。这个顺序的逻辑是自底向上每一层都建立在前一层之上。当然不是绝对的但按这个顺序走遇到的“看不懂”会少很多。热词里agent 开发学习路线和agent 学习路线出现多次说明大家很需要这个。我的路线建议是第一周跑通一个最小 agent第二周给它加工具和记忆第三周学部署和推理引擎第四周做安全和可观测性。四周下来你对整个链路会有实感比看一个月文档强。5.2 我踩过的几个典型坑第一个坑是过早优化推理引擎。刚开始做的时候我花了很多时间调 vllm 的参数想榨干每一滴性能结果发现瓶颈根本不在推理而在 agent 的编排逻辑和工具调用延迟上。后来我学乖了先用默认参数跑通用 profiling 找到真正的瓶颈再优化。第二个坑是torch 环境混用。我在一个环境里同时装了 conda 和 pip 的 torch结果 import 的时候加载的是错的那个报了一堆莫名其妙的 CUDA 错误。排查了大半天才发现是环境问题。从那以后我一个环境只用一种包管理器。第三个坑是agent 记忆无限增长。早期我没做记忆的淘汰机制跑久了记忆库越来越大检索越来越慢而且旧记忆干扰新决策。后来加了时效和容量限制效果立刻好转。记忆不是越多越好是要精准。第四个坑是忽略 shm-size。docker 部署 vllm 时没设--shm-size容器跑一会儿就卡死日志里也没什么明显错误。查了很久才知道是共享内存不够导致多进程通信失败。这个坑很隐蔽因为报错信息不直接指向原因。5.3 工具链的日常维护习惯最后分享几个我日常维护这套工具链的习惯。版本锁定所有关键依赖torch、vllm、sglang都记录确切版本升级前先在测试环境验证。压测基线维护一个固定的压测脚本每次升级后跑一遍对比吞吐和延迟有异常立刻回滚。日志集中推理引擎、agent、工具调用的日志统一收集出问题时能串起来看。镜像管理docker 镜像打标签时带上日期和版本别用 latest否则回滚时找不到对应版本。这些习惯看起来琐碎但真出事的时候它们能帮你把排查时间从几小时压到几分钟。AI Infra 和 agent 这个领域变化快新版本、新框架层出不穷唯一能让你稳住的就是这套工程习惯。技术会过时习惯不会。我个人在实际操作中的体会是这套东西没有“学完”的一天。vllm 会出新版本sglang 会加新特性agent 框架会迭代torch 会更新。重要的不是记住每个细节而是理解每一层的职责和它们之间的接口。理解了接口上层怎么变你都能快速接上。这份技能清单我会一直更新下去也建议你维护一份自己的——遇到问题记一笔解决完记一笔时间久了它就是你自己最值钱的文档。
