27届大模型面试准备三十四端侧大模型部署与压缩工程——把 7B 塞进手机与显卡的实战本篇是 A 系列第 34 篇。前面 A19 讲过量化原理、A30 讲过服务端推理优化、A27 讲过蒸馏。但把模型跑在手机、PC、边缘盒子、车载芯片是另一套完全不同的工程显存不是问题、内存带宽才是瓶颈NPU 是主角、CUDA 不是功耗和发热是硬约束。本文聚焦端侧on-device大模型部署把压缩、推理引擎、内存管理串成一条可落地的链路。A33 讲的是怎么取分布里的 token本文讲的是在哪取、取得起取不起——两者共同构成大模型落地的最后一公里。一、为什么端侧是大模型落地的必答题云端推理有三大原罪隐私数据出端、延迟网络往返 排队、成本每 token 都烧钱。端侧推理恰好对症云端推理 端侧推理 延迟组成: 网络RTT排队前向 仅前向(本地) 数据: 上传到服务器 不出本机 成本: 按 token / 调用计费 一次性部署, 边际成本≈0 离线: 依赖网络 飞行模式也能用 功耗: 服务器吃电 受设备电池/发热限制所以端侧不是性能差的将就而是隐私敏感、实时、离线、低成本场景的唯一解。手机语音助手、车载对话、本地代码补全、隐私文档分析都指向端侧。面试被问为什么不直接调 API要能讲清这四条账。反过来端侧也不是万能复杂长上下文、需要最新知识的任务还是得靠云端。所以端还是云本质是路由问题本文第七节会讲。二、端侧的三座大山带宽、内存、算力服务端优化常盯着显存够不够端侧第一瓶颈其实是内存带宽memory bandwidth。端侧推理时间 ≈ 计算时间 搬运时间 小算子: 受算力限制 大矩阵(权重读取): 受 内存带宽 限制 - 端侧主战场 例: 7B 模型 FP16 权重 ~14GB, 哪怕 100GB/s 带宽, 仅读一遍权重就要 0.14s 要实时(30 tok/s)就得反复读, 带宽直接决定吞吐三座大山1.带宽墙权重要从存储DRAM/磁盘搬到计算单元带宽决定上限。量化直接砍权重体积是最有效的手段。2.内存墙手机的可用内存可能只有 4~8GB模型权重 KV Cache 运行时必须都装下常要靠mmap 按需分页而非一次性加载。3.算力墙NPU/CPU 峰值算力有限且持续算力受发热限制手机跑几秒就降频。┌──────────────┬─────────────┬────────────────────────────┐ │ 瓶颈 │ 端侧表现 │ 对应解法 │ ├──────────────┼─────────────┼────────────────────────────┤ │ 内存带宽 │ 致命 │ 量化(4bit)、权重复用 │ │ 可用内存 │ 紧张 │ mmap 分页、KV Cache 压缩 │ │ 持续算力 │ 受发热限制 │ 低比特、算子融合、NPU │ │ 功耗/电池 │ 硬性约束 │ 早退、动态算力分配 │ └──────────────┴─────────────┴────────────────────────────┘三、压缩端侧的第一刀永远是量化端侧模型几乎必做量化。回顾量化家族A19 详细讲过这里讲部署视角INT4 / INT2端侧主流。7B 模型 INT4 后权重约 3.5GB能塞进手机。AWQ、GPTQ 是常用 PTQ 方案。FP8服务端友好端侧 NPU 逐步支持精度损失小。混合精度敏感层如 attention 的某些投影留高精度其余压低——比全层统一 4bit更稳。训练后量化PTQvs 量化感知训练QAT端侧追求极致时QAT 用少量数据微调恢复精度但成本高多数场景 PTQ 校准集足够。# 用 llama.cpp / GGUF 做端侧量化概念示意# 1) 原始模型转 GGUFpythonconvert_hf_to_gguf.pyQwen2.5-7B/--outfileqwen.gguf# 2) 量化到不同比特./llama-quantizeqwen.ggufqwen-Q4_K_M.ggufQ4_K_M./llama-quantizeqwen.ggufqwen-Q2_K.ggufQ2_K# 更小更失真# Q4_K_M: 质量与体积平衡, 端侧 7B 首选# Q5_K_M: 质量更好, 体积更大一个容易被忽视的点端侧的精度损失比服务端更敏感因为端侧常跑小模型1B~3B本来就脆弱压到 INT2 可能直接崩。所以端侧量化要更谨慎地做逐层敏感度分析把对 perplexity 影响大的层保留高精度。这一点和 A19 讲的服务端量化可接受更大压缩比形成对照——端侧容错更低。四、推理引擎谁在端侧跑模型端侧没有 vLLM 这种大一统而是按平台分裂┌────────────────┬──────────────────────┬──────────────────────┐ │ 引擎/框架 │ 平台 │ 特点 │ ├────────────────┼──────────────────────┼──────────────────────┤ │ llama.cpp │ 跨平台(C/CPU/GPU) │ GGUF、量化生态最成熟 │ │ MLC LLM │ 移动/iOS/Android/Web │ TVM 编译, NPU 友好 │ │ Ollama │ 桌面(Mac/Win/Linux) │ llama.cpp 封装, 易用 │ │ ExecuTorch │ 端侧(PyTorch 官方) │ 移动端推理, 边缘部署 │ │ TensorRT-LLM │ NVIDIA GPU/数据中心 │ 极致优化, 非严格端侧 │ │ CoreML/MNN │ Apple/移动 NPU │ 厂商加速, 闭源生态 │ │ onnxruntime │ 跨平台 │ ONNX 中间表示 │ └────────────────┴──────────────────────┴──────────────────────┘选型逻辑要最大兼容性与量化生态选 llama.cpp要真·手机 NPU 加速选 MLC LLM / ExecuTorch要桌面开发者体验选 Ollama。面试能列出这张表并说清为什么端侧没有统一引擎已经超出多数候选人。根本原因是端侧硬件NPU 架构、驱动、内存模型极度碎片化一个引擎很难在所有芯片上都做到最优。五、内存管理mmap 与 KV Cache 的端侧腾挪端侧内存紧张两个关键技术5.1 mmap 按需加载权重大模型权重文件可能比可用内存大。用内存映射mmap把文件映射到虚拟地址只在实际访问的页才真正读入物理内存OS 按 LRU 回收。这样模型能开、但不一次性占满内存。// llama.cpp 用 mmap 加载权重概念void*ptrmmap(NULL,file_size,PROT_READ,MAP_PRIVATE,fd,0);// 访问某层时 OS 才把对应页换入; 不需要的页被回收// 手机上可配合 MADV_DONTNEED 主动释放不用的层5.2 KV Cache 压缩端侧上下文长了 KV Cache 占内存爆炸。手段A30 提过端侧更重要-量化 KV Cache8bit/4bit省一半以上。-滑动窗口 / 对话裁剪只保留最近 N 轮。-前缀缓存复用系统 prompt 的 KV 只算一次。端侧 7B, 上下文 4k, FP16 KV ~ 每层都要存 k,v - 量化到 8bit 直接省 50% 内存 - 配合只保留最近对话, 长聊天也不崩六、NPU 与算子端侧的算力真相手机的AI 算力宣传很猛几十 TOPS但工程上要清醒-峰值算力 ≠ 持续算力NPU 跑几秒就因发热降频实际可持续算力可能只有峰值的 1/3。-算子覆盖不全NPU 对常见算子快但对新型算子如某些 MoE 路由、自定义激活可能不支持被迫回退 CPU反而更慢。-精度支持有限很多 NPU 只高效支持 INT8/INT4FP16 反而慢所以端侧量化不是可选项而是必选项。# MLC LLM 编译到手机 NPU概念# 1) 定义模型 量化modelmlc.Model(Llama-3-8B,quantizationq4f16_1)# 2) 用 TVM 编译为目标硬件 (Android NPU / Apple Neural Engine)model.build(targetandroid,gpumali)# 3) 打包 apk / 动态库, 端上加载七、端云协同不是二选一而是分工最成熟的落地往往是端云协同而非纯端侧用户请求 │ ├─ 简单/隐私任务 ── 端侧小模型直接答 (低延迟、零成本、离线) │ └─ 复杂/长上下文 ── 路由到云端大模型 (高质量) 路由判断: 意图复杂度 / 是否需要检索 / 隐私等级这其实是 B26Agent 成本工程和 A30推理优化在端侧的投影用路由把贵的大模型用在刀刃上。端侧小模型做第一道过滤 隐私兜底云端做重活。面试能画出这个路由架构会显得你有真实落地经验而非只会调 API。八、端侧特有的质量坑量化掉点4bit 下某些任务尤其是需要精确计数、长链推理明显退化。对策敏感层升精度、关键任务走端云协同。首 token 延迟TTFT端侧加载权重 编译图可能要几秒用户以为卡死。对策预加载、预热、进度提示。发热降频连续对话后越聊越慢。对策限流、动态降 batch、必要时提示切云端。系统碎片化Android 机型 NPU 各异一套引擎难全适配。对策CPU 兜底路径 分机型灰度。九、生产落地深潜部署 checklist 与工程真相把端侧模型真正推上线我建议按这张清单逐条过关。第一关是体积与内存目标设备可用内存多少模型量化后权重 KV Cache 峰值是否压得进用 mmap 能否避免一次性 OOM第二关是延迟预算TTFT目标1.5s、解码速度目标15 tok/s 才不憋屈、长对话下是否仍能维持第三关是精度验收在目标任务的本地测试集上4bit 相比 FP16 掉点是否2%掉点超标的层要升回 8bit 或 16bit。第四关是功耗与发热连续 5 分钟对话设备温度与降频曲线如何是否需要在系统层限流。这张清单的精髓是先定设备规格再反向选压缩档位而不是先训好模型再想办法塞。很多团队拿着一个 14GB 的 FP16 模型去适配 6GB 内存的手机怎么做都难受——正确做法是立项时就锁定目标设备 目标延迟 目标精度据此选基座大小1B/3B/7B和量化档Q4/Q5/Q8。这和普通服务端模型越大越好、显存不够就加卡的思维方式正好相反是端侧工程最反直觉、也最容易被 junior 忽略的一点。9.1 量化格式与引擎强绑定再补一个真实踩坑端侧量化格式和引擎强绑定。llama.cpp 的 GGUF Q4_K_M、MLC 的 q4f16_1、CoreML 的 4bit三者数值实现不同、跨引擎不能混用。曾经有团队在服务器用 llama.cpp 测了 Q4 精度达标上线却用 MLC 重新量化结果同一模型精度差了 5 个点——因为校准集和量化粒度不同。所以端侧压缩必须在哪个引擎跑就在哪个引擎量化把量化步骤固化进 CI而不是本地手动敲命令。能讲出这个细节面试基本直接判定你做过真端侧而不是纸上谈兵。9.2 端侧与服务端优化的本质差异补一节思维转换——很多做惯服务端推理优化的工程师上手端侧会本能地用同一套打法结果处处碰壁。核心差异有四点。其一瓶颈不同服务端卡显存和算力端侧卡内存带宽所以服务端靠堆卡、端侧靠量化压缩带宽需求。其二可观测性不同服务端有完善的 GPU 监控、profiling端侧 NPU 常常是黑盒连这一层跑了多久都拿不到细粒度数据只能靠端到端延迟反推。其三失败模式不同服务端失败多是 OOM 或超时端侧失败多是发热降频导致的前几轮快、后几轮慢、以及机型碎片化导致的这台能跑那台崩。其四迭代速度不同服务端改个配置秒级生效端侧改量化要重新编译、重新打包、重新上架迭代以天计。把这四点刻进脑子才能避免用服务端思维做端侧的错位。9.3 实测解读、跨平台适配与成本账补一节看懂数字的能力这是工程师和调参侠的分界。端侧部署报告里常写Q4 下 perplexity 只涨 0.3但你要会追问这个 0.3 是在什么测试集上测的通用语言模型基准的 0.3 可能毫无意义业务任务的掉点才是真金。我习惯在目标业务的小测试集比如真实的客服问答、真实的代码补全片段上做精度验收而不是信通用 benchmark。曾经有个项目在 WikiText 上 Q4 几乎无损但实际代码补全任务掉点 12%——因为代码对精确 token 更敏感通用基准掩盖了。所以端侧验收的铁律是在业务数据上测不在公开基准上自我安慰。跨平台适配是另一块硬骨头。同一份 GGUF 在 llama.cpp 上跑得欢到了某 Android 机型用 MLC 重编译速度可能差三倍原因是 NPU 驱动版本和算子支持不同。我的经验是建立机型矩阵测试列出目标用户 TOP 10 机型每台实测 TTFT、解码速度、内存峰值、发热降频曲线据此决定哪些机型走 NPU 加速、哪些机型降级 CPU、哪些机型直接提示用云端。这其实是一张能力分级表和 B26 的成本工程、B34 的路由思想一脉相承——不是所有设备都该跑同一个模型按能力分级是端侧落地的常识。另外iOS 和 Android 的 NPU 生态完全割裂CoreML vs NNAPI/Mali一套引擎很难两端都最优往往要接受一端体验略差的现实或者分平台投入。关于趋势也补几句面试常问端侧未来怎么走。其一是端侧小模型能力快速逼近1B~3B 级别模型经过高质量数据和蒸馏已能 cover 大量日常任务端侧可行性越来越高。其二是NPU 生态标准化各芯片厂商在推统一推理接口跨机型适配成本有望下降。其三是端云协同成为默认架构纯端或纯云都非最优路由 协同是主流。其四是端侧 Agent把本文的端侧模型 轻量编排跑在手机上做离线可用的个人助理是接下来的兵家必争之地。把这些趋势和前面的工程现实结合着讲会让你的端侧认知显得既落地又有前瞻性。9.4 哪些服务端技巧在端侧不成立最后收个口端侧大模型不是把云端模型砍小搬过来这么简单它是一套独立的方法论——以带宽而非算力为第一约束、以量化而非堆卡为第一手段、以机型分级而非统一部署为第一策略。补充一个常被问的工程细节端侧要不要做投机解码A25/A30理论上投机解码能加速自回归但端侧 NPU 对草稿模型 验证这种双模型来回调度支持很差且草稿模型本身也要占内存收益常常被 overhead 吃光。所以端侧主流加速手段仍是量化 算子融合 KV Cache 量化投机解码在端侧尚未成主流。这也说明一个道理服务端的加速技巧不能无脑平移到端侧每个技巧都要重新在端侧约束下评估收益。能指出哪些服务端优化在端侧不成立、为什么比罗列一堆优化名词更显深度——它体现的是按平台重新推导的工程思维而非背优化清单。9.5 端侧 MoE 与首次加载体验补两个常被低估的实战点。第一是端侧 MoE。端侧 MoE如某些 1B-active 的小 MoE是个有意思的方向——总参数大但每 token 只激活一小部分推理算力接近小模型、能力接近大模型。但它对 NPU 的算子支持和内存布局要求更高工程成熟度还不如稠密小模型。所以当下端侧主力仍是稠密小模型 激进量化MoE 端侧是值得关注但尚早的趋势。面试能讲清为什么端侧 MoE 还没成主流比泛泛说MoE 好更显老练。第二是首次加载体验。很多 demo 在电脑上跑得飞快因为权重早进内存真机上第一次冷启动要 mmap 可能的图编译TTFT 可能 5~10 秒用户直接以为卡死。对策是预加载常驻、或先推一条正在加载的过渡反馈、或在 App 启动时后台预热。这看似小事却是端侧产品口碑的分水岭——用户不在乎你模型多先进只在乎点下去多久出字。把首响体验当一等指标是端侧团队和玩具项目的区别。9.6 端侧部署的完整 timeline 与格式治理给一个真实的端侧落地排期让抽象方法论落到节奏上。第 1~2 天锁定目标设备清单TOP 机型 最低内存规格和验收指标TTFT、tok/s、精度掉点上限、温升曲线。第 3~5 天选基座大小 量化档位在本地做精度验收确定 Q4 还是 Q5。第 6~8 天接入推理引擎llama.cpp / MLC打通 mmap 加载、KV Cache 量化、流式输出。第 9~12 天做端云协同路由简单走端、复杂走云接业务。第 13~15 天机型矩阵实测分级策略上线灰度 5% 看崩溃率与满意度。这个 timeline 的关键不是天数而是先定规格再选方案的顺序——反过来先训大模型再想办法塞一定反复返工。最后一句实务经验模型格式与生态碎片化的 CI 化治理。GGUFllama.cpp、SafetensorsHuggingFace、GGML 旧格式、各厂商私有格式彼此不通用一篇模型常有多个格式的社区转换版质量参差。选型时要确认目标引擎官方支持该格式、且该格式版本与引擎版本匹配否则轻则精度异常重则加载崩溃。建议把格式转换 校验固化进 CI 流水线每次模型更新自动转目标格式并跑精度验收而不是人工临时敲命令。这和服务端模型上线要走 CI是一个道理端侧只是多了格式这一环。把端侧模型当成需要严格版本管理与验收的制品是工程成熟度的体现。9.7 端侧基座选型矩阵立项时按能力需求 vs 设备余量选基座给一张速查表基座 参数量 量化后体积 适用场景 设备门槛 1B 约1B ~0.6GB Q4 闲聊/分类/简单抽取 低端机也可 3B 约3B ~1.8GB Q4 摘要/改写/轻量问答 中端机流畅 7B 约7B ~3.5GB Q4 复杂推理/代码生成 旗舰机/端侧独显经验法则先按最低目标设备选能跑的最大基座再用量化压到体积预算内不要反过来拿 7B 去适配 4GB 内存的低端机那样怎么做都难受。这也解释了为什么端侧 1B~3B 蒸馏模型呼应 A27 蒸馏近来吃香——它们在低端设备上就能 cover 大量日常任务是端侧可行性的真正推手。选型时若拿不准先用最小可用基座跑通链路再用更大基座做 A/B比一上来堆 7B 再想办法压缩更稳。十补、端侧部署的验收速查清单把前文要点压成一张可勾选清单①体积——量化后权重KV Cache 峰值压进目标设备内存mmap 兜底②延迟——TTFT1.5s、解码15 tok/s、长对话不崩③精度——业务测试集上 4bit 掉点2%超标层升回 8/16bit④功耗——连续 5 分钟温升与降频曲线可接受⑤协同——简单走端、复杂走云路由规则明确。五条全过才上线任何一条不达标都先回去调压缩档位或换更小基座而不是硬上。能背出这张清单面试基本直接判定你做过真端侧而非只在笔记本上 ollama run。十、面试速答 高频追问清单面试速答背下来- 端侧三瓶颈内存带宽主、可用内存、持续算力受发热限。量化砍权重体积是最直接手段。- 端侧几乎必量化7B INT4≈3.5GB 可塞手机敏感层留高精度小模型压到 INT2 易崩。- 引擎按平台分llama.cpp跨平台/量化生态、MLC LLM/ExecuTorch真 NPU、Ollama桌面易用。- mmap 按需分页避免一次性 OOMKV Cache 量化对话裁剪省内存。- NPU 峰值≠持续算力且算子/精度覆盖有限量化是必选项不是可选项。- 端云协同小模型做隐私兜底过滤云端做重活路由是关键。- 量化必须在目标引擎做格式与引擎强绑定跨引擎精度不可继承。高频追问1. 为什么端侧不学服务端用 vLLM答缺统一 NPU 抽象、内存更紧、要离线引擎按平台分裂。2. mmap 真能省内存吗答只映射不占满物理内存访问才换入OS 回收不用的页。3. 4bit 掉点怎么救答敏感层升精度、关键任务走端云协同、必要时 QAT 微调。4. 端侧 MoE 能用吗答方向好但 NPU/内存布局支持不成熟主力仍是稠密小模型量化。5. 怎么定量化档位答先锁设备规格与延迟/精度目标反推基座大小与比特档而非先训后塞。6. 为什么量化必须在目标引擎做答各引擎数值实现/校准不同跨引擎精度不可继承。7. 投机解码在端侧为什么难落地答双模型调度 NPU 支持差、占内存收益常被 overhead 吃光。 
长河君 · 2026/8/16 8:32:14 · 阅读 1.2k 27届大模型面试准备（三十四）：端侧大模型部署与压缩工程——把 7B 塞进手机与显卡的实战
27届大模型面试准备三十四端侧大模型部署与压缩工程——把 7B 塞进手机与显卡的实战本篇是 A 系列第 34 篇。前面 A19 讲过量化原理、A30 讲过服务端推理优化、A27 讲过蒸馏。但把模型跑在手机、PC、边缘盒子、车载芯片是另一套完全不同的工程显存不是问题、内存带宽才是瓶颈NPU 是主角、CUDA 不是功耗和发热是硬约束。本文聚焦端侧on-device大模型部署把压缩、推理引擎、内存管理串成一条可落地的链路。A33 讲的是怎么取分布里的 token本文讲的是在哪取、取得起取不起——两者共同构成大模型落地的最后一公里。一、为什么端侧是大模型落地的必答题云端推理有三大原罪隐私数据出端、延迟网络往返 排队、成本每 token 都烧钱。端侧推理恰好对症云端推理 端侧推理 延迟组成: 网络RTT排队前向 仅前向(本地) 数据: 上传到服务器 不出本机 成本: 按 token / 调用计费 一次性部署, 边际成本≈0 离线: 依赖网络 飞行模式也能用 功耗: 服务器吃电 受设备电池/发热限制所以端侧不是性能差的将就而是隐私敏感、实时、离线、低成本场景的唯一解。手机语音助手、车载对话、本地代码补全、隐私文档分析都指向端侧。面试被问为什么不直接调 API要能讲清这四条账。反过来端侧也不是万能复杂长上下文、需要最新知识的任务还是得靠云端。所以端还是云本质是路由问题本文第七节会讲。二、端侧的三座大山带宽、内存、算力服务端优化常盯着显存够不够端侧第一瓶颈其实是内存带宽memory bandwidth。端侧推理时间 ≈ 计算时间 搬运时间 小算子: 受算力限制 大矩阵(权重读取): 受 内存带宽 限制 - 端侧主战场 例: 7B 模型 FP16 权重 ~14GB, 哪怕 100GB/s 带宽, 仅读一遍权重就要 0.14s 要实时(30 tok/s)就得反复读, 带宽直接决定吞吐三座大山1.带宽墙权重要从存储DRAM/磁盘搬到计算单元带宽决定上限。量化直接砍权重体积是最有效的手段。2.内存墙手机的可用内存可能只有 4~8GB模型权重 KV Cache 运行时必须都装下常要靠mmap 按需分页而非一次性加载。3.算力墙NPU/CPU 峰值算力有限且持续算力受发热限制手机跑几秒就降频。┌──────────────┬─────────────┬────────────────────────────┐ │ 瓶颈 │ 端侧表现 │ 对应解法 │ ├──────────────┼─────────────┼────────────────────────────┤ │ 内存带宽 │ 致命 │ 量化(4bit)、权重复用 │ │ 可用内存 │ 紧张 │ mmap 分页、KV Cache 压缩 │ │ 持续算力 │ 受发热限制 │ 低比特、算子融合、NPU │ │ 功耗/电池 │ 硬性约束 │ 早退、动态算力分配 │ └──────────────┴─────────────┴────────────────────────────┘三、压缩端侧的第一刀永远是量化端侧模型几乎必做量化。回顾量化家族A19 详细讲过这里讲部署视角INT4 / INT2端侧主流。7B 模型 INT4 后权重约 3.5GB能塞进手机。AWQ、GPTQ 是常用 PTQ 方案。FP8服务端友好端侧 NPU 逐步支持精度损失小。混合精度敏感层如 attention 的某些投影留高精度其余压低——比全层统一 4bit更稳。训练后量化PTQvs 量化感知训练QAT端侧追求极致时QAT 用少量数据微调恢复精度但成本高多数场景 PTQ 校准集足够。# 用 llama.cpp / GGUF 做端侧量化概念示意# 1) 原始模型转 GGUFpythonconvert_hf_to_gguf.pyQwen2.5-7B/--outfileqwen.gguf# 2) 量化到不同比特./llama-quantizeqwen.ggufqwen-Q4_K_M.ggufQ4_K_M./llama-quantizeqwen.ggufqwen-Q2_K.ggufQ2_K# 更小更失真# Q4_K_M: 质量与体积平衡, 端侧 7B 首选# Q5_K_M: 质量更好, 体积更大一个容易被忽视的点端侧的精度损失比服务端更敏感因为端侧常跑小模型1B~3B本来就脆弱压到 INT2 可能直接崩。所以端侧量化要更谨慎地做逐层敏感度分析把对 perplexity 影响大的层保留高精度。这一点和 A19 讲的服务端量化可接受更大压缩比形成对照——端侧容错更低。四、推理引擎谁在端侧跑模型端侧没有 vLLM 这种大一统而是按平台分裂┌────────────────┬──────────────────────┬──────────────────────┐ │ 引擎/框架 │ 平台 │ 特点 │ ├────────────────┼──────────────────────┼──────────────────────┤ │ llama.cpp │ 跨平台(C/CPU/GPU) │ GGUF、量化生态最成熟 │ │ MLC LLM │ 移动/iOS/Android/Web │ TVM 编译, NPU 友好 │ │ Ollama │ 桌面(Mac/Win/Linux) │ llama.cpp 封装, 易用 │ │ ExecuTorch │ 端侧(PyTorch 官方) │ 移动端推理, 边缘部署 │ │ TensorRT-LLM │ NVIDIA GPU/数据中心 │ 极致优化, 非严格端侧 │ │ CoreML/MNN │ Apple/移动 NPU │ 厂商加速, 闭源生态 │ │ onnxruntime │ 跨平台 │ ONNX 中间表示 │ └────────────────┴──────────────────────┴──────────────────────┘选型逻辑要最大兼容性与量化生态选 llama.cpp要真·手机 NPU 加速选 MLC LLM / ExecuTorch要桌面开发者体验选 Ollama。面试能列出这张表并说清为什么端侧没有统一引擎已经超出多数候选人。根本原因是端侧硬件NPU 架构、驱动、内存模型极度碎片化一个引擎很难在所有芯片上都做到最优。五、内存管理mmap 与 KV Cache 的端侧腾挪端侧内存紧张两个关键技术5.1 mmap 按需加载权重大模型权重文件可能比可用内存大。用内存映射mmap把文件映射到虚拟地址只在实际访问的页才真正读入物理内存OS 按 LRU 回收。这样模型能开、但不一次性占满内存。// llama.cpp 用 mmap 加载权重概念void*ptrmmap(NULL,file_size,PROT_READ,MAP_PRIVATE,fd,0);// 访问某层时 OS 才把对应页换入; 不需要的页被回收// 手机上可配合 MADV_DONTNEED 主动释放不用的层5.2 KV Cache 压缩端侧上下文长了 KV Cache 占内存爆炸。手段A30 提过端侧更重要-量化 KV Cache8bit/4bit省一半以上。-滑动窗口 / 对话裁剪只保留最近 N 轮。-前缀缓存复用系统 prompt 的 KV 只算一次。端侧 7B, 上下文 4k, FP16 KV ~ 每层都要存 k,v - 量化到 8bit 直接省 50% 内存 - 配合只保留最近对话, 长聊天也不崩六、NPU 与算子端侧的算力真相手机的AI 算力宣传很猛几十 TOPS但工程上要清醒-峰值算力 ≠ 持续算力NPU 跑几秒就因发热降频实际可持续算力可能只有峰值的 1/3。-算子覆盖不全NPU 对常见算子快但对新型算子如某些 MoE 路由、自定义激活可能不支持被迫回退 CPU反而更慢。-精度支持有限很多 NPU 只高效支持 INT8/INT4FP16 反而慢所以端侧量化不是可选项而是必选项。# MLC LLM 编译到手机 NPU概念# 1) 定义模型 量化modelmlc.Model(Llama-3-8B,quantizationq4f16_1)# 2) 用 TVM 编译为目标硬件 (Android NPU / Apple Neural Engine)model.build(targetandroid,gpumali)# 3) 打包 apk / 动态库, 端上加载七、端云协同不是二选一而是分工最成熟的落地往往是端云协同而非纯端侧用户请求 │ ├─ 简单/隐私任务 ── 端侧小模型直接答 (低延迟、零成本、离线) │ └─ 复杂/长上下文 ── 路由到云端大模型 (高质量) 路由判断: 意图复杂度 / 是否需要检索 / 隐私等级这其实是 B26Agent 成本工程和 A30推理优化在端侧的投影用路由把贵的大模型用在刀刃上。端侧小模型做第一道过滤 隐私兜底云端做重活。面试能画出这个路由架构会显得你有真实落地经验而非只会调 API。八、端侧特有的质量坑量化掉点4bit 下某些任务尤其是需要精确计数、长链推理明显退化。对策敏感层升精度、关键任务走端云协同。首 token 延迟TTFT端侧加载权重 编译图可能要几秒用户以为卡死。对策预加载、预热、进度提示。发热降频连续对话后越聊越慢。对策限流、动态降 batch、必要时提示切云端。系统碎片化Android 机型 NPU 各异一套引擎难全适配。对策CPU 兜底路径 分机型灰度。九、生产落地深潜部署 checklist 与工程真相把端侧模型真正推上线我建议按这张清单逐条过关。第一关是体积与内存目标设备可用内存多少模型量化后权重 KV Cache 峰值是否压得进用 mmap 能否避免一次性 OOM第二关是延迟预算TTFT目标1.5s、解码速度目标15 tok/s 才不憋屈、长对话下是否仍能维持第三关是精度验收在目标任务的本地测试集上4bit 相比 FP16 掉点是否2%掉点超标的层要升回 8bit 或 16bit。第四关是功耗与发热连续 5 分钟对话设备温度与降频曲线如何是否需要在系统层限流。这张清单的精髓是先定设备规格再反向选压缩档位而不是先训好模型再想办法塞。很多团队拿着一个 14GB 的 FP16 模型去适配 6GB 内存的手机怎么做都难受——正确做法是立项时就锁定目标设备 目标延迟 目标精度据此选基座大小1B/3B/7B和量化档Q4/Q5/Q8。这和普通服务端模型越大越好、显存不够就加卡的思维方式正好相反是端侧工程最反直觉、也最容易被 junior 忽略的一点。9.1 量化格式与引擎强绑定再补一个真实踩坑端侧量化格式和引擎强绑定。llama.cpp 的 GGUF Q4_K_M、MLC 的 q4f16_1、CoreML 的 4bit三者数值实现不同、跨引擎不能混用。曾经有团队在服务器用 llama.cpp 测了 Q4 精度达标上线却用 MLC 重新量化结果同一模型精度差了 5 个点——因为校准集和量化粒度不同。所以端侧压缩必须在哪个引擎跑就在哪个引擎量化把量化步骤固化进 CI而不是本地手动敲命令。能讲出这个细节面试基本直接判定你做过真端侧而不是纸上谈兵。9.2 端侧与服务端优化的本质差异补一节思维转换——很多做惯服务端推理优化的工程师上手端侧会本能地用同一套打法结果处处碰壁。核心差异有四点。其一瓶颈不同服务端卡显存和算力端侧卡内存带宽所以服务端靠堆卡、端侧靠量化压缩带宽需求。其二可观测性不同服务端有完善的 GPU 监控、profiling端侧 NPU 常常是黑盒连这一层跑了多久都拿不到细粒度数据只能靠端到端延迟反推。其三失败模式不同服务端失败多是 OOM 或超时端侧失败多是发热降频导致的前几轮快、后几轮慢、以及机型碎片化导致的这台能跑那台崩。其四迭代速度不同服务端改个配置秒级生效端侧改量化要重新编译、重新打包、重新上架迭代以天计。把这四点刻进脑子才能避免用服务端思维做端侧的错位。9.3 实测解读、跨平台适配与成本账补一节看懂数字的能力这是工程师和调参侠的分界。端侧部署报告里常写Q4 下 perplexity 只涨 0.3但你要会追问这个 0.3 是在什么测试集上测的通用语言模型基准的 0.3 可能毫无意义业务任务的掉点才是真金。我习惯在目标业务的小测试集比如真实的客服问答、真实的代码补全片段上做精度验收而不是信通用 benchmark。曾经有个项目在 WikiText 上 Q4 几乎无损但实际代码补全任务掉点 12%——因为代码对精确 token 更敏感通用基准掩盖了。所以端侧验收的铁律是在业务数据上测不在公开基准上自我安慰。跨平台适配是另一块硬骨头。同一份 GGUF 在 llama.cpp 上跑得欢到了某 Android 机型用 MLC 重编译速度可能差三倍原因是 NPU 驱动版本和算子支持不同。我的经验是建立机型矩阵测试列出目标用户 TOP 10 机型每台实测 TTFT、解码速度、内存峰值、发热降频曲线据此决定哪些机型走 NPU 加速、哪些机型降级 CPU、哪些机型直接提示用云端。这其实是一张能力分级表和 B26 的成本工程、B34 的路由思想一脉相承——不是所有设备都该跑同一个模型按能力分级是端侧落地的常识。另外iOS 和 Android 的 NPU 生态完全割裂CoreML vs NNAPI/Mali一套引擎很难两端都最优往往要接受一端体验略差的现实或者分平台投入。关于趋势也补几句面试常问端侧未来怎么走。其一是端侧小模型能力快速逼近1B~3B 级别模型经过高质量数据和蒸馏已能 cover 大量日常任务端侧可行性越来越高。其二是NPU 生态标准化各芯片厂商在推统一推理接口跨机型适配成本有望下降。其三是端云协同成为默认架构纯端或纯云都非最优路由 协同是主流。其四是端侧 Agent把本文的端侧模型 轻量编排跑在手机上做离线可用的个人助理是接下来的兵家必争之地。把这些趋势和前面的工程现实结合着讲会让你的端侧认知显得既落地又有前瞻性。9.4 哪些服务端技巧在端侧不成立最后收个口端侧大模型不是把云端模型砍小搬过来这么简单它是一套独立的方法论——以带宽而非算力为第一约束、以量化而非堆卡为第一手段、以机型分级而非统一部署为第一策略。补充一个常被问的工程细节端侧要不要做投机解码A25/A30理论上投机解码能加速自回归但端侧 NPU 对草稿模型 验证这种双模型来回调度支持很差且草稿模型本身也要占内存收益常常被 overhead 吃光。所以端侧主流加速手段仍是量化 算子融合 KV Cache 量化投机解码在端侧尚未成主流。这也说明一个道理服务端的加速技巧不能无脑平移到端侧每个技巧都要重新在端侧约束下评估收益。能指出哪些服务端优化在端侧不成立、为什么比罗列一堆优化名词更显深度——它体现的是按平台重新推导的工程思维而非背优化清单。9.5 端侧 MoE 与首次加载体验补两个常被低估的实战点。第一是端侧 MoE。端侧 MoE如某些 1B-active 的小 MoE是个有意思的方向——总参数大但每 token 只激活一小部分推理算力接近小模型、能力接近大模型。但它对 NPU 的算子支持和内存布局要求更高工程成熟度还不如稠密小模型。所以当下端侧主力仍是稠密小模型 激进量化MoE 端侧是值得关注但尚早的趋势。面试能讲清为什么端侧 MoE 还没成主流比泛泛说MoE 好更显老练。第二是首次加载体验。很多 demo 在电脑上跑得飞快因为权重早进内存真机上第一次冷启动要 mmap 可能的图编译TTFT 可能 5~10 秒用户直接以为卡死。对策是预加载常驻、或先推一条正在加载的过渡反馈、或在 App 启动时后台预热。这看似小事却是端侧产品口碑的分水岭——用户不在乎你模型多先进只在乎点下去多久出字。把首响体验当一等指标是端侧团队和玩具项目的区别。9.6 端侧部署的完整 timeline 与格式治理给一个真实的端侧落地排期让抽象方法论落到节奏上。第 1~2 天锁定目标设备清单TOP 机型 最低内存规格和验收指标TTFT、tok/s、精度掉点上限、温升曲线。第 3~5 天选基座大小 量化档位在本地做精度验收确定 Q4 还是 Q5。第 6~8 天接入推理引擎llama.cpp / MLC打通 mmap 加载、KV Cache 量化、流式输出。第 9~12 天做端云协同路由简单走端、复杂走云接业务。第 13~15 天机型矩阵实测分级策略上线灰度 5% 看崩溃率与满意度。这个 timeline 的关键不是天数而是先定规格再选方案的顺序——反过来先训大模型再想办法塞一定反复返工。最后一句实务经验模型格式与生态碎片化的 CI 化治理。GGUFllama.cpp、SafetensorsHuggingFace、GGML 旧格式、各厂商私有格式彼此不通用一篇模型常有多个格式的社区转换版质量参差。选型时要确认目标引擎官方支持该格式、且该格式版本与引擎版本匹配否则轻则精度异常重则加载崩溃。建议把格式转换 校验固化进 CI 流水线每次模型更新自动转目标格式并跑精度验收而不是人工临时敲命令。这和服务端模型上线要走 CI是一个道理端侧只是多了格式这一环。把端侧模型当成需要严格版本管理与验收的制品是工程成熟度的体现。9.7 端侧基座选型矩阵立项时按能力需求 vs 设备余量选基座给一张速查表基座 参数量 量化后体积 适用场景 设备门槛 1B 约1B ~0.6GB Q4 闲聊/分类/简单抽取 低端机也可 3B 约3B ~1.8GB Q4 摘要/改写/轻量问答 中端机流畅 7B 约7B ~3.5GB Q4 复杂推理/代码生成 旗舰机/端侧独显经验法则先按最低目标设备选能跑的最大基座再用量化压到体积预算内不要反过来拿 7B 去适配 4GB 内存的低端机那样怎么做都难受。这也解释了为什么端侧 1B~3B 蒸馏模型呼应 A27 蒸馏近来吃香——它们在低端设备上就能 cover 大量日常任务是端侧可行性的真正推手。选型时若拿不准先用最小可用基座跑通链路再用更大基座做 A/B比一上来堆 7B 再想办法压缩更稳。十补、端侧部署的验收速查清单把前文要点压成一张可勾选清单①体积——量化后权重KV Cache 峰值压进目标设备内存mmap 兜底②延迟——TTFT1.5s、解码15 tok/s、长对话不崩③精度——业务测试集上 4bit 掉点2%超标层升回 8/16bit④功耗——连续 5 分钟温升与降频曲线可接受⑤协同——简单走端、复杂走云路由规则明确。五条全过才上线任何一条不达标都先回去调压缩档位或换更小基座而不是硬上。能背出这张清单面试基本直接判定你做过真端侧而非只在笔记本上 ollama run。十、面试速答 高频追问清单面试速答背下来- 端侧三瓶颈内存带宽主、可用内存、持续算力受发热限。量化砍权重体积是最直接手段。- 端侧几乎必量化7B INT4≈3.5GB 可塞手机敏感层留高精度小模型压到 INT2 易崩。- 引擎按平台分llama.cpp跨平台/量化生态、MLC LLM/ExecuTorch真 NPU、Ollama桌面易用。- mmap 按需分页避免一次性 OOMKV Cache 量化对话裁剪省内存。- NPU 峰值≠持续算力且算子/精度覆盖有限量化是必选项不是可选项。- 端云协同小模型做隐私兜底过滤云端做重活路由是关键。- 量化必须在目标引擎做格式与引擎强绑定跨引擎精度不可继承。高频追问1. 为什么端侧不学服务端用 vLLM答缺统一 NPU 抽象、内存更紧、要离线引擎按平台分裂。2. mmap 真能省内存吗答只映射不占满物理内存访问才换入OS 回收不用的页。3. 4bit 掉点怎么救答敏感层升精度、关键任务走端云协同、必要时 QAT 微调。4. 端侧 MoE 能用吗答方向好但 NPU/内存布局支持不成熟主力仍是稠密小模型量化。5. 怎么定量化档位答先锁设备规格与延迟/精度目标反推基座大小与比特档而非先训后塞。6. 为什么量化必须在目标引擎做答各引擎数值实现/校准不同跨引擎精度不可继承。7. 投机解码在端侧为什么难落地答双模型调度 NPU 支持差、占内存收益常被 overhead 吃光。