想把 Colibrì 的内存占用压下去，又不想牺牲首字延迟，先把两个配置项拆开看：冷层目录决定哪一部分权重落到磁盘，热层上限决定有多少权重必须常驻内存。热层上限直接决定常驻内存的上限，冷层目录则决定超出热层的那部分权重从哪个介质读。首字延迟主要由“请求开始要用的那段权重是否已经在内存”决定，因此两个配置都会影响首字延迟，但影响路径不同：冷层目录换的是介质速度，热层上限换的是命中比例。判断顺序建议是先用内存差值定出必须挪出去的量级，再做单变量对照。

先用权重总体积减去可用内存（扣除其他进程与并发余量）算出必须挪到磁盘的量级，再据此设冷层目录和热层上限。只改冷层目录时看介质差异，只改热层上限时看容量带来的边际收益；热层上限加到首字延迟不再明显下降就停手，剩下的内存留给页缓存。字段名和默认值以仓库文档与实际启动日志为准，不要假定默认就是省内存。

先算清权重总量与可用内存之间的差值

先量权重文件的体积，不是量进程 RSS。如果权重按层或按分片存放，逐个目录看更接近真实分布：

du -sh /path/to/weights/*        # 目录粗看，能看出哪层最大
ls -l  /path/to/weights/*.bin    # 单文件字节数

再量机器上真正可用的内存。MemFree 通常偏小，MemAvailable 更接近“还能给新进程用多少”，但它把可回收页缓存算进去了；如果 Colibrì 用 mmap 方式读权重，页缓存本身也会占内存，所以还要给并发请求和其他进程留出余量：

free -m
grep -E 'MemTotal|MemAvailable' /proc/meminfo

差值计算可以写成：需要挪出去的量 = 权重总体积 −（MemAvailable − 预留给其他进程与并发的量）。如果结果为负，说明不需要落盘也放得下，冷层目录此时更多是缩短启动或降低常驻 RSS 的手段；如果为正，这个正值就是冷层要承接的量级，热层上限大致等于权重总量减去这部分，而不是凭感觉写一个整数。预留量建议先保守取大一些，跑过一轮再收。

冷层目录与热层上限分别写在哪

两个变量要能独立调整，最好不要写在同一行里做联动。下面只是示意骨架，字段名与是否支持按比例写法，以仓库文档为准：

storage:
  cold_layer_dir: /var/lib/colibri/cold   # 冷层落盘目录
  hot_layer_limit: 8G                     # 热层常驻上限

默认行为需要结合环境确认：多数实现里冷层目录缺省指向本地缓存目录，热层上限缺省为不限制（全部常驻）或按可用内存自动推算。也就是说，不改热层上限只改冷层目录，常驻内存可能几乎不动，这一点在后面的对照里会体现出来。

启动时三项一起确认，只看日志的“已启用”容易被误导：

colibri serve `--config` /etc/colibri/config.yaml 2>&1 | grep -iE 'cold|hot|layer|offload'
ls -l /var/lib/colibri/cold | head      # 目录是否真被写入
ps -o rss= -p $(pgrep -f colibri)      # RSS 是否落在热层上限附近

如果 RSS 明显高于设定的热层上限，常见原因是冷层目录不可写、权限不足后回退到内存，或者配置项没被读取。目录里有文件、日志有记录、RSS 跟上限对得上，三条都满足才算生效。

固定热层上限只改冷层目录做对照

这一组对照用来分离介质因素。热层上限保持不动，只换冷层目录所在的盘（本地 SSD、另一块盘、网络盘）。同一批请求要固定 prompt 集、并发数和上下文长度，并在每轮开始前清一次页缓存，否则上一次读的页缓存会把介质差异掩盖掉。清缓存的操作建议只在测试机做：

sync; echo 3 > /proc/sys/vm/drop_caches    # 需权限，测试机使用

读盘次数可以用 pidstat -d -p 观察进程级读写，或看 /proc/diskstats 前后差值；首字延迟用客户端计时或服务端日志里的首 token 时间；RSS 用 ps -o rss=。判断方式很直接：读盘次数接近而首字延迟差距明显，说明是介质速度在起作用；读盘次数差异很大，说明冷层被访问的次数本身变了，要先检查热层是否按预期命中。

再固定冷层目录只改热层上限

这一组用来观察容量对延迟的边际影响。冷层目录不变，把热层上限按权重总量分成几档逐步抬高，每档重复同一批请求并记录同样三项：

停止加码的判断依据建议是：同一档位重复跑几次，先估出首字延迟自身的波动范围；相邻两档之间的下降幅度落进这个波动范围，就没有继续加的必要，因为再往上只是吃内存。同时看 RSS 是否随上限同步变化——RSS 不动，说明配置没被读取，或者当前请求实际用到的权重早就落在热层里，此时延迟的改善与上限无关。最后留一部分内存给页缓存和突发并发，通常比把热层顶到极限更稳。