二途序

九月月报：本地 LLM 的天花板是内存带宽

覆盖范围：9.7 / 9.14 / 9.21 / 9.28 四周（9.28 周含 10 月初日期）。本月工作背景一句话：直博去向落定（进化计算 × LLM 交叉方向）、Linux 笔记本改造为内网助手底座、rss-reader 立项、本地小模型部署调通。

本月方法地图

mindmap
  root((九月方法))
    决策方法
      三步决策法
      方向等于交集
    性能分析
      实测基线先行
      内存带宽墙
    系统架构
      RSS 即消息队列
      内网自持
      任务分层
    排障与迁移
      服务绑定地址第一课
      先底层后上层
      先画全流程地图

原理深读：为什么本地 3B 模型只能跑 16 tok / s

是什么：llama.cpp 在 Linux 笔记本上部署 Granite 3B（Q4 量化），实测生成速度约 16 tok / s。做优化前先测瓶颈，结论是：撞内存带宽墙，软件已无优化空间。

为什么成立（机理）：自回归解码是逐 token 生成的 —— 每生成一个 token，都要把模型权重完整读一遍。batch = 1 时计算量极小、搬运量极大（算术强度约 1 FLOP / byte 量级 —— 这是推导值；Databricks 原文的表述是：decode "取决于权重加载得多快，而不是计算得多快"）。于是生成速度的上限由一条公式决定：

tok/s 上限 ≈ 有效内存带宽 ÷ 权重总字节数

实测反过来验证了这条公式：DDR4-2667 双通道峰值带宽约 42.7 GB/s，实测 16 tok/s 占峰值约 81%（≈34.6 GB/s）。按 granite-4.2-3b 官方 Q4_K_M 权重 2.24 GB 反推：16 tok/s × 2.24 GB ≈ 35.9 GB/s，与实测同量级 —— 数字彼此咬合。内存 2667 MT/s 是平台硬件上限，换推理框架、调参数的理论空间不到两成 —— 优化方向错了，再努力也是零。

由此得到三个可迁移的推论：

  1. 量化不是精度妥协，是带宽优化。Q4 量化把权重复制变小，直接抬高 tok / s 上限的分母。
  2. 共享内存平台上核显卸载无收益。核显和 CPU 共用同一条内存带宽，数据还要多跨一次拷贝 —— 实测卸载反而降速。优化的前提是确认瓶颈资源真的被绕开了。
  3. 硬件升级要升级瓶颈本身。这条平台上，加内存通道 / 换更高频率内存 > 任何软件优化。

边界在哪：

  • 该结论只覆盖 decode（逐 token 生成）阶段。prefill（读长上下文出首 token）是计算受限，长文档场景瓶颈会移到算力。
  • 只适用于 dense（稠密）模型。granite 3B 系分两支：a800m 系是 MoE（每 token 只读被激活的那部分权重），4.1 / 4.2-3b 是 dense（每 token 读全部权重）。本文按 dense 分支处理 —— 实测带宽占用与 dense 权重体积自洽；若部署的是 MoE 分支，公式要改成 "带宽 ÷ 激活权重字节数"。
  • GPU 有独立 HBM 显存，带宽与计算解耦，这套 "内存带宽决定一切" 的推理不能直接搬过去。
  • batch > 1 的服务场景，吞吐瓶颈转移到算力与调度，单请求延迟与吞吐要分开讨论。

业界对照：Databricks 的推理性能指南明确 "首 token 生成通常是计算受限，后续 decode 是内存受限操作"，并提出 MBU（带宽利用率）作为核心指标 —— 定义为 "达成带宽 ÷ 峰值带宽"，其中达成带宽 =（模型参数总量 + KV cache）÷ 每 token 平均时间；NVIDIA 的推理优化文章也明确 "模型执行经常受限于内存带宽 —— 尤其是权重读取"。本月实测（81% 带宽占用）正是 MBU 思路在消费级硬件上的手工复现。

原理清单

  • 三步决策法：自我梳理（做了什么、能做什么）→ 广泛调研（形成初判）→ 定向核实（敲定关键信息）。每一步都在收敛，避免信息不足时拍终局决定。本月用它完成直博去向、导师、方向三定。
  • 方向 = 交集：新方向选 "已有积累 × 新机会" 的交集 ——LLM 工程经验（agent、RAG）× 智能优化课题，交集处最省力且有复利。
  • RSS 就是消息队列：拉取式消费天然具备持久化、按需消费、削峰三个性质。由此推出消费策略：每日限额读取，不追时效。展开见已发布文章《 RSS 就是消息队列 》。
  • 内网自持：抓取（firecrawl）与推理（本地 llama）都不出内网 —— 个人长期运行的系统，成本可控与数据可控是设计约束，不是加分项。
  • 任务分层：3B 本地模型做分类、摘要等轻任务，重分析交给大模型；小模型的提示词要少而显式，靠它自由发挥只会翻车。
  • 服务绑定地址第一课：127.0.0.1 只指当前机器。pi 连不上 llama-server，根因就是 llama-server 默认绑定回环地址，改 0.0.0.0 才对外可达。"本机服务连不上" 先查绑定地址，再查防火墙。
  • 先画全流程地图再学组件：用 "电商 10 亿日志分析" 案例串起 Flume → Kafka → HDFS → Spark → Hive → Flink → MySQL，每个组件的价值只有放进整条链路才看得见。逐个背概念是低效路径。
  • 先底层后上层：系统迁移的顺序是介质 → 系统 → 存储 → 环境。底层不稳，上层返工。
  • 长链路沉淀成模板：海外 AI 订阅要连过支付与访问两道坎（订阅成功 ≠ 能用）。"USDT + 虚拟卡 + 地区调整" 一次打通后模板化，下次照抄。
  • 时效性甄别：信息消费系统天然有 "追实时" 的冲动，但个人学习场景晚几小时读毫无损失。先判定需求真伪，再设计消费模型。

反例与边界

  • 核显卸载（反直觉反例）：直觉上 "把计算卸给核显" 是加速，实测反而降速 —— 共享带宽平台上，卸载没有绕开瓶颈资源，只是多了搬运成本。反直觉结果先查 "瓶颈假设" 是否成立。
  • 追时效（伪需求反例）：为不存在的时效要求设计实时管线，是过度设计。

参考资料