企业官网建设流程全解析

最近一个朋友把一份三十多页的 PDF 丢给新手机做摘要，按下按钮之后整整等了接近二十秒，屏幕才蹦出第一个字。这二十秒里手机在干什么？绝大部分时间都在做 prefill，也就是把整份文档一次性“读”进模型，先生成 KV Cache。后来我拿到新一代骁龙8（按代际叫法就称第六代骁龙8）的宣传材料，里面专门用“prefill +80%”当核心卖点，再对照我们团队在端侧 AI 项目里的实测经验，我发现这事值得拆开聊一聊。

这篇文章不跑分、不念参数，只讲三件事：prefill 为什么会成为旗舰芯片的必争之地；80% 的提升到底来自哪些架构与软件变化；以及端侧 AI 圈子里最常被忽略的问题——厂商口中的“算力”和真实可用的性能之间，有一条可能烧掉你整个项目预算的鸿沟。尤其对做 Agent 架构、端侧大模型部署或移动 AI 应用的同学来说，这比单纯追新旗舰更有参考价值。

1. 为什么手机厂商开始把 prefill 当成发布会核心卖点

1.1 手机 AI 任务的重心，从“生成一句话”变成“读完整份材料”

前两年大家聊端侧 AI，演示场景基本是“帮我写一段朋友圈文案”或者“讲个冷笑话”，这种输入通常只有十几个 token，prefill 一闪就过，用户感知不到。但现在端侧模型开始处理会议纪要、PDF 文档、聊天记录检索、录音转写后的问答，prompt 长度从几十 token 膨胀到几千甚至上万 token。

以一份 30 页 PDF 为例，OCR 加版式还原之后截断到模型上下文窗口，按 4096 token 输入算是很常规的。这时候模型要先扫描这 4096 个 token，计算每一层的注意力，把中间结果存成 KV Cache，再开始逐字生成摘要。如果你的芯片 prefill 能力不行，用户看到的体验就是“按下按钮后手机愣了几秒甚至十几秒，然后才开始打字”。

很多团队把注意力全部放在 decode（生成 token）的速度上，忽略了 prefill 才是长输入场景里真正的体验瓶颈。厂商显然也注意到这一点，所以新一代旗舰芯片不再只吹“每秒生成多少 token”，而是开始直接标 prefill 吞吐量提升多少。

1.2 prefill 和 decode 是两种完全不同的体力活

这里要先拆清楚两个阶段的物理画像，不能混为一谈。

prefill 阶段：模型拿到整段 prompt，所有 token 并行参与计算。这个过程本质上是超大规模的矩阵乘加运算，计算密度极高，而且 token 之间没有依赖关系，芯片可以把大量计算单元同时拉满。瓶颈主要看“单位时间内能完成多少乘加运算”，也就是靠算力和数据供给速度来堆。

decode 阶段：模型每次只生成一个 token，然后用这个新 token 更新 KV Cache，再进行下一次生成。这是严格的串行过程，强依赖前一步的输出，芯片没法把 8 个 token 放一起并行计算。每个 token 都必须把模型权重和 KV Cache 从内存里重新搬运一遍，瓶颈变成了“每秒能搬多少数据”，也就是内存带宽和低延迟访问。

用一个生活化的类比：prefill 像把一批原料同时倒进产线，整条产线满负荷跑；decode 像流水线出口每人只能拧一颗螺丝，加再多人也快不了多少。新芯片如果为 prefill 做了大幅优化，decode 未必能吃到大红利，反过来也一样。你在发布会看到“prefill +80%”，基本可以判断新架构的“产线吞吐”和“物料存放”都动了大手术，而不只是单纯堆算力单元。

1.3 prefill 的时间账：光算 KV Cache 就够吓人

prefill 阶段除了计算量大，还会快速产生大量中间数据。KV Cache 大小的粗略公式是：

KV Cache 字节数 = 2 × 序列长度 × 层数 × KV 头数 × head_dim × 数据精度字节数

拿一个 3B 级别的模型举例，32 层，KV heads 为 8，head_dim 为 128，FP16 精度下跑 4096 token：

2 × 4096 × 32 × 8 × 128 × 2 字节 = 512 MB

你没看错，单单 KV Cache 就是 512MB，注意力分数和激活值还没算进去。这还是在 12GB 或 16GB 内存的旗舰机上，如果是一台 8GB 内存手机，跑长上下文 prefill 时内存压力极大，系统稍微一压缩后台，推理进程就可能被干掉。所以 prefill 快不快，不只是影响首字延迟，还直接决定了这台设备“能不能跑长文档”以及“能跑多长”。

2. 第六代骁龙8的 80% 是怎么挤出来的：硬件加速与软件调度的合力

2.1 硬件侧：张量核心、SRAM 和内部互连的三板斧

从公开信息和工程推演来看，第六代骁龙8 这代 prefill 提升的核心不是单纯把 NPU 频率往上拉，而是三个硬件层面同步做调整：

第一，张量核心的可并行执行宽度变大了。prefill 的特长是“批次大、并行度高”，如果 NPU 里乘加阵列能够在一次指令里吞下更大的矩阵块，prefill 吞吐量会直接受益。这相当于把产线从“四车道”拓宽成“八车道”。

第二，片上 SRAM 容量和局部数据复用能力显著增强。LLM 的权重虽然有几个GB，但某个时间片内只需要一小块权重量和一个激活块；如果 Z 这些数据能留在片内 SRAM 里反复用，就不用频繁跑去 DRAM 读，省下的时间非常可观。prefill 阶段尤其适合做这种“分块驻留”优化，因为序列方向上数据是连续且可预取的，调度器可以很舒服地把矩阵切成 tile，塞进 SRAM 循环利用。

第三，内部互连和系统级缓存的一致性调度变强了。第六代骁龙8 在 CPU、GPU、NPU 之间共享内存带宽的调度上做了更细粒度的分配。prefill 是一整块连续内存读写的大活，总线调度如果做得好，NPU 等待数据的时间会明显下降。很多芯片跑分拉胯，不是计算单元不够，而是“饭端不上桌”，内部总线才是真瓶颈。

当然这些不是官方 spec 逐条确认的，更接近从实测结果反推。我自己的判断是：这代架构把“数据搬运”地位抬高到了跟“计算”同一层级，这是 prefill 能涨 80% 的核心原因。

2.2 软件侧：计算图融合、KV Cache 分页、分级调度

硬件只是场地，真正让 80% 落地的还有软件栈。同样的模型在新旧芯片上的算子实现方式完全不同。

第一是算子融合。现在推理引擎不会再傻傻地按 PyTorch 原图一层层跑。prefill 里的 QKV 投影、attention score 计算、softmax、输出投影，会被编译器融成几个大的 kernel，减少中间张量的写入和读出。Softmax 可以用 online 方式跟矩阵乘融合，RoPE 位置编码也提前预计算好，不再每个算子往返内存。

第二是 KV Cache 的分页管理。这代运行时会像页式内存一样把 KV Cache 切成固定大小的块，按需分配。注意，这不是单纯省内存，而是让 prefill 阶段能连续写一大块内存，减少碎片和随机读写，数据搬移效率高不少。

第三是异构分级调度。芯片会根据 prompt 长度做动态决策：短 prompt 用低功耗核心慢慢跑，长 prompt 直接切到张量核心全速执行。这样既保住了聊天场景的省电，又能在阅读场景里把峰值性能拉满。纯硬件改动做不到这么灵活，这层软件调度对 80% 的贡献至少占三到四成。

2.3 用三个数字看懂上一代到这代的变化

下面这张表是我按常见的 3B/6B INT4 模型做的一个推演示意，不代表任何官方实验室数据，但能看出架构倾向：

重点是比例差异。decode 的提升只有十几个百分点，而 prefill 直接涨了近一倍。这说明新架构把运算并行度、数据复用和内存调度这三块应用在了 prefill 最容易受益的地方。如果你是聊天型应用，这个提升感知不强，因为短 prompt 的 prefill 本来就不慢；但如果你是文档摘要、会议纪要、长上下文问答类应用，80% 的 prefill 提升是“能不能用”和“好不好用”的分水岭。

3. 端侧 AI 的“算力骗局”：从 TOPS 峰值到持续性能的化简游戏

3.1 TOPS 是“算力房子的图纸”，不是你可以住的面积

现在很多芯片发布会喜欢强调“XXX TOPS”，好像数字越大端侧 AI 就越强。但TOPS 只是一个理论峰值：它假设所有计算单元在同一时刻满负荷运行，并且永远不用等数据。

实际情况是手机 SoC 有严格的功耗墙和散热约束。拿着手机连续跑 10 分钟 AI 任务，温度一上来，调度器立刻降频，NPU、GPU 的频率都会往下走，最终维持在一个“能压住温度”的平衡点。发布会上的峰值 TOPS 只代表“理论上撑几秒钟”的状态，代表不了持续性能。

更关键的是内存带宽。芯片算力再高，如果 DRAM 带宽喂不饱，计算单元就只能空转等待。手机 LPDDR5X 的带宽大概在 136GB/s 到 165GB/s 这个量级，而一个宣称 INT8 100 TOPS 的 NPU，在没有任何数据复用的极端情况下，每秒需要搬的数据量远超带宽上限。所以实际项目里，多数 NPU 对 LLM 的利用率可能只有三四成，这个数字已经算不错了。

3.2 发布会最喜欢藏起来的：INT4、稀疏、短提示

“算力数字的游戏”主要集中在三个地方：

精度口径。同规格的 NPU，跑 INT4 比跑 INT8 快一倍，跑稀疏模型又比跑稠密模型快一倍。厂商宣传时往往直接取最高组合：INT4 + 稀疏 + 峰值频率。现实里，端侧 LLM 要做 INT4 量化部署，但 Transformer 的注意力计算并不天然适合稀疏结构，结构化剪枝之后的效果又很难保证质量。你在宣传里看到 80 TOPS 的高分，实际跑一个稠密 INT8 模型时，可能只有 20 到 30 TOPS 的效果。

预热与短提示。发布会 demo 通常是提前把模型加载进内存、做好权重布局，再用一个只有几十 token 的短 prompt 跑出“秒回”效果。真实用户场景是冷启动加载、长上下文 prefill、持续多轮对话，这些才是决定项目能不能上线的关键。

性能衰减。手机跑 AI 推理时间一长，热节流会把性能按百分比往下打。某些评测只跑 30 秒，刚好错过降频点；真实用户可能一开屏就连续用三五分钟，差异非常明显。

3.3 识别算力宣传水分的五个提问清单

在跟芯片厂商、方案商或内部选型沟通时，我习惯用下面这几问来过滤水分，建议你直接抄走：

问完这五个问题，90% 的“算力神话”都会现形。并不是说厂商在造假，而是不同口径的数字背后代表的能力完全不一样，选型时混着用是要出事故的。

4. 把这 80% 变现：端侧项目的评测方法、预填充时机与缓存策略

4.1 先建一套“真场景”验收基准，不要被演示 Demo 牵着走

无论项目里用的是新一代旗舰还是现有设备，都建议建一套自己的验收基准，别直接信厂商给的单点测速。

我自己在做端侧模型评测时，固定这样一套参数：

工具方面，高通平台可以用 QNN 配套的 benchmark 工具，MNN、TFLite Benchmark 也可以指定输入序列长度。关键是不要用厂商预设的测试文件，拿你自己业务里最长的真实 prompt 去压测，测出来的数字才敢写进项目评估报告。

4.2 把 prefill 安排在“用户看不到”的时间片里

芯片给了 80% 的提升，这是上限；能不能让用户感受到，还要靠工程上的“错峰”设计。

我在实际项目里最常用的思路叫“机会性 prefill”。手机在充电、息屏、空闲时，系统会把用户已经上传但还没打开的文档提前跑一遍 prefill，生成摘要并保存结果。等用户真正点开“总结”按钮时，模型已经处理完了，TTFT 直接变成接近零。这在功耗和发热上也没那么难接受，因为可以利用夜间或碎片时间，而不是在人正在用手机的时候抢占资源。

另一个思路是做端云协同的拆分：短 prompt 和隐私敏感数据留在端侧处理，长文档的 prefill 放到有更强算力的服务端完成，再把生成结果返回给端侧做展示。这样既不用在手机上硬扛几万 token 的 prefill，也保住了实时体验。前提是你的产品允许云端参与，如果严格要求全端侧，那就优先做上面说的离线预填充。

4.3 缓存复用：让同一个 system prompt 不再重复 prefill

很多端侧 Agent 应用喜欢把所有系统提示词、工具说明、历史记录拼在一起塞进模型，然后每次请求都从头 prefill 一遍。这是极大的浪费。

以“Agent 架构”和“多 Agent 协作”这个方向为例，多个 Agent 之间如果有共享的系统提示词和工具定义，完全可以做共享前缀缓存。只要前缀相同，KV Cache 就能复用，新请求只需要计算新增的那一小段。这跟大模型 API 服务里的 prefix caching 是一个道理，端侧同样能做。

再具体一点，如果你的端侧模型跑一个“邮件整理机器人”，系统提示词占了 1500 token，真实用户邮件只有 300 token，那每次请求有 80% 的 prefill 量是重复的。把系统提示词单独缓存，每次只算用户邮件部分，prefill 成本直接砍掉大半。这比换新芯片的收益更明显，而且不需要额外硬件投入。

KV Cache 的分页管理也值得注意。手机内存紧张时，系统可以把旧会话的 KV Cache 块压缩、换出，甚至按重要性丢弃一部分。运行时以块为单位维护缓存生命周期，比整段 buffer 的方式灵活得多。对长时间运行的多轮 Agent 场景来说，这几乎是必备手段。

5. 踩过几次坑之后的选型心得：先判断你的场景是“聊天型”还是“阅读型”

5.1 聊天型场景：decode 和内存带宽才是重点

如果你的核心功能是短对话、文案润色、简短问答，prompt 通常在几百 token 以内，prefill 再快，用户也很难体感到差别。真正影响体验的是连续生成时的 token 速度，以及多轮对话后内存是否够用。

这类场景选型时，我不太建议追最新旗舰。上一代芯片的 decode 能力已经够用，重点去看内存带宽、系统可用内存、以及推理框架是否支持流式输出。把预算花在模型蒸馏、量化、减少重复计算上，性价比更高。

5.2 阅读型场景：prefill 和 KV Cache 才是重点

如果产品重度依赖文档、PDF、会议记录、长篇邮件，那 prefill 吞吐量就是命门。第六代骁龙8 的 +80% 在这里才真正值回票价。

这种场景选型时，单独看 prefill tokens/s 还不够，还要看长上下文下 KV Cache 对内存的占用。很多手机标称支持几十亿参数模型，但跑到 8192 token 时内存直接爆掉。所以评估公式必须是：模型量化后的大小 + 最大上下文 KV Cache 大小 + 系统其他进程占用，必须低于设备可用内存，而且要留出 20% 以上的缓冲。

5.3 不要为“旗舰算力”多付钱，直到你能量化需求

在项目立项时，我常用一个最简单的用户等待预算来倒推需求：用户能接受的首 token 等待时间是 3 秒以内，还是 10 秒以内？

假设你的文档方案需要 prefill 3000 token，如果芯片只能做到 75 tokens/s，TTFT 就是 40 秒，用户肯定跑了；如果芯片能做到 135 tokens/s，TTFT 降到 22 秒，还是不够。这时候你要么继续优化模型和量化，要么改成离线预填充，要么做云端辅助。单靠换芯片解决不了所有问题。

三十页 PDF、二十秒等待、80% 的 prefill 提升，这三个东西连起来才是理解第六代骁龙8这代产品的真正线索。80% 确实是个明显的架构进步，但落到你自己的产品里，能不能把这个进步变成用户可感知的流畅体验，取决于你有没有前置的评测方法、错峰计算设计和 KV Cache 复用策略。硬件红利是厂商给的，工程红利是自己挣的，后者往往才是项目成败的关键。