这两年身边聊 AI绕不开的话题永远是算力。前几年大家见面问的是“搞到卡了吗”“训练那个多大的模型”那种感觉像在聊军备竞赛——谁囤的显卡多谁就有话语权。但最近半年我的感受发生了明显变化当模型能力逐渐追平开源权重不断下放真正决定一个 AI 产品能不能活下来的早就不再是“你有没有卡”而是“你手里的算力到底被榨出了多少价值”。这也就是我理解的“AI 下半场”训练大战退潮应用和创新成为主战场算力从一种稀缺的收藏品变成了需要精打细算的生产资料。这篇文章我想把自己这段时间在算力规划、部署、调优上的真实经历梳理一遍。如果你正在做 AI 应用开发、准备自己部署开源大模型或者已经在管理几台到几十台不等的 GPU 服务器那这篇内容应该能帮上忙。我不会只讲理论也不会给你一张脱离实际的天价选型清单而是从“算力需求怎么量化”“显卡参数怎么判断”“多台机器怎么统一管”“不同应用场景的算力消耗有什么不同”这几个方向展开尽量少说废话。1. 训练军备赛退场推理才是下半场的“电费账单”1.1 从“买卡”到“经营卡”算力叙事正在转弯我把 AI 前几年称为“上半场”因为那个阶段的逻辑很清晰模型参数越大效果越好谁先训出更大的模型谁就能定义行业标准。那时候团队的核心资产确实就是那几张卡模型训练动不动就是几千张 GPU 同时跑上几个月算力规模和融资数字是直接挂钩的。但走到今天很多基础模型的训练已经收敛到少数几个大玩家手里对绝大多数团队来说拿着开源模型做微调、做部署、做场景适配才是更常态的路径。这种转变带来一个巨大的变化训练成本是一次性的但推理成本是持续性的。训练就像拍一部电影预算再高拍完就结束推理则像电影上线后的电费和服务器租金只要用户在访问、产品在运行这个成本就一直在烧。过去大家舍得为训练花钱是因为训练完能出一个“作品”但推理成本是天天流淌的现金流躲不开也藏不住。我自己就有亲身经历。有一段时间团队做内部 AI 工具微调完一个 7B 模型大家都很兴奋觉得总算跑通了。结果上线做了个小范围测试一百多个人用每天产生的推理请求量看着不高但一周下来电费、GPU 租用费、运维时间加在一起负责人直接被吓到了。那一刻我才真正意识到上半场比的是谁能把模型造出来下半场比的是谁能用更低的成本把模型“天天开着”。1.2 训练和推理的算力消耗逻辑完全不同很多人对算力的理解还停留在“参数量越大越费电”这个说法对训练大体成立但推理不完全是这样。训练时模型权重是在每个 batch 上都反复更新数值计算量巨大而且训练要经历成千上万步迭代一次训练任务烧掉的浮点运算量往往是推理的几十万倍。推理则不同权重已经固定每来一个请求模型只做一次前向计算按顺序把 token 一个个生成出来。但推理真正的特点在于“细碎且重复”。每一个用户请求都是一次独立的前向计算请求量一旦涨上来叠加效应非常惊人。尤其到了 Agent、AI 编程这类场景一个任务内部会反复调用模型单次任务的总 token 消耗量可能被放大十倍甚至几十倍。这意味着哪怕你的模型本身不算大只要调用频率上去了、上下文变长了推理成本依然可以迅速失控。注意训练阶段投入是一次性的资本开支而推理则是“每一笔订单都要扣手续费”。如果产品长期不能形成正向收益你的算力投入就会变成一个永远填不满的洞。2. 用 Token 而不是用“卡”来估算算力需求2.1 先搞明白 Token、参数和算力之间的关系聊算力需求很多人一上来就问“我需要几张 4090”或者“租多少台 A100”。但这个问题本身没问到点子上因为同样的显卡在不同场景下能提供的有效服务能力天差地别。关键在于你每天要处理多少 token以及要求的响应速度和并发量是多少。先明确三个基础概念参数Parameter模型的权重规模比如 7B 就是 70 亿参数。参数越多模型通常越聪明但每次推理需要计算的量也越大。Token模型处理文本的最小单位一个汉字可能对应一到多个 token。模型每生成一个字就是生成一个 token。算力需求一次推理需要完成的浮点运算量大致可以按经验公式估算推理总计算量 ≈ 2 × 模型参数量 × 生成的 Token 数这个公式是业内有名的近似估算方式计算结果虽然不是精确的数字但用来做容量规划已经足够。通俗理解就是你让一个 7B 模型生成 300 个 token大约等效于做了“70 亿 × 300 × 2”次基本运算也就是大约 4200 亿次浮点运算。如果换成 70B 模型同样生成 300 token需求直接放大十倍。知道了这个逻辑你就会明白决定算力需求的核心变量不是“卡的数量”而是“每天要生成多少 token”。这就像货运公司不会说“我有三辆车”而会说“我每天能跑多少吨公里”显卡只是你的车“吨公里”才是你的业务量。2.2 一套可以直接套用的算力估算流程我给自己团队做算力规划时习惯按下面几步来测算完全不需要复杂的预测模型只需要产品侧给几个运营数字就行预估每日请求量这个从产品规划里就能拿到比如“上线前三个月预计日活 3000 人人均每天调用 20 次”那日请求量就是 6 万次。确认单次请求的输入和输出 token看产品交互设计。比如知识库问答输入可能是用户问题加检索回来的相关文档平均在 1200~2000 token 之间输出大约在 300~500 token 之间。计算每日总 token 消耗日请求量 × (输入 token 输出 token)注意输入 token 也不能忽略因为前向计算同样要处理输入内容。估算需要的总算力用上面的经验公式把每日总 token 中“输出部分”代入计算。输入部分虽然也占显存和计算但大部分场景里生成部分的复杂度更高先用这个粗粒度口径做规划是合理的。除以单卡能提供的有效算力注意这里一定要用“有效算力”不是显卡理论 TOPS。受限于显存带宽、批处理大小和软件调度实际能利用的往往只有峰值的 30%~50%。我举个例子。假设你做一个企业知识库问答系统用 7B 开源模型日均请求量5 万次平均输入1500 token平均输出300 token日均总 token5 万 × 1800 9000 万 token估算总算力约 2 × 70 亿 × 5 万 × 300 2.1 万亿次浮点运算规模然后你需要看一台中高端推理卡一天能“消化”多少 token。以一台搭载主流高端加速卡的单机为例如果做足工程优化一天大概能吞吐几千万 token。按这个口径5 万日请求量理论上 1~2 张卡的核心算力就够了。但现实必须叠加并发因素如果峰值时段有大量请求同时到达而单机显存装不下那么多并发序列你就会需要更多卡来做水平扩展。2.3 并发、延迟和成本三个硬约束的取舍上面只算了“总量”但真实线上系统还受两个约束延迟和并发。同一个 7B 模型一次请求进来模型要先读入你的输入再逐字生成输出这个过程受显存带宽和批次大小影响很大。如果把 4 个请求拼在一起作为一个 batch 处理显卡利用率会高很多但第一个 token 的响应时间也会变长。你要在“单请求速度”和“整卡吞吐量”之间做取舍。实际落地时我通常这样判断如果产品对延迟要求高比如在线聊天机器人那就不要过度放大批处理大小宁可让一部分显卡闲置也要保证响应速度。如果任务是异步的比如夜间批量内容总结、离线数据处理那就把 batch 拉满尽可能压榨硬件的吞吐极限。如果并发峰值明显那么就要留出 30% 以上的算力冗余否则高峰期一起涌入队列会越积越长体验立刻崩塌。经验不要按“日均请求量”直接部署一定要按“峰值并发”来算卡数。日均数据可以骗人但峰值的排队时间不会。3. 显卡算力 TOPS 排行只决定上限不决定实际体验3.1 TOPS 是“峰值速度”不是“服务速度”现在网上有各种“显卡 AI 算力 TOPS 排行”很多人照着榜单买卡买完发现推理速度并没有想象中快。原因很简单TOPS 衡量的是 GPU 在最优条件下每秒能做多少次整数运算但实际 AI 推理是一个被内存带宽、显存容量、数据搬运和软件调度层层限制的过程。就好比你有一辆极速 350 公里的跑车但每天上班路线全是拥堵路段实际通勤速度可能还不如一辆小电驴。推理过程的瓶颈分布大致可以分三块环节主要消耗实际瓶颈读取模型权重显存带宽权重越大读取越慢处理输入内容计算单元输入越长计算量越大逐 token 生成显存带宽 计算单元生成速度直接体现在用户体验上所以你会发现一些游戏显卡虽然在 TOPS 榜单上名次靠前但用来跑大模型推理吞吐量反而不一定打得过专业计算卡。核心原因就是显存带宽和专业卡差距过大导致模型权重在显存里“搬运”得慢。3.2 显存容量决定了你能“装下”多大的上下文另一个榜单上看不见的关键指标是显存容量。推理时除了模型权重还需要存储每个请求的中间状态尤其是注意力机制的 KV 缓存这部分显存消耗随着上下文长度和并发请求数线性增长。如果你只有 24GB 显存部署 13B 模型后权重就占掉一多半能同时处理的并发请求数量会很有限。一旦超出显存就只能靠 CPU 内存兜底性能断崖式下跌这在线上是不可接受的。我实际遇到过这种情况用消费级显卡部署一个 34B 模型量化之后权重刚好塞进显存但每次推理一多很快就触顶。后来换了一张显存更大但 TOPS 数字更低的卡并发能力和总吞吐反而翻倍了。看性能要看的不是“峰值算力”而是“峰值算力能在多大规模的任务下持续释放”。3.3 选卡的正确判断顺序如果你想自己部署模型又不想被各式榜单带偏我建议按下面的顺序评估先测真实吞吐拿你要部署的模型用真实的输入输出长度测一下它每秒能生成多少 token。这比任何参数都可靠。看显存容量确保模型权重加最大上下文下的 KV 缓存能轻松塞进显存并且至少留出 20% 余量。看显存带宽在模型大小相同时显存带宽决定了生成速度的天花板。看多卡互联如果你要考虑拆分模型或多卡并行卡间互联带宽很关键否则跨卡通信会吃掉大量性能。最后才看 TOPSTOPS 更反映训练方面或者矩阵计算的峰值能力对推理来说它不是核心决策指标。建议做容量评估前先在目标显卡上跑一次 200 token 输出的基准测试记录生成速度和显存占用数据有了方案自然就清楚了。4. 从单机调试到服务器集群统一管理4.1 为什么多台机器不能继续“各管各的”当手里机器少的时候SSH 登录上去敲命令也没问题。但一旦上了多台服务器再靠一个个登录去人肉管理问题很快就来这台机器的 GPU 利用率只剩 5%那台机器的任务排队排了几小时还有一台驱动版本和别人的不一样部署个环境都要折腾半天。整个集群的资源利用率可能连 30% 都不到但单看每台机器好像又都很忙。统一管理的本质是把多台独立的 GPU 服务器变成“一个算力池”。用户或任务管理器来提交需求时不关心具体跑在哪台机器上由调度系统根据当前的负载、显存、卡数来自动分配。这样不仅省去大量重复运维工作更重要的是能把碎片化的资源聚在一起提高整体利用率。4.2 最小可用的算力池管理方案基于我这边的实际经验如果你要从零搭一套小规模集群管理不需要一上来就上很复杂的云原生平台可以分三步走第一步标准化环境。把每台机器的操作系统、驱动版本、容器运行时尽量统一。强烈建议用容器封装训练和推理环境这样换机器跑不会出现“我本地明明好的到服务器就起不来”的问题。镜像仓库留在内网方便复用。第二步部署一个任务调度器。常见的有 Slurm 和 Kubernetes 两个技术方向。Slurm 在传统 HPC 领域用得多对 PyTorch 分布式训练很友好Kubernetes 跟云原生生态结合更紧密做在线推理服务比较顺手。小团队如果以离线训练和批量任务为主用 Slurm 起步会更简单如果主打在线 API 服务Kubernetes 是长期趋势。记住调度器的核心作用有两个让任务找到合适的卡让卡不闲着。第三步统一监控和报警。多台机器时光是“哪台卡挂了”“哪张卡温度过高”这种问题靠人工盯着就够呛。最简单的办法是统一收集每台机器的 GPU 利用率、显存占用、温度、功耗并通过关键指标设置告警。刚开始不需要很复杂的可观测系统一个基本的监控面板加一个通知机器人就够了。下面这几个命令和思路是我日常管理 GPU 服务器时用得最频繁的# 查看单台或本地机器的 GPU 实时状态 nvidia-smi # 监控多卡利用率、显存、温度1秒刷新一次 nvidia-smi dmon -s pucvmet -d 1 # 定期采集多台机器的指标统一上报监控系统 nvidia-smi --query-gpuindex,uuid,utilization.gpu,memory.used,temperature.gpu \ --formatcsv -l 60 /var/log/gpu_metrics.csv这些命令的作用不是给你炫技而是让你在“出了问题再登录”和“随时知道集群状态”之间划一条明确的线。只有先掌握集群的健康状态调度器才有意义否则你都不知道资源瓶颈卡在哪。4.3 我踩过的三个集群管理坑讲三个真实发生在我这边的例子给还没入坑的人提前打个预防针。第一个坑是节点状态不一致。某次周末跑批量推理任务一调度就报错排查半天发现其中一台机器驱动被静默更新过导致卡在容器里不可见。从那之后我强制所有机器统一维护窗口驱动和系统补丁只能通过统一流程下发禁止人肉登录升级。第二个坑是任务排队机制缺失。早期没有配置资源配额一个人提交了 8 卡训练任务把所有机器占满了其他人的推理任务全部排队等待。后来给不同项目组设置了队列优先级和最大卡数限制才解决这种“饿死”现象。第三个坑是空转浪费。监控数据上线后我发现很多任务实际只用了单张卡却申请了多台机器还有不少测试环境跑完忘了释放GPU 空转好几天。现在我的做法是所有任务必须设置最大运行时间和自动释放策略没用完就销毁。一通调整下来整个集群的有效吞吐量提升非常明显。经验集群管理的目标不是“装上某个调度器”而是把任务的申请、执行、释放变成一条有约束、有监控、有回收的流水线。管理工具只是手段治理规则才是核心。5. Agent、AI 编程、AI 视频不同应用场景的算力消耗逻辑完全不同5.1 AI Agent一次任务拆成 N 次调用Token 消耗成倍放大AI Agent 是这两年特别火的方向几乎每个做 AI 应用的人都在琢磨它。但 Agent 场景的算力消耗模式和传统问答完全不同传统问答是“问一次答一次”Agent 是“一次任务内部要思考、拆解、调用工具、查看结果、再思考”等于把原来的一次推理放大了很多倍。举个例子让 Agent 完成“帮我把本周的销售数据汇总成周报”这个任务它可能要经历读取数据工具调用、生成中间分析、生成结构化报告前后触发模型推理十几次总 token 消耗可能是直接问答的 5 到 10 倍。如果中间需要处理的上下文又长比如读了几十个文档片段那显存和计算的压力立刻翻倍。因此做 Agent 产品时我强烈建议设置最大迭代次数避免 Agent 陷入死循环导致成本失控。对结果做缓存相同的子任务结果直接复用不重复调用模型。能用规则、代码处理的环节就不要交给模型。让模型只做它擅长的事其他流程用工程手段解决。5.2 AI 编程长上下文和大输出让显存压力拉满AI 编程工具是另一个典型场景。跟普通聊天不同代码场景的输入往往特别长——一个文件可能几百行一个项目上下文可能上万行。长输入带来的直接问题是模型每次都要对整段输入进行 prefill 计算并且在生成阶段KV 缓存的体量会随着上下文长度快速增长显存占用非常大。实际使用中你会发现同一个模型在短输入场景下并发能力很强但到了代码场景输入一长单请求能占用的显存就剧烈上升能同时跑的并发请求瞬间缩小。优化手段主要有两条路第一通过检索和代码结构解析只把真正相关的代码片段喂给模型而不是把整个代码库硬塞进去第二利用上下文缓存让相同的项目前缀在多次请求之间共享计算能省下大量的重复 prefill 开销。5.3 AI 视频把文本推理问题变成了“渲染”问题AI 视频和文本模型的算力消耗差距不是一倍两倍而是数量级的差距。文本模型一次生成几百个 token撑死也就上千 token视频生成要做多次扩散采样每次采样都要处理一整个隐空间张量计算量随分辨率和帧数极速膨胀。可以说AI 视频的算力消耗更像传统 CG 渲染而不是文本推理。同样是给用户提供服务处理文本任务的服务器可以实时响应视频生成则很难做到秒级返回一般要走异步队列用户提交请求后台排队生成完再通知。部署的时候得做好队列和任务优先级管理尽量错峰填谷避免所有请求挤在同一时间点抢占资源。不同应用场景的算力消耗模式比较可以简单参考下表场景输入特点输出特点主要算力压力典型优化方向文本问答短到几百 token几百 token并发量和吞吐批量调度、量化AI Agent短到上千 token多次调用、累计多调用次数放大迭代上限、缓存AI 编程上下文可达数万 token代码长生成量大显存和 KV 缓存检索裁剪、前缀缓存AI 视频文本描述多帧图像采样迭代计算量爆炸异步队列、降分辨率试跑6. 真正拉开差距的是“软算力”缓存、量化、路由和工程取舍6.1 提示词缓存和 KV Cache入场即回本的关键优化很多团队在部署推理服务时第一反应是“换更贵的显卡”却忽略了软件层面最大的一个省钱点——提示词缓存。在真实产品里很多请求都共享同一个系统提示词和很长的公共前缀比如客服产品有固定的角色设定、律所产品有固定的条款说明。如果每次都让模型从头重新处理这些内容等于每一笔请求都在重复做无用功。提示词缓存会把这些公共前缀的计算结果暂存下来新请求来了之后直接复用只需要计算新增的那一小段内容。这个优化对长上下文场景特别明显有时候能把单请求的输入计算成本砍掉一半甚至更多。类似的思路还有 KV Cache 的显存管理通过更聪明的调度方式让显存里能同时塞下更多请求提升整体并发吞吐。6.2 量化不是无脑压缩要按场景分层选择模型量化是把大模型的权重从较高精度压缩到较低精度比如从 FP16 压缩到 INT8 甚至更低换来显存占用下降、推理速度提升。这项技术确实是现阶段性价比最高的“软算力”来源但一定要明确一件事量化不是无脑压缩是有损的能不能接受要看具体任务。我自己的习惯是分级处理如果模型只做简单分类和摘要用 INT8 甚至 4bit 量化没太大问题如果是写代码、做数学推理这类对输出确定性要求高的任务量化后效果波动会很敏感至少要用 W8A8 这样相对稳妥的量化方式并在上线前做一轮效果对比测试。记住不要迷信“量化后效果不变”的宣传以你自己的测试集数据为准。6.3 流量路由让“大模型”干大事“小模型”干小事最后再讲一个我在线上系统里特别看重的优化层——流量路由。任何一个有一定规模请求量的 AI 系统都不需要让所有请求都跑到最大最聪明的模型上。简单问题用 7B 模型就能答得很好复杂问题才需要 70B 级别模型把这两类请求全部混在一起跑大模型等于每天都在铺张浪费。可以设计一个路由策略先让容易、重复的问题走小模型或者直接命中缓存判断可能有难度、需要复杂推理的请求才升级到大模型。这个策略看起来简单但在实际业务里省下的成本相当可观。GPU 资源又贵又紧张让“好钢用在刀刃上”不是一句口号而是 AI 下半场活下来的基本素养。真正让我觉得算力这事值得认真对待的不是技术多炫而是每一项优化都可以直接折算成成本。过去一年我逐渐养成一个习惯每一次性能优化之后先记下原来的生成速度、显存占用、并发能力改完再看收益曲线。算力资源不会自己变得便宜但更聪明的使用方式可以让同样一张卡发挥出几倍的价值。如果你现在正站在“要不要再买几张卡”的岔路口我的建议是先别急着下单把你现有的请求日志拉出来算清楚日均 token、峰值并发、单次请求长度再结合缓存、量化和路由手段做一轮优化很可能你会发现现有的算力还有大半身位没被榨干。