摘要AI 基础设施从「跑起来」演进为「跑得稳、跑得省、跑得可观测」。2026 奇点智能大会「AI Infra 基础设施与 AgenticOps」专题由杨健(北航计算机学院副教授)、裴明明(网易智企 AI 平台负责人)、谭颖然(沐曦光启)担纲。本文以「监控面板文字版」形式,系统性拆解 AI Infra 的 4 大工程领域——GPU 集群调度、KV Cache 管理、多租户推理、Agent 可观测性。SEO关键词:AI Infra / AgenticOps / GPU 调度 / KV Cache / 多租户推理 / Agent 可观测性 / 大模型运维 / 网易智企 / 2026 奇点智能大会一、为什么 AI Infra 是 2026 的「最热门」「最缺人」领域2024-2026 年,大模型从「少数公司玩得起」走向「所有公司都要用」。但大模型的运行成本是传统软件的 10-100 倍——单次推理可能需要 8 张 H100,持续运行每月算力成本高达数百万。这意味着,AI Infra 工程师的职责发生了根本变化:时代核心职责核心指标传统 Infra(2015-2020)保证服务可用、扩缩容QPS、延迟、错误率云原生 Infra(2020-2023)K8s 编排、Service Mesh资源利用率、启动时间AI Infra(2023-)GPU 调度、推理优化、成本控制Token/$、GPU 利用率、KV Cache 命中率杨健(北航计算机学院副教授)在 2026 奇点智能大会新加入议题里,会专门拆解 AgenticOps(Agent 时代的运维)与传统 DevOps 的本质区别。二、领域 1:GPU 集群调度 监控面板文字版╔══════════════════════════════════════════════════╗ ║ GPU 集群健康度监控面板 ║ ╠══════════════════════════════════════════════════╣ ║ 总 GPU 数: 256 张 H100 ║ ║ 在线 GPU 数: 252 张(98.4%) ║ ║ GPU 利用率: 78%(目标 75%) ║ ║ 显存利用率: 65%(目标 60-75%) ║ ║ 调度延迟: 12s(目标 30s) ║ ║ 排队任务数: 23 个 ║ ║ 失败率: 0.8%(目标 1%) ║ ║ 单 Token 成本: ¥0.012(目标 ¥0.02) ║ ╚════════════════════════════════════════════════╝ 4 大调度策略策略原理优势局限FCFS(先来先服务)任务按提交顺序排队简单GPU 利用率低Bin Packing把小任务打包到同一 GPU利用率高大任务等待时间长Spread把任务分散到不同 GPU容错好利用率低Gang Scheduling协同任务一起调度适合分布式训练调度复杂️ 工程实现:GPU 调度器# 伪代码:基于 K8s 的 GPU 调度器classGPUScheduler:defschedule(self,task):智能调度 GPU 资源# 1. 查询空闲 GPUavailable_gpusself.query_idle_gpus(min_memorytask.required_memory,gpu_typetask.gpu_type# H100/A100/沐曦)ifnotavailable_gpus:# 排队等待self.queue.put(task)return{status:queued}# 2. 选择最优调度策略iftask.typetraining:# 训练任务:连续占用,用 Gang Schedulingreturnself.gang_schedule(task,available_gpus)eliftask.typeinference:# 推理任务:弹性扩缩容,用 Bin Packingreturnself.bin_pack(task,available_gpus)eliftask.typeinteractive:# 交互式任务:低延迟,用 Spreadreturnself.spread(task,available_gpus)杨健对 GPU 调度的关键判断:「GPU 调度不是单维问题,是多目标优化」——需要同时考虑利用率、延迟、公平性、容错,单目标最优往往会牺牲其他维度。多目标 Pareto 前沿是工业级 GPU 调度器设计的核心方法论。三、领域 2:KV Cache 管理 监控面板文字版╔══════════════════════════════════════════════════╗ ║ KV Cache 优化监控面板 ║ ╠══════════════════════════════════════════════════╣ ║ 显存总量: 80GB(单卡 H100) ║ ║ 模型权重占用: 14GB(Llama-3 8B) ║ ║ KV Cache 占用: 32GB(40%) ║ ║ 可用显存: 34GB(43%) ║ ║ KV Cache 命中率: 87%(目标 80%) ║ ║ PagedAttention 块: 1024 块(每块 16 token) ║ ║ 块碎片率: 12%(目标 15%) ║ ║ 卸载到 CPU 的 KV: 8GB(冷数据) ║ ╚════════════════════════════════════════════════╝ 5 大 KV Cache 优化技术技术显存节省延迟影响实施难度PagedAttention(vLLM)4-8x几乎无中Continuous Batching2-3x降低 P99中Multi-Head Latent Attention(MLA)8-16x需重训高KV Cache Quantization(INT8/INT4)2-4x略增中Prefix Caching3-10x(长 prompt)显著降低低️ 工程实现:Prefix Caching# 伪代码:Prefix Caching(前缀缓存)classPrefixCache:def__init__(self):self.cacheLRUCache(max_size10000)defget_or_compute(self,prompt,model):命中前缀缓存则直接复用,否则重新计算# 1. 找最长公共前缀cache_keyself.find_longest_prefix(prompt)ifcache_keyandcache_keyinself.cache:# 命中:复用缓存的 KVcached_kvself.cache[cache_key]new_tokensprompt[len(cache_key):]new_kvmodel.compute_kv(new_tokens,prefix_kvcached_kv)returnnew_kv# 未命中:完整计算kvmodel.compute_kv(prompt)self.cache[prompt]kvreturnkv适用场景:多轮对话、Agent 长链路、RAG 检索结果后处理。在这些场景下,Prefix Caching 可以把首 token 延迟从 1.2s 降到 80ms。四、领域 3:多租户推理服务 监控面板文字版╔══════════════════════════════════════════════════╗ ║ 多租户推理服务监控面板 ║ ╠══════════════════════════════════════════════════╣ ║ 租户总数: 120 个 ║ ║ 在线租户: 98 个 ║ ║ 总 QPS: 8500 ║ ║ P50 延迟: 120ms ║ ║ P99 延迟: 480ms ║ ║ 公平性指数: 0.92(目标 0.85) ║ ║ 资源抢占次数: 3 次/小时 ║ ║ 租户 SLA 违约: 0 个(全部达标) ║ ╚════════════════════════════════════════════════╝ 多租户隔离的 3 个层级隔离层级隔离方式隔离强度适用场景物理隔离每个租户独占 GPU强金融、政务(合规要求)逻辑隔离同一 GPU 不同模型实例中中小企业(成本敏感)共享隔离同一 GPU 同一模型多租户弱C 端应用(极致成本)裴明明(网易智企 AI 平台技术负责人)的核心判断:「多租户推理服务的设计核心是『公平性』——既要保证大租户的 SLA,又不能饿死小租户。加权公平队列(WFQ)是工业级多租户推理的事实标准算法。五、领域 4:Agent 可观测性 监控面板文字版╔══════════════════════════════════════════════════╗ ║ Agent 可观测性监控面板 ║ ╠══════════════════════════════════════════════════╣ ║ 活跃 Agent 数: 340 个 ║ ║ 总调用次数: 12,500 次/分钟 ║ ║ 平均链路长度: 5.2 步 ║ ║ 工具调用成功率: 94% ║ ║ 任务完成率: 82% ║ ║ 平均任务耗时: 18s ║ ║ Token 消耗: 2.3M/分钟 ║ ║ 异常 Agent 数: 12 个(超时/死循环) ║ ╚════════════════════════════════════════════════╝ Agent 可观测性的 4 大支柱支柱内容工具Trace(链路追踪)单次 Agent 调用的完整链路LangSmith、Phoenix、LangfuseMetric(指标)聚合指标(成功率、延迟、Token)Prometheus、GrafanaLog(日志)Agent 思考过程、工具调用详情ELK、LokiEval(评估)Agent 输出质量持续评估LangSmith、Patronus️ 工程实现:Agent 链路追踪# 伪代码:Agent 链路追踪classTracedAgent:def__init__(self,agent):self.agentagent self.tracerOpenTelemetryTracer()defrun(self,user_query,trace_idNone):withself.tracer.start_span(agent.run,trace_idtrace_id)asspan:span.set_attribute(user.query,user_query)# 1. 思考阶段withself.tracer.start_span(agent.thinking,parentspan):thinkingself.agent.think(user_query)span.set_attribute(agent.thinking,thinking)# 2. 工具调用阶段fortool_callinself.agent.get_tool_calls():withself.tracer.start_span(ftool.{tool_call.name},parentspan)astool_span:tool_span.set_attribute(tool.args,tool_call.args)resultself.agent.execute_tool(tool_call)tool_span.set_attribute(tool.result,result)tool_span.set_attribute(tool.duration_ms,...)# 3. 响应阶段responseself.agent.respond()span.set_attribute(agent.response,response)returnresponse六、AI Infra 工程师的 5 项关键能力GPU 硬件深度理解——理解 CUDA Core、Tensor Core、显存带宽、NVLink,而不只是「会 K8s」推理优化实战——PagedAttention、量化、批处理、Prefix Caching,需要亲自动手调优可观测性建设——从 Day 1 就建立 Trace/Metric/Log 体系,不要等问题出现才补成本意识——AI 算力贵,每个 GPU 调度决策都要考虑成本影响业务理解——理解 LLM、Agent 的工作原理,才能做出更好的调度决策七、常见问题 FAQQ1:GPU 利用率 70% 以下怎么办?3 个方向排查:① 是否有频繁的小任务调度(小任务打包提升利用率);② 是否有 KV Cache 命中率低导致重复计算;③ 是否有显存不足导致大模型无法并行(考虑模型量化或 GPU 升级)。Q2:多租户推理怎么避免「邻居效应」?大租户的突发流量会抢占小租户的 GPU 资源。加权公平队列(WFQ)给每个租户设置权重,突发流量超过权重时会被限流。Netflix 的内部实践表明,WFQ 可以把公平性指数从 0.6 提升到 0.92。Q3:Agent 可观测性为什么比传统微服务难?Agent 是长链路、不可预测、Token 消耗大的——单次调用可能涉及 5-10 个工具、20-50 个 LLM 调用、消耗 10K-100K Token。传统的「调用一次记一次」的可观测性思路不再适用,需要Token 级别的链路追踪与Agent 行为的可视化回放。想深入了解杨健、裴明明、谭颖然等 AI Infra 方向嘉宾的完整工程实践,可前往奇点大会官方渠道免费领取大会 PPT 详细资料。