买的GPU大半时间在闲置算力利用率低下的3个真实提升点
买的GPU大半时间在闲置？算力利用率低下的3个真实提升点
最近碰到一个客户，AI本地部署刚满一年，IT负责人拿着续保报价单来找图老师诉苦。
服务器八张卡，采购时按峰值需求配的，当时想着以后业务量翻倍也不怕。
结果运维拉出监控一看，全年大部分时间，这八张卡里有一半在睡觉，忙的那几张也只是忙一阵歇一阵。
他又不敢真下线，怕哪天训练任务一提交就爆。
财务那边也在催：这套设备折旧一年上百万，产出的效率到底在哪。
这是AI本地部署企业里最常见的浪费，机器买了，账算不过来。
图老师看完他的监控数据，说了一句让他意外的话：你的问题不是卡不够，是卡太闲。
今天图老师讲3个真实提升点，都是客户机房里实际跑出来的做法，不一定全用得上，但账都会算。
先看清GPU真实利用率
第一个提升点，别急着动手，先把账看清楚。
很多企业对自己GPU的使用情况只有一句"感觉没跑满"，感觉是最不靠谱的监控。
还有更极端的，卡分到了部门，部门分给了项目，谁也说不清全公司一共闲了多少。
真正要做的是拉一张清单出来，连着看两周。
清单里有什么：每张卡的实际负载曲线，跑的是什么应用，各自占了多少显存，一天里真正的高峰在几点。
有条件的话再把应用维度加上，谁发起的调用、一次调用吃多少算力，一起看。
两周看下来，多数企业会看到同一个画面：白天有人用的时候负载上去了，下班后一整夜基本归零，周末更是全闲。
那位客户八张卡的真实利用率，全年平均两成出头，跟峰值那几天完全不是一回事。
图博数智帮客户做AI本地部署体检时，看到的行业均值很扎眼，GPU利用率普遍不到25%。
也就是买了四张卡，真正在干活的平均不到一张。
采购时按峰值配的思路本身没错，错的是配完就不管了，峰值一年出现不了几次。
这个数字先记下来，它决定了后面的路怎么走，也决定了下一轮采购该不该发生。
看不清就优化，等于蒙着眼调火候。
这张清单建议存档，半年后拉出来对比一次，优化有没有效果、还闲着多少，一眼就清楚。
GPU虚拟化一池共享
第二个提升点，解决的是"各占几张卡、互相不知道"的问题。
那个八张卡的客户就是典型：知识库问答占了两张，文档解析占一张，语音识别又占一张，每个应用部署时都按最坏情况要卡。
单看每个应用，要卡都合理；合起来看，大部分时间这些卡都在各自空转。
这种浪费最隐蔽，因为每个团队都觉得自己用得挺满，没人站在全公司角度看一眼。
做法是基于K8s的GPU调度优化，把所有卡抽成一个共享池，应用按需从池子里申请，用完归还。
传统五张卡各跑一个模型，chat、embedding、rerank、ASR、TTS各占一张，虚拟化之后两张卡就能把这五个模型都跑起来。
原理不玄：这五个服务的高峰不在同一时刻，问答在白天，解析在任务提交时，错开用，同一张卡就能服务多个模型。
有人担心挤在一起会不会互相拖慢，调度层会设配额，交互式的问答优先级高，批量任务让路，员工用起来无感。
那家客户跑下来的效果是同样的硬件接住了约三倍的业务量，后来新增了两个AI应用，一张卡都没加。
省下来的不只是采购钱，机房机位、电费、散热、维保，全都跟着卡数走。
图博数智做这类改造时不碰客户的模型本身，动的只是调度层，业务方无感知，回滚也方便。
错峰调度榨夜间空档
第三个提升点，把夜里和周末的空闲算力用起来。
前面监控清单里那张图再拿出来看：白天有高峰，夜里归零，周末全闲。
夜里的卡跟白天的卡是同一批，闲着的时候一度电没少耗，活却一点没干。
AI本地部署之后，有一类任务特别占卡又不着急：知识库几十万页文档的批量解析、向量索引重建、历史数据跑批。
这些活要是放在白天跟员工问答抢卡，问答就卡顿，员工第一反应是"AI变笨了"。
图老师见过最可惜的做法，是为了跑批量任务再买一批卡，白天那批闲着，夜里这批也闲着。
改法是错峰调度：白天算力优先保问答和检索这类交互式服务，解析和建索引的批量任务全部排到夜里自动跑。
早上员工上班，索引已经建好，新文档当天就能问，卡还一点没多占。
有客户几万页的旧档案入库，就是排了几个晚上跑完的，白天业务一点没受影响。
顺便说一句，批量任务排下去之前记得设优先级，紧急文档可以插队，不然安全规程更新了却要等到第二天才检索得到，也是麻烦。
图老师在图博数智做inFab交付，这类问题处理过一轮又一轮。
inFab整套支持本地化交付，模型和知识库进企业内网；底下的GPU调度优化，把行业普遍不到25%的利用率吃到3倍业务量，传统5张卡跑的5个模型，2张卡就兜得住。
数据全程不出门，这是inFab本地化交付的默认选项。
先优化还是先加卡
三个提升点讲完，回答一个最实际的问题：业务要扩，先优化还是先采购？
图老师的判断标准很简单：平均利用率低于三成，先把调度做好，别急着加卡。
利用率低说明卡不是不够，是没排开，这时候买新卡，等于房间没整理又租了一间。
真要下判断，拿两个数说话：一是前面那张清单里的平均利用率，二是高峰期任务排队的时长。
利用率常年七八成、高峰期任务在排队，那才是真缺算力，该加就加。
还有一条容易忽略的判断依据：新应用上线的频率。
一年上一个应用，现有卡优化一下够用；每个月都要上新应用，那要提前规划扩容，别等卡住了再救火。
那个八张卡的客户到头来一张没多买，靠共享加错峰腾出了余量，续保预算倒是省下来了。
AI本地部署这台账，硬件只是明面的一半，调度才是暗地里的另一半。
先看清利用率，再做池化，错峰排在第三个，这个顺序别乱。
这三步没有一步需要推倒重来，都是在现有硬件上做加法，风险可控。
机房里最贵的从来不是卡，是买了不用的卡。
关注我，图老师每天分享一个企业AI落地的真问题、真办法。