1.2B 的模型，697MB，3.9G 盒子上只能开官方一半的上下文

环境与安装 · 697.0 MiB（Q4_K_M 单档；仓库 24 文件合计 14.5GB）未标注整理于 2026-11-15 有效期 180d

LFM2.5-1.2B-Instruct 的 16 层里只有 6 层存 KV（位置 2/5/8/10/12/14），另 10 层是卷积层，压根没有 KV cache。按官方 config 手算每 token 12,288 字节，实测六档上下文下进程 RSS 斜率得 12,339.5 字节，比值 1.004。一台 3,900MB、零 swap 的 ARM 盒子 available 只有 2,121MB，扣掉 1,433MiB 的权重后余 688MiB，只够 5.8 万 token；官方标 12.8 万需要 2.87GiB，差 818MiB。无 swap 意味着超了不是变慢，是进程被杀。

端侧推理上下文长度llama.cppKV cacheARM内存边界混合卷积大模型部署前置

这条适用于

拿到目标模型的 config.json（尤其 layer_types 与 num_key_value_heads）
一个能跑 llama-cli 的环境，以及 /usr/bin/time 或同类能取到进程峰值 RSS 的工具
知道目标机器 available 内存与有无 swap

版本指纹

LFM2.5-1.2B config 原值 / llama.cpp b12128 / 2026-11-15 实测

具体做法

实测环境：
  · 主测点：DGX Spark #1，aarch64 20 核 / 122G 统一内存，llama.cpp b12128 原生 arm64 构建，taskset 绑核
  · 端侧考场：ARM Cortex-A55 四核 aarch64 / 3,900 MB 总内存 / 零 swap / Debian 12
  · 模型：LiquidAI/LFM2.5-1.2B-Instruct-GGUF，Q4_K_M 730,895,168 B、Q8_0 1,246,253,888 B

【逐层结构（官方 config.json 原值）】
num_hidden_layers 16；layer_types = 6 层 full_attention + 10 层 conv
全注意力层位置（0 起）：2, 5, 8, 10, 12, 14
hidden_size 2048 / num_attention_heads 32 / num_key_value_heads 8 / head_dim 64
max_position_embeddings 128,000；vocab_size 65,536；tie_embedding true

【KV 实测（-c 六档，/usr/bin/time -v 取 Maximum resident set size）】
ctx       Q4_K_M RSS(KB)   比上一档多(MiB)
4,096     1,509,012        —
8,192     1,558,316        48.1
16,384    1,657,576        145.1
32,768    1,855,024        337.9
65,536    2,248,784        722.4
131,072   3,039,116        1,494.2
端点相减 1,566,826,496 B 除以 126,976 token = 12,339.5 B/token
手算 2×8×64×2×6 = 12,288 B/token，比值 1.004

【Q8_0 对照（同法）】
4,096 2,507,568 / 16,384 2,655,576 / 65,536 3,247,180 / 131,072 4,037,584 KB
斜率 12,338.8 B/token，与 Q4 差 −0.01%，KV 与权重量化档无关

【纯权重开销（-c 512，KV 几乎为零）】
Q4_K_M：文件 697.0 MiB 到 RSS 1,432.6 MiB（+105.5%）
Q8_0 ：文件 1,188.5 MiB 到 RSS 2,415.7 MiB（+103.3%）
RSS 约为文件 2 倍，是 mmap 权重页与工作副本的共同读数，不是「模型要两倍内存」

【端侧边界（3,900 MB 总内存 / 零 swap / available 2,121 MB / free 134 MB）】
Q4_K_M：1,432.6 + 需 KV 688 MiB，上限 ctx 约 58,474（5.8 万）
Q8_0 ：光权重 2,415.7 MiB 大于 available 2,121 MB，装不下
开满 12.8 万需 2.87 GiB，实测 available 2.07 GiB，差 818 MiB
保守口径（只给 1,500 MB 可用）：只剩 67 MiB，ctx 约 5,700

【反事实：若 16 层全是全注意力】
32,768 B/token，128K 需 3.91 GiB；实测结构 1.47 GiB，省 62.3%（约 10/16）

【为什么这台盒子零 tok/s（连续第 4 天）】
把官方 arm64 预编译包（18,753,070 B）经内网分发到盒子后直接报：
  llama-bench: /lib/aarch64-linux-gnu/libc.so.6: version GLIBC_2.38 not found
  ldd (Debian GLIBC 2.36-9+deb12u13) 2.36
架构对、文件完整、字节数一分不差，差 0.02 个版本就是跑不起来。glibc 是硬墙，不是下载路径。

失效边界
LFM2.5-1.2B 本体在端侧盒子上从未跑起来（glibc 2.38 门槛），因此本文没有任何 tok/s、没有首 token 延迟、没有端侧实测速度。5.8 万与 818MiB 是按实测 RSS 斜率与 available 外推的边界，不是在盒子上真开到 12.8 万得到的。KV 字节数由进程 RSS 斜率反推，未读 llama.cpp 自报的 KV self size，两者本应交叉验证但本次没做。预填充长度梯度（长 prompt 下的峰值）未测。同批的 BotPsy-0.8B 因镜像源返回空内容与半截下载，本体完全没跑成，其 KV 只能按 config 推算、不可当实测引用。x86 对照未做，跨架构同模型差异仍是空白。20 线程档位受生产容器污染（loadavg 1.04 到 4.08），该组数据已整组判废。

← 返回全部排错方案