本地部署的大模型越用越慢是错觉吗3个真实排查点
本地部署的大模型越用越慢是错觉吗？3个真实排查点
最近碰到一个客户，一家制造业企业的IT负责人，大模型本地部署上线刚满半年，找图老师诉苦。
上线头一个月，员工都说好，问答快、总结准。
第二个月开始，抱怨慢慢多起来：回答要等半天，有时候干脆转圈。
他的原话是：员工说AI变笨了，领导问我是不是该换更大的模型。
图老师让他先别急着花钱，把监控数据拉出来一起看了一个下午。
看完他就明白了，慢是真慢，但锅真不在模型身上。
图老师先给结论：模型大概率没变笨，是部署环境在拖后腿。
大模型本地部署这件事，上线只是起点，用起来之后的性能维护才是日常。
慢从哪来？图老师给你3个真实排查点，一个一个过。
排查点一：请求排队卡却在睡
第一个要查的，是最常见的假象：并发上来了，请求在排队，GPU却在睡觉。
刚上线时几十个人试用，一台机器一个模型，绰绰有余。
全公司推开之后，几百人同时提问，所有请求挤同一条通道，响应时间被拉长好几倍。
上午十点最明显，全公司都在问，每个人的回答都慢半拍，午休一过又好了。
这时候去看监控，很多人会愣住：GPU利用率不到25%，卡基本闲着，用户却在等。
这是行业里非常普遍的现象：卡按应用切死了，一个模型独占几张卡，忙闲不均，谁也借不了谁的力。
排查动作很简单，打开监控看两个数：请求队列长度，以及每张卡的真实负载。
队列一路涨、卡却大片时间闲着，调度问题的实锤就拿到了。
顺带把高峰时段和高峰人数记下来，后面判断要不要扩容、什么时候扩，这两个数就是依据。
图博数智做本地AI部署时处理这类问题，用的是基于K8s的GPU调度优化。
在K8s上做GPU虚拟化加智能调度，一张卡按需跑多个模型，请求高峰自动分流。
传统方式5张卡各跑各的模型，调度优化之后2张卡就能兜住，同样硬件扛下约3倍的业务量。
换算成体验就是：高峰期没人排队，模型还是那几个模型，用户的等待直接短下来。
所以员工喊慢的时候，先别急着买卡，先看排队和利用率对不对得上。
对不上，问题在调度，不在算力总量，这时候买新卡等于给堵车的路口再加车道，钱花了，堵还在。
回头再看那位IT负责人的处境，领导要的换大模型，三个排查点走完根本没排上号。
排查点二：文档涨量检索变慢
第二个排查点，藏在知识库那头，很多人想不到。
大模型本地部署之后，企业一般会接一个知识库做问答，把文档喂进去。
刚上线时几万页文档，检索飞快，因为向量库小、索引轻。
半年过去，各部门看效果不错，天天往里传，文档量涨了几个量级。
除了量，质也变了：早期传的是精选文档，后来连会议纪要、扫描件、历史图纸说明都往里塞。
问题跟着来了：用户的每个问题，系统都要在海量向量里做相似度检索，库越大，检索越慢。
回答慢的锅，模型背了，其实是检索层在拖时间。
判断也不难：拿同一个问题，分别用挂知识库和不挂知识库两种方式问一遍。
不挂库秒回、挂库要等，那就是检索层的事，跟模型半点关系没有。
图博数智有个制造业客户就卡在这一步，扩库之后问答明显变钝，团队一度怀疑要换更大的模型。
实际动手做两件事就缓过来了：向量库分层管理，热数据和大库分开；索引定期重建，放在夜间批量跑，错峰不占白天的问答资源。
顺手把高频问题的检索结果做缓存，常见问题的响应直接回到刚上线时的水平。
另外入库环节就做好分流也很值：常用制度类、高频问答类文档单独放一层，海量历史资料放另一层。
文档量只会越涨越大，检索架构不跟着长，慢是迟早的事。
排查点三：模型和业务抢机器
第三个排查点，查资源隔离，这一条最容易漏。
不少企业图省事，把模型服务、知识库、业务系统全塞在同一台服务器上。
上线初期没问题，等业务系统跑起报表、跑起批处理，麻烦来了。
业务高峰期CPU和内存被抢占，模型推理分不到足够资源，用户那头的感受就是一个字：慢。
这种慢有个特征：跟着业务系统的节奏走，报表一跑就卡，报表跑完就好。
更麻烦的是排查困难，各自看各自的日志，谁都说自己没毛病。
图老师见过最典型的情况：每天下午固定时段集体变慢，追查下来，是业务侧的定时任务在和模型抢内存。
解法不复杂：资源隔离加错峰。
模型服务和重负载业务分机部署，实在分不开就用容器做资源配额，各管各的份额。
批量任务统一挪到夜间，白天把机器留给问答，一增一减，体感差别很大。
还有个容易忽视的细节：模型服务自己也要留余量，并发高峰来了能扩、闲时能收，别按峰值焊死配置。
图老师在图博数智做inFab交付，这类问题处理过一轮又一轮。
inFab整套支持本地化交付，模型和知识库进企业内网；底下的GPU调度优化，把行业普遍不到25%的利用率吃到3倍业务量，传统5张卡跑的5个模型，2张卡就兜得住。
数据全程不出门，这是inFab本地化交付的默认选项。
慢了之后先查什么
三个排查点讲完，给一组可以直接拿去用的判断标准。
用户喊慢，先看监控里有没有请求排队：有排队、卡又闲着，查调度。
问答慢但闲聊不慢，八成是检索层：查向量库规模，以及索引多久没重建。
每天固定时段慢、其他时间正常：查资源抢占和定时任务。
排查顺序建议从上往下走，先调度、再检索、后隔离，越往后查起来越费劲，便宜的先查。
一句话总结：先分清慢在模型、慢在检索，还是慢在资源，三者的解法完全不同。
这三步都查过还是慢，才轮到考虑加硬件或者换模型，顺序别做反。
那位IT负责人照着这个顺序查，排队和检索两处各改了一轮，两周后员工的抱怨基本消失。
他后来跟图老师讲了一句挺到位的话：以前把上线当终点，现在才明白运营才是开始。
大模型本地部署是场长跑，上线那天的流畅只是起点，调度、检索、隔离这三件事盯住了，才能一直快下去。
关注我，图老师每天分享一个企业AI落地的真问题、真办法。