企业官网建设流程全解析

1. 先把交付物这事说清楚：AI运维和传统运维到底差在哪

这两年"AI运维"这个词被炒得很热，各种大会、岗位、工具链都在讲。但说句实话，很多团队喊着要做AI运维，实际上连自己的交付物是什么都说不清楚。你去问一个运维负责人：这个季度你交付了什么？他大概率会答：算力指标、告警闭环、服务可用性。这些答案对吗？对，但它是传统运维的答案，不是AI运维的答案。

我自己的理解是，AI运维的交付物不能用"可用性"这一个维度来概括。传统应用运维，交付的是服务可用性：请求能通、数据库能连、磁盘没满，基本就达标了。但AI业务不一样，模型推理慢一百毫秒，用户体验就是断崖式下跌；向量召回率掉了三个百分点，RAG问答就开始胡言乱语；算力资源被某个任务吃光了，其他团队的实验就得排队等两天。这些都不是"挂了"或者"没挂"的问题，而是"效果够不够好""资源够不够省""过程能不能被理解"的问题。

所以这篇文章我想把AI运维的交付物拆开揉碎讲一遍。按照当前生产环境里的实际分工，我会重点说四块：算力环境、推理服务、检索基础设施、智能体运维。每块我都会讲清楚它到底交付什么、怎么验收、坑在哪里。适合谁看？适合已经从传统运维转到AI业务的同学，也适合正在搭平台、写SOP的团队负责人。这篇文章不会给你一个万能答案，但能帮你把"交付物"这三个字落到实处。

2. 算力环境：一张卡只是起点，三层协议栈才算交付

2.1 算力环境的第一个误区：以为买了卡就完事了

很多团队规划算力环境的时候，第一反应是预算和采购：买多少张卡、什么型号、多少显存。这当然很重要，但算力环境作为运维交付物，远远不是"有一批可用GPU"那么轻巧。

我比较喜欢用一个三层协议栈的模型来理解算力环境：最底下是硬件层，包含GPU型号、显存容量、卡间互联拓扑；中间是系统层，包含驱动版本、CUDA运行库、容器运行时、健康检查机制；最上面是调度层，包含资源池划分、限额、优先级、抢占策略。运维要交付的，不是某一层，而是这三层叠加之后形成的"算力抽象"——业务方只需要告诉平台我要多少卡、要什么型号、要跑多久，平台保证分配、隔离和故障自愈，业务不用关心卡在哪台物理机上。

大多数踩坑案例都出在把这三层混为一谈。比如采购时只看了单卡算力，没看卡间互联拓扑。结果训练框架跑起来，多卡通信效率只有理论值的六成，本来预期的加速比完全没达到。再比如系统层驱动版本和业务镜像里的CUDA版本不兼容，容器一启动就报错，排了半天发现是主机驱动太旧。这些问题在传统运维里几乎不会遇到，因为你顶多处理"CPU指令集不兼容"，而现在你要管理的是整个异构算力生态，每一层都有自己的兼容性矩阵。

2.2 硬件层交付：拓扑感知是AI运维的基本功

硬件层的交付物不只是一份资产台账，更是一份拓扑感知图。怎么理解？现代训练任务大多是分布式多卡并行，卡和卡之间的通信带宽直接影响训练效率。像NVLink这种高速互联，和走PCIe总线的通信，延迟和带宽差一个数量级。如果平台在分配资源的时候，把任务的两个worker分到不同物理机上、只能走万兆网络通信，那即便每张卡的算力都一样，训练效率也会明显下滑。

所以做算力环境交付的时候，我建议至少把以下几个信息建模到资源平台里：卡型号、显存大小、驱动兼容范围、所在物理机、卡间互联类型（是NVLink还是普通PCIe）、跨机网络带宽。调度器分配任务时，优先保证同一任务的卡在拓扑上靠近，这是AI算力环境跟传统虚机环境最大的区别——传统环境里CPU和内存是"同质资源"，而算力环境里的卡不是同质的，位置不同，性能差异巨大。

另外，异构卡混用是一个早晚要面对的问题。不同代的卡元件混在一个资源池里，驱动版本和算力特性可能不一致。我见过不少团队早期因为卡不够，把几款不同代际的卡混在一个队列里，结果同一个推理服务今天跑在A卡上，明天被调度到B卡上，延迟和显存行为都不一样，给容量评估带来了很多干扰。如果条件允许，最好在调度层面做卡型亲和性，至少要把"同型号同代际"作为默认策略，否则后面排查性能问题时你会疯掉的。

2.3 系统层交付：驱动、运行时和健康检查的工程化

系统层是传统运维同学最熟悉的领域，但AI场景下它的交付标准更苛刻。一个常见的问题是驱动和CUDA版本的管理。生产环境里的业务镜像五花八门，有的基于CUDA 11.8，有的基于CUDA 12.1，如果主机驱动太老，新镜像根本跑不起来。我的建议是：尽早把驱动版本和允许的CUDA版本范围纳入资源标签，调度器在调度容器时先做兼容性匹配，而不是等容器启动失败再人工介入。

健康检查也得重新设计。传统主机的健康检查看CPU负载、内存占用、磁盘IO就够了，但GPU的"亚健康"状态很难被CPU指标反映出来。比如显存ECC错误持续累积、卡温度偏高导致降频运行、NVLink链路带宽衰减，这些故障不会让机器从平台里掉线，但会让业务性能打折。所以系统层的交付物里，除了基础监控，至少还要包含：GPU健康状态巡检脚本、ECC错误计数、降频事件记录、以及定期的算力基准测试。

我习惯在新卡交付上线前跑一遍标准benchmark（比如算力测试和通信延迟测试），把基线记录存档。这样某天业务反馈"训练变慢了"，运维可以直接拿当前数据和基线比对，快速判断是卡本身衰减了，还是任务竞争导致的。很多时候，这种基线数据比一堆监控图表都管用。

2.4 调度层交付：配额、限额和"防贪吃"机制

调度层往往是算力环境满天飞的时候才被重视的。业务团队一多，大家都在排队要卡，如果没有配额和优先级机制，资源池很快就会变成丛林法则——谁嗓门大谁用得多。作为交付物，调度层必须提供几个硬能力：资源配额（每个团队能申请多少卡）、抢占策略（高优任务能否抢占低优任务的资源）、以及防贪吃机制（单个任务最多能占多少资源，防止一个实验把集群都吃光）。

这些能力里，防贪吃最容易被忽略。有一次我们一个同事调试数据并行代码，batch size配错了，显存直接被打满，调度器一看还有空余就继续往上堆，最后整个节点的任务都被拖垮了。所以我现在做算力平台，一直把"单任务资源上限"当成默认配置来要求，哪怕业务方觉得配额够用，也要设一个兜底上限。真正的算力环境交付，不只是给用户一张卡，而是给他一整套"有边界、可预期、能隔离"的资源使用规则，这才是运维的价值所在。

3. 推理服务：交付的不是"能访问"，而是"性能曲线和降级路径"

3.1 推理服务的交付物为什么不能用"可用性"衡量

推理服务是AI业务直接对外的入口，它的交付物定义得清不清楚，直接影响用户体感。传统Web服务，只要接口平均响应时间在几百毫秒内、错误率低于阈值，一般就算健康。但大模型推理服务不一样，它的性能是非线性的：请求一多、并发一高，首token延迟可能从300毫秒直接飙升到3秒，而且这不是靠加机器就能简单解决的，因为模型推理的推理计算量和显存带宽约束摆在那里。

所以在我看来，推理服务要交付的东西，是一次完整的性能画像：在什么样的并发下、什么样的输入输出长度下、能达到什么水平的延迟和吞吐。它不是一部署就完事的，而是经过压测得到一条性能曲线，并且把这条曲线作为容量规划和告警阈值的依据。生产环境里没有这条曲线，你就没法回答"要不要扩容""什么时候扩容""降级到哪个模型能扛住流量"这些问题。

3.2 推理引擎选型：vLLM、TGI、SGLang和TensorRT-LLM的实际差异

选推理引擎这件事，有点像传统运维选Web服务器，但影响要大得多。核心区别在于引擎对批处理和显存的利用方式。比如vLLM主打的PagedAttention，把KV Cache分页管理，显存利用率高，动态批处理能力强，是目前生产环境里用得最多、社区最活跃的选项之一。TGI是Hugging Face出的，跟transformers生态衔接好，但灵活性和性能调优空间目前看略逊一筹。SGLang则是在结构化生成和复杂控制流上有优势，适合工具调用和智能体场景。TensorRT-LLM性能上限高，但工程成本也高，一般适合流量超大、性能要求极其苛刻、且有专人投入的场景。

选型时我给一个非常务实的建议：先用社区活跃度最高的方案做基线，跑通业务后再考虑要不要为极致性能迁移。因为推理引擎的坑大多不在你选的框架本身，而在你的业务特征——比如超长上下文的KV Cache管理、流式输出的连接断开处理、多副本间的负载均衡。这些问题是所有引擎都要面对的，只是表现形式不同。别为了10%的性能提升，把整个团队的排查经验清零，那是亏本买卖。

3.3 压测和容量评估：从三维度画性能曲线

推理服务的压测和传统压测也完全不是一回事。传统压测关注的是QPS和响应时间，但推理压测至少要控制三个维度：请求并发数、输入输出token长度、模型参数量/量化级别。同样一个模型，上下文很短和上下文超长时，性能差距可能是好几倍。所以压测必须分场景跑，把典型业务的长短分布都覆盖到，而不是只跑一个"平均请求"。

我记得有一次给一个RAG服务的推理做容量规划，只看平均QPS结果，感觉能扛500并发。后来把知识库的上下文长度都压到真实业务的分布里再测，发现用户一旦追问多轮，上下文膨胀后，显存和延迟都扛不住，60并发就开始明显劣化。那次之后我就把压测报告里加了一个"上下文长度敏感性"的维度，每次上线前必跑。这个习惯帮我们在早期避免过好几次容量误判。

3.4 降级路径：推理服务里最容易被忽视的交付物

推理服务还有一个传统服务不太需要考虑的交付物：降级路径。传统Web服务降级，通常是切流量到备用机房。但AI推理服务降级，至少要提前定义好三件事：第一，模型降级——主模型扛不住的时候，是否切到更小、更快的备用模型，效果损失多少要提前评估；第二，量化降级——是否把模型临时切成int8或更低精度，换取更高的吞吐；第三，超参降级——是否降低生成长度上限、关闭某些代价高的能力（比如联网检索、复杂工具调用），来降低单请求的资源消耗。

这三条路径都不是上线后再拍的，而是要提前做小流量验证，把效果损失和性能收益都量化出来。等到线上真的出问题再临时决策，基本只能靠拍脑袋。另外要提醒一句：给推理服务配的告警，别用传统"错误率+延迟"这一套就完了，至少要加上排队等待时间、首token延迟、吞吐变化趋势这些AI场景特有的指标。尤其是排队等待时间，它往往是最早暴露容量问题的信号，但传统监控体系里很少有人看它。

4. 检索基础设施：最容易背锅的一层，交付物是检索质量

4.1 为什么RAG时代的检索设施成了基础设施

RAG（检索增强生成）架构现在几乎是大模型应用的标准配置，但运维视角下它有个很尴尬的位置：它不直接对用户输出结果，却深刻影响最终输出质量。用户问了个问题，模型答得很差，业务方第一个想到的是模型不行，但排查到最后经常发现是检索没召回到正确的内容。这个锅，通常是运维和平台团队背，因为检索系统是你维护的。所以我把检索基础设施单独拎出来讲，因为它既像中间件又不像中间件——你要维护的不仅是系统的稳定性，还有检索效果本身。

检索基础设施的交付物，我认为可以归纳成四个字：检索质量。具体拆开就是召回率、命中率、端到端检索延迟、索引数据的时效性。这四个指标里，前两个决定了RAG效果的上限，后两个决定了用户体验的下限。传统ES运维只要保证集群不挂、查询能返回就够了，但在AI场景里，你可能还要回答"为什么这个query没召回相关内容"这样的问题——那就要求你的检索链路有足够的可观测性。

4.2 数据切分和向量化的工程细节

检索基础设施的运维，很难绕过两个环节：文档切分和向量化。切分策略直接决定召回效果——切得太粗，单个文本块包含太多不相关的内容，向量表示被稀释；切得太细，又容易丢失上下文，语义信息不完整。这块没有银弹，只能按业务类型反复试。比如知识库问答通常按语义块切分，代码库检索则可能按函数级别切分更有效。

向量化也不是一劳永逸的。Embedding模型会升级，升级后同一段文本的向量表示变了，如果没做对齐，新旧向量混在一个索引里，检索效果就会出现诡异变化。我建议把所有文档的向量化版本号作为元数据管理，一旦上线新的Embedding模型，就要全量重建索引，并且做好A/B对比验证——召回率不能降，这是底线。这些工作看起来琐碎，但它们恰恰是检索基础设施作为"交付物"区别于"临时工具"的标志。

4.3 向量库选型：从Milvus到pgvector，怎么选才不后悔

向量数据库的选型是个大话题，我只能聊聊运维视角的核心判断。专业的向量数据库（比如Milvus、Qdrant）功能全、性能好、支持分布式，适合数据量大、QPS高的独立场景，但运维成本和架构复杂度也高。传统检索引擎（比如ES）通过插件支持向量检索，胜在复用已有技术栈，如果你团队本来就是ES维护的主力，过渡成本低。关系数据库加插件（比如pgvector）适合数据量中等、团队不想引入新组件的场景。云托管的向量数据库则适合不想自己运维的团队，但要注意厂商绑定和数据迁移成本。

我给团队的建议是：别一上来就选最专业的分布式向量库。先把数据规模和对延迟的要求摸清楚，几百GB以内、QPS不高的话，pgvector这类方案完全能扛，运维成本低一个量级。等业务真的涨到需要水平扩展了，再考虑迁移。这里有一个很现实的问题：向量数据库虽然是AI技术栈的一部分，但它的运维模型还是数据库运维，你要管索引、管备份、管扩容，这些能力在传统数据库团队里是现成的，完全可以复用。

4.4 增量更新、索引一致性和检索链路的可观测性

检索基础设施在运维上有一个很麻烦的点：数据是动态的。知识库每天都在更新，新文档进来要切分、向量化、写入索引，还要处理删除和修改的文档，保证检索结果不会过期。这里最容易出问题的是增量和全量索引之间的状态一致性。我见过不少事故，都是增量任务悄悄失败，老索引还在正常服务，业务方面以为知识库更新了，用户却一直检索不到新内容。

所以做检索基础设施交付，一定要把"索引新鲜度"作为核心监控指标。每次增量同步任务执行完，对账一下索引里最新文档条数和源库是否一致，不一致就直接告警。检索链路的可观测性方面，建议至少把请求的完整链路trace起来：query进来后走了哪个切分器、命中哪个索引分片、召回了哪些文档、重排序后选了什么内容给模型。有了这条链路，你才能在上游"答错了"的时候快速定位是不是检索环节出了问题，不然每次都得业务方拿用户问题来反推，效率极低。

5. 智能体运维：交付的是"能被看懂的过程"和安全护栏

5.1 智能体不是单体服务：运维对象的形态变了

智能体（Agent）运维是目前最让人头疼的部分，原因是它的形态和传统服务完全不一样。传统服务是无状态的、请求响应式的，你只要保证进程活着、能处理请求就行。但一个智能体是一个有状态的、自主决策的复合系统，它由大模型驱动，会调用外部工具，会在多轮循环里逐步完成一个复杂任务。它的生命周期不是"请求进来、结果出去"这么简单，而是"任务启动、规划、调用工具、观察结果、再规划、直到完成或放弃"。

这就给运维带来了两个问题：第一，智能体的运行状态不是靠看CPU和内存就能理解的，你得看它的决策轨迹；第二，智能体做的事情有时候连设计者都不能完全预测，这和你部署一个预先定义好的微服务完全不同。所以智能体运维的交付物，在我看来不是"服务的可用性"，而是"任务执行过程的可观测性"和"风险的可控性"。前者让你能看懂它在干什么，后者让你能随时按住它不要乱来。

5.2 智能体运维的关键指标：从循环次数到人工介入率

那么智能体运维到底该盯哪些指标？我自己在实践中排序是：任务完成率、工具调用成功率、平均循环次数、人工介入率、单任务资源消耗。任务完成率是最终效果指标，但这个指标要结合工具调用成功率一起看，因为智能体大量工作是通过工具完成的，工具老失败，任务不可能完成好。平均循环次数则反映智能体的执行效率，一个任务如果循环了20次、调用了10次工具还结束不了，多半是规划逻辑有问题或者在原地打转。

人工介入率这个指标，最容易被忽略，但其实最关键。智能体在什么情况下会被转给人工处理？是权限不足、风险不可控还是能力不够？这些"人类接管点"的数据，是优化智能体最重要的一手资料。另外，单任务资源消耗也要记：一个智能体任务吃掉多少token、多少次模型调用、多少算力，这些都要计入成本。很多团队用了智能体感觉很酷，月底一看模型账单吓一跳，就是因为这个指标从一开始就没纳入交付物体系。

5.3 可观测性：让"非确定性"变回"可追踪"

智能体最让运维崩溃的性质是非确定性——同样的输入，两次运行的任务轨迹可能完全不一样。这就意味着你不能靠传统日志来复现问题，因为你根本没法保证能复现。所以我做智能体观测的第一条原则就是：把每一次任务的完整决策轨迹落下来，包括模型输入输出、各项工具调用的参数和结果、每一步的推理摘要、以及状态流转记录。为此必须保证每条trace都带上全局任务ID，模型环节、工具环节、状态存储环节都通过这个ID串联起来。

有了任务ID之后，按任务回放整个执行过程，排查效率就高多了。比如一个任务失败，你可以直接看到它在第几步开始偏离预期，是模型理解出了问题，还是工具返回了异常数据，又或者是某一步的上下文丢失导致状态错乱。这套能力和传统APM在理念上一脉相承，但对象从"请求"变成了"任务"，从"接口"变成了"决策步骤"——这个转变要花不少功夫，但它是智能体运维的核心基本功，绕不过去。没有这套东西，智能体数量一多，你基本就被困在"用户说它不对、但你不知道哪里不对"的泥潭里。

5.4 安全护栏：超时、预算、权限和"一键熔断"

智能体运维里最要命的还不是技术问题，而是失控问题。一个自主决策的系统，如果权限给大了、循环没有上限、预算不做控制，它完全可能在无人值守时把事情搞得很离谱。所以智能体运维的交付物里，安全护栏是硬性的。

我给自己定了几个默认配置：第一，所有智能体任务必须有最大循环次数，默认15轮，超过就强制终止并告警；第二，所有工具调用必须有预算上限，按任务维度记账，超了就降级或者人工审批；第三，文件读写、网络请求、数据删除这类高风险操作默认进审批，不做成"全自动"；第四，提供一键熔断能力，从平台层面可以直接终止某个智能体的执行，并撤销它已经申请的临时凭证。这些能力听着不复杂，但在系统层面提前做成可配置项，和事后再补完全两回事。尤其要注意临时凭证的回收——智能体调云API、连数据库都要短时凭证，任务结束了凭证没回收，那才是真的后患。

说到身份和权限，再补充一句：智能体调外部系统的账号绝对不能是通用管理员账号，最好是独立的、最小权限的、可审计的。每条任务的调用记录都要能追溯到具体是哪次任务在什么时间、以什么身份做了什么操作。智能体越是"自主"，你的审计链路就越要"被动完整"，这一组矛盾会长期存在，运维的职责就是把这个闭环焊死。

6. 四个交付物的验收维度：一张表看懂边界

上面讲的四块内容，如果汇聚成一张验收对比表，会清晰很多：

这张表还说明了一个问题：AI运维的交付物从来不是"部署了什么系统"，而是"这个系统在真实负载下表现如何、出了状况是否可控、成本和效果能不能算清楚"。这四件事里的每一件，都是传统运维能力的延伸，而不是推倒重来。换句话讲，之前做监控、做部署、做容量规划的经验，在AI运维里全部有效，只是评估的坐标系变了——你关心的指标从"服务有没有挂"变成了"效果好不好、成本高不高、过程能不能被理解"。

7. 最后聊聊我对这个岗位的体会

做AI运维这几年，我最大的感受是：这个岗位的交付物，本质上是在回答三个问题——效果能不能稳定复现，成本能不能被约束，过程能不能被解释。很多团队纠结于买了多少卡、接了多少模型，这些当然重要，但真正让AI业务往前走的，是"业务方什么时候敢信这个系统、出了问题多久能定位、资源投入产出比能不能算清楚"。

如果你正在从传统运维往AI运维转，我建议你从最基础的事情做起：把自己负责的每一条链路都画出完整的数据流向，然后把每一次"性能异常"和"效果波动"都记录下来，积累成自己的基线库。多记几次，你对AI系统的体感和直觉就建立起来了，再看那些花里胡哨的平台和工具，你的判断力会完全不同。

最后再分享一个实际操作中的小技巧：每天花十分钟看一下推理服务的基础数据曲线，再对照一下当天的业务效果反馈。你会发现，很多模型效果的投诉其实早在三天前的延迟和检索命中率曲线里就有征兆了。先把这条联动关系看懂，你就已经比大多数被动救火的运维团队往前走了一大步。