企业官网建设流程全解析

1. 别再把AI Infra当成机房：全景分层和边界感

1.1 一个真实的线上故障：延迟突刺到底是谁的锅

上个月我陪一位做企业知识库的朋友排查线上故障，他们基于RAG（检索增强生成）做的问答服务，在晚高峰的P95延迟从2秒一下子飙到7秒。业务方的第一反应是模型太慢，催着模型组换大参数模型；模型组测了半天说单次推理耗时没有明显变化，觉得是向量数据库召回阶段出了问题；向量库的运维又甩锅给网络带宽，说跨可用区的流量有抖动。层层踢皮球之后，我们花了整整一个下午把链路拆开，最后发现真正的根因是一台GPU节点上显存碎片化严重，导致推理引擎无法把小的预填充请求合并成连续批次，批处理吞吐直接塌了一半。

这件事让我特别有感触：当你的业务跑在模型之上时，你调的已经不只是一个模型服务，而是一整套AI基础设施（AI Infra）——从底层的算力底座到上层的智能应用之间，每一层都可能成为瓶颈，也都可能成为撬动性能的杠杆。过去我们说“调服务”，现在其实是在“调一套基础设施”。

这也是我想把这篇文章写给两类人的原因。一类是刚接触AI项目的开发者，手里有一个Agent或RAG应用的想法，但对从GPU到应用之间到底发生了什么只有模糊概念；另一类是有一定经验的技术负责人，可能已经在用Kubernetes跑模型推理，但希望把碎片化的认知整理成一套能落地的框架。下面我会沿着“算力底座→调度管理→模型服务→智能应用→安全防护”这条链路，把关键选型、踩坑经验和设计思路一次讲透。

1.2 AI Infra的横向切面：从GPU到Agent中间有几层

很多人一听到AI Infra就想到机房、机柜、服务器，认为这是运维和硬件工程师的活。这是一种非常普遍的误解。实际上，AI Infra是横跨硬件、系统软件、平台工程和应用框架的综合性领域，它更像是一层一层的“堆栈”，每一层都在向上层屏蔽复杂性。

从我的视角看，一个完整的AI Infra至少包含六个横向层次：

• 物理算力层：GPU、CPU、NPU、内存、高速网络、并行存储等物理资源；
• 虚拟化与资源池化层：GPU驱动、容器运行时、设备插件、CUDA/ROCm等软件栈，把物理算力切成可分配的资源单位；
• 编排调度层：把GPU、内存、存储通过Kubernetes、Slurm、Volcano等平台编排成可对外提供服务的动态资源池；
• 模型服务层：负责模型推理、微调、蒸馏等模型任务的执行，包括vLLM、TensorRT-LLM、Triton、Ray等推理和训练引擎；
• 数据与模型管理层：数据集版本、向量索引、模型仓库、特征存储、实验追踪，保证AI的“生产原料”可信可追溯；
• 应用与智能体层：Agent框架、工具调用协议、记忆存储、人与模型交互的接口，也就是业务真正可感知的“智能”。

你可以把这个结构想象成城市交通系统。物理算力层是道路和桥梁，资源池化层是交通信号灯和收费系统，调度层是导航和应急调度中心，模型服务层是公交和地铁线路，数据管理层是地图和路况数据，智能应用层则是你手机上最终展示的导航结果。没有道路，一切都空谈；但光修路不建调度系统，城市照样瘫痪。AI Infra的“桥梁”意义正在于此：它把最底层的原始算力，转化为上层应用可以直接引用的智能能力。

1.3 “桥梁”和“底座”的区别：为什么这个词不是玩概念

标题里用了“技术桥梁”而不是“算力底座”，是有意为之。底座是静态的，桥梁是动态的；底座强调的是承载，桥梁强调的是连接和转换。一个GPU集群堆在那里只是潜在的算力，只有通过调度、服务化、API化之后到达应用手里，它才变成真正的生产力。AI Infra就是完成这个“转换”的关键环节。

举一个很直接的例子：现在很多创业团队用开源模型做垂直场景的Agent，他们并不需要拥有自己的GPU集群，只使用云厂商的模型服务，通过API调用就能完成业务流程。表面上这跟Infra没关系，实际上从模型路由、上下文管理、工具调用鉴权到用量的配额控制，全部是Infra能力在支撑。再往深一层，如果某个Agent应用需要低延迟、专属部署，那就要考虑GPU实例规格、推理引擎选型、自动扩缩容策略，这些就是AI Infra的核心工作。总而言之，AI Infra不是某一个具体的硬件或软件，而是一整套从“算力”到“智能”的转换体系。

理解这一点之后再去看后面的章节，你会更容易发现：每一个我们视为理所当然的“智能应用”，背后都有无数个基础设施决策在支撑。

2. 算力底座的真实博弈：GPU、互联和存储怎么选

2.1 算力密度的三个层次：单卡、多卡和分布式集群

算力底座是AI Infra中最看得见摸得着的一部分，但也是最容易被消费主义带偏的：一说做大模型就恨不得上几百张卡。真实世界里的算力选型，需要根据工作负载的规模和性质分三个层次来看。

第一层是单卡推理与微调。如果一个7B参数模型用BF16精度部署，权重大约占14GB显存，那么一张24GB显存的消费级显卡就能跑起来，加上KV Cache之后可能有点紧，但用FP16或AWQ 4-bit量化后就宽裕得多。个人开发者做RAG小应用、工具调用Agent的验证，单卡甚至纯CPU推理都是可接受的起点。我自己的经验是：起步阶段不要追求大集群，先用一张卡把模型跑通，理解推理引擎的参数含义，这比盲目上规模有价值得多。

第二层是单机多卡。当模型参数达到30B以上，或者并发推理需要更大吞吐时，单卡就不够了。比如用两到四张卡做张量并行（Tensor Parallelism），把Transformer的矩阵乘法切到多张卡上并行计算。这里有一个新手经常忽略的地方：张量并行的效率极度依赖卡间互联带宽。把4张卡插在通过PCIe Switch连接的主板上和插在NVLink全互联的主板上，吞吐差距可以到30%以上。所以多卡环境下，互联方案往往比单卡型号更能决定整体性能。

第三层才是真正的集群。大规模预训练、全参数微调或者高并发推理服务，需要在数十乃至上千张卡之间做数据并行、流水线并行、专家并行（MoE场景）的混合并行策略。到了这个层次，稳定的集群网络、高效的任务调度、容错和断点续训就成了重中之重。这时候算力底座的主战场已经不是单卡算力，而是集群的“木桶效应”。

2.2 互联选型：NVLink、RoCE还是InfiniBand

互联是算力底座中被低估最严重的一个维度。很多团队在买机器时把预算全花在GPU上，结果组网时发现总线带宽不足以支撑多卡通信，训练效率惨不忍睹。我在之前的一家客户现场见过一个典型的案例：他们采购了一批搭载高性能GPU的服务器，但网络仍停留在普通的25G以太网，做张量并行时每步迭代的通信时间比计算时间还长，4卡的实际加速比连2倍都不到，纯纯的“木桶效应”。

在目前的实践中，互联方案基本是三个选择。NVLink是NVIDIA自家生态内的GPU间高速互联，主要用于单机多卡场景，带宽极高且延迟极低，这是张量并行的首选。RoCE（RDMA over Converged Ethernet）和InfiniBand则解决跨节点通信问题。RoCE的优势在于可以复用现有以太网基础设施，成本较低，但需要精细的流控配置和拥塞管理，否则丢包会严重影响性能。InfiniBand性能更稳定，端到端RDMA能力出色，但成本高一个数量级，且需要专门的专业团队运维。

怎么选？我的建议是：单机4卡以下，主要依赖NVLink；多机训练或大规模推理集群，优先评估RoCE，因为现阶段很多云厂商和开源方案都能把RoCE调得比较稳；如果是百卡以上、训练任务对稳定性要求极高的场景，InfiniBand带来的收益明显大于成本。另外还有一个容易被忽略的点：网卡数量与拓扑设计。一个计算节点用2张100G网卡还是8张200G网卡，决定了整个集群的通信瓶颈位置，这一步必须在采购前做流量建模，而不是买了再说。

2.3 数据路径上的隐性瓶颈：存储与数据传输

算力底座除了GPU和网络，还有一个经常被拖出来背锅的组件：存储。很多人在本地开发时觉得数据加载不是问题，因为操作系统帮你缓存了；一旦上了集群，数据集存在远端，训练时每个step都要重新拉取样本，存储吞吐一旦跟不上，GPU就只能干等。那种“GPU利用率上不去”的经典场景，有一大半数据管道的锅。

针对训练场景，存储方案通常有两个方向：一是对象存储（如S3、MinIO、阿里云OSS）加上训练框架内的预取和缓存机制，适合数据规模巨大但随机访问频度低的场景；二是并行文件系统（如Lustre、GPFS）或全闪NVMe存储阵列，适合需要高速随机读写的场景。很多云上训练方案会采用“对象存储+本地NVMe缓存盘”的混合架构：冷数据走对象存储，热数据缓存到计算节点的本地NVMe盘，兼顾成本和性能。

推理场景的存储挑战则是另一回事。模型文件动辄几十GB，如果每次扩容的新实例都要从远端重新拉取模型，冷启动时间会非常长。所以推理服务往往愿意为“模型加载加速”额外付费，比如把模型放在高性能NAS上，或者用模型仓库配合镜像预热。这里有一个非常实际的建议：如果你的Agent应用有秒级弹性的需求，请一定把模型文件放在按可用区就近的高速存储上，同时做容器镜像与模型文件的预缓存。我见过不少团队在Kubernetes扩容后因为模型拉取太慢而集体超时的，这类问题不是模型的问题，是数据基础设施调度的锅。

3. 调度和资源池化：GPU利用率从30%到70%的实操路径

3.1 为什么你的GPU利用率只有30%

大部分团队第一次看DCGM监控面板时都会受到打击：标称的算力利用率长期徘徊在30%上下，GPU在部署后的前几分钟内利用率高，随后就像泄了气一样断崖式下跌。这几乎不是某个单一原因造成的，而是资源分配、任务排队和运行效率三个层面的综合结果。

首先是资源分配不合理。很多人用Kubernetes部署GPU服务时，一个Pod声明“nvidia.com/gpu: 1”就完事了，但完全没有考虑显存和算力的匹配。一个推理引擎在显存不足时会频繁重新申请内存，在显存充足但并发请求不够时又只能空转。第二种常见问题是任务排队和碎片化。多个推理服务共享一张卡时，如果不同请求的输入长度差异巨大，GPU的批处理效率会被长尾请求拖垮，产生碎片化的预填充计算。这个现象在vLLM还没有启用连续批处理时特别常见，现在虽然引擎优化了很多，但如果你用的是未开启PagedAttention的框架，依旧会遇到同样的问题。

第三个原因是调度器的粗放。默认情况下，Kubernetes按请求顺序把Pod调度到任意有GPU的节点，完全不考虑节点间通信、已经运行的Pod与新增Pod之间的亲和性。训练和推理任务混部时，一个跑训练的任务因为多卡通信吃满了网络，干扰了旁边的在线推理服务，互相拖累。要解决这个问题，光盯着GPU利用率本身没有意义，得从调度策略和资源共享机制上做文章。

3.2 算力调度的三种主流路线及适用场景

算力调度这片技术地形复杂，没有一个万能方案，不同规模和应用形态适合完全不同的路线。我梳理下来，大多数团队最终会落在三条路线上。

第一条路线是Kubernetes原生的GPU管理。借助NVIDIA Device Plugin，你可以让K8s识别GPU资源，用requests/limits限制每Pod的GPU用量，配合官方和社区的调度组件实现基础的排队和抢占。对于以在线推理服务为主、模型规模在几十GB以内的团队，这条路线最自然。它最大的优点是生态成熟，和容器化、微服务、可观测性体系无缝对接。

第二条路线是在Kubernetes之上叠加批处理调度器。Volcano和Kueue是比较有代表性的两个选择。Volcano提供队列、优先级、Gang Scheduling（成组调度）等能力，非常适合训练任务；Kueue则是Kubernetes官方生态里偏向配额管理和作业排队的方案，对弹性资源切分更友好。如果你既要在同一个集群里跑在线推理，又要跑定期训练任务，这种叠加方案可能是最合适的。用小实验说明一下：我们有一个内部集群，10张A100，白天跑推理和开发调试，凌晨空闲窗口跑微调和定期评测，就是用Kueue的队列划分配合CronJob实现的，GPU的日均利用率比原先分开部署提高了40%以上。

第三条路线是使用Slurm这类传统高性能计算调度器。如果你的团队主要做科研计算、超大规模训练，或者有大量MPI/集合通信作业，Slurm在排队策略、多机多卡任务管理和作业依赖上有不可替代的优势。很多大模型预训练团队至今仍然把Slurm作为主力调度器，因为经过充分调优的Slurm在万卡场景的稳定性和可控性上确实有积累优势。缺点是Slurm与云原生生态集成不够顺畅，容器和微服务机制相对原始。

调度方案选型本质上没有一个“最好”，只能说贴合你的工作量模式的才是“最适合”。我建议把“在线推理”、“离线训练”、“开发调试”这三类工作负载分开建模，再看哪条路线能同时满足其需求。

3.3 弹性伸缩和成本控制：从规格选择到排队策略

算力调度真正产生效益的地方，是把“弹性”做出来。GPU是按小时收费的，哪怕是你自建的机房，电费和折旧也在走。所以成本控制的核心，就是让任务在最快需要的时刻获得资源，在不需要的时刻立刻释放。

在推理场景，弹性伸缩通常基于QPS或队列深度。vLLM的连续批处理让单个实例可以支撑更高的并发，所以判断指标不应该只看QPS，还要看平均排队延迟和KV Cache占用率。用Kubernetes HPA时，很多人习惯直接绑CPU指标，这在GPU场景往往是糟糕的选择，因为GPU利用率可能很低，而排队已经在积压。更合适的做法是结合自定义指标，比如推理引擎暴露的running queue size或者GPU显存使用率。这里有一个实践细节：弹性伸缩的冷却时间必须比模型冷启动时间长，否则会出现扩容后模型还没加载完，流量高峰已经过去的尴尬。

在训练场景，弹性更多体现在队列抢占和优先级。低优先级的实验任务可以在空闲窗口利用碎片资源，高优先级的正式任务可以抢占前者的GPU。很多调度器支持PriorityClass和Preemption策略，但配置时要小心：被抢占的任务如果频繁中断，断点续训机制没做好，反而会浪费更多时间重新加载。我的建议是，对可能被抢占的任务建立自动保存checkpoint的机制，并严格控制抢占频率，不要让低优任务无限循环重启。

成本控制的最后一环是实例规格的匹配。做推理服务的很容易只考虑显存多大，不考虑并发模型和算力匹配。以7B模型服务为例，如果并发主要是数十到上百的办公场景，一张高算力的数据中心卡可能利用率低于10%，而两个并发实例分摊流量反而可以把一张卡跑满。这里给出一个大致对照：

这个表不是绝对的，但它能帮你在做预算和规格评估时有一个大致方向，避免一上来就堆顶级配置。

4. 推理不再是唯一重心：Agent工作负载正在重写Infra需求

4.1 推理服务的惯性思维：为什么Agent会打破它

过去我们把AI应用主要理解为“请求-响应”：客户端发来prompt，模型返回completion，服务端把延迟和吞吐优化好就行。做推理服务的优化逻辑也比较清晰：提升批处理大小、优化KV Cache、预热模型、设置合理的超时。这套思维在对话机器人、内容生成等场景下行之有效，但放到Agent智能体上，就会露出一堆新的问题。

Agent的本质是“模型自主决策和行动”。一次用户请求，可能会让Agent内部解析意图、调用搜索API、读取网页、调用本地工具、生成中间结果、再次调用模型、最后汇总答案。这意味着一次用户会话在Infra层可能触发10次甚至更多次模型调用，而这10次调用之间存在复杂的依赖关系，有些可以并行，有些必须串行。相当多的并发控制、状态同步和资源规划问题，在传统推理服务中根本不会出现。

我最近在关注低代码Agent平台（比如Coze等“扣子”这类智能体开发工具）的实践，它们的出现大大降低了Agent应用的上手门槛，业务人员可以像搭积木一样搭建工作流。但这类平台对Infra的要求并不低：每个Agent工作流背后是大量的模型调用、工具节点和条件分支，底层基础设施必须支持高并发的工作流编排和毫秒级的工具调用响应。换句话说，工具越“傻瓜”，底座越不能“傻瓜”。

4.2 Agent工作负载的几个典型特征

结合自己看过的一些生产环境Agent服务，我总结了四个Infra层面需要重新设计的典型特征，这些特征在传统模型推理中很少被同时考虑：

第一是长会话与状态存储。Agent和用户的交互通常持续多轮，涉及对话历史、临时结果和状态变量。这些状态不能只放在内存里，因为Agent可能被调度到另一个实例上，Kubernetes的Pod漂移会让它丢失“记忆”。所以需要外部状态存储，比如用Redis作为会话状态的暂存区，用向量库存储需要长期保留的事实。

第二是工具调用的网络化。Agent要调用外部工具，就一定会产生出站网络请求。在传统的推理服务中，我们往往限制出站流量，但在Agent场景下，出站访问是刚需。这给安全边界带来了全新的挑战：你怎么控制一个可能被恶意网页内容诱导的Agent不去调用危险接口？

第三是动态的资源需求。同一个Agent，在处理简单问答时可能只要几KB的上下文，在阅读长文档时可能要求64K甚至128K的上下文窗口，这也是为什么KV Cache的预留管理成了Agent场景的重点。如果所有Agent都按最大窗口预留资源，成本会非常吓人。通过动态显存管理、PagedAttention等技术，让服务仅在需要时扩展上下文空间，这是成本优化的核心。

第四是一轮会话内复杂的模型请求拓扑。Agent可能先调用一个快速小模型做意图识别，再调用一个大模型做最终推理，中间穿插调用embedding模型做向量检索。这相当于要求Infra支持“异构模型混合路由”，不是只用一个大模型服务就能搞定的。

4.3 一套可落地的Agent服务部署参考

说了这么多抽象特征，给一套可落地的架构参考。假设你的Agent服务基于Python/FastAPI编写，需要调用一个本地部署的13B模型服务和一个外部搜索API，整体跑在Kubernetes上。一个简化的部署拓扑如下：

apiVersion: apps/v1 kind: Deployment metadata: name: agent-worker labels: app: agent-worker spec: replicas: 4 selector: matchLabels: app: agent-worker template: metadata: labels: app: agent-worker spec: containers: - name: agent image: registry.example.com/agent:latest ports: - containerPort: 8000 resources: requests: cpu: 2 memory: 4Gi limits: cpu: 4 memory: 8Gi env: - name: MODEL_ENDPOINT value: "http://llm-server:8001/v1" - name: REDIS_URL value: "redis://redis-state:6379/0" - name: TOOL_ALLOWLIST value: "search,calculator,calendar" - name: MAX_STEPS value: "20" --- apiVersion: v1 kind: Service metadata: name: agent-worker spec: selector: app: agent-worker ports: - port: 8000 targetPort: 8000

注意这些环境变量背后的设计意图：MODEL_ENDPOINT指向独立的模型推理服务，而不是在Agent容器里直接加载模型，这样模型推理的伸缩和Agent逻辑的伸缩可以解耦；REDIS_URL用于保存会话上下文，让任意一个Agent副本都能接续之前的状态；TOOL_ALLOWLIST做工具级白名单，防止一个Agent拿到全部工具的权限；MAX_STEPS限制单次任务的最大推理步数，避免恶意循环或者失控的Agent消耗过多资源和费用。

这种拆分的本质，是把“模型能力”和“业务逻辑”分层管理。模型推理服务可以用vLLM做高性能批处理，Agent逻辑层则只负责编排，两者各自伸缩、互不干扰。

4.4 可观测性升级：从模型指标到行为追踪

Agent场景对可观测性的要求也远比传统推理高。传统推理服务看三个指标就够：QPS、延迟、错误率。但Agent是“多步、多工具、多状态”的工作流，一旦出现问题，你需要回答的问题是：Agent在执行哪一步时出现了异常？是模型回答格式不对导致工具调用失败，还是工具返回内容太长导致上下文溢出？是某个权限配置拦截了合法调用，还是外部API超时拖垮了整个工作流？

因此，Agent的可观测性必须引入分布式追踪的思路。最基础的做法是给每个用户会话生成一个traceID，在Agent的每一次模型调用、工具调用、状态写入时都把traceID透传下去，并将关键步骤的耗时和输出摘要记录到日志里。用OpenTelemetry标准把推理引擎、向量库、外部工具的Span全部关联起来，这样排查问题时就能直观看到整条链路的运行情况。

我见过太多团队只监控Agent服务的CPU和内存，出了事故完全无法定位是外部API的问题还是Agent逻辑的问题，这是最典型的Infra建设盲区。记住一条经验：Agent越智能，它的行为路径越不可预测，你就越需要一个能让你“看见它在干什么”的观测体系。没有可观测性的Agent服务，就像一个没有仪表盘的飞机，飞起来了但根本不知道什么时候会故障。

5. 智能体应用的安全死角：从OWASP Top 10看Infra要补哪些课

5.1 安全为什么成了Infra的事

很多做Infra的同学以前对应用安全不太敏感，觉得那是业务层的责任。但Agent一出现，这个边界就被打破了。原因非常简单：Agent是一个能够主动行动的系统，它能调用工具、访问外部网站、代表用户执行操作。过去一个模型服务的安全问题主要是越权访问、数据泄露，但现在你可以想象这样的场景：一个Agent收到一封包含恶意指令的邮件，邮件正文里藏了提示注入的内容，Agent读取邮件后把它当作系统指令执行，于是它调用了内部的支付工具、删除了特定文件、或者把敏感信息拼接进了下一次外部请求。

这种风险无法完全靠应用层的代码审查解决，因为Agent的行为在运行时是动态生成的，你无法在部署前穷举它的决策路径。作为Infra团队，你必须把安全能力内建到基础设施中——通信隔离、权限模型、出站控制、审计日志，这些才是兜底的东西。安全问题正在从“应用的防腐层”变成“基础设施的承重墙”。

5.2 智能体应用风险清单：参考OWASP的新方向

OWASP社区长期维护Web应用与LLM应用的安全风险清单，近几年又出现了专门面向智能体应用的风险方向（社区在推动类似“ASI01-ASI10”这样的智能体应用Top 10框架）。虽然细节可能还在演进，但核心风险方向已经比较明确，我自己归纳为四类。

第一是提示注入。这是广义的注入攻击，攻击者把恶意指令藏在外部的网页、文档、工具返回值里，诱使Agent执行非预期操作。第二是过度授权。Agent被赋予了过多工具的访问权限，即使它没有恶意，也可能因为一次误判而执行破坏性操作。第三是上下文/记忆污染。攻击者通过对话历史或外部内容污染Agent的记忆库，让它在后续会话中持续产生错误输出。第四是资源滥用。恶意用户通过构造超大上下文、死循环式的工具调用，消耗大量模型推理算力，造成服务方巨大的费用开支。

这四类风险看起来是应用问题，但每一条都需要Infra侧给出结构性的防线。提示注入需要在数据路径上做“指令与数据分离”，例如对远端内容打标记、做隔离上下文，而不是把它直接塞进系统提示词；过度授权需要在工具层做粗粒度的白名单加细粒度的会话内动态授权；上下文污染需要建立记忆存储的写入审计和定期回滚机制；资源滥用则依赖配额控制、执行步数上限和计费熔断。

5.3 基础设施侧的防护实践：权限、隔离、审计

从实际落地的角度，我给几个具体可执行的Infra侧安全措施，这些不依赖任何特定安全产品，常规开源技术栈就能实现：

其一，最小权限与动态授权。Agent容器使用独立的ServiceAccount，只挂载它真正需要的工具凭证。对关键操作（如删除、转账、发送消息）做二次确认，可以通过人工审批接口，或者在工具调用链路上设置高权限操作的显式确认标记。权限模型不是一次配置就结束的，每次给Agent增加新工具时，都应该同步审查它的权限边界。

其二，沙箱隔离。无论Agent调用什么外部工具，确保它在受限的网络环境里执行。出站流量通过白名单代理，内部敏感系统通过独立的命名空间和网络策略隔离。一个Agent容器被攻破后，它的横向移动半径必须被限制在最小范围。Kubernetes NetworkPolicy在这里非常有用，可以按Agent名划分出独立的网络边界。

其三，审计与可追溯。所有Agent的工具调用、上下文修改、外部请求都应记录成不可篡改的审计日志，并保留足够长的留存周期。这样一旦发生事故，你能回答“Agent在哪个时刻、根据什么内容、调用了哪些工具、返回了什么结果”。没有这种记录，任何安全事故排查都是盲人摸象。

最后，在成本控制这件事上，给每一个Agent会话设置预算上限，例如最大执行步数、最大工具调用次数、单会话最高token消耗量。这看起来是财务问题，实际上是防攻击的兜底措施。很多恶意利用的本质就是消耗你的资源，当你把消耗限制在可控范围内时，攻击者的收益就会大幅下降。

从我个人这一年多的实践经验看，AI Infra这个岗位真正难的不是某一个组件怎么配，而是把算力、调度、模型服务、应用和安全串成一条完整的链路来看问题。一个线上毛刺，可能是显存碎片，可能是调度排队，也可能是Agent工具的权限配置，每一层都在互相影响。所谓“从算力底座到智能应用的技术桥梁”，本质上就是有人把这辆车的底盘、变速箱和方向盘当成一个整体来调校，而不是各自看各自的零件。希望这篇内容能给正在踩坑的你一些启发，也欢迎在实践中遇到具体问题时多交流。