记一次在轻量云服务器上跑开源小模型的调优过程

最近想在自己的华为云服务器上跑个开源模型，主要用来做日常文本的分类和提取，给自己的几个抓取脚本当后台接口。服务器配的是8核16G的配置，没有单买显卡，打算纯靠CPU跑量化版本。原本以为装好环境把模型拉下来就能直接用，实际部署跑压测的时候，还是遇到了几个没想到的细节问题。

第一个问题是内存差点被OOM打死。
刚开始没太在意量化格式，顺手拉了一个q8精度的权重。结果服务刚启动，空载就吃掉了接近8G内存，稍微来两个并发请求，内存占用瞬间飙到90%以上，Linux系统的OOM Killer直接把推理进程强制杀掉了。
后来对比了一下测试数据，像这类单纯的信息提取任务，其实没必要上q8。换成q4_k_m格式后，整个模型常驻内存降到了4.5G左右，给系统和后台其他脚本留出了足够的余量。实测在处理短文本时，4位量化的输出质量和原来基本没有肉眼可见的差距，但生成速度快了差不多三成。

第二个问题是CPU线程数并不是越多越好。
我的机器是8核，默认配置下推理程序直接把线程拉满了8个。
我开着top看监控，发现8个核心全占满的时候，Token生成速度反而不如调低一点。主要原因是云虚拟机的核在跑高负载向量计算时，线程开太满会导致内存带宽瓶颈和频繁的上下文切换。
后来把推理线程数手动限制在5个，并把几个后台常驻脚本绑定到其余核心上。调整之后，生成速度从每秒4个Token稳定提到了快6个Token，CPU的温度和负载曲线也平稳了不少。

第三个问题是长文本下的请求假死。
自己的脚本有时候会把整篇网页抓取下来的文本丢进去做摘要，一旦输入长度超过两千字，预处理（Prefill）阶段的耗时就会明显变长，首字延迟往往要等上七八秒。
最开始我的Python调用端写的是普通HTTP请求，设置了5秒超时，导致长文本请求频繁抛超时异常。
后来改了两处：一是调用端全面改用流式接收（stream模式），只要模型吐出第一个字符就算连接成功，避免整包等待引发的误判；二是输入端在丢给模型前，先用正则把重复的空格、回车和网页无用标签剔除掉，尽量把Prompt压在有效区间内。

目前这套轻量方案挂在后台跑了两周多，应付我个人每天几百次的资讯分析和格式化提取完全够用。对于并发要求不高、预算有限的个人开发者来说，在普通CPU机器上跑低位量化的小模型，算是一个性价比挺高的折中选择。