企业官网建设流程全解析

上周我把一套新的AI推理集群从开发环境往生产迁移。集群本身不复杂，三台带GPU的机器，装好驱动、起上容器就完事。但到了要写交接文档的时候，我发现自己根本说不清楚这台机器上到底跑着什么服务。于是我把AI-Infra-Guard拉起来跑了一遍技能扫描。这工具的名字乍一听很唬人，实际上做的事情很实在：自动把你基础设施里跑着的AI组件、推理引擎、依赖服务全部盘一遍，然后生成一张能力清单。我用Docker一键部署，整个过程不到十分钟。真正让我想写下这篇文章的，是后面那次漏报复盘——它差点让我把一套有问题的环境当成健康环境收进生产。

1. 为什么要在这个时间点聊AI-Infra-Guard

1.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: - TZ=Asia/Shanghai - GUARD_MODE=hybrid - SCAN_CONCURRENCY=30 - DB_TYPE=sqlite init: true

解释几个关键参数：

• GUARD_MODE=hybrid表示同时启用主动探测和Agent采集两种模式。如果你当前只有主动探测需求，可以改成scanner-only。
• SCAN_CONCURRENCY=30是并发探测数。这个值不是越大越好，我实际测试中，30是比较均衡的数值；拉到50以上，中小型环境的网关和交换机偶尔会出现ICMP限流。
• DB_TYPE=sqlite是单机部署模式。如果你打算做成团队共享服务，扫描量很大，建议把存储切到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.04，Docker跑容器化服务。这套环境准备承载一个开源模型的推理服务，三台机器分别承担不同模型的推理任务。

部署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状态显示inactive，firewalld也没在跑。防火墙排除。

第三步，进入节点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 部署与扫描问题速查表

6.2 关于并发数的一个真实体会

有朋友问我为什么强调并发不是越高越好。我做过一次对比实验：同一网段扫描，并发调到50时扫描时间确实从8分钟缩短到5分钟，但节点上某个网络监控服务开始报警，说探测流量太密集。这说明并发过高会干扰业务网络。稳妥方案是“从低到高慢慢试”，找到你的网络环境能承受的上限，然后保留30%余量。

6.3 扫描周期怎么定才合理

经常有人问多久扫一次。我的建议是：稳定环境一周一次基线扫描，变更频繁的环境每24小时一次。扫描频率不是越高越好，扫描本身会消耗网络资源。但AI基础设施最怕的是“没人知道环境变成什么样了”，所以宁可多扫几次，也不能让它变成一次性工具。

我个人实际操作中还有一个小技巧：每次扫描报告出来之后，手动复制一份到变更记录里，标注“本次扫描前/后的差异”。这样两三次之后，你会掌握一套非常完整的环境演进轨迹，排障时价值不可估量。这个习惯是我踩完漏报的坑之后养成的，现在分享给你，希望你不用像我一样靠一次意外来长记性。