深夜调优：一个奶爸在GLM和FastGPT之间反复横跳的八月

晚上十一点半，广州老城区。两个娃终于都睡了。我蹑手蹑脚关上卧室门，客厅的旧空调嗡嗡响着。屏幕上开着三个终端，一个跑着GLM的API压测，一个挂着FastGPT的Docker日志，还有一个是老板晚上八点发的消息：“老陈，那个知识库问答的项目，客户说响应有点慢，你看能不能优化下？”

这个项目说来话长。去年年底公司接了个制造业客户的活儿，要给售后知识库做问答系统。客户要求私有化部署，数据不出厂区，预算不高。方案是开源RAG框架FastGPT，大模型选GLM-4，中文技术文档理解不错。

上线第一个月一切正常。第二个月，知识库从三千条文档涨到一万二千条，单次问答响应时间从两秒飙到八秒，甚至十五秒。客户IT小伙打电话来：“陈工，我们领导问了，这系统是不是没给够资源啊？要不要加服务器？”加服务器？IT预算卡得比我家娃的零食还严。再说，这明显不是资源问题，是架构问题。

那天晚上我哄完娃，蹲在阳台抽了半根烟，脑子里开始盘算。FastGPT的检索链路：query来了先embedding，然后向量检索，再rerank，最后拼prompt扔给GLM生成。日志显示：向量检索平均耗时3.2秒，rerank又吃掉1.8秒，GLM生成2.5秒，中间还有序列化和网络开销。

问题定位了，怎么优化才是真正的技术活。

**第一刀砍向量检索。**FastGPT默认用的pgvector，HNSW索引参数没调过。我把ef_search从40调到100，m从16调到24，重建索引花了一个多小时。检索耗时从3.2秒降到1.1秒。但一万多条文档里很多是重复版本，同一个产品说明书从V1到V7全传上来了。我写了个去重脚本，按文档哈希和标题相似度合并，知识库从一万二降到七千八。检索又快了0.3秒。

**第二刀砍rerank。**rerank模型跑在CPU上，每次要加载，加载耗时占了大头。我改成常驻内存的服务模式，用FastAPI包了一层，启动时预加载模型，请求来了直接推理。rerank从1.8秒降到0.6秒。

**第三刀砍GLM调用。**GLM-4的API调用本身不慢，但我的prompt写得有问题。为了追求“全面”，把检索出来的top 10文档片段全塞进上下文，还加了一堆系统提示词。结果上下文爆炸，生成时间被拖长，token消耗也大。我精简了prompt，只保留top 5片段，系统提示词砍掉三分之二，温度调到0.3。GLM生成从2.5秒降到1.2秒。

三个晚上，每天等娃睡了之后干到凌晨一点半。中间还出了个插曲：我手贱在FastGPT配置里改了个参数，整个服务挂了，大半夜爬起来修，老婆被吵醒，丢过来一句“你那个破项目比娃还难带”。

最终压测下来，单次问答平均响应时间从8.2秒降到2.3秒，P95在3.1秒以内。客户试了一周，IT小伙发来消息：“陈工，现在快多了，领导说不用加服务器了。”

但这个过程让我对“性能优化”有了新的理解。以前觉得性能优化就是调参数、加缓存、上CDN，是纯技术活。这次做完才发现，性能优化的本质是理解业务。知识库为什么膨胀？因为文档管理混乱，版本不分。查询为什么慢？因为用户问的问题太宽泛，比如直接问“这个设备怎么修”，而不是具体的型号和故障码。我后来加了一个引导式提问的功能：用户输入模糊问题时，系统先用GLM生成几个澄清问题让用户选择。检索准确率提升了，响应时间反而进一步下降。

再说云计算。客户一开始坚持私有化，数据不出厂区。但售后工程师经常出差用手机查知识库，私有化服务器在厂区内网，外网访问要过VPN，体验极差。最终给了混合方案：核心数据和推理在私有云，前端应用和部分非敏感缓存放公有云，专线打通。GLM的API调用走公有云出口，但所有文档数据脱敏后才发送，合规部门审了两周才点头。云计算不是非此即彼的选择题，而是需要根据业务场景反复权衡的应用题。

FastGPT和GLM都是好工具，但工具不会替你思考。你得知道瓶颈在哪里，知道哪些参数值得调，哪些优化做了也没用。就像带娃，你知道娃半夜哭是饿了还是尿了，才能对症下药。盲目优化和盲目哄娃一样，都是浪费精力。

技术这条路，没有终点，只有不断调优。能把自己操心的事情做好，也是一种本事。