这个站跑在一台 4G 内存的腾讯云小机器上。这个数字看着不起眼，可它反向决定了半个技术栈——尤其是模型这块。哪些模型能进来、以什么方式进来，几乎全是被这 4G 逼出来的。
先把账摆出来。系统加 Docker 吃掉约 0.6G，Postgres 配了 256MB 的 shared_buffers、实际占约 0.5G，FastAPI 进程带着嵌入模型约 0.7G，Caddy 几乎不占。ingest 入库时峰值再加 0.8G。算下来峰值约 2.7G，留给腾挪的不到 1.5G。任何一个想常驻的模型，都得在这个额度里找位置。
嵌入模型：进程内的小家伙
向量检索 需要一个嵌入模型把文字变成向量。我选的是 bge-small-zh——512 维、约 500MB、进程内跑 CPU 推理。为什么不上 Ollama 挂个更强的 bge-m3？因为 bge-m3 是 1024 维、约 2G，加上 Ollama 自己的开销，直接把额度撑爆。500MB 的小模型进程内常驻，是唯一塞得下的方案。
代价是精度。bge-small-zh 是 2023 年的模型，放到 2026 年，C-MTEB 榜上已经被 Qwen3-Embedding-0.6B 这类新模型甩开近十分。够用，但不再是最好。
量化：能不能把更强的压进来
那能不能把更强的模型压小、塞进这台机器？这是量化的用武之地。
Qwen3-Embedding-0.6B 原始 fp32 权重约 2.4G，装不下；Q4_K_M 量化之后，模型体积约 400MB、运行约 1G 内存——4G 机器塞得下。量化是用精度换体积：把 32 位浮点权重压成 4 位整数，模型小几倍，效果掉一点点。
但量化不是免费的。有个现实容易被乐观估计盖过去：0.6B 比 bge-small 的 24M 参数大了二十多倍，就算量化压了体积，CPU 推理的延迟压不下来——“纯 CPU 50–150 tokens/s 可接受”这种说法，真跑起来站不住。所以换不换，是”检索质量 vs 入库/查询延迟”的权衡，不是无脑赢。好在嵌入器是个可替换接口，真要换，写个新子类、ingest --rebuild 一次就过去了，架构早留好了口子。
大模型：干脆不本地跑
DeepSeek 那类大语言模型，我干脆不在本地跑。本地连个 4B 都装不下，而这个站真正需要 LLM 的地方很少、很轻——从笔记里抽点隐性关系、给术语生成个释义草稿。花小钱调云端 API，比为了”全本地”硬扛内存划算得多。
这也是整个选型的基调：把重的、不稳的推到边缘和末级，核心保持轻、稳、可离线重建。核心链路——写 md、建节点、双链、向量检索——完全不碰 LLM，API 挂了就跳过这一步，其余照常。
LoRA：留给未来的一个口子
更远一点的设想是 LoRA 微调。通用大模型抽取知识关系，泛而不精；要是拿这个站积累的笔记当训练数据，用 LoRA 微调一个小模型专门干”从我的笔记里抽概念关系”这一件事，可能又小又准。
LoRA 的巧处在于不动原模型权重，只训练一小撮低秩矩阵——几十 MB 的增量，就能让模型学会一个专项任务。它是路线图上一到三年的事，不急，但方向先留着。
一台 4G 小机器，逼着你想清楚每一个模型到底有没有必要。这未必是坏事——约束往往比”我全都要”更能逼出清醒的选择。等哪天真觉得检索不够用了、或者攒够了微调数据，架构留好的口子随时能换。在那之前，小而稳，够用。