企业级AI应用最近两年的变化比前面十年加起来都多。“算力”这两个字从技术圈的性能参数讨论变成了企业管理者和财务都要盯着的经营指标以“数谷”为代表的智能算力集聚区也实实在在迎来了一轮高增长。我自己长期做AI平台和基础设施最直观的感受不是来自发布会上的新模型而是客户发来的算力容量规划需求——越来越具体、越来越着急、问题也越来越复杂。这篇文章我会从实际项目视角出发重点讲清楚几件事企业级AI应用到底在哪些环节消耗算力、怎么把业务量换算成Token和GPU卡数、选卡时为什么不能只看Tops排行、多台算力服务器统一管理怎么做以及从Demo到稳定生产之间最容易被忽视的坑。如果你是正在给企业AI应用做算力规划的同学或者被领导冷不丁问了一句“我们到底要买多少卡”这篇文章应该能给你一张可落地的参照表。1. 算力需求的真实增长点企业级AI应用到底在用什么“吃”算力1.1 从单点尝鲜到核心业务嵌入前几年聊AI算力大家谈得最多的是“训练一个模型需要多少卡”。那时候AI在企业里大多是锦上添花的项目做一个问答机器人、跑一轮测试数据、生成几张营销图算力消耗是偶发性的一个季度也跑不了几次大任务。现在的局面完全不一样。企业级AI应用开始进入核心业务流程而且是7×24小时在线的那种。智能客服要处理全天候的用户会话营销团队用大模型批量生成文案和短视频脚本研发团队用AI编程工具做代码补全和Review运营团队让Agent自动整理数据报表。这些场景没有一个是一次性任务全部是持续性的生产流量。我见过最典型的案例是一家零售企业的客服系统改造。原来人工客服高峰期要100多人同时在线后来接入了大模型辅助回复。刚开始只是给客服人员做回复建议算力消耗不温不火后来业务方觉得效果不错直接做了面向用户的智能体还接入了App、小程序和外呼电话三个入口。结果一个月内每秒的模型请求数翻了40多倍原来的两组GPU服务器直接被打满。这个转变非常真实企业AI应用一旦进入核心业务线算力需求就不是线性增长了而是台阶式跳涨。1.2 三类高消耗场景大模型推理、Agent编排、多模态内容生成如果说算力需求存在“三驾马车”那当前最明显的三类高消耗场景分别是场景类型典型例子算力消耗特征增长特点在线大模型推理智能客服、代码补全、智能文档总结请求并发高输出Token持续生成随业务流量波动7×24在线Agent编排与多轮调用自动数据分析、自动化运维、研究助手单个任务会反复调用模型多次一次任务消耗放大数倍多模态内容生成AI短剧、AI分镜、AI配音、营销视频图像和视频生成算力消耗极高任务格式升级带动消耗暴涨先聊在线推理。大模型推理的特点是“每次请求都要实时跑一遍模型”模型在显存里推理时一遍遍读取权重并计算。对于一个7B参数的模型每生成一个Token都要做一次完整的前向计算输出1000个Token就是1000次前向计算。并发一高GPU立刻成为瓶颈这也是为什么很多企业感知到的算力压力主要来自推理接口。Agent编排这个场景特别容易被人低估。很多人觉得Agent无非是把模型调用包装了一下算力消耗和普通聊天差不多。但实际生产里一个Agent任务经常要分解成规划、工具调用、结果分析、再生成回复多个步骤每一步都可能调用一次模型。之前我们给一个数据分析Agent做压测单个任务平均要调用大模型6次每次输入输出加一起差不多2000多个Token。如果业务方规划的是每天10万个任务那实际产生的模型调用量就是60万次——这就是隐形的算力放大器。多模态内容生成就更不用说了。AI生成一张图片所需的算力是文本生成的几十倍AI生成一段几分钟的视频算力消耗又比图片高一个数量级。最近AI短剧和AI漫剧的制作流程开始大量使用生成式AI做分镜、换脸、配音和特效这个方向一旦跑起来单项目消耗的GPU时数很容易超过传统业务一整年的用量。1.3 为什么这些需求会往“数谷”汇聚企业算力需求暴涨之后自然会面临一个现实问题自己的机房放不下。一方面GPU采购周期长另一方面电力、散热、机柜资源这些都不是一朝一夕能解决的。于是越来越多的企业选择把大模型推理、训练任务放到算力集聚区去这就是“数谷”这类智能算力枢纽高增长的原因之一。数谷式的算力供给逻辑和以前卖几台服务器完全是两回事。它的核心是把分散在各地的小算力池集中起来统一调度、统一计费、统一运维企业不用自己操心基础设施开通就能用。这个模式在今年明显加速从我们对接过的几十家客户来看几乎有一半已经或正在考虑把GPU资源从自建机房迁移到公共算力服务平台。2. 把“Token算力需求”说清楚企业AI算力规划的第一步2.1 从业务指标反推Token吞吐量做算力规划时99%的人第一句话是“我们想上一个大模型”第二句话是“大概需要多少张卡”。但“多少张卡”不是一个可以直接回答的问题它需要一个中间变量Token吞吐量。Token是模型处理文本的最小单位一个汉字大概对应1到2个Token。算力规划的底层逻辑就是先把业务请求量换算成每秒需要处理的Token数量再用Token吞吐量反推需要多少张GPU。具体怎么换算先收集几个关键业务指标高峰期的请求并发数QPS单次请求的平均输入Token数单次请求的平均输出Token数预留的峰值冗余倍数。计算公式可以简化成每秒Token需求 并发QPS × (平均输入Token数 平均输出Token数)举个例子一个智能客服系统高峰期并发50个请求每个请求平均输入800个Token、输出600个Token那每秒的Token需求量就是50 × (800 600) 70,000 Token/s这里要提醒一下模型处理输入和输出的机制不太一样。输入阶段PreFill是并行计算吃算力输出阶段Decode是逐个Token生成更吃显存带宽。但做容量规划时先用总量估算出一个方向再结合具体框架做基准测试这是最务实的思路。2.2 从Token需求到卡数估算一个完整示例光说公式容易飘我拿一个真实的规划案例来演示。有一家客户要做智能客服Agent业务目标是高峰期每分钟处理300个会话每个会话内部平均要调用大模型3次每次请求的输入加输出共9000个Token。先计算单次会话需要的Token量每个Agent会话Token量 3次调用 × 9000 Token 27,000 Token高峰期一分钟300个会话一分钟的Token需求300 × 27,000 8,100,000 Token/min换算成每秒8,100,000 / 60 135,000 Token/s看到这个数字等于每秒需要处理13.5万个Token。接下来看单张GPU能跑多少。我们当时用一款主流推理卡做基准测试在7B参数模型、开启连续批处理的条件下单卡实测吞吐大概是9000到10000 Token/s。按9000算135,000 / 9000 ≈ 15 张卡但这只是“刚好顶住”的卡数没有算冗余。企业级生产环境一般要预留至少50%的余量应对流量突刺和单卡故障15 × 1.5 22.5向上取整就是23到24张卡再把显存校验考虑进去。7B模型FP16权重约14GB加上4096上下文的KV Cache和推理框架的运行时开销单张卡跑2到4个并发会话比较合适。高峰期需要50个并发会话需要跑节点的副本数至少也要十几二十个。综合算下来之前估算的24张卡在数量上是合理的但分布方式需要调整——比如拆成3个节点每个节点8卡既保证并发能力又预留单节点故障的迁移空间。2.3 Token评估中最容易出现的两个偏差Token评估做多了会发现大家常踩两个坑一是只用理论峰值做估算二是低估长上下文对显存的消耗。第一个坑很好理解。GPU的Tops很高但实际业务能跑出的Token吞吐远远低于理论峰值因为模型推理除了算力还吃显存带宽、批处理策略和框架优化。同样一张卡有人能跑到8000 Token/s有人只跑出3000 Token/s差距基本都出在框架和参数配置上。所以在做卡数估算前一定要先用自己手里的模型和推理框架做一轮基准测试别直接套用厂商的理论数字。第二个坑是长上下文的显存消耗。很多Agent应用喜欢把历史对话、知识库片段全塞进上下文里上下文一长KV Cache的显存消耗是线性增长的。原来2048上下文时一张卡能塞8个并发请求改成8192上下文后可能4个都塞不进去。这不是模型本身变大了而是KV Cache把显存吃了。评估时如果只看模型参数量一定会出现“买的卡数够但一上线显存就爆”的尴尬。我在实际操作中养成了一个习惯所有容量评估表格里除了卡数和Token吞吐一定会单独列一栏“最大上下文长度”。这一栏看起来不起眼但往往是决定显存够不够的关键参数。3. GPU选型与算力组合别只盯着Tops排行3.1 Tops、显存、显存带宽与吞吐谁才是关键指标打开各大算力评测榜满屏都是“AI算力Tops排行”。Tops代表显卡的理论峰值算力看起来非常直观但它只是“发动机排量”不是实际车速。大模型推理这个场景里瓶颈往往不在算力而在显存带宽。为什么因为推理时模型权重固定在显存里每生成一个Token都要把全部权重从显存搬到计算单元过一遍。我常打一个比方算力是仓库里搬运工的数量显存带宽是传送带的宽度。传送带不够宽搬运工再多也只能排队等着。有个非常实用的估算公式单Token生成延迟约等于“模型权重字节数除以显存带宽”。以70B模型为例FP16权重约140GB如果显存带宽是2TB/s那生成一个Token的理论延迟大约是70毫秒。用户体感上就是模型打字有点慢。如果用INT4量化权重降到35GB同样带宽下延迟能压到20毫秒以内。这个公式能解释为什么量化对大模型推理提速这么明显——不是算力变强了而是需要搬的数据变少了。选择GPU时除了Tops至少还要看三个指标显存容量、显存带宽、以及是否支持企业级可靠性特性比如ECC显存纠错。家庭卡用作开发调试没问题但7×24小时在线服务长期跑高负载风扇寿命、显存报错、驱动稳定性都会成为隐患。3.2 训练、微调、推理场景的卡型选择差异很多团队买卡时想“一卡走天下”结果发现训练、微调、推理对卡的需求重点完全不同。简单做了一张选型参考表场景核心瓶颈指标推荐卡型倾向关键注意事项预训练/大规模SFT显存容量、卡间互联带宽旗舰级计算卡多卡互联集群网络和并行策略比单卡性能更重要参数高效微调/LoRA显存容量、吞吐中高端计算卡或大显存卡批量大小受限时显存比算力更值钱在线推理单卡吞吐、延迟、并发强调显存带宽和批量推理的卡型必须实测连续批处理下的真实吞吐离线批量任务总吞吐、单位Token成本性价比中端卡可以大量堆叠用成本/Token来评估而不是单卡Tops这里重点说一下在线推理。推理服务普遍吃“并发”而并发能力很大程度上由显存决定显存够大就能同时塞进更多的请求做连续批处理GPU利用率才能拉起来。所以经常会看到推理场景用48GB显存的卡而不是24GB的旗舰游戏卡原因很简单一张48GB的卡能并发的请求数量几乎是24GB的两倍虽然单卡算力不一定更高但整体吞吐和成本更优。3.3 异构算力混合使用把每一分钱花在刀刃上真正上了生产环境以后你会发现一个企业级AI应用很少只有一个大模型在跑。一个智能客服系统顶层的对话生成用大模型中间的情绪判断、意图分类可能用一个小模型正则匹配和业务规则用CPU就能搞定后面的向量检索可能还需要一张中端卡专门跑Embedding。异构算力混合的本质是不要让70B大模型去干“过滤垃圾词”这类简单活。我们在一套系统里做过一次调优把高频简单请求从大模型切换到小模型和规则引擎大模型推理服务的QPS压力直接下降了60%而整体业务准确率几乎没有变化。这就是把算力花在刀刃上的典型做法。具体的资源分层可以参考这个思路第一层少量高端卡只跑核心大模型第二层中端卡或大显存卡跑小模型、向量化、多模态编码第三层CPU和普通服务器跑规则引擎、数据预处理、业务逻辑。这样一套组合下来同样的业务量算力成本往往能省30%到50%。不少客户在扩容前以为又要买几十张高端卡做完异构拆分后发现现有资源还能再撑一年。4. 多台算力服务器统一管理的工程落地4.1 算力集群的“管理平面”搭建思路GPU服务器数量一多管理问题会比买卡问题更早暴露。今天这台卡驱动坏了明天那台显存报错后天另一个团队说“我明明提交了任务为什么没跑起来”——这些都是多机管理的日常。当前最主流的两条路线一个是Kubernetes加GPU设备插件适合在线推理和微服务化应用另一个是Slurm这类任务调度器适合批量训练和离线计算。不少大型集群是两套并存在线服务走K8s离线训练走Slurm中间用共享存储和统一配额打通。如果是K8s路线核心是把GPU声明成可调度的资源。装上NVIDIA设备插件后Pod里声明nvidia.com/gpu: 1就能申请到一张卡Kubernetes会自动完成节点选择。骨架配置类似这样apiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-device-plugin-daemonset spec: selector: matchLabels: name: nvidia-device-plugin-ds template: metadata: labels: name: nvidia-device-plugin-ds spec: containers: - name: nvidia-device-plugin image: nvidia/k8s-device-plugin:latest imagePullPolicy: IfNotPresent securityContext: privileged: true env: - name: NVIDIA_VISIBLE_DEVICES value: all设备插件的作用不只是“让K8s认识GPU”它还会在每张卡上做健康检查发现ECC错误或驱动异常能自动摘除故障卡。这个自动隔离能力比你自己写脚本巡检靠谱得多强烈建议所有跑GPU的K8s集群都装一份。4.2 任务调度与资源池化从排队到动态分配多团队共享算力时最常见的矛盾就是“一个团队的任务把集群撑爆其他团队干等”。要解决这个问题必须做资源配额和分池。在Kubernetes里可以按项目建Namespace然后用ResourceQuota限制每个命名空间最多申请多少张GPUapiVersion: v1 kind: ResourceQuota metadata: name: gpu-quota namespace: ai-客服项目组 spec: hard: requests.nvidia.com/gpu: 8配额的意义不是限制增长而是让不同团队在同一个集群里有序共存。A团队最多只能占用8张卡剩下10张卡一定会留给B团队。谁先谁后、谁多谁少业务负责人去协调而不是靠运维每天手动“抢卡”。任务调度层面在线推理和离线训练要分开处理。在线推理是常驻服务建议优先调度保证延迟稳定离线训练任务可以用binpack策略尽最大可能把任务堆到同一批节点上把空闲节点的卡腾出来方便夜间整体断电节能。调度策略看起来不起眼但真能影响几十万元的月度电费。4.3 监控和告警算力的“水位计”和“早报警”多台算力服务器部署起来以后监控就是第一道防线。我推荐的最小组件组合是DCGM Exporter采集GPU硬件指标Prometheus做指标存储和告警Grafana出可视化面板Alertmanager负责通知。告警规则里最值得盯的几项指标包括监控指标正常范围需要关注的值含义GPU利用率40%-90%持续95%以上算力是否被打满显存使用率50%-80%持续90%以上可能OOM或KV Cache不足GPU温度65℃以下超过85℃散热或负载异常功耗低于TDP长时间满功率硬件寿命受影响推理P99延迟根据SLA超出目标值的1.5倍服务质量正在恶化排队请求数接近0持续增长算力即将不够一个典型告警规则示例groups: - name: gpu-alerts rules: - alert: GPU显存水位过高 expr: (1 - dcgm_memory_free / dcgm_memory_total) 0.9 for: 5m labels: severity: warning annotations: summary: 节点{{ $labels.instance }} GPU显存使用率超过90%这里有个我踩过的坑不要只盯“平均利用率”。某个节点5分钟内平均利用率60%看起来还好但实际上在晚高峰出现了连续10分钟的排队因为那5分钟内GPU前两分钟被打满后三分钟任务队列堆着没算完平均下来反而显得不高。所以监控不仅要做资源水位还要监控任务排队深度两者结合才能真实反映“算力是不是够了”。5. 企业级AI应用的工程化陷阱从Demo到生产的距离5.1 延迟抖动、并发峰值和故障恢复的实战处理每个项目在Demo阶段都很顺利一上生产就现原形。我参与过一个AI文档总结项目单机Demo时请求响应只要几百毫秒但全量上线后第一个小时P99延迟就到了3秒客户直接投诉。排查下来有三层问题。第一层是并发上来后GPU开始排队一批批请求堆积第二层是推理服务没有开连续批处理每个请求独占GPU资源浪费严重第三层是某两台的GPU驱动版本不一致其中一台性能明显下降。处理方案是四步走第一步统一驱动和推理框架版本消除节点差异第二步开启连续批处理让GPU同时处理多个请求吞吐直接翻倍第三步加缓存层短时间内的相似请求直接命中缓存减少重复计算第四步做多副本部署单节点故障时流量能自动切走。这里要特别强调缓存的价值。很多企业AI应用的重复率远超想象同一个会议纪要模板、同一段高频客服问答、同一个产品介绍可能每天被请求几百次。加一层语义缓存相同或相似输入直接返回之前的结果命中了就能省下这部分算力。我们实际项目中缓存命中率最高做到过35%相当于白送了三分之一算力。5.2 成本治理闲置算力、自动缩容与智能调度算力成本最大的坑不是买贵了而是买了没跑满。我见过不少企业GPU采购流程走了三个月终于到货后业务实际只用20%的资源大部分时间都在闲置。做成本治理有几个手段是直接被验证有效的给在线服务配置水平扩缩容低峰期缩到最小副本高峰期再拉起来离线训练任务集中到夜间和周末跑和在线推理错峰空闲超过一定时间的节点自动缩容或者切换到更便宜的算力资源池定期清理僵尸Pod和长期占用显存的残留任务。很多K8s集群默认不会回收闲置GPU明明没有业务在跑Pod还占着卡。这是资源浪费的大头。建议做一条定时任务定期扫描超过24小时没有流量的推理服务自动缩容到1个副本并在业务群发出通知。等有流量了再自动扩容。另外现在公共算力平台普遍支持按需购买比一次性的自建采购灵活很多。我们的策略是“自有集群保底公共算力弹性”平时自有集群跑常规流量大促或活动前临时从公共算力平台拉几十张卡等活动结束直接释放。这样既不需要为峰值买单也不会在低峰期养一堆闲置卡。5.3 数谷算力模式给企业带来的新选择过去企业要上AI最头疼的是基础设施GPU采购周期长、机房改造贵、运维要求高小团队根本没有能力独立搞定。数谷这类智能算力集聚区解决的问题就是“把算力变成像水电一样按需使用的服务”。现在常见的接入模式有三种。第一种是算力租用企业直接租GPU节点自己装环境、跑模型灵活度和自建几乎一样但不用管机房第二种是模型API服务算力方直接把大模型封装成接口企业按Token量付费省去部署和运维第三种是专属资源池算力方从物理层做隔离专门给某个企业保留一批算力满足数据安全要求。这三种模式对应的是不同阶段的企业需求。刚起步的团队用第二种最快跑通业务模型使用成熟后切到第一种可以精细调优降低成本需要数据合规和稳定容灾的再用第三种。数谷算力高增长本质上就是这三类需求同时被激活了。6. 数谷算力高增长的底层逻辑从资源供给到AI工程服务6.1 从“卖资源”转向“卖服务”算力像水电一样开通即用早期算力中心的核心业务是把GPU租出去本质上是卖硬件资源。这个模式有一个很明显的问题硬件资源是标准化的但企业需求是千差万别的。有的企业只要跑一个开源模型推理有的企业需要微调自己的行业模型还有的企业完全不想管GPU只要一个能调用的AI接口。高增长的“数谷”模式恰好是把这个链条走通了。平台不光提供裸算力还提供模型仓库、推理服务、微调工具、监控运维这些周边的工程能力。企业到平台上不是“买了一张卡”而是“开通了一个带大模型的AI服务”。这个转向非常关键它让不会写CUDA、不懂显存管理的普通开发团队也能用上企业级AI能力。从我们对接的经验来看企业选择算力服务商时最看重的往往不是单卡性能多强而是三个问题开通要多长时间、计费是不是灵活、出了问题能不能有人尽快响应。谁能把这三件事做扎实谁就能吃到这轮增长红利。6.2 从“训练为中心”到“训练推理Agent部署”的复合供给这轮数谷算力高增长和上一轮有明显区别上一轮主要靠大模型训练拉动训练任务再大也是波峰式、项目制的这轮增长的主力其实是推理和Agent部署是持续性的、生产级的。训练算力和推理算力的特性完全不同。训练任务可以排队晚几分钟提交没关系但对卡间互联和并行能力要求极高推理任务对延迟极其敏感用户点了一下“发送”按钮两三秒没响应就会觉得产品卡顿。数谷要给企业级AI应用提供算力底座就必须同时支持这两种负载并且用调度系统做错峰白天跑在线推理夜间把富余算力切换给离线训练。这里还有一个经常被忽略的细节Agent应用对算力的需求形态和传统推理不一样。一个Agent任务在运行过程中模型调用之间往往夹杂着工具调用、等待外部接口响应等阶段GPU在等待期其实是空转的。如果平台能把多个Agent任务交错调度把空窗期填上其他计算任务整体算力利用率能提升一大截。这不是单纯的硬件问题而是算力编排能力的体现。6.3 应用承载力的增强模型服务、工具链、智算生态最后聊一下生态。数谷智能算力这轮高增长不只是GPU出货量在涨更是AI应用承载力的整体增强。现在围绕算力平台已经长出来一批面向AI编程、AI短剧、AI智能体的开发工具链。这些工具链的普及又把更多企业拉入了AI应用的大门形成了一个正循环。我之前和一个做AI短剧的团队聊过他们的算力策略全部依赖公共算力平台分镜用文生图模型脚本用大模型生成配音用语音合成最后调用视频生成模型合成片段。整个制作流程要跑好几个模型但团队没有购买任何一台GPU服务器全部通过API按量调用。这种“轻资产”模式让很多以前不敢碰AI的企业开始提速算力需求也随之上涨。对企业用户来说算力供应越丰富、生态越成熟越不需要自己从零建设。所以我的建议是做企业级AI应用规划时不要再把自己当作“要买GPU机房的人”而是当作“要挑选算力服务组合的人”。先看业务需要哪几类模型、量级多大、数据安全要求多高再去匹配自有算力、公共算力、模型API这三种资源的比例。选型对了后面几年的成本曲线和扩容节奏都会舒服很多。如果让我重新做一次算力规划我会先花一到两周时间把业务侧的Token消耗摸清楚再做一次推理基准测试最后才谈买卡和选型。先小规模验证再逐步扩容宁可多等一个月也不要一上来就囤几十张卡放在那儿吃灰。算力高增长是行业的红利但落到每个企业头上终究比的是谁算得更细、用得更省。
企业级AI应用最近两年的变化比前面十年加起来都多。“算力”这两个字从技术圈的性能参数讨论变成了企业管理者和财务都要盯着的经营指标以“数谷”为代表的智能算力集聚区也实实在在迎来了一轮高增长。我自己长期做AI平台和基础设施最直观的感受不是来自发布会上的新模型而是客户发来的算力容量规划需求——越来越具体、越来越着急、问题也越来越复杂。这篇文章我会从实际项目视角出发重点讲清楚几件事企业级AI应用到底在哪些环节消耗算力、怎么把业务量换算成Token和GPU卡数、选卡时为什么不能只看Tops排行、多台算力服务器统一管理怎么做以及从Demo到稳定生产之间最容易被忽视的坑。如果你是正在给企业AI应用做算力规划的同学或者被领导冷不丁问了一句“我们到底要买多少卡”这篇文章应该能给你一张可落地的参照表。1. 算力需求的真实增长点企业级AI应用到底在用什么“吃”算力1.1 从单点尝鲜到核心业务嵌入前几年聊AI算力大家谈得最多的是“训练一个模型需要多少卡”。那时候AI在企业里大多是锦上添花的项目做一个问答机器人、跑一轮测试数据、生成几张营销图算力消耗是偶发性的一个季度也跑不了几次大任务。现在的局面完全不一样。企业级AI应用开始进入核心业务流程而且是7×24小时在线的那种。智能客服要处理全天候的用户会话营销团队用大模型批量生成文案和短视频脚本研发团队用AI编程工具做代码补全和Review运营团队让Agent自动整理数据报表。这些场景没有一个是一次性任务全部是持续性的生产流量。我见过最典型的案例是一家零售企业的客服系统改造。原来人工客服高峰期要100多人同时在线后来接入了大模型辅助回复。刚开始只是给客服人员做回复建议算力消耗不温不火后来业务方觉得效果不错直接做了面向用户的智能体还接入了App、小程序和外呼电话三个入口。结果一个月内每秒的模型请求数翻了40多倍原来的两组GPU服务器直接被打满。这个转变非常真实企业AI应用一旦进入核心业务线算力需求就不是线性增长了而是台阶式跳涨。1.2 三类高消耗场景大模型推理、Agent编排、多模态内容生成如果说算力需求存在“三驾马车”那当前最明显的三类高消耗场景分别是场景类型典型例子算力消耗特征增长特点在线大模型推理智能客服、代码补全、智能文档总结请求并发高输出Token持续生成随业务流量波动7×24在线Agent编排与多轮调用自动数据分析、自动化运维、研究助手单个任务会反复调用模型多次一次任务消耗放大数倍多模态内容生成AI短剧、AI分镜、AI配音、营销视频图像和视频生成算力消耗极高任务格式升级带动消耗暴涨先聊在线推理。大模型推理的特点是“每次请求都要实时跑一遍模型”模型在显存里推理时一遍遍读取权重并计算。对于一个7B参数的模型每生成一个Token都要做一次完整的前向计算输出1000个Token就是1000次前向计算。并发一高GPU立刻成为瓶颈这也是为什么很多企业感知到的算力压力主要来自推理接口。Agent编排这个场景特别容易被人低估。很多人觉得Agent无非是把模型调用包装了一下算力消耗和普通聊天差不多。但实际生产里一个Agent任务经常要分解成规划、工具调用、结果分析、再生成回复多个步骤每一步都可能调用一次模型。之前我们给一个数据分析Agent做压测单个任务平均要调用大模型6次每次输入输出加一起差不多2000多个Token。如果业务方规划的是每天10万个任务那实际产生的模型调用量就是60万次——这就是隐形的算力放大器。多模态内容生成就更不用说了。AI生成一张图片所需的算力是文本生成的几十倍AI生成一段几分钟的视频算力消耗又比图片高一个数量级。最近AI短剧和AI漫剧的制作流程开始大量使用生成式AI做分镜、换脸、配音和特效这个方向一旦跑起来单项目消耗的GPU时数很容易超过传统业务一整年的用量。1.3 为什么这些需求会往“数谷”汇聚企业算力需求暴涨之后自然会面临一个现实问题自己的机房放不下。一方面GPU采购周期长另一方面电力、散热、机柜资源这些都不是一朝一夕能解决的。于是越来越多的企业选择把大模型推理、训练任务放到算力集聚区去这就是“数谷”这类智能算力枢纽高增长的原因之一。数谷式的算力供给逻辑和以前卖几台服务器完全是两回事。它的核心是把分散在各地的小算力池集中起来统一调度、统一计费、统一运维企业不用自己操心基础设施开通就能用。这个模式在今年明显加速从我们对接过的几十家客户来看几乎有一半已经或正在考虑把GPU资源从自建机房迁移到公共算力服务平台。2. 把“Token算力需求”说清楚企业AI算力规划的第一步2.1 从业务指标反推Token吞吐量做算力规划时99%的人第一句话是“我们想上一个大模型”第二句话是“大概需要多少张卡”。但“多少张卡”不是一个可以直接回答的问题它需要一个中间变量Token吞吐量。Token是模型处理文本的最小单位一个汉字大概对应1到2个Token。算力规划的底层逻辑就是先把业务请求量换算成每秒需要处理的Token数量再用Token吞吐量反推需要多少张GPU。具体怎么换算先收集几个关键业务指标高峰期的请求并发数QPS单次请求的平均输入Token数单次请求的平均输出Token数预留的峰值冗余倍数。计算公式可以简化成每秒Token需求 并发QPS × (平均输入Token数 平均输出Token数)举个例子一个智能客服系统高峰期并发50个请求每个请求平均输入800个Token、输出600个Token那每秒的Token需求量就是50 × (800 600) 70,000 Token/s这里要提醒一下模型处理输入和输出的机制不太一样。输入阶段PreFill是并行计算吃算力输出阶段Decode是逐个Token生成更吃显存带宽。但做容量规划时先用总量估算出一个方向再结合具体框架做基准测试这是最务实的思路。2.2 从Token需求到卡数估算一个完整示例光说公式容易飘我拿一个真实的规划案例来演示。有一家客户要做智能客服Agent业务目标是高峰期每分钟处理300个会话每个会话内部平均要调用大模型3次每次请求的输入加输出共9000个Token。先计算单次会话需要的Token量每个Agent会话Token量 3次调用 × 9000 Token 27,000 Token高峰期一分钟300个会话一分钟的Token需求300 × 27,000 8,100,000 Token/min换算成每秒8,100,000 / 60 135,000 Token/s看到这个数字等于每秒需要处理13.5万个Token。接下来看单张GPU能跑多少。我们当时用一款主流推理卡做基准测试在7B参数模型、开启连续批处理的条件下单卡实测吞吐大概是9000到10000 Token/s。按9000算135,000 / 9000 ≈ 15 张卡但这只是“刚好顶住”的卡数没有算冗余。企业级生产环境一般要预留至少50%的余量应对流量突刺和单卡故障15 × 1.5 22.5向上取整就是23到24张卡再把显存校验考虑进去。7B模型FP16权重约14GB加上4096上下文的KV Cache和推理框架的运行时开销单张卡跑2到4个并发会话比较合适。高峰期需要50个并发会话需要跑节点的副本数至少也要十几二十个。综合算下来之前估算的24张卡在数量上是合理的但分布方式需要调整——比如拆成3个节点每个节点8卡既保证并发能力又预留单节点故障的迁移空间。2.3 Token评估中最容易出现的两个偏差Token评估做多了会发现大家常踩两个坑一是只用理论峰值做估算二是低估长上下文对显存的消耗。第一个坑很好理解。GPU的Tops很高但实际业务能跑出的Token吞吐远远低于理论峰值因为模型推理除了算力还吃显存带宽、批处理策略和框架优化。同样一张卡有人能跑到8000 Token/s有人只跑出3000 Token/s差距基本都出在框架和参数配置上。所以在做卡数估算前一定要先用自己手里的模型和推理框架做一轮基准测试别直接套用厂商的理论数字。第二个坑是长上下文的显存消耗。很多Agent应用喜欢把历史对话、知识库片段全塞进上下文里上下文一长KV Cache的显存消耗是线性增长的。原来2048上下文时一张卡能塞8个并发请求改成8192上下文后可能4个都塞不进去。这不是模型本身变大了而是KV Cache把显存吃了。评估时如果只看模型参数量一定会出现“买的卡数够但一上线显存就爆”的尴尬。我在实际操作中养成了一个习惯所有容量评估表格里除了卡数和Token吞吐一定会单独列一栏“最大上下文长度”。这一栏看起来不起眼但往往是决定显存够不够的关键参数。3. GPU选型与算力组合别只盯着Tops排行3.1 Tops、显存、显存带宽与吞吐谁才是关键指标打开各大算力评测榜满屏都是“AI算力Tops排行”。Tops代表显卡的理论峰值算力看起来非常直观但它只是“发动机排量”不是实际车速。大模型推理这个场景里瓶颈往往不在算力而在显存带宽。为什么因为推理时模型权重固定在显存里每生成一个Token都要把全部权重从显存搬到计算单元过一遍。我常打一个比方算力是仓库里搬运工的数量显存带宽是传送带的宽度。传送带不够宽搬运工再多也只能排队等着。有个非常实用的估算公式单Token生成延迟约等于“模型权重字节数除以显存带宽”。以70B模型为例FP16权重约140GB如果显存带宽是2TB/s那生成一个Token的理论延迟大约是70毫秒。用户体感上就是模型打字有点慢。如果用INT4量化权重降到35GB同样带宽下延迟能压到20毫秒以内。这个公式能解释为什么量化对大模型推理提速这么明显——不是算力变强了而是需要搬的数据变少了。选择GPU时除了Tops至少还要看三个指标显存容量、显存带宽、以及是否支持企业级可靠性特性比如ECC显存纠错。家庭卡用作开发调试没问题但7×24小时在线服务长期跑高负载风扇寿命、显存报错、驱动稳定性都会成为隐患。3.2 训练、微调、推理场景的卡型选择差异很多团队买卡时想“一卡走天下”结果发现训练、微调、推理对卡的需求重点完全不同。简单做了一张选型参考表场景核心瓶颈指标推荐卡型倾向关键注意事项预训练/大规模SFT显存容量、卡间互联带宽旗舰级计算卡多卡互联集群网络和并行策略比单卡性能更重要参数高效微调/LoRA显存容量、吞吐中高端计算卡或大显存卡批量大小受限时显存比算力更值钱在线推理单卡吞吐、延迟、并发强调显存带宽和批量推理的卡型必须实测连续批处理下的真实吞吐离线批量任务总吞吐、单位Token成本性价比中端卡可以大量堆叠用成本/Token来评估而不是单卡Tops这里重点说一下在线推理。推理服务普遍吃“并发”而并发能力很大程度上由显存决定显存够大就能同时塞进更多的请求做连续批处理GPU利用率才能拉起来。所以经常会看到推理场景用48GB显存的卡而不是24GB的旗舰游戏卡原因很简单一张48GB的卡能并发的请求数量几乎是24GB的两倍虽然单卡算力不一定更高但整体吞吐和成本更优。3.3 异构算力混合使用把每一分钱花在刀刃上真正上了生产环境以后你会发现一个企业级AI应用很少只有一个大模型在跑。一个智能客服系统顶层的对话生成用大模型中间的情绪判断、意图分类可能用一个小模型正则匹配和业务规则用CPU就能搞定后面的向量检索可能还需要一张中端卡专门跑Embedding。异构算力混合的本质是不要让70B大模型去干“过滤垃圾词”这类简单活。我们在一套系统里做过一次调优把高频简单请求从大模型切换到小模型和规则引擎大模型推理服务的QPS压力直接下降了60%而整体业务准确率几乎没有变化。这就是把算力花在刀刃上的典型做法。具体的资源分层可以参考这个思路第一层少量高端卡只跑核心大模型第二层中端卡或大显存卡跑小模型、向量化、多模态编码第三层CPU和普通服务器跑规则引擎、数据预处理、业务逻辑。这样一套组合下来同样的业务量算力成本往往能省30%到50%。不少客户在扩容前以为又要买几十张高端卡做完异构拆分后发现现有资源还能再撑一年。4. 多台算力服务器统一管理的工程落地4.1 算力集群的“管理平面”搭建思路GPU服务器数量一多管理问题会比买卡问题更早暴露。今天这台卡驱动坏了明天那台显存报错后天另一个团队说“我明明提交了任务为什么没跑起来”——这些都是多机管理的日常。当前最主流的两条路线一个是Kubernetes加GPU设备插件适合在线推理和微服务化应用另一个是Slurm这类任务调度器适合批量训练和离线计算。不少大型集群是两套并存在线服务走K8s离线训练走Slurm中间用共享存储和统一配额打通。如果是K8s路线核心是把GPU声明成可调度的资源。装上NVIDIA设备插件后Pod里声明nvidia.com/gpu: 1就能申请到一张卡Kubernetes会自动完成节点选择。骨架配置类似这样apiVersion: apps/v1 kind: DaemonSet metadata: name: nvidia-device-plugin-daemonset spec: selector: matchLabels: name: nvidia-device-plugin-ds template: metadata: labels: name: nvidia-device-plugin-ds spec: containers: - name: nvidia-device-plugin image: nvidia/k8s-device-plugin:latest imagePullPolicy: IfNotPresent securityContext: privileged: true env: - name: NVIDIA_VISIBLE_DEVICES value: all设备插件的作用不只是“让K8s认识GPU”它还会在每张卡上做健康检查发现ECC错误或驱动异常能自动摘除故障卡。这个自动隔离能力比你自己写脚本巡检靠谱得多强烈建议所有跑GPU的K8s集群都装一份。4.2 任务调度与资源池化从排队到动态分配多团队共享算力时最常见的矛盾就是“一个团队的任务把集群撑爆其他团队干等”。要解决这个问题必须做资源配额和分池。在Kubernetes里可以按项目建Namespace然后用ResourceQuota限制每个命名空间最多申请多少张GPUapiVersion: v1 kind: ResourceQuota metadata: name: gpu-quota namespace: ai-客服项目组 spec: hard: requests.nvidia.com/gpu: 8配额的意义不是限制增长而是让不同团队在同一个集群里有序共存。A团队最多只能占用8张卡剩下10张卡一定会留给B团队。谁先谁后、谁多谁少业务负责人去协调而不是靠运维每天手动“抢卡”。任务调度层面在线推理和离线训练要分开处理。在线推理是常驻服务建议优先调度保证延迟稳定离线训练任务可以用binpack策略尽最大可能把任务堆到同一批节点上把空闲节点的卡腾出来方便夜间整体断电节能。调度策略看起来不起眼但真能影响几十万元的月度电费。4.3 监控和告警算力的“水位计”和“早报警”多台算力服务器部署起来以后监控就是第一道防线。我推荐的最小组件组合是DCGM Exporter采集GPU硬件指标Prometheus做指标存储和告警Grafana出可视化面板Alertmanager负责通知。告警规则里最值得盯的几项指标包括监控指标正常范围需要关注的值含义GPU利用率40%-90%持续95%以上算力是否被打满显存使用率50%-80%持续90%以上可能OOM或KV Cache不足GPU温度65℃以下超过85℃散热或负载异常功耗低于TDP长时间满功率硬件寿命受影响推理P99延迟根据SLA超出目标值的1.5倍服务质量正在恶化排队请求数接近0持续增长算力即将不够一个典型告警规则示例groups: - name: gpu-alerts rules: - alert: GPU显存水位过高 expr: (1 - dcgm_memory_free / dcgm_memory_total) 0.9 for: 5m labels: severity: warning annotations: summary: 节点{{ $labels.instance }} GPU显存使用率超过90%这里有个我踩过的坑不要只盯“平均利用率”。某个节点5分钟内平均利用率60%看起来还好但实际上在晚高峰出现了连续10分钟的排队因为那5分钟内GPU前两分钟被打满后三分钟任务队列堆着没算完平均下来反而显得不高。所以监控不仅要做资源水位还要监控任务排队深度两者结合才能真实反映“算力是不是够了”。5. 企业级AI应用的工程化陷阱从Demo到生产的距离5.1 延迟抖动、并发峰值和故障恢复的实战处理每个项目在Demo阶段都很顺利一上生产就现原形。我参与过一个AI文档总结项目单机Demo时请求响应只要几百毫秒但全量上线后第一个小时P99延迟就到了3秒客户直接投诉。排查下来有三层问题。第一层是并发上来后GPU开始排队一批批请求堆积第二层是推理服务没有开连续批处理每个请求独占GPU资源浪费严重第三层是某两台的GPU驱动版本不一致其中一台性能明显下降。处理方案是四步走第一步统一驱动和推理框架版本消除节点差异第二步开启连续批处理让GPU同时处理多个请求吞吐直接翻倍第三步加缓存层短时间内的相似请求直接命中缓存减少重复计算第四步做多副本部署单节点故障时流量能自动切走。这里要特别强调缓存的价值。很多企业AI应用的重复率远超想象同一个会议纪要模板、同一段高频客服问答、同一个产品介绍可能每天被请求几百次。加一层语义缓存相同或相似输入直接返回之前的结果命中了就能省下这部分算力。我们实际项目中缓存命中率最高做到过35%相当于白送了三分之一算力。5.2 成本治理闲置算力、自动缩容与智能调度算力成本最大的坑不是买贵了而是买了没跑满。我见过不少企业GPU采购流程走了三个月终于到货后业务实际只用20%的资源大部分时间都在闲置。做成本治理有几个手段是直接被验证有效的给在线服务配置水平扩缩容低峰期缩到最小副本高峰期再拉起来离线训练任务集中到夜间和周末跑和在线推理错峰空闲超过一定时间的节点自动缩容或者切换到更便宜的算力资源池定期清理僵尸Pod和长期占用显存的残留任务。很多K8s集群默认不会回收闲置GPU明明没有业务在跑Pod还占着卡。这是资源浪费的大头。建议做一条定时任务定期扫描超过24小时没有流量的推理服务自动缩容到1个副本并在业务群发出通知。等有流量了再自动扩容。另外现在公共算力平台普遍支持按需购买比一次性的自建采购灵活很多。我们的策略是“自有集群保底公共算力弹性”平时自有集群跑常规流量大促或活动前临时从公共算力平台拉几十张卡等活动结束直接释放。这样既不需要为峰值买单也不会在低峰期养一堆闲置卡。5.3 数谷算力模式给企业带来的新选择过去企业要上AI最头疼的是基础设施GPU采购周期长、机房改造贵、运维要求高小团队根本没有能力独立搞定。数谷这类智能算力集聚区解决的问题就是“把算力变成像水电一样按需使用的服务”。现在常见的接入模式有三种。第一种是算力租用企业直接租GPU节点自己装环境、跑模型灵活度和自建几乎一样但不用管机房第二种是模型API服务算力方直接把大模型封装成接口企业按Token量付费省去部署和运维第三种是专属资源池算力方从物理层做隔离专门给某个企业保留一批算力满足数据安全要求。这三种模式对应的是不同阶段的企业需求。刚起步的团队用第二种最快跑通业务模型使用成熟后切到第一种可以精细调优降低成本需要数据合规和稳定容灾的再用第三种。数谷算力高增长本质上就是这三类需求同时被激活了。6. 数谷算力高增长的底层逻辑从资源供给到AI工程服务6.1 从“卖资源”转向“卖服务”算力像水电一样开通即用早期算力中心的核心业务是把GPU租出去本质上是卖硬件资源。这个模式有一个很明显的问题硬件资源是标准化的但企业需求是千差万别的。有的企业只要跑一个开源模型推理有的企业需要微调自己的行业模型还有的企业完全不想管GPU只要一个能调用的AI接口。高增长的“数谷”模式恰好是把这个链条走通了。平台不光提供裸算力还提供模型仓库、推理服务、微调工具、监控运维这些周边的工程能力。企业到平台上不是“买了一张卡”而是“开通了一个带大模型的AI服务”。这个转向非常关键它让不会写CUDA、不懂显存管理的普通开发团队也能用上企业级AI能力。从我们对接的经验来看企业选择算力服务商时最看重的往往不是单卡性能多强而是三个问题开通要多长时间、计费是不是灵活、出了问题能不能有人尽快响应。谁能把这三件事做扎实谁就能吃到这轮增长红利。6.2 从“训练为中心”到“训练推理Agent部署”的复合供给这轮数谷算力高增长和上一轮有明显区别上一轮主要靠大模型训练拉动训练任务再大也是波峰式、项目制的这轮增长的主力其实是推理和Agent部署是持续性的、生产级的。训练算力和推理算力的特性完全不同。训练任务可以排队晚几分钟提交没关系但对卡间互联和并行能力要求极高推理任务对延迟极其敏感用户点了一下“发送”按钮两三秒没响应就会觉得产品卡顿。数谷要给企业级AI应用提供算力底座就必须同时支持这两种负载并且用调度系统做错峰白天跑在线推理夜间把富余算力切换给离线训练。这里还有一个经常被忽略的细节Agent应用对算力的需求形态和传统推理不一样。一个Agent任务在运行过程中模型调用之间往往夹杂着工具调用、等待外部接口响应等阶段GPU在等待期其实是空转的。如果平台能把多个Agent任务交错调度把空窗期填上其他计算任务整体算力利用率能提升一大截。这不是单纯的硬件问题而是算力编排能力的体现。6.3 应用承载力的增强模型服务、工具链、智算生态最后聊一下生态。数谷智能算力这轮高增长不只是GPU出货量在涨更是AI应用承载力的整体增强。现在围绕算力平台已经长出来一批面向AI编程、AI短剧、AI智能体的开发工具链。这些工具链的普及又把更多企业拉入了AI应用的大门形成了一个正循环。我之前和一个做AI短剧的团队聊过他们的算力策略全部依赖公共算力平台分镜用文生图模型脚本用大模型生成配音用语音合成最后调用视频生成模型合成片段。整个制作流程要跑好几个模型但团队没有购买任何一台GPU服务器全部通过API按量调用。这种“轻资产”模式让很多以前不敢碰AI的企业开始提速算力需求也随之上涨。对企业用户来说算力供应越丰富、生态越成熟越不需要自己从零建设。所以我的建议是做企业级AI应用规划时不要再把自己当作“要买GPU机房的人”而是当作“要挑选算力服务组合的人”。先看业务需要哪几类模型、量级多大、数据安全要求多高再去匹配自有算力、公共算力、模型API这三种资源的比例。选型对了后面几年的成本曲线和扩容节奏都会舒服很多。如果让我重新做一次算力规划我会先花一到两周时间把业务侧的Token消耗摸清楚再做一次推理基准测试最后才谈买卡和选型。先小规模验证再逐步扩容宁可多等一个月也不要一上来就囤几十张卡放在那儿吃灰。算力高增长是行业的红利但落到每个企业头上终究比的是谁算得更细、用得更省。
