既然 OpenAI 不稳，我就把所有的 SOP 迁到了 Llama 镜像。今天下午，我本地部署的那个 Llama-7B 模型，在生成第 37 条博客草稿时又卡死了。不是显存爆了，是 Python 进程自己僵在那儿，日志里连个错误都没有。我盯着黑屏的终端，脑子里就一个念头：这破玩意儿，比我去年带的那几个应届生还难伺候。但没办法，OpenAI 的 API 昨天又抽了半小时，我付费的 GPT-3.5 接口返回了一堆 “rate limit exceeded”，可我的请求频率明明在配额内。这种不可控，在交付里是致命的。客户不会听你解释云端服务商的问题，他们只会觉得你菜。
所以，硬着头皮也得把本地化这条路走通。性能瓶颈不在模型推理，而在数据存取。我最初的架构很“互联网”，博客草稿、用户配置、操作日志全扔在云上的 MySQL 里，每次生成都要跨网络读写。本地模型本来推理就慢，再加上几百毫秒的数据库网络延迟，整个流程慢得像便秘。我拆了 nginx 日志看，平均响应时间 8.7 秒，这谁受得了。
我决定把数据层彻底本地化。第一个想到的是 SQLite。这玩意儿太老了，老到互联网圈子里提它都觉得“土”。但它的好处是，没有服务进程，没有网络开销，就是一个文件。我在项目根目录建了个 `.db` 文件，用 Python 的 `sqlite3` 库直连。所有的博客元数据——标题、生成状态、使用的提示词模板、版本号——全压进去。为了应对可能的高并发（虽然目前就我一个用户），我打开了 WAL 模式，并且所有写操作都封装在带重试的事务里。
改动不大，就三个核心表，但效果立竿见影。最直观的是延迟：从发起生成请求到拿到第一条流式响应，从之前的 3 秒多降到了 900 毫秒以内。这 900 毫秒里，有 800 毫秒是 Llama 模型在吭哧吭哧计算，真正花在数据存取上的时间几乎可以忽略。那种流畅感，是云端方案永远给不了的确定感。我甚至写了个简单的监控脚本，每秒去 `SELECT COUNT(*)`，看看有没有锁死，结果稳如老狗。
这让我想起 2017 年做微信小程序的时候，为了绕过腾讯的审核，把核心逻辑都塞到前端，用 `localStorage` 存关键状态。当时也是被逼的，但效果出奇的好。技术潮流天天变，今天向量数据库明天分布式训练，但很多问题的本质，就是把数据离计算近一点，再近一点。用最直接、最没有依赖的方式去解决。Llama 模型是不如 GPT-4 聪明，经常胡言乱语，需要我精心设计提示词去约束它。SQLite 也确实没法支撑百万 QPS 的社交应用。可对于我这个“一个人就是一支队伍”的博客引擎来说，它们构成的这个简陋系统，每一行代码、每一个字节的流向，我都清清楚楚。它可能随时会崩，但崩了我知道怎么修，知道问题出在哪个 `if` 语句上。这种掌控感，是过去两年在管理泥潭里挣扎时，最渴望也最丢失的东西。
身体还是有点跟不上了。搞完这个迁移，已经是凌晨一点。站起来去接水，膝盖咔哒响了一声。想起健身教练的话，核心肌群太弱，久坐的代偿。技术栈可以回退到简单稳固，但这副 2019 年透支过的身体，债还没还完。喝口水，回来看着那个安静运行的终端，和旁边那个小小的 `.db` 文件。行吧，至少今晚，这个系统是稳的。
