核心要点

  • 能给主路径:选小模型 + 低比特量化(常 4bit)压住内存与体积

  • 能讲运行时:用 llama.cpp / MLC LLM / MediaPipe 等端侧框架,委托 NPU/GPU 加速

  • 能讲 KV cache:管理上下文缓存以省重复计算,但它占内存、随上下文增长需控制

  • 能点瓶颈:解码阶段受内存带宽制约,长上下文与续航/发热是主要约束

标准回答

一、先把结论讲清楚

整体思路

二、拆开机制和判断点

端侧跑 LLM 的关键是把内存占用和访存压到设备能承受的范围。

三、补上例子、边界和取舍

  • 选模型:优先小尺寸模型(SLM),必要时蒸馏/微调到目标任务;
  • 量化:权重通常量化到 4bit(如 GGUF/INT4),大幅降低体积与带宽需求,是端侧 LLM 的标配;
  • 运行时:用 llama.cpp、MLC LLM、MediaPipe 等专门框架,把算子委托给 GPU/NPU 加速;
  • KV cache 管理:缓存历史 key/value 避免重复计算,但它随上下文线性增长占内存,需限制上下文长度或做缓存淘汰/量化。

主要约束

自回归解码是访存密集型,性能瓶颈在内存带宽而非纯算力;长上下文会同时推高 KV cache 内存与延迟;持续生成还受功耗、发热降频与续航限制。因此端侧 LLM 多用于短上下文、低频交互的本地任务,复杂场景回落云端。

常见误区

⚠️ 常见踩坑

误区一:容易答偏的地方:只压模型权重却忽视 KV cache 内存——长上下文下 KV cache 可能比权重还吃内存;以及拿端侧 LLM 跑长链复杂推理,忽略发热降频导致的速度骤降。

追问

追问 1为什么端侧 LLM 普遍用 4bit 而不是 INT8?

LLM 权重量大,4bit 相比 8bit 再砍一半内存与带宽,对内存受限的手机至关重要,且现代权重量化(如 AWQ/GPTQ 系)在 4bit 下掉点已可控。INT8 精度更稳但体积偏大,常用于对精度更敏感或内存更充裕的场景。

追问 2长上下文下 KV cache 怎么优化?

常见手段:限制/滑动窗口上下文、对 KV cache 做低比特量化、采用分组查询注意力(GQA)减少 KV 头数、以及缓存淘汰策略。目标是把随上下文线性增长的 KV 内存压下来,避免爆内存与带宽瓶颈拖慢解码。

🔗 相似问题

同一考点的不同问法,换着练更稳

没找到想看的面试题?把你想看的告诉我们 →

延伸学习

按主题分类的相关资源,便于系统复习