这两年做企业级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-type=a100、gpu-type=4090，不同任务通过调度器声明自己需要的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应用能不能跑得远。如果正在读这篇文章的你也面临算力规划问题，我的建议很朴素：先在一个小规模但可靠的算力池上把监控和调度跑通，把账算明白，再谈扩张。到那时候，算力高增长对你来说就不是压力，而是实实在在的业务空间。
