上周我把一套新的AI推理集群从开发环境往生产迁移。集群本身不复杂三台带GPU的机器装好驱动、起上容器就完事。但到了要写交接文档的时候我发现自己根本说不清楚这台机器上到底跑着什么服务。于是我把AI-Infra-Guard拉起来跑了一遍技能扫描。这工具的名字乍一听很唬人实际上做的事情很实在自动把你基础设施里跑着的AI组件、推理引擎、依赖服务全部盘一遍然后生成一张能力清单。我用Docker一键部署整个过程不到十分钟。真正让我想写下这篇文章的是后面那次漏报复盘——它差点让我把一套有问题的环境当成健康环境收进生产。1. 为什么要在这个时间点聊AI-Infra-Guard1.1 AI基础设施的“黑盒困境”做AI基础设施的人都有一种共同的焦虑堆栈越来越厚没人说得清“现在到底在跑什么”。应用层有推理服务中间层有向量库、消息队列、模型仓库底层还有GPU驱动、CUDA版本、容器运行时。任何一个环节版本不匹配线上推理效果就是玄学。我见过最典型的一个场景开发同学说“模型已经部署好了”但等你要上线的时候发现所谓的部署只是在一个临时容器里起来了容器一删什么都没了。另一类更隐蔽的情况是GPU节点上某个服务占着端口另一个服务悄悄绕过端口用了另外一套配置。这些东西如果不扫一遍靠人肉记忆根本没有办法。AI-Infra-Guard解决的正是这个问题。它把AI基础设施当作一个可以被探测、被盘点、被审计的对象通过主动扫描和Agent采集两种方式把节点上所有AI相关“技能点”捞出来形成一份可读性很强的报告。简单说它就是AI基础设施的“体检仪”。1.2 它和其他监控系统的区别很多人第一反应是Prometheus和NodeExporter不也能做吗能但那是两条路线。Prometheus系是“持续观测”它告诉你“现在CPU用了多少、内存还剩多少”它假设你已经知道要监控哪些目标然后给你画曲线。AI-Infra-Guard的核心思路是“发现与盘点”它回答的是“这台机器上有哪些AI能力、哪些组件、哪些服务在跑、它们的版本和状态是否正常”。两者不是替代关系而是互补关系——先用Guard扫一遍摸清家底再针对性上监控。这个定位决定了它的部署形态极其轻量。官方推荐Docker方式一个容器一个Compose文件一套配置起来就能用。不需要搭数据库集群不需要额外中间件这对大多数团队来说是非常友好的上手门槛。1.3 谁适合用这个方案我的判断是下面三类人最需要它刚接手一套AI环境的运维或平台工程师。接手第一天用它扫一遍比翻交接文档靠谱得多。准备从开发环境向生产环境迁移的研发团队。迁移之前扫一遍确认源环境里到底有多少隐藏服务防止“漏带”或“漏关”。做AI Infra交付的乙方或内部平台团队。交付验收时把扫描报告导出作为环境基线存档后面出问题对照排查效率极高。如果你只是在一台笔记本上跑个小demo那确实用不上。但只要你的环境里机器超过两台、服务超过五个扫描盘点带来的收益会非常明显。2. 用Docker部署AI-Infra-Guard的完整流程2.1 环境准备与配置选型先说硬件要求。我实测下来的结论是这个工具本身很省资源单节点部署2核4G内存的机器绰绰有余磁盘占用主要是存储扫描报告的Volume初期给10G就够。不过如果你要扫描的节点数量多、技能点密建议给宿主机留足网络带宽因为主动探测模式会并发发包。部署之前先把Docker装好。这块我踩过不少坑这里直接说结论Linux环境建议二进制安装官方版本不要用系统自带的旧版包Windows环境如果业务紧直接上Docker Desktop但如果是在内网服务器上我仍然推荐用Linux虚拟机装Docker Engine。无他稳定。有个细节值得单独提醒Docker版本不要太老。AI-Infra-Guard的Compose文件里用到了一些较新的配置字段比如init、platform默认的docker compose命令在1.29以上才可靠。加装docker-compose-plugin这个插件之后docker compose不带横杠也很好用。2.2 编写并启动Compose服务镜像拉下来之后核心工作就是写一份Compose配置。我直接给出我目前在用的版本经过多轮验证稳定复现无问题services: ai-infra-guard: image: ai-infra-guard:0.9.3 container_name: infra-guard-server restart: unless-stopped ports: - 8080:8080 volumes: - ./data:/app/data - ./config:/app/config environment: - TZAsia/Shanghai - GUARD_MODEhybrid - SCAN_CONCURRENCY30 - DB_TYPEsqlite init: true解释几个关键参数GUARD_MODEhybrid表示同时启用主动探测和Agent采集两种模式。如果你当前只有主动探测需求可以改成scanner-only。SCAN_CONCURRENCY30是并发探测数。这个值不是越大越好我实际测试中30是比较均衡的数值拉到50以上中小型环境的网关和交换机偶尔会出现ICMP限流。DB_TYPEsqlite是单机部署模式。如果你打算做成团队共享服务扫描量很大建议把存储切到PostgreSQL后面会单独说。启动命令很简单docker compose up -d第一次启动需要拉镜像和初始化数据库视网络情况等待一两分钟。之后访问http://服务器IP:8080就能看到控制台。如果页面打不开先用docker compose logs -f看日志90%的启动失败都在这里能直接找到原因。2.3 第一个扫描任务的正确打开方式部署成功之后别急着扫。先花五分钟做一件事在控制台的“节点管理”里把要扫描的目标机器加进去。支持两种方式一是IP直填二是网段扫描。我的习惯是优先用网段扫描比如192.168.10.0/24让工具自己发现存活节点。但这有个前提——目标机器的防火墙需要允许来自Guard容器IP的探测请求。很多人在这里被卡住明明配置都对扫描结果全是超时最后发现是目标机器的ufw或者firewalld把ICMP和TCP探测全拦了。第一次扫描跑起来之后不要急着看结果。等它跑完然后和你的已知环境清单做一次比对。如果扫描结果和你预期的完全一致说明环境正常如果多出几个服务别慌那很可能是一些常驻后台而你忘了记录的服务如果少了东西恭喜你你已经站在了和我一样的漏报复盘起点上。3. 技能扫描到底在扫什么3.1 探测原理主动发包与Agent采集双通道AI-Infra-Guard的扫描机制用一句话概括主动探测负责“看得见的”Agent采集负责“藏得深的”。主动探测模式是从Guard容器向目标节点发包尝试发现开放端口和指纹信息。它会识别常见AI组件端口比如vLLM的8000、Triton的8001、Milvus的19530、Redis的6379、MySQL的3306以及与Docker/容器运行时相关的2375等。指纹识别靠的是端口响应头的特征匹配比如某个端口返回的HTTP头带server: vllm字样就能标记为vLLM推理服务。Agent采集模式则需要在目标节点上装一个轻量采集器它会主动汇报GPU型号、驱动版本、CUDA版本、运行的容器列表、监听端口这些写在“机器内部”的信息。主动探测看不到的东西Agent都能看到。在实际部署中我建议混合模式同时开这样两边数据交叉印证准确率最高。3.2 技能点的分层归类“技能扫描”里的“技能点”是AI-Infra-Guard对扫描对象进行的抽象分类。大致分四层算力层GPU型号、数量、显存、驱动版本、CUDA版本、cuDNN版本。这一层是AI基础设施的地基版本不匹配会引发连锁问题。推理层vLLM、Triton、TensorRT-LLM、ONNX Runtime等服务。重点是服务的监听地址、端口、模型路径、并发配置。数据层向量数据库、关系数据库、缓存中间件、对象存储挂载。这些是AI应用的“记忆”和“弹药”。编排层Docker容器、K8s节点、任务调度系统。它们决定服务以什么方式跑起来、是否能自愈。每扫出一个技能点工具会标注它的状态正常、离线、版本异常、权限受限。你可以在界面上按状态筛选快速找到异常项。3.3 扫描结果的可信度边界必须把丑话说在前面扫描结果不等于环境全量真相。任何基于端口探测的技术手段都有两个天然盲区——第一服务只监听在127.0.0.1上外部探测根本看不到第二服务通过Unix Socket通信不走TCP端口。这两个盲区正是我那次漏报的根源。所以正确姿势不是“扫完就信”而是“扫完作为线索再人工确认关键资产”。扫描工具的效率价值在于把你需要确认的范围从几十台机器缩小到几个可疑点。越早建立这个认知越少踩坑。4. 一次完整的扫描实战记录4.1 实战环境三节点GPU推理集群我的目标环境是三台GPU服务器型号是双路至强配两张A800操作系统Ubuntu 22.04Docker跑容器化服务。这套环境准备承载一个开源模型的推理服务三台机器分别承担不同模型的推理任务。部署AI-Infra-Guard之前我凭记忆列了一份“预期清单”每台机器都有vLLM推理服务节点1带一个Milvus向量库节点2和节点3各有一个Redis实例全部由Docker Compose管理。这些信息来自开发团队的口头交接没有任何文档支撑。后来证明这份口头清单恰恰是我复盘时最有价值的对照物。4.2 配置扫描任务的关键参数在控制台新建扫描任务时有几个参数需要认真填直接决定扫描质量和速度。第一是并发数。按单节点扫描来说并发20到30足够如果扫描整个网段建议从15开始试稳定后再提高。第二是端口列表。默认列表覆盖了主流AI组件端口但如果你有自定义端口比如vLLM跑在8090而不是8000一定要在“自定义端口”里手动加。第三是超时阈值。默认是3秒我对内网环境会调到2秒加快扫描速度如果跨网段扫建议调到5秒避免误判。我这次的配置是目标三台机器并发20端口覆盖默认自定义8090、19531超时3秒。扫描任务从启动到出报告大约8分钟其中绝大部分时间花在端口指纹识别上。4.3 扫描报告的阅读姿势报告出来后我第一眼扫的是总览页节点三台、技能点总计二十多个大部分状态正常。但当我对照自己的预期清单时发现问题了——节点3的vLLM服务没有出现在技能点列表里。这就是我当时踩进的一个认知陷阱总览页显示一切正常以至于我差点直接导出报告当作环境基线。但我多留了个心眼打开节点3的详情页发现“推理服务”区域完全是空的。其他两个节点都有vLLM技能点唯独节点3缺失。我也顺手验证了界面上的其他信息GPU信息正常驱动版本正常容器运行时可见。整个节点看起来很健康唯独没有推理服务。和团队确认后得知节点3确实部署了模型推理。明明应该在却没扫出来——这是一个标准的漏报。5. 那次漏报以及我是怎么一步步排查的5.1 漏报现场还原漏报的直接表现是节点3上确实跑着vLLM且服务可用但AI-Infra-Guard的技能扫描结果里完全没有这条记录。端口扫描阶段节点的常见端口列表里没有8000也没有8090。也就是说探测流量根本没有找到这个服务。我第一反应是怀疑工具BUG。于是手动在Guard容器里执行探测命令确认端口确实不通。工具没毛病问题在环境本身。5.2 排查路径从容器网络到防火墙再到进程监听排查顺序按“由外到内”推进每一步都排除了一个假设。第一步检查Guard容器到节点3的网络连通性。ping 节点3IP通过说明网络层正常。第二步检查节点3的防火墙规则。Ubuntu环境ufw状态显示inactivefirewalld也没在跑。防火墙排除。第三步进入节点3检查vLLM进程监听状态。这一步直接看到根因ss -tlnp | grep vllm的结果显示vLLM监听在127.0.0.1:8000监听地址是回环地址外部发包自然进不来。第四步确认服务实际可用。在节点3本机执行推理请求响应正常。问题清楚了——服务可用但监听地址绑错了。5.3 根因监听地址绑定在回环接口上vLLM启动时默认绑定0.0.0.0但团队在调试时手动加了--host 127.0.0.1来避免测试请求暴露到局域网。后来把这个启动参数写成了systemd服务配置一直没改回来。于是生产验证的时候服务“看起来在跑”实际上被锁死在本地。这类问题在AI基础设施里非常典型尤其常见于一个服务先在开发环境调试再被“原样打包”到生产的场景。监听地址、模型路径、并发参数里藏着大量为了调试方便而留下的非生产配置。修复方式很简单把启动参数里的host改成0.0.0.0重启服务重新扫描vLLM技能点立刻出现了。但这次漏报留下的启示远比修复本身重要。5.4 复盘出来的三条规则第一条技能扫描漏报时优先怀疑服务监听地址而不是扫描工具失效。回环绑定是最常见的漏报根因。第二条扫描报告不能只读总览必须和已知清单逐项核对。总览页的健康状态是“按已发现对象计算”的根本不会知道你漏了哪些对象。第三条每次环境变更之后都要跑一次基线扫描。这次漏报之所以有惊无险是因为我在迁移前做了对照此后我养成了习惯每周扫一次变更后必扫一次。6. 常见问题速查与避坑心得6.1 部署与扫描问题速查表现象可能原因解决办法容器启动后Web界面无法访问端口映射未生效或防火墙拦截检查docker compose ps确认8080映射宿主机防火墙放行端口扫描结果全是超时目标机防火墙拦截探测流量在目标机放行Guard容器所在网段的ICMP和TCP探测端口部分技能点未识别自定义端口没添加在扫描任务中手动补充自定义端口和相关指纹规则监听在127.0.0.1的服务漏报服务绑定回环地址外部探测不可见修改服务监听地址为0.0.0.0或改用Agent采集模式扫描速度过慢并发数设置过低适当调高SCAN_CONCURRENCY同时关注网关限流数据量增长快磁盘告急SQLite模式存储膨胀定期清理历史扫描任务或迁移到PostgreSQL6.2 关于并发数的一个真实体会有朋友问我为什么强调并发不是越高越好。我做过一次对比实验同一网段扫描并发调到50时扫描时间确实从8分钟缩短到5分钟但节点上某个网络监控服务开始报警说探测流量太密集。这说明并发过高会干扰业务网络。稳妥方案是“从低到高慢慢试”找到你的网络环境能承受的上限然后保留30%余量。6.3 扫描周期怎么定才合理经常有人问多久扫一次。我的建议是稳定环境一周一次基线扫描变更频繁的环境每24小时一次。扫描频率不是越高越好扫描本身会消耗网络资源。但AI基础设施最怕的是“没人知道环境变成什么样了”所以宁可多扫几次也不能让它变成一次性工具。我个人实际操作中还有一个小技巧每次扫描报告出来之后手动复制一份到变更记录里标注“本次扫描前/后的差异”。这样两三次之后你会掌握一套非常完整的环境演进轨迹排障时价值不可估量。这个习惯是我踩完漏报的坑之后养成的现在分享给你希望你不用像我一样靠一次意外来长记性。
