企业官网建设流程全解析

前阵子接到一个需求：在单机 8 卡 H20 上部署 DeepSeek-V4.1，把 512K token 的长文档推理跑起来，在线服务要求首字延迟压到秒级。硬件到货当天我们做了第一次压测，结果很打击人——512K 上下文平均首字延迟 18 秒，最长的甚至跑到了 26 秒。这个数字意味着业务侧没法用：用户发来一份几百页的文档，等 18 秒才看到第一个字，体验上等于“挂了”。后来经过三周左右的优化，我们把同样的负载压到了 1.42 秒，整体加速 12.7 倍。这篇文想把整个优化过程、每一步的取舍逻辑、以及真正踩过的坑完整记录下来。内容围绕长上下文推理的瓶颈拆解、并行策略、KV cache 管理、注意力稀疏化和预填充调度展开，适合正在做长文本推理部署、或者打算在 H20 这类大显存低算力卡上跑大模型的同学参考。

先说结论：12.7 倍不是靠某一个“神操作”达成的，而是把 KV cache 显存占用、注意力计算复杂度、前缀复用率和 prefill 调度四件事分别压了一遍，最后相乘出来的。每件事单独看收益没有特别夸张，但组合起来就是量变到质变。

1. 先弄明白 512K 首字延迟到底卡在哪个环节

1.1 H20 的硬件性格：显存很大，算力其实一般

H20 这款卡在网上争议不小。它单卡有 96GB 的 HBM3 显存，内存带宽在 4TB/s 左右，但 FP16 稠密算力只有 150 TFLOPS 上下，对比同代高算力卡差了一个量级。说白了，它的定位是“大内存条”，不是“计算炮”。

这个性格决定了它适合什么样的推理负载：凡是需要把大量参数和中间状态装在显存里、但每次计算量相对不高的任务，它是好手；凡是需要把几十 TFLOPS 的矩阵乘法打满的任务，它反而容易吃亏。DeepSeek-V4.1 这类 MoE 模型叠加 512K 长上下文，恰好同时踩中了它的优点和缺点——模型权重加 KV cache 能装下，但 prefill 阶段要跑的计算量实在太大。

很多同学拿到 H20 第一反应是“96GB 显存什么模型都能上”，这没错，但真正部署后会发现瓶颈从“装不装得下”变成了“算得动算不动”。我们最开始犯的错误就是把 H20 当算力卡用，试图靠硬算把 512K prefill 算完。

1.2 首字延迟的三个构成部分

服务端的首字延迟（TTFT）通常由三段组成：

• 调度排队时间：请求进入推理引擎后，等待 GPU 资源的时间
• 预填充时间：把 prompt 里的 token 逐个过一遍模型，生成 KV cache
• 启动解码时间：前向一次、输出第一个 token 的时间

对于短 prompt，第三段是主导；但对于 512K 的 prompt，第二段几乎等于全部。512K token 意味着模型要“读”完大概 500 页左右的内容才开始回答，这个过程在 prefill 里就是一次超级长的前向传播。

一个容易忽略的细节是，prefill 不只是算力瓶颈，还有显存带宽瓶颈。每个 token 的中间激活值都要写进显存再读出来，512K 个 token 累积起来的激活值总量是惊人的。我们实测下来，在 H20 上做全量 512K prefill 时，GPU 计算单元利用率只有十几个百分点，其余时间都在等显存搬运。

1.3 用一道算术题说明为什么“硬算”行不通

假设 DeepSeek-V4.1 在单 token prefill 时的有效计算量约为 2×N_active，其中 N_active 是激活参数量。按 MoE 模型常见情况取个近似值——激活参数在 300B 左右——那么 512K token 的 prefill 计算量大约是：

2 × 300e9 × 512e3 ≈ 3.07e17 FLOPs

8 卡 H20 的总 FP16 算力大约 8 × 150 TFLOPS = 1.2 PFLOPS。理想情况下全部打满，算完也需要 3.07e17 / 1.2e15 ≈ 256 秒。就算考虑 MLA 架构下 attention 部分占比没那么高、实际激活参数到不了 300B，这个量级也意味着几十秒级别的理论下界。

所以问题很清楚：如果不从“算法层”降低计算量，只靠工程优化，首字延迟的天花板就在那里。这也是我们后来把主要精力放到注意力稀疏化上的根本原因。

2. 优化前先盘的几件基础事：并行切分、推理引擎和基准测量

2.1 并行切分：TP8 不如 TP4×EP2

8 卡 H20 在单机内通过 NVLink 全互联，理论上做 8 卡张量并行没有通信瓶颈。但 DeepSeek-V4.1 是 MoE 架构，直接上 TP8 会出现两个问题：一是 attention 的中间张量在 8 卡之间做 all-reduce，虽然 MLA 压缩了 KV cache，但 Q 和 K 的矩阵乘结果依然要频繁同步；二是 MoE 专家网络在 TP8 下被切得太碎，每个专家分布到 8 张卡上，路由到某个专家时所有卡都要参与计算，专家本身的局部性优势被削弱。

我们实验后确定的方案是 TP4 × EP2：4 卡一组做张量并行，两组之间做专家并行。每个专家的参数完整落在一组卡上，路由命中后只需要组内通信。对比 TP8 方案，这个配置在 512K prefill 场景下整体提速大约 20%，在 decode 阶段收益更明显，因为 decode 时每次只有一个 token，专家并行可以让不同的请求命中不同的专家，天然分摊负载。

如果你也在做 MoE 模型的推理部署，我建议不要默认“几卡就上几路 TP”，先用 profiling 工具看清楚 all-reduce 占比。MoE 模型的并行切分一定得考虑专家路由分布。

2.2 推理框架选型：默认调度器扛不住超长请求混合负载

开源的推理服务框架很多，大部分都做了连续批处理和分块 prefill，单看功能都够用。但我们的负载有一个特点：请求长度极不均匀，有的是几千 token 的短问题，有的是 512K 的长文档，混合在一个队列里。默认的 prefill 调度策略喜欢“大请求抢道”，一个 512K 的 prefill 进来，最长可能把后面几十个小请求卡住好几秒。

我们没有重写底层内核，而是自己做了一层调度模块：维护两个队列，长请求拆成 chunk 后以较低优先级进入 prefill，短请求优先插队。内核层继续用成熟的融合 attention 和推理执行器，但“先算谁后算谁”由我们自己的模块决定。这一步单独带来的收益没有特别大，TTFT 大概只降了 10% 到 15%，但它保证了后续优化措施不会因为长请求堵车而被浪费。

有个经验值得分享：在做任何底层优化之前，先把调度行为搞清楚。很多“线上慢”的问题其实是调度问题，不是计算问题。在测试环境里单请求跑得飞快、上了线上就慢，十有八九是长请求把 GPU 占死了。

2.3 测量口径：没有统一基准，一切优化都是耍流氓

优化之前我们先把测量方法定死了。TTFT 不能拿单请求测——那样测的是“独占环境下的理论值”，线上是 32 并发混合负载，完全不是一回事。我们固定了一组测试集：50 个请求，长度分布在 4K 到 512K 之间，512K 的请求占 20%，把并发打到 32，每个优化项跑 5 轮取中位数。

冷热状态分开测。前缀缓存命中率直接受测试方法影响，如果反复用同一个 prompt 测，缓存命中率接近 100%，测出来的数据线上根本复现不了。我们的正式指标分两类：冷启动 TTFT（清空所有 cache）和混合 TTFT（模拟线上真实命中率）。后面所有优化效果的对比都基于同一套口径。

这一步看似枯燥，但它是整个项目没有走偏的关键。没有这套基准，后面做的量化、稀疏化很容易被“测得快但线上不快”的假象误导。

3. 四个主攻方向：稀疏化、量化、前缀缓存、预填充切分

3.1 稀疏注意力：把平方复杂度从根上降下来

512K 全量注意力的复杂度是 O(n²)，这个 n 大到一定程度，任何工程手段都救不了。我们的方案是把注意力改成“局部窗口 + 全局锚点”的稀疏结构：

• 把 512K 序列切成长度 4096 的块，块内做完整注意力
• 每个块选出 64 个代表 token 作为全局锚点，锚点之间、锚点与所有块之间保持全局注意力
• 普通 token 只能看到本块的内容 + 所有锚点，跨块细节信息通过锚点间接传递

这样做的效果很明显：单次 prefill 的 attention 计算量大约只有全量注意力的三分之一左右。同时显存带宽压力也大幅下降，因为 attention 分数矩阵不再需要铺满整个 n×n 空间。

我知道有人会质疑稀疏注意力会丢信息。确实会。我们在实现时做了一层兜底：若检索模块发现某个 chunk 与用户问题相关，会把该 chunk 重新以全量注意力的方式注入到最新上下文里。说白了就是“先粗读再精读”，让模型不需要在 prefill 阶段就把 500 页文档每个字都牢牢记住。

3.2 KV cache 量化到 FP8：先把显存带宽按住

DeepSeek-V4.1 延续了 MLA 架构，KV cache 本身已经被压缩过一轮，显存占用相比传统 MHA 模型要小很多。但 H20 的瓶颈在带宽，KV cache 只在显存里“变小”还不够，读写它的时间依然是实打实的。

我们做了 KV cache 的 FP8 量化：每组 token 的 K 和 V 按组做缩放因子，不做 per-tensor 那种粗粒度量化。实测下来，KV cache 读写带宽占用大约降了一半，TTFT 这个环节收益明显。精度方面，在长文档 QA 验证集上 ROUGE-L 只掉了 0.3 个点左右，业务方可以接受。

需要提醒的是，KV cache 量化和权重量化是两回事。权重量化降的是参数量读取带宽，KV cache 量化降的是推理过程中的中间状态读写带宽。H20 这类带宽敏感场景，KV cache 量化的收益往往比权重量化更直接。我们特意没有动权重，全模型保持 FP16，避免出现“省了带宽赔了精度”的尴尬。

3.3 前缀缓存：把“公共开头”榨干

线上长文档问答有个规律——同一个用户或同一批任务，请求的 prompt 前段几乎一样：要么是相同的系统提示词，要么是相同的一堆检索文档拼在前头。这种情况下前缀缓存是最不讲道理的优化：直接把前 N 个 token 的 KV cache 存起来，下次请求命中后，prefill 只需要计算新增的那一小段。

我们的前缀缓存实现是“哈希 key + 块式存储”：把 KV cache 按 token 区间切片，每个切片用内容哈希做 key，命中后直接复用。实测下来，在模拟线上分布的混合测试里，前缀命中率大约 40% 到 50%，TTFT 大约降了 30%。这个收益是无需任何精度折损的，属于白拿。

实现时要小心一个坑：前缀缓存的存储上限。8 卡 H20 的显存总共 768GB，模型权重和在线 KV cache 已经占掉大半，再叠加前缀缓存，很容易爆显存。我们的策略是为前缀缓存设置独立显存池，最多占用剩余显存的 70%，Cache 淘汰策略用简单的 LRU，不搞花活——命中率已经不错了，淘汰策略的边际收益微乎其微。

3.4 Chunked prefill：让 512K 不再是“一堵墙”

全量 512K prefill 的问题在于，它是一个不可分割的大任务，一旦开始就要把 512K 全部算完才能进入 decode，期间 GPU 被整个占住。Chunked prefill 的思路是把它切成若干个小 chunk，每个 chunk 做完后允许调度器插入其他请求。

这一步对我们的收益主要不在 TTFT 本身，而在于“并发友好性”。做了 chunked prefill 之后，512K 请求处理到一半时，短请求可以插进来跑完，整体吞吐上去了，长请求的首字延迟也因为“先做了一部分、拿到初步结果就开始解码”而明显下降——配合稀疏注意力，我们实际上允许模型在前 16K token 读完后就先输出一个“框架性回答”，剩余 token 在后台继续读。

需要控制 chunk 大小。太大会让调度粒度变粗，太小会让 kernel 启动开销占比升高。我们最终选了 4096 token 一个 chunk，在 H20 上平衡性最好。

4. 从 18 秒到 1.42 秒：分项收益与测量细节

4.1 完整的测试流程

每项优化完成后，我们都会用同一样本集跑一遍完整测试。具体操作是：写一个压测脚本，向服务发送 50 个请求，每个请求带独立的 prompt，长度分布固定，并发 32，统计 TTFT 的中位数和 P95。冷启动指标单独跑一轮，先清空前缀缓存，再发送所有请求。

整个过程中有一个细节：模型输出的第一个 token 时间点，不能以“收到第一个字节”为准，而要由推理引擎内部记录“首个 decode 迭代完成的时间”。网络传输和流式分块会干扰测量，两个时间点可能差出几百毫秒，对于“秒级”优化目标来说这误差太大了。

4.2 分项收益拆解

下面这张表记录了我们每个优化项单独验证的收益，以及累进之后的 TTFT 变化：

注意，这些收益不是严格可乘的，因为有些优化之间相互影响。但大致量级是准的：稀疏注意力是最大的单项贡献，KV cache 量化第二，前缀缓存第三，并行和调度属于基建。最终 512K 请求的 TTFT 从 18 秒降到 1.42 秒，12.7 倍加速。

4.3 “12.7 倍”有没有水分

严格说，这个数字是在我们的混合负载、我们的缓存命中率、我们的稀疏配置下测出来的。如果你换一个场景，比如所有请求都是完全不同的长文档、没有任何公共前缀，那么前缀缓存那一项收益直接归零，累计加速会掉到大约 7 到 8 倍。如果把稀疏注意力也关掉，KV cache 量化和并行优化的收益加起来大约 2.5 倍。

所以“12.7 倍”应该理解为“这个具体方案在这个具体 workload 上的整体收益”。对于长文档分析、代码库问答这类有公共前缀、有检索前置步骤的场景，它是可以复现的；对于完全随机的长 prompt 输入，你依然能拿到稀疏注意力和 KV cache 量化的收益，但别指望 12 倍。

5. 踩过的坑：三类“看着优化了、实际没用”的问题

5.1 KV cache 全量 FP8 量化后，事实性问答开始胡说

第一次做 KV cache 量化时，我们图省事全部转成 FP8，一测 TTFT 确实降了，但仔细看输出结果发现：涉及文档中具体数字、日期、条款编号的问答，错误率明显上升。原因出在量化粒度上，KV cache 里某些关键 token 的数值范围很大，均匀量化导致细粒度信息丢失。

解决办法是改成分组量化：每 32 个 token 一组计算独立的缩放因子，同时给 attention 输出层保留更高精度的残差连接。改完之后错误率回到可接受范围。这个教训告诉我们：量化方案一定要量化粒度验证，不能只看显存带宽收益就上线。

5.2 稀疏注意力把“藏在长文中段”的关键信息跳过

另一个折腾了很久的问题是稀疏注意力的漏召回。场景是这样的：一份合同的关键免责条款出现在第 200K 到 250K token 之间，恰好不是锚点所在的位置，本地窗口也没覆盖到，模型在回答“合同里有没有提到某个赔偿上限”时直接说没有。

后来我们加了两层补救：第一层是关键词触发回溯——对用户问题做一次关键词抽取，如果这些关键词命中某个未进入全局注意力的 chunk，就把该 chunk 以全量注意力重新注入；第二层是让锚点选择不再均匀分布，而是根据 TF-IDF 权重选“信息密度高”的 token 做锚点。经过这两层调整，长文档问答的召回率基本恢复到全量注意力的水平，而计算量并没有明显增加。

5.3 用重复 prompt 测出了“假的 13 倍”

项目中途有个同事用同一个 512K prompt 连发 100 个请求测性能，测出来的 TTFT 只有 1.1 秒，比我们还快。后来查清楚，前缀缓存把 512K 的公共前缀全部命中了，相当于每次只算最后几个 token。我们在正式测试里特意区分了冷启动和混合模式，就是因为这个。

这个坑特别容易踩，尤其是做缓存类优化的人。上线前一定要问自己一个问题：线上真实请求里，重复前缀占比到底有多少？如果命不中，收益就是纸面的。

6. 什么场景适合这套方案，什么场景别硬抄

6.1 按场景分类的决策参考

我们这套方案里，稀疏注意力是收益最大但风险也最大的部分。如果你的业务场景是全开放式的对话，用户可能问任何问题，关键词回溯很难兜底，那我建议先用量化、缓存和调度优化，把稀疏注意力放到充分评测之后再说。

6.2 decode 阶段会变成下一个瓶颈

首字延迟压到 1.42 秒之后，我们很快发现新的瓶颈来了——decode 阶段的每 token 延迟。512K 长上下文的 decode 跟短上下文完全不是一个量级，每次生成一个 token 都要流式读取全部 KV cache，显存带宽又开始吃紧。目前我们在试投机解码和更激进的 decode 阶段 KV cache 量化，但那是另一个故事了。如果你也做到这一步，建议趁早关注。

6.3 只有 1 卡或 4 卡的简化版本

没有 8 卡 H20 的同学也不用失望，这套优化里有一部分是低配环境完全能复用的：

• KV cache FP8 量化：单卡就能做，收益很直接
• 前缀缓存：单卡也能做，关键是缓存池大小要控制好
• Chunked prefill：单卡也能做，但收益主要在并发场景
• 稀疏注意力：单卡也能做，但要注意漏召回问题，且需要在评测集上做充分验证

并行切分那部分（TP4×EP2）只对多卡环境有意义，1 卡用户可以直接跳过。

最后分享一点个人体会。这次从 18 秒到 1.42 秒，最大的经验不是某个量化技巧或稀疏化方案，而是“先测量、再优化”这个流程的威力。项目前两周我们被各种“看起来合理的优化”牵着走，每次改动都感觉有效，但集成到一起就互相打架。后来把测量方法固定下来，每次只改一个变量，很快就找到了真正的主瓶颈——注意力计算量。没有这套测量流程，我们很可能在量化上再抠出 30% 收益，却忽略稀疏注意力这个 3 倍的大机会。

另一个体会是：长上下文优化没有银弹，所有方案都是跟 workload 做匹配。如果你现在的任务是纯离线分析，不妨把 prefill 时间放宽到 20 秒以上，这样很多激进优化根本不需要做；如果你做的是在线助手，那前置检索、前缀缓存、稀疏注意力的组合几乎是必经之路。先搞清楚自己的请求分布、缓存命中率、精度容忍度，再决定要做哪几步。后面如果再有机会，我会把 decode 阶段的长上下文优化单独拿出来写一篇，那里面坑更多。