这两年做企业级AI应用最大的感受就一个字挤。不是说市场挤而是算力资源特别挤尤其是推理侧的算力。前两年大家聊AI还停留在“调个API试试”今年已经完全变了企业客户开口就是“我们想把智能客服接到生产系统里”“我们想让Agent自动做报表和工单”随之而来的就是从测试环境到生产环境的算力瓶颈。“数谷智能算力迎来高增长”这个标题我在一线是实打实感受到了。我们所在的产业园区几个智算中心今年都在密集扩容采购型号从4090一路看到H800、L40S排队等卡的周期越来越长。但更让我头疼的不是买不到卡而是很多企业根本不知道买来的卡怎么分配、怎么评估够不够用、怎么在多台服务器之间统一调度。算力涨得快使用效率却普遍跟不上这中间的落差恰恰是真正值得写一写的东西。这篇博文不聊“算力是未来”这种正确废话就围绕企业级AI应用落地时最现实的几个问题展开token算力需求到底怎么评估、多台算力服务器怎么统一管理、Agent应用为什么比传统问答更烧算力、以及我在实际排障中踩过的坑。希望能给正在做AI Infra或者正打算上算力集群的朋友一些参考。1. 算力高增长背后的真实需求企业AI应用到底消耗了什么1.1 从“跑demo”到“跑生产”算力需求完全不是一个量级我发现很多团队对算力的理解还停留在demo阶段。做个演示系统一台带GPU的开发机就够了最多微调一个小模型跑几个推理请求看起来一切都很美好。一旦进入生产环境情况立刻失控并发用户进来了上下文变长了RAG要检索大量知识库片段Agent还会反复调用工具和模型token消耗量翻几十倍。最典型的是客户服务场景。一个纯客服QA机器人单次请求的输入加输出可能只有300到500个token但同样是客服场景如果接入了Agent让它先去查订单、再看退款规则、再生成答复往往要调用大模型5到8次单次任务轻松消耗1万到5万token。如果每个请求还要携带长长的系统提示词和历史会话记录token量还会继续膨胀。所以说企业级AI应用一旦跑起来算力需求在三个维度同时放大并发数、单请求token数、请求链路长度。规划算力的时候如果只按demo阶段的调用量乘以一个系数大概率第一批卡买回来就不够用。1.2 训练、推理、调度三种算力形态别混为一谈算力这个词被用得太泛了实际在工程上至少应该拆成三个维度训练算力、推理算力、调度算力。训练算力是集中式、长周期的典型场景是预训练和微调。它最关心的是算力集群的线性扩展能力和单卡浮点性能一般用TFLOPS、显存带宽、NCCL通信效率来评估。大多数企业其实不需要天天训练大模型一年可能就做几次微调这块投入是一次性的。推理算力是持续型、高并发的也是企业AI应用每天烧钱最多的地方。推理和训练的优化方向完全不同推理更看重延迟、吞吐和单位token成本所以量化、动态batching、KV Cache复用这些技巧都用在推理侧。调度算力则容易被忽略它指的是把多台服务器上的GPU资源统一管理起来按需分配给不同任务和团队。没有调度层再多的卡也只能是一堆零散的机器有了调度层8张卡和80张卡才能变成一个可伸缩的资源池。今年“数谷智能算力高增长”增长的其实主要是推理和调度侧的投入。企业级AI应用之前不显山不露水是因为大家都在试水真正跑量之后推理算力的需求会像滚雪球一样变大。我建议大家做预算时把权重放在推理算力不要被“训练大模型”这种话术带偏。2. token算力需求评估先算清楚账再谈采购2.1 一个可复用的算力估算公式很多企业问的第一个问题就是我们要上AI应用到底需要多少张GPU说实话没人能一眼给出精确数字但我们可以用一个估算公式把账算个七七八八。整体思路是这样的先估算业务高峰期的token吞吐需求再除以单卡推理吞吐得到卡数。[ \text{所需GPU数量} \approx \frac{\text{高峰期每秒输出token数}}{\text{单卡每秒可输出token数}} ]单卡每秒可输出token数怎么估以7B模型为例FP16精度下用vLLM这类优化过动态batching的推理框架A100/H100级别的单卡输出吞吐保守取50到80 token/s如果用了INT8量化吞吐能提升到80到120 token/s如果模型是13B吞吐大概按7B的60%到70%折算。关键点在于这里一定要区分“输入token”和“输出token”。输入阶段是并行计算速度快输出阶段是自回归逐token生成算力成本高得多。所以估算时应以输出token吞吐为基准输入token的算力开销可以折算为输出token开销的50%到100%叠加进去或者通过实测确定输入输出比例后加权计算。下面是一个完整的估算案例。2.2 一个客服Agent的GPU需求估算案例假设某企业的智能客服Agent每天处理10万次请求高峰集中在4个小时内也就是大概4万秒。那么高峰期每秒需要处理约2.5个请求。每个请求的链路假设如下Agent规划、工具调用、RAG检索、回复生成平均总输出token约1500 token平均总输入token约5000 token。由于输入token的算力成本大约是输出token的一半等效输出token量约为[ 5000 \times 0.5 1500 4000 \text{ token/请求} ]高峰期每秒等效输出token需求[ 2.5 \times 4000 10000 \text{ token/s} ]如果用7B模型A100单卡FP16输出吞吐按60 token/s算理论上需要约167张卡。这个数字会吓到很多人但现实中通过三个手段可以压缩它。第一是prompt cache。客服场景的系统提示词和RAG前缀相对固定命中情况下输入token的重复计算可以省掉80%以上等效输出token需求可能从4000降到2200左右。第二是动态batching把并发请求拼成batch单卡吞吐能从60提升到100以上。第三是INT8量化吞吐再提升一截。经过这三项优化同样的业务量可能只需要50到70张卡。所以我的结论是评估算力需求时先算业务侧的量再算推理优化后的吞吐否则你会在算力采购上多花两到三倍的钱。2.3 评估过程中常见的三个误区误区一只看模型参数量不看上下文长度。7B模型听起来很轻量但RAG场景下一个请求塞进8000个token的上下文KV Cache会吃掉大量显存。7B模型的KV Cache每个token大概要占MB级别的显存具体取决于层数和注意力头数。8000个token的上下文单个并发请求就可能吃几GB显存。评估卡数时如果不考虑上下文长度按短文本对话来估一到生产环境就直接显存溢出。误区二把输入token当成总token来算。现在各家模型厂商的计费方式通常是输入便宜、输出贵这个差异在算力消耗上一样存在。推理GPU在生成阶段是逐token自回归计算速度天然慢。很多团队拿输入token量去估算吞吐出来一个很乐观的数字上线后才发现生成延迟完全不可控。误区三忽略降级策略。真实业务的并发曲线不可能永远在峰值给所有峰值都配置满满的算力意味着大部分时间算力闲置。合理的做法是设置限流、排队、缓存降级机制让算力池承载85%的峰值即可剩下15%用排队或者更便宜的备用算力扛过去。算力规划不是做数学题而是在成本和体验之间找平衡。另外一个经验不要等算力不够了再临时加机器。我看到很多项目是先跑起来线上GPU利用率长时间超过90%然后再紧急采购中间业务已经损失了。建议上线前就按上述公式做一次估算同时预留30%的缓冲算力用来应对突发的流量尖峰。3. AI Infra建设多算力服务器统一管理的工程实践3.1 资源池化让不同项目的GPU共享起来算力买回来只是第一步更难的是怎么管。早期我们公司就是这么个状态算法部门买了4张A100做模型训练业务部门买了8张4090跑推理数据团队又弄了几台旧的V100做数据处理。每拨人各管各的机器谁也不知道对方的GPU利用率是多少。后来做了一次摸底A100集群利用率只有30%4090那边倒是跑得很满但V100基本闲着。这个问题的解法就是资源池化。把底层GPU资源统一纳管变成一个可以按需申请的资源池。具体来说我建议用容器化加集群调度器的方式落地。训练任务可以走Slurm在线推理服务可以走Kubernetes加Volcano或者Koordinator这类调度组件。Kubernetes本身对GPU也有支持通过nvidia-device-plugin暴露GPU资源调度器负责把Pod调度到有卡的节点上。我们实践下来的标准做法是集群节点按GPU型号打标签比如gpu-typea100、gpu-type4090不同任务通过调度器声明自己需要的GPU型号和数量由调度器统一分配。同时挂载共享存储模型权重和数据集放在共享存储里节点不用重复拷贝。镜像放在私有仓库节点热加载。这样加新卡、换节点都不需要改任务配置调度器自己会找资源。资源池化最大的收益不是省了买卡的钱而是把零散的碎片算力汇集成一个整体利用率能普遍从30%拉高到60%以上。3.2 异构算力怎么选消费级显卡能不能当生产卡这个问题几乎每个客户都会问因为4090价格实在是诱人。我的看法是消费级显卡和服务器级显卡不是同一个物种使用场景完全不同。对比项其实很清晰维度消费级显卡如RTX 4090企业级显卡如L40S、A100、H800单卡价格低约1万多到2万高几万到几十万不等显存容量24GB封顶48GB到96GB起步NVLink互联不支持支持多卡通信效率高稳定性与散热面向单机消费场景7x24小时机房环境设计驱动与生态部分场景受限官方支持完善适用场景开发测试、小规模推理生产级推理、模型训练我的经验是4090非常适合做开发、测试、原型验证甚至在低并发推理场景下可以承担生产任务。但它的显存只有24GB这意味着13B模型量化后还能勉强跑70B模型基本无望。同时没有NVLink多卡训练或超大模型的张量并行会非常吃力通信会成为瓶颈。如果企业预算有限可以用“混部”策略把消费级显卡和服务器级显卡放在同一个资源池里用调度器打标签隔离。生产环境的强一致性服务跑在企业级显卡上内部工具、非核心批处理任务放在4090上。注意不要让不同优先级的任务混在同一张卡上否则一个把显存打满另一个直接OOM互相影响。3.3 弹性扩缩容给算力池装一个“水龙头”算力管理做到资源池化还只是第一步真正要解决的是伸缩问题。企业AI应用的流量通常有明确的波峰波谷比如白天办公时间高凌晨低电商行业大促高日常低。如果算力池只能固定规模那要么高峰期扛不住要么闲时白白浪费电费。我建议给算力池加自动扩缩容能力。在线推理服务用Kubernetes的话可以基于自定义指标来做HPA比如按GPU利用率、请求排队长度、平均推理延迟来触发扩容。我们常用的是“双指标”策略当GPU利用率连续5分钟超过75%且请求平均延迟超过800毫秒时扩容节点当GPU利用率连续30分钟低于30%时缩容节点。冷却时间至少设置10到15分钟避免因流量抖动频繁扩缩容。扩容方式上要区分两种一是集群内部扩容就是唤醒闲置节点二是跨云扩容把本地算力池和公有云算力池连起来。跨云扩容需要网络打通、镜像同步、鉴权互通复杂度高一些但能用云上弹性资源应对极高峰值省下大量固定成本。这里要特别提醒一个坑很多模型加载到显存需要30秒甚至几分钟弹性扩容如果等到请求积压才开始加载用户早就超时了。所以要做“预扩容”根据历史流量曲线提前半小时预测性地扩容到预期水位或者对服务副本设置最小保留数避免全部缩光后冷启动。4. AI Agent与企业级AI应用的工程化落地4.1 为什么Agent应用更容易“烧穿”算力池如果只是做一个普通的RAG问答算力需求其实可控。但今年大量企业开始上Agent算力消耗就完全不一样了。原因是Agent的工作机制决定的。一个Agent任务通常要经历规划、拆解、调用工具、读取结果、判断下一步、最终生成答案等环节。每个环节都很可能要调用一次大模型少的三四次多的十几次。而且为了让Agent“记住”上下文每一轮调用都要携带之前的全部对话状态输入token会越滚越大。一个复杂任务消耗几十万token都是正常的。还有一个隐蔽的放大因素系统提示词。为了让Agent遵循规则开发者会写很长的system prompt可能几千字再加上工具描述、字段定义、few-shot示例。这些内容在每一次模型调用里都会被完整计算基本等同于白付的算力成本。RAG场景下每次检索回来的相关片段也被塞进上下文可能又是几千token。这并不意味着Agent这条路走错了而是说做Agent应用时一定要把“算力效率”当成功能需求来设计。比如减少无效重试工具调用失败后首先要做的是修正调用参数而不是无脑重新生成能一步完成的工具调用不要为它搭一条多轮Agent链路高频小场景可以考虑用一个专用的小模型去承接而不是所有请求都堆给最大的模型。4.2 推理优化三板斧量化、缓存、请求合并算力池能扩容但成本也摆在那里所以推理侧的优化比什么都重要。我总结下来最立竿见影的是三板斧。第一是量化。把模型从FP16压到INT8显存占用能减少接近一半推理吞吐通常提升30%到50%。INT4更激进显存占用降到四分之一但精度损失明显适合对结果质量不敏感的场景。实操中我建议在业务数据集上做量化前后的效果对比不要只盯着指标好看。量化后的模型要进行回归测试尤其是Agent场景一个实体识别错误就可能让整条链路崩掉。第二是缓存。推理框架普遍支持前缀缓存和KV Cache复用多轮对话、固定系统提示词、RAG固定前缀这三个场景命中率最高。实践中我们发现客服场景接入prompt cache后相同前缀的重复计算能省掉60%以上用户侧几乎无感知。缓存要注意生命周期管理会话结束、知识库更新后要及时失效否则会返回过期信息。第三是请求合并。GPU的算力优势体现在并行计算上单个请求喂给GPU有很多算力是浪费的。通过动态batching推理框架会把Timeout窗口内到达的多个请求拼成一个batch一起走前向计算大幅提高吞吐。这也是vLLM这类框架比朴素写个模型API调用快很多的核心原因。框架选型上我的偏好是追求极致吞吐选SGLang生态成熟选vLLM搞生成模型且需要深度定制用TensorRT-LLM。不要频繁切换框架每个框架的优化参数都需要针对自己的模型去调。4.3 算力花得值不值要靠可观测性来说话买多少卡、怎么优化最终都要落到一个问题算力花得值不值。我见过不少团队GPU利用率看起来很高但业务量并没有增长那说明算力被浪费在不该花的地方了。要回答这个问题必须建设可观测性。除了看GPU利用率、显存占用、温度这类基础设施指标更要看业务指标。我通常会让团队埋点记录几个关键数据单个Agent任务的模型调用次数、单次调用的输入输出token数、单步耗时、token命中缓存的比例。只有拿到这些数据才能回答“到底是大模型能力不行还是算力不够还是上下文太长”。举一个真实案例。之前一个客户反馈Agent应用延迟很高GPU都快打满了直觉是算力不够。我们排查后发现问题出在工具调用环节Agent调用查询接口时经常传入错误参数失败后触发重试一个任务平均要发起12次模型调用其中7次都浪费在工具纠错上。这种情况加再多的卡也没用后来我们把工具参数schema简化同时增加输入校验规则模型调用次数从12次降到了4次延迟直接降了一半。所以我的建议是在买新卡之前先把每个Agent任务的“token流向”画出来。你会发现大量算力都消耗在重试、无效调用和冗余上下文上。可观测性不是运维团队的附庸它是算力成本控制的核心工具。5. 常见问题与排查技巧实录5.1 高频问题排查速查表现象排查路径解决建议GPU利用率低但请求排队严重查看是否batching参数不当单卡并发能力没有发挥调整max-num-seqs、max-batch-size开启动态batching推理延迟间歇性飙高检查是否有低优先级任务挤占了GPU显存或计算资源用调度器做资源隔离设置显存和线程配额显存OOM频繁检查KV Cache预留过大或并发副本数过多调整KV Cache策略限制单副本并发或改用更大显存卡多台GPU服务器任务训练不收敛大概率是通信瓶颈检查是否走了NVLink/RDMA多机训练务必启用高速互联小规模任务尽量单机多卡token计费与实际用量对不上检查提示词是否被重复拼接工具返回过长精简系统提示词限制工具返回内容长度扩缩容后效果不明显看扩缩容冷却时间是否太短或指标过于敏感加冷却时间采用趋势预测式扩容减少毛刺5.2 从“算力不够”到“算力用好”几条实用避坑心得算力项目的排查工作做多了你会发现大多数故障都不是“卡太少”引起的而是“卡没用好”。这里分享几条经常写在公司内部文档里的心得。第一加卡之前先看排队时长是不是真的由算力不足引起。很多时候请求排队是因为数据库慢、外部接口慢或者代码有死锁GPU反而在空转。建议先把全链路耗时拆开看再决定是否加算力。第二注意驱动和CUDA版本的兼容矩阵。异构GPU混部时不同型号卡对驱动版本的要求可能不一致强行装在同一节点会导致部分卡无法使用。我们现在的做法是节点按驱动版本分组调度器通过标签调度对应任务。第三日志和监控别在集群规模扩大后才想起来建设。GPU本身的指标可以通过DCGM采集配合Prometheus和Grafana展示落地成本不高。业务侧token指标则建议自研埋点把每次调用的token数、耗时、缓存命中情况打到统一日志平台后续做成本分析会很方便。第四租用智算中心资源时要盯紧计费口径。有些按卡时计费有些按token吞吐计费还有的会额外收取共享存储和网络流量费。如果是按卡时计费就要特别注意任务结束后的资源释放否则闲置资源也会产生费用如果按token计费那推理优化的收益会直接体现在账单上。踩过几次坑之后我个人评估一个企业级AI项目第一件事已经不是看模型排行榜而是先画清楚“用户请求到token再到GPU利用率”这条链路。算力市场增长再快单位成本还是得靠一个个工程细节去压。可能第一天买卡是最容易的后续的资源池化、调度策略、推理优化、可观测性建设才真正决定了企业AI应用能不能跑得远。如果正在读这篇文章的你也面临算力规划问题我的建议很朴素先在一个小规模但可靠的算力池上把监控和调度跑通把账算明白再谈扩张。到那时候算力高增长对你来说就不是压力而是实实在在的业务空间。