关掉书房里所有不必要的照明，只留屏幕微光，不是为了省电，是为了让注意力像手术刀一样精准。今天的目标是把那个该死的推理模型再剪掉1%的冗余，不是为了炫技，是为了让它在单核CPU的VPS上跑得更快一点，把每月那几十刀的服务器成本彻底打下来。代码写得好，真比服务器买得贵更重要，这话现在听起来不是格言，是生存法则。
这个模型是我用FastAPI封装的，核心是个微调过的轻量级LLM，负责处理用户上传的文档，做摘要和关键信息提取。流程看起来很简单：用户上传 -> 预处理（分块、向量化）-> 模型推理 -> 返回结构化结果。但魔鬼全在细节里。预处理的分块策略，我之前用的是固定字符数滑动窗口，为了保证上下文连贯性，重叠率设了30%。在云端，这点计算量毛都不算。但现在我要把它塞进一个1核1G内存、可能还跟别人共享CPU的廉价VPS里，每一次不必要的字符复制，都是对响应时间和内存的谋杀。
我盯着预处理模块的代码。重叠率30%是基于一个假设：重要信息可能恰好落在两个分块的边缘。但这个假设有多强？我调出过去三个月处理过的几千份文档日志，写了个脚本分析信息点（我手动标注的关键实体和结论句）的实际分布。结果有点打脸：超过85%的信息点完整地落在单一分块内；落在边缘需要靠重叠捕获的，不到10%；剩下5%是垃圾信息。为了10%的边缘情况，让每一份文档的文本总量凭空增加30%，这买卖太亏了。
我把重叠率从30%调到15%。这不够，这是妥协，不是剪枝。真正的剪枝是改变算法。我能不能动态判断哪里需要重叠？我想到了用标点密度和段落长度做一个简单的启发式规则：在句号、问号密集的“硬段落”结尾处，少重叠甚至不重叠；在段落很长、只有逗号分隔的“软段落”内部，才在预计的句子边界处增加重叠。这需要修改分块函数，引入一个轻量级的标点分析步骤。这个分析本身有成本，但比起无脑复制30%的文本，成本小得多。我快速写了个原型，用历史数据跑了一下，信息捕获率只下降了不到0.5%，但整体需要处理的文本量减少了22%。这22%，就是实实在在减少的token化开销和模型推理的输入长度。
接下来是向量化。我一直用的sentence-transformers里的all-MiniLM-L6-v2，算是平衡了质量和速度的经典选择。但在推理时，真的每一段都需要转化成768维的稠密向量吗？我的流程是：用户查询时，才用查询语句的向量去匹配文档块向量。文档上传时的向量化，其实是为了构建索引，供后续检索。这里有个优化点：我可以先用一个更粗糙、更快的方法（比如基于词频的TF-IDF）做初步筛选，只对排名前Top-K的文档块进行精确的向量相似度计算。这叫“召回后精排”。但我的应用场景里，用户上传的往往是单一文档，需要处理的是文档内部的分块。文档内部的块数有限，通常也就几十个，用TF-IDF再做一层过滤，引入的复杂度可能抵消不了收益。我否定了这个想法。
但向量模型本身有没有冗余？我查了一下，这个all-MiniLM-L6-v2有22.7M参数。对于我这种固定领域的文档摘要，或许不需要这么通用的表示能力。我想起Hugging Face上那些更小的模型，像`all-MiniLM-L3-v2`，维度只有384，参数少得多。我下载下来，用我积累的一批文档块和查询对做了个快速测试。在语义相似度匹配的任务上，效果差距在3%以内，但编码速度提升了近40%。就是它了。这40%的速度提升，在用户感知上，可能就是等待时间从1.5秒降到1秒以内的区别。
最后是推理模型本身。我用的虽然是个“轻量级”模型，但也有7B参数了。我一直在用vLLM来部署，看中了它的PagedAttention和高效内存管理。但在资源极度受限的环境下，vLLM本身也有开销。我切换到更底层的、更“裸”的推理方案，比如直接用Hugging Face的`pipeline`，并开启`torch.compile`进行图优化，同时把模型精度从FP16降到INT8量化。这个过程很痛苦，需要反复测试不同批次大小下的内存溢出点。屏幕微光下，终端里不断滚动的内存错误信息像是某种嘲弄。我像在走钢丝，一边是精度损失带来的效果衰减，一边是内存限制带来的崩溃风险。
我写了个自动化脚本，用测试集循环跑不同的量化配置和批次大小，记录响应时间、内存峰值和输出质量（用BLEU和ROUGE分数简单衡量）。最终找到了一个平衡点：INT8量化，批次大小为1（流式处理），配合`torch.compile`的`max-autotune`模式。效果损失在可接受的2%范围内，但内存占用下降了35%，单次推理速度提升了25%。这最后的25%，是硬生生从硬件限制里抠出来的。
全部改完，已经凌晨三点。我重新打开房间的灯，突如其来的光亮有些刺眼。我把优化后的代码部署到那台廉价的VPS上，跑了一个完整的压力测试。平均响应时间从之前的2.3秒降到了1.1秒，内存使用峰值稳定在800MB以下。这意味着那台每月8美元的机器，现在可以稳稳地同时服务多个用户了。省下的不是几十上百美元，而是在“超级个体”的游戏中，用极致的技术把控换来的生存空间和利润空间。成本控制做到这个份上，已经不是在写代码，是在雕刻代码的骨骼，榨干每一滴算力的价值。
这大概就是单兵作战的宿命。没有团队可以分摊，没有预算可以挥霍，每一个百分点的性能提升，每一分钱的成本下降，都得靠自己从算法和逻辑的缝隙里用手抠出来。窗外还是黑的，但屏幕上的监控曲线平稳得令人安心。这最后1%的剪枝，剪掉的不是代码，是心里那份对资源不足的焦虑。
