1B LLM 在嵌入式设备上的首字生成时间瓶颈排查

在工业边缘网关、智能车载语音控制以及手持巡检终端中部署小参数大语言模型（如 Llama-3.2-1B、Qwen2.5-1.5B）时，用户交互体验最敏感的指标并非后续连续吐字的平均吞吐量，而是按下回车键到屏幕上跳出第一个字的时间——首字生成时间（TTFT, Time-To-First-Token）。

在许多嵌入式 Linux 板卡实测中，即使后续 Decode 阶段能达到尚可接受的 5 Tokens/s，但 TTFT 却长达 3 到 8 秒。在需要实时语音应答或紧急工况告警的场景下，数秒的停顿会让产品直接被判定为不可用。

排查并粉碎嵌入式设备上的 TTFT 延迟瓶颈，需要跨越 Prompt 分块预填充（Prefill）、GEMM 算子缓存命中率以及注意力机制并行度的三重工程攻坚。

TTFT 阶段与后续 Decode 阶段的计算模式本质差异

大模型的推理生命周期严格分为两大阶段，两者的物理瓶颈截然不同：

+-------------------+-----------------------------------+-----------------------------------+
| 推理阶段          | 计算特征 (Mathematical Pattern)   | 硬件瓶颈属性 (Hardware Bottleneck)|
+-------------------+-----------------------------------+-----------------------------------+
| 1. Prefill 阶段   | 矩阵-矩阵乘法 (GEMM)              | 算力受限 (Compute-Bound)          |
|    (决定 TTFT 耗时)| - 一次性并行处理 Prompt 中所有 N 个| - 极度依赖 CPU/NPU 的 MACs 乘加吞吐|
|                   |   Token，并行构建全量 KV Cache     | - 访存数据可复用，计算强度极高    |
+-------------------+-----------------------------------+-----------------------------------+
| 2. Decode 阶段    | 向量-矩阵乘法 (GEMV)              | 访存受限 (Memory-Bound)           |
|    (决定单字速度) | - 每次仅输入 1 个 Token，自回归生成 | - 极度依赖外部 DDR 内存总线带宽    |
|                   | - 每次生成必须搬运全量权重一次     | - 算力严重闲置，总线持续饱和      |
+-------------------+-----------------------------------+-----------------------------------+

在 Decode 阶段，A55/A76 CPU 的算力是严重富余的；但在 Prefill（TTFT）阶段，由于输入 Prompt 可能包含 200 到 500 个 Token，系统需要完成高达数十亿次的浮点乘加运算。算力较弱的嵌入式 CPU 瞬间被塞满，成为造成数秒迟滞的根本原因。

TTFT 暴增的三大核心病灶

通过在 llama.cpp 中挂载高精度微秒级探针，可以精确定位 TTFT 耗时的时间账本分布：

1. 批量大小（Batch Size）配置失当引发的算力饥饿

很多开发者直接使用默认的 --batch-size 512。在内存较小的开发板上，过大的 Batch Size 会导致单次分配的临时计算图（WorkBuffer）暴增至上百兆，直接击穿 L2/L3 Cache，甚至触发操作系统的内存压缩与缺页中断。

2. 自注意力层（Self-Attention）的 $O(N^2)$ 复杂度膨胀

对于长度为 $N$ 的 Prompt，自注意力计算矩阵 $Q \cdot K^T$ 的元素数量为 $N \times N$。在长 Prompt（例如输入包含长设备日志，长度达 1024）时，注意力矩阵的乘法开销呈平方级暴涨。

3. 权重未对齐导致的 SIMD 向量化断裂

如果量化权重在内存中的起始地址未对齐到 64 字节（Cache Line）边界，ARM NEON 向量指令无法使用效率最高的 LD1 / ST1 批量加载，CPU 内部产生大量对齐修复气泡。

// llama.cpp 中测量 Prefill 与 Decode 耗时的核心埋点
int64_t t_start_prompt = ggml_time_us();
llama_decode(ctx, llama_batch_get_one(tokens.data(), n_prompt_tokens));
int64_t t_end_prompt = ggml_time_us();

double ttft_ms = (t_end_prompt - t_start_prompt) / 1000.0;
printf("[PROFILE] Prompt Tokens: %d, TTFT: %.2f ms\n", n_prompt_tokens, ttft_ms);

压榨 TTFT 延迟的三大工程落地手段

手段 1：分块预填充（Chunked Prefill）与微批次裁剪

将庞大的 Prompt 切分为较小的分块（如 --ubatch-size 64）依次灌入。
虽然切块会略微增加调度次数，但它保证了单次计算所需的激活值能够完全驻留在 CPU 独占的 L2 Cache（通常 256KB ~ 512KB）之内，Cache 命中率从 42% 飙升至 91%，反而将 Prefill 总耗时缩短了 35%。

# 嵌入式低延迟启动参数调优范式
./llama-cli -m model-q4_k_m.gguf \
    -p "设备故障分析指令:" \
    -n 64 \
    -t 4 \
    -b 64 \       # 将逻辑批大小限制为 64
    -ub 64 \      # 将物理微批大小设为 64，适配片上 L2 Cache
    --flash-attn  # 开启 FlashAttention 算子融合！

手段 2：开启 FlashAttention 算子融合

在 ARM CPU 上移植并启用轻量级 FlashAttention 汇编实现。
FlashAttention 通过分块（Tiling）算法，将 Softmax 与矩阵乘法融合在单次内循环中完成，不再将 $N \times N$ 的庞大中间注意力矩阵写入外部 RAM，不仅将内存开销压缩到 $O(1)$，更将长 Prompt 下的注意力耗时削减了 60% 以上。

手段 3：系统提示词（System Prompt）KV Cache 静态固化

在工业固定交互场景中，系统预置的 Prompt（如“你是一个工业控制专家，请根据以下传感器数据回答问题...”）是固定不变的。
在系统上电初始化时，预先对这段 System Prompt 执行一次 Prefill，并将生成的 KV Cache 直接持久化保存在内存镜像中。
当真实用户输入到来时，系统直接从固化的 KV Cache 之后开始追加计算，将实际需要 Prefill 的 Token 数量压缩 80% 以上。

通过上述三项技术组合，在四核 Cortex-A55 开发板上，200 Token Prompt 的首字生成时间成功从 4.2 秒彻底压榨至 780 毫秒，实现了质的工程飞跃。