豆浆大叔

两个场景会发生 KVCache 传输：

1. Prefix KVCache 全局池化，Prefix KVCache 跨机复用
2. PD 分离，KVCache 从 P 传输到 D

虽然 KVCache 经过了几轮的压缩，已经小了几个数量级，对应的传输开销也小了很多

但是，上下文在变长，KVCache 的传输开销还是不容小觑的

今天来算算这两个场景的 KVCache 传输，对推理系统的影响

假设场景

GLM 5.3，H20 PD 分离部署

P 节点：单机 TP8 + CP8

D 节点：双机 DP16 + EP16

平均输入长度：100k

平均输出长度：1000

平均 KVCache 命中率：90%-95%

投机采样：投机 3 个，verify 4 个，平均接受长度 3 个

QPS 计算

P 节点，100k input/90k cached 的请求，计算耗时按照 1.5s 计算，单机 QPS = 0.66qps

D 节点，按照 TPOT 20ms 计算，单请求耗时 1000/(1000/20) = 20s

单 rank batch-size = 8 计算，单 rank QPS = 8/20 =0.4qps，双机 QPS = 0.4 * 16 = 6.4qps

P 节点

100k 的 input，KVCache 按照 fp8 存储，对应的大小的约 5GB

假设没有上层网关的 KVCache 亲和路由，也没有 D 节点侧的 KVCache 复用

对于一个请求，会在 P 节点上产生 5GB * 3 =15 GB 的传输

1. Prefix KVCache 的接收/发送，产生各 5GB 的入和出的流量
2. P => D 的发送，产生 5 GB 的出流量

按照 H20 上 400Gbit（50GB）* 4 的网卡配置，理论上 75ms 可以传输完成

按照 0.66 的 QPS，折算成带宽诉求只有 ~10GB/s，传输确实不是瓶颈

如果 5GB 流量放在单网卡上（TP8 上 KVCache 是重复的），理论传输耗时 100ms，这个时延也是可以接受的小头开销

那么，KVCache 亲和路由的理论收益，只是 100ms 的传输耗时么？我们继续算

D 节点

P 节点因为是 TP8，机内流量走了 NVLink，与跨机的 RDMA 流量天然是隔离的

但是，D 节点因为有双机 EP16，所以，还有跨机的 EP 通信流量

EP 通信

EP 通信分为 Dispatch 和 Combine

Dispatch 按照 fp8 的精度，每个 token 每层的传输量是：50KB

(6144 + 6144/128*4 + 16) * 8 = 50,816

Combine 按照 fp8 的精度，每个 token 每层的传输量是：98KB

(6144 * 2) * 8 = 98,304

每 rank 按照 batch-size = 8 计算，再算上投机采样

每 rank 上 Dispatch 流量 = 50KB * 8 * 4 = 1.6MB

每 rank 上 Combine 流量 = 98KB * 8 * 4 = 3.1MB

按照 50% 机内（走 NVLink）、50% 跨机（走 RDMA）

每 rank、每层的 Dispatch、Combine 流量是：0.8MB、1.6MB

按照 TPOT 20ms、平均接受长度 3 计算，一次 forward 耗时 60ms，每层耗时 800us

也就意味着，每 800us，每个 rank 流量为：(0.8 + 1.6) * 2 = 4.8 MB

对应的传输带宽诉求为：4.8MB / 0.8ms = 6GB/s

相对每 rank 的传输带宽为 25GB，这个量还没到瓶颈

流量冲突

P -> D 传输带宽： ~2GB/s（5GB * 0.4qps）

EP 通信带宽：6GB/s

加起来也明显小于单 rank 的 25GB 带宽，带宽视角是足够的了

但是，KVCache 传输 和 EP 通信 是两种完全不同的流量特征

KVCache 传输是典型的 Burst 流量，随机产生的大流量（GB 级别），对时延不敏感

EP 通信是高频的小流量（MB 级别），对时延很敏感

极端 case

假设这个极端的 case：

4.8MB 的 EP 通信，完全排在了 5GB 的 PD KVCache 传输任务之后，形成了网络排队

那么，原来 100us 的传输耗时，就会变成 100ms 级别了，相当于，这次 forward 就卡了 100ms 了

同时，由于 EP16 的每个 rank 是同步的，单个 rank 卡 100ms，也等于 16 rank 都卡了 100ms。

按照双机 6.4qps 计算，意味着每秒要卡 100ms * 6.4，有 64% 的时间，EP 通信都是被 KVCache 传输堵塞了

实际估算

当然，这是极端的 case，实际上，5GB 的 KVCache 传输，并不是完全的 Burst 流量

真实场景下，KVCache 传输的瓶颈并不在网卡传输上，而是引擎 + Transfer-Engine 构成的控制面板开销上

比如，KVCache 在 HBM 的碎片化，光提交 RDMA 任务的开销就不小，Burst 与否取决于这一层的优化

因此实际上，按照带宽竞争的影响估算是更合理的

理论上每秒在 EP 通信耗时：6GB/25GB = 240ms

理论上 EP 通信撞上 KVCache 传输的概率：6.4qps * 100ms / 1000ms = 64%

假设两个流量撞上之后，公平竞争带宽（传输速率减半），EP 通信耗时需要额外增加：240ms * 64% = 153 ms

（这个假设是比较保守的，假设 KVCache 传输的 burst 流量实际上平滑的，不会打满带宽，造成网络排队）

如果这部分增加的 EP 通信耗时，也不能被 overlap 掉，那么每秒增加的 EP 通信等待就是 153ms

（这个假设是有点粗暴，EP 通信肯定是要做 overlap 的，但是也不会完全 overlap 掉，这个展开又是单独一篇了，所以，这里粗暴点）

简单折算下来，KVCache 传输，对于 EP 通信造成的影响就是时延增加 15.3%

优化方案

为了减少 KVCache 传输，对于 EP 通信的影响，P 和 D 都需要优化：

1. Decode 开启 KVCache 缓存，加上 D 侧的 KVCache 亲和，P->D 的传输也使用增量传输，减少传输量
2. Prefix 也开启 KVCache 亲和路由，不仅仅可以减少 100ms 的传输耗时，也可以减少 P 侧的带宽竞争

这里的 KVCache 亲和性路由，不再是为了 Prefix KVCache 命中率，因为有了全局池化，KVCache 命中率主要是跟缓存池容量相关了

而是为了本地 KVCache 命中率，减少传输带宽，包括跨机网络、PCIE 等等。

在 KVCache 命中 90+% 已经常态化的 Agentic 场景中，稍微考虑一下 KVCache 亲和性，减少个八九成的传输量还是比较实际的

KVCache 亲和性路由

在网关上 KVCache 亲和性路由的实现，有近似、精确 KVCache-aware 两种方案

当我们对于 KVCache 亲和性路由的期望，降低为减少传输量之后，精确方案的收益比又需要重新评估了

但是，近似方案也不是一点问题也没有，主要矛盾是池化后的 KVCache 存储节点，不一定是处理推理请求的节点

这里其实是有 co-design 的地方：KVCache 亲和性路由 + KVCache 缓存 配合，用来提升 KVCache 本地命中率 + 减少 KVCache 冗余存储

多说几句

100ms + 15.3% 时延增加，只是 GLM 5.3 + H20 简单估算出来的

实际上 AI 的发展就是这么迅猛，存在很多的变量

1. 模型：DeepSeek-V4.1-Flash 已经把每个 token 压缩到了 890 字节，又是数量级的下降 …
2. 硬件：H20 是阉割算力，如果用海外主流的 B 卡，算力有数量级的提升，网络带宽却只有翻倍的增幅；但是，在 NVL72 架构下，EP 通信基本都可以收敛在 NVLink 域内，也不会 PD KVCache 传输与 EP 通信争用了
3. 业务：上下文会变长，命中率还会提升，如果命中率从 90% 提升到 95%，虽然只提升 5%，对于传输量而言，却是翻倍的增长

不管怎么变，在系统工程里，缓存本地化是比较常用的优化，KVCache 亲和性路由的成本也不高

DS Flash V4.1 虽然只加了一个小版本号，但是模型架构调整也不小…

每 token 的全局 KVCache 大小，压缩到 890 byte，相比 V3 的 34k（fp8）又压缩了四十倍 …

今儿来详细算一算这个 KVCache 的大小

本来计划算一下，PD 分离、KVCache 池化，对于 KVCache 传输带宽的诉求，但是，赶上 KVCache 又压缩了这么多，索性先从 KVCache 大小算起

其实，搞大模型，就得会搞各种算术题，真的庖丁解牛般算清楚了，可以减少很多的无效的尝试（当然，算 KVCache 大小只是个初级的门槛了

Global KVCache：890 byte

最终计算公式：

KV_global = 3 × (356 / 2) + 1 × 356 = 890 Bytes/token

接下来，我们逐个拆解

kv_source_layer_ids

1

"kv_source_layer_ids": [2, 8, 14, 20]

虽然模型有 40 层，但是只有这四层会产生 Global KVCache，890 byte 就是这个部分，对应上面公式的 3 和 1，表示的是这四层。

其他层用的滑动窗口注意力，128 的窗口，当然也是需要占 HBM 的。但是，按照 DS 的说法（SWA Bounded Replay），这部分可以不用持久化到 KVCache 池里，因为只需要回放最近 128 个 token 就能重新算出来。

再扯远一点，这次 V4.1 是 Causal Encoder-Decoder（CED）架构，Decoder 的全局 KVCache 是由 Encoder 最终 hidden state 投影出来的，不走逐层计算。所以在 PD 分离架构中，Prefill 节点都不用跑后面 20 层 Decoder（Prefill 每 token 只激活 8B 参数，Decode 是 16B），Decoder 的 SWA 窗口 KV 再由 Decode 节点自己 replay 出来，这样既减少 P 节点的计算量，也减少 HBM 用量。

Global KV entry：356 byte

356 byte 是一个 Global KV entry 的大小，又分为两个部分

1. Main KV = 512 * 0.5 + 512 / 16 = 288

hidden_size: 5120

head_dim: 512

5120 维的 hidden state，经过 512 维的投影，压缩了 10 倍，只有 512 维了

0.5 是 KVCache 使用的 FP4 E2M1 格式，每个只有 0.5 byte

但是，FP4 E2M1 范围有限，每 16 个 channel 会共享一个缩放因子，FP8 E4M3 格式的

也就是每个 KVCache 的值，实际上是 FP4 * FP8 的乘积

2. Indexer K = 128 * 0.5 + 128 / 32 = 68

index_topk = 512

每次只选 top 512 token 的 KVCache 参与计算，那么选哪 512 个呢，这里需要 Indexer 来计算

index_head_dim = 128

而 Indexer 选择也不会直接去读 KVCache 原数据，而是再投影到 128 维的 Index Key，减少 Index 的开销。

Key 是用 FP4 存储，每 32 channel 共享一个 FP8 缩放因子

最终两者汇总加起来：288 + 68 = 356

compress_ratios

V4.1 主打一个复用，没有 V4 那种 1/4、1/128 的复杂压缩了。

前面 3 层有 KVCache 会每 2 token 压缩，还是 512 维度，最后 1 层就不做 token 维度的压缩了

对应这个公式：KV_global = 3 × (356 / 2) + 1 × 356 = 890 Bytes/token

也就是前面 3 个 356 byte，需要 1/2，最后一个不需要了

SWA：2.58 MB

40 层中，只有 4 层会产生 Global KVCache，但滑动窗口注意力是每层都有的，也要占用 HBM，不过这个就小很多了

40 * 128 * (512 + 512/32) = 2.58 MB

head_dim 还是 512 维的压缩，FP8 格式存储，每 32 channel 共享一个 FP8 的 scale

一共 40 层，每层都有自己独立的滑动窗口，窗口大小是 128，因此，不管 context 有多长，滑动窗口的容量就是固定的了

作为一个对比，1M 上下文，Global KVCache 是 890 MB，SWA 始终都是 2.58 MB，差了 300 多倍，还是小很多的。

replay

值得一提的是，SWA 如果需要存储在 KVCache 池里，也是挺麻烦的事情（KDA 的 recurrent state 也类似）

虽然 HBM 容量占用是不大了，但是为了可能的复用，需要较频繁的往 KVCache 池里写入，淘汰，给 KVCache 存储带来了不少的麻烦。

本质上这种更新很频繁，复用概率较低的数据，存入 KVCache 池的性价比就不高。

DS Flash V4.1 干脆让 SWA 可以 replay 重新计算（近似）恢复，属于计算换存储/IO 了。理论上精确重建需要回放 层数 × 窗口 = 20 × 128 = 2560 个 token（每多一层，窗口就往前移一格），Bounded Replay 只回放最后 128 个，所以是近似恢复；但也正因为窗口只有 128，计算成本是可以接受的。

40 层架构

梳理下最终 40 层的架构

Encoder（L00 ~ L19），三层产生 Global KV，每层 178 B：

Decoder（L20 ~ L39），全局 KV 全部由 L20 从 Encoder 最终 hidden state 投影产生，后续层只复用 KV、按需重建索引：

合计：3 × 178 + 1 × 356 = 890 B/token

最后

DeepSeek 为了降低成本，确实玩得很花

仔细拆解下来，这次 V4.1 在 Attention 机制上，主要是跨层的 KVCache 复用，以及由此延伸出的 Encoder 和 Decoder 的区分

至于 Index 跨层共享，在 GLM 5.2 也已经有了

还有 Engram 终于也是用起来了，这又是一个新的落地玩法

看看 DeepSeek Pro scale 之后能达到什么效果吧，期待 …

本质

MaaS（Model as a Service）本质上是一个科技房地产的生意。

最近跟一大佬聊天，他的这个总结，我觉得还是挺精辟的。

随着模型智能的提升，前沿模型的 token 单价也在水涨船高，做一家赚钱的 MaaS 这个叙事更加通顺了，今儿就来大体上的聊聊。

房地产

做 MaaS 首先得有卡，这就像房地产一样，需要囤地皮，这是一个重资产的游戏。

但是卡跟卡也不一样，什么时候，买什么样的卡，就跟判断趋势，什么时候，囤什么地段的地皮，是一个逻辑。

卖卡大师，黄教主说：买得越多，赚得越多。The more you buy, the more you make.

意思是说，NVIDIA 的 GPU 卡是黄金地段，客流量高，肯定卖得好，大家都囤起来。

要是没有出口管制，这话放在当下，也是事实。

但是在当下的政策环境，以及考虑到长远（肯定也不希望市面上只有一个卖地皮的），什么时候，买多少，买哪家的卡，也挺考虑战略眼光的。

科技

从卡到 token 的生产过程，就考验团队的技术实力了，也是想探讨的重点。

这里的本质是：服务质量 + 运营效率。

服务质量

服务质量又分为两块：

可用性：包括各种模型能力是否都支持，比如 tools call 这种的，还有长期运行的稳定性等，三天两头出故障，用户也跑没了。这块算是入场券，是门槛性质的要求，就不展开了。

时延：也就是单个用户感受到的出字快慢，通常用单用户的吞吐 token/s 来衡量，这也是 MaaS 比较特别、需要着重关注的地方。

上一篇我们有过简单介绍：用户买的就是时间（时延），但是，推理的时延跟吞吐（效率）是一个取舍关系。

简单说：为了用户满意，希望时延要低，但是成本想降低，希望时延要高。

定价建模

中间的一个平衡点，就是价格。

什么价格，提供什么样的时延服务保障，这个也很讲究。

核心是，MaaS 厂商自己得有建模，心里有数，才好跟客户谈价。

其次是，这个时延 vs 价格，也得有足够的吸引力，毕竟主流模型是开源的，客户也会多处询价（国外不开源的前沿模型，人家有这个垄断优势，那就另说了）。

运营效率

分为两块：单点效率 + 集群效率

单点效率

单点讲的是最小单元的效率。

衡量指标是：给定模型，给定时延 SLO 要求，给定流量 pattern 下，产出的单位 token 的成本。

单点效率优化的成果，正是上面定价建模的输入，主要工作是，推理引擎侧的优化。

常用的优化方向包括：

1. 切分策略，包括：TP、DP、EP、CP 这些。
   通常是，针对指定的模型，指定的计算卡，设计适合的切分策略，已经算比较成熟的常规操作了。
2. 量化：主流 SOTA 模型，都往 FP4 走了
   国内存量硬件原生支持 FP4 的不多，即使算力上有吃亏（比不过 B 系列的原生支持），量化也是有很大收益的。
3. 投机采样：不仅提升单用户的吐字速率，整体计算效率也有提升
   硬件喜欢大矩阵乘，投机是搞大矩阵的有效途径之一
4. 算子优化，通算融合：
   这种算比较偏硬件底层的优化了，主流模型、主流硬件上，开源的也不差，也是现在 AI 投入较多的方向。

集群效率

集群是说规模化的效率，比如万卡集群的整体效率。

衡量指标就比较多了：

1. Prefix KVCache 命中率
2. 时延 SLO 稳定度
3. 资源利用率

Prefix KVCache 命中率

两点先讲清楚：

1. Prefix KVCache 命中率，最开始的依赖是推理引擎得做好，但是没放单点里，因为这已经算推理引擎的默认要求了。
2. 现在 KVCache 是多层混合存储的了，这里的命中率就包括了每层的命中率，都有要求。

除了推理引擎的最基础支持，保证命中率，关键是这两个：

1. 全局 KVCache 池化，这是整个集群 KVCache 命中率的基础保障，有 DRAM 的存储加持，基本可以做到接近理论命中率。
2. Cache 亲和路由，这是为了提升 HBM 上的 L1 命中率，以及本机 DRAM 上 L2 命中率，可以很好的降低 TTFT 和各级传输带宽。

这两个是相互配合的关系，少哪个都会很别扭。

我听过一些比较极端的暴论，比如有了全局 KVCache 池化，就不需要 Cache 亲和的，我只能说他没搞过大规模生产服务。

KVCache 的传输开销是可以建模计算出来的，后续有空再细聊了。

同样，只有 Cache 亲和，没有全局 KVCache 池化，让 Cache 亲和来背命中率，也是戴着镣铐跳舞，很被动。

因为路由层的调度，还要承担更重要的时延 SLO 的任务。

时延 SLO 稳定度

上一篇也铺垫了不少，给定已经部署好的推理集群，时延和集群吞吐是取舍关系。

时延太高了，破了给用户承诺的 SLO 阈值，用户会投诉。

时延太低，也说明集群吞吐是下降的，毛利会降低，甚至会亏损。

因此，时延如果稳定在承诺的 SLO 那条线，是利润最高的点。

国外的我不知道，国内的大部分是低峰期的时延明显要低，很明显，这个时候毛利肯定是更低的了。

少数的供应商，部分模型上，时延很稳定，说明品控做得不错。

如何做到时延稳定呢，后续有空单独开篇细聊了。

资源利用率

回到房地产的比方，资源利用率就是出租率，空置的房子是不产生收益的。

应对低峰期，最赚钱的方式是，在满足时延 SLO 的情况下，对在线服务做缩容，也就是我们常说的弹性伸缩。

缩下来的资源，可以拿来跑离线任务，就像淡季把空置的物业转作他用，把资源充分利用起来。

虽然现在离线任务的规模还不够大，但是只要把产品做好了，价格到位了，还是能找到不少客户的。比如大模型训练里的数据标注等等。

如何做好弹性伸缩，这个跟上面的时延 SLO 稳定度也是强相关的，这两个也需要很强的协同配合，后面再细聊吧。

最后

回到开头的比方，做一家赚钱的 MaaS，就是三件事：地皮、科技、规模。

一是地皮，也就是卡，什么时候买、买多少、买哪家的，需要看清形势，审时度势。

二是科技，从卡到 token 的生产过程，如何优化、能多赚钱，是 MaaS 平台持续需要深耕钻研的。

三是规模，MaaS 跟通算的云一样，本质上吃的是规模化的红利，随着开源模型的智能逐步追上闭源的前沿模型，token 消耗的规模越来越大，MaaS 的成长空间还是不错的。

另外，模型后面的开源 License 也是个变量，kimi k3 算是开了一个和 MaaS 分成的先河，估计后续足够前沿、能掌握定价权的模型，都会效仿这种分成模式。

不过，这些都只是利益分配问题，我还是认为做一家赚钱的 MaaS 是行得通的。

答案

1. 智能：不同的模型，智能水平差距还是挺大的
2. 时间：相同模型，不同供应商的耗时也差距不小

智能

这个是最直观的，同样的百万 token，最新的 SOTA 模型，比起一年前的 SOTA 模型，能干得活多了很多。

时间

这个通常不太提及，因为大多数时候，作为普通用户的我们没得选…

做 Agentic 应用的创业者，会比较多关注这个，毕竟他的用户还是关心任务完成时间的。

回顾上一篇，大模型推理，本质上是一个批处理计算，为了提升 GPU 上的吞吐，提升并发度，是最常用的策略。

但是，提升并发度之后，针对单个用户请求的吞吐速率就慢了…

时延 vs 成本

举个生活中的例子，同样的点外卖

一对一闪送，肯定是最快的，但是，价格是要更贵的。这就相当于推理的小并发推理

普通外卖，骑手都是好几单同时送的，顺路要接其他单的，速度肯定要慢的。这就是推理中的大并发推理

真实中的推理，不同的响应速度，成本可能要差个几倍，一般都是可以建模出来的。

当然，造成响应速度差异的，也有很多其他因素，咱们这里就不细究了。

作为用户的启示

如果是个人开发者，其实 token 消耗量不会很大，通常都是模型能力 > 时延 的筛选逻辑。

如果是 token 消耗量很大的 Agentic 应用创业者，通常都有很好的成本意识。

比如会去选合适的模型，优化长上下文，来降低成本。

长远来看，控制好任务的耗时预期，也是值得考虑的优化方向。

比如有些应用场景下，如果对时延要求不高，是可以找 MaaS 供应商谈个好价钱的。

当前，这些都是体量大了才有的操作，0-1 的创业期，用最好的就对了。

对 MaaS 平台的观察

国外的 token 供应商，提供不同的响应速度的服务，比如 OpenAI、Anthropic 的模型服务都有快速模式，更快的速度，更贵的价格。

国内的算力确实紧张，体量也小不少，没有标准化的提供不同时延的服务等级。不过，我估计，体量到位了，只要肯付溢价，应该还是谈个更快速度的。

aiping 数据分析

最近抓 aiping 的数据做了个方便查询历史的汇总，针对近两周数据也做了一些分析。

发现大部分都是这个规律：0点 - 6点这个时段，周末的时段，明显会快很多。

归一化后的速率热力图，还是非常明显的。

这确实很符合国内的波峰波谷特征，但是，也说明，大家的弹性策略，做得确实也都不咋样。

当然，也有相对做得好的，阿里云百炼的速率，相对保持的不错，有几个 Qwen 系列的模型，非常的平稳。

我估计是做了深度的建模，做了 SLO 感知的调度。

有意思的推测

还有几个有意思的推测，也挺好玩的

1. 金山云的 GLM 5.2 都有 TPS 100 以上的，估计用 B 卡在跑推理了
2. 硅基流动的 DeepSeek V3/R1 系列，TPS 只有 20 左右，估计是跑在国产卡上了 …

未来预测

随着国内算力的充足，token 体量的增长，不同时延 SLO 档位 token 服务，估计也会变成标准化的服务能力。

供应侧，不同代际、供应商的卡，能跑出来的水位是不一样的。

需求侧，token 体量大了，也会更关注成本，context 优化之类手段榨干之后，控好时延，大概率也是要用上的。

即使未来演进，只要模型参数量摆在这，推理还在追求计算强度，那么时延和成本之间的冲突就一直会存在。

好了，下一篇预告，聊聊供给侧，如何做好（赚钱）的 MaaS。

大白话

大模型推理，本质上是一个批处理计算。

因为读取的权重参数非常多，显存带宽不够用了，希望每次读取的参数，可以多进行几次计算，以提高计算强度。

再加上自回归计算特征，每次计算只产生一个 token（算上投机采样，通常也只有几个 token），因此，提升请求的并发度就很有必要了。

显存带宽

以 GLM 5.2 为例：753B 参数、40B 激活；FP8 精度；hidden size 6144；一共 78 层、前三层 Dense；256 个 routed 专家、激活 8 专家、共享专家一个；稀疏注意力取 top 2048，IndexShare 每 4 层共享 1 indexer。

单个请求，Decode 产生一个 token，至少需要读取 40B 参数量，FP8 下一个参数一个字节，也就是 ~40GB。

其中：

Attention（78 层合计）: 12.872B

DSA Indexer（21 个合计）: 0.197B

前 3 层 Dense FFN: 0.679B

75 层 MoE: (8×37.749 + 37.749 + 1.573) × 75 = 25.598B

这里单个专家 37.749M = 3 × 6144 × 2048（gate/up/down 三个矩阵，专家中间层 2048），1.573M 是 router = 256 × 6144。

LM Head: 0.952B

合计：12.872+0.197+0.679+25.598+0.952 = 40.298B

当 Batch 增大时，假设 routing 是均匀的，被激活的 routed 专家数量是：Expert(B) = 256 * (1 - (31/32)^B)

激活参数量（即单 token 的显存读取量）是：Active(B) = 17.649 + 2.831 * Expert(B)

画成走势图，就是：

除了权重，Decode 还要读 KV cache；好在稀疏注意力只读 top 2048 的 KV：576×2048×2 × 78 ≈ 0.18GB/token，相比 40GB 的权重读取是小头。

不过，DSA Indexer 为了选出 top 2048，还要扫描全量 Context：21×128×2 × L × B

平均 context 128k，10 batch，也有 6.9GB，也是不小的开销。

计算

还是先从单 batch 开始，计算量分为三个部分：

线性计算，包括：Dense / MoE / Projection 计算，40B 激活 => 80 GFlops

DSA Indexer 计算量：按照 128k context 计算：2×32×128×131072×21 = 22.5 GFlops

Sparse MLA 的计算量：(2×64×2048×576 + 2×64×2048×512) × 78 = 22.2 GFlops

合计：125 GFlops

也就是说，单 batch 下计算强度只有 125 GFlops / 40 GB ≈ 3 FLOP/Byte，远低于主流 GPU 的拐点（数百 FLOP/Byte），是纯粹的带宽 bound。

但是，当 Batch 增大时，计算量是几乎线性增长的（每个 token 的计算互相独立），而显存读取量却像上面的走势图一样逐渐饱和。

所以，计算强度可以随着 batch-size 的增加，持续增大。不过即使 B=128，计算强度也只有 ~22 FLOP/Byte，仍然没有脱离带宽 bound 的区间。

GPU Tensor Core

以上是大模型计算的理论分析，实际上在真实 GPU 硬件也是大 batch-size 友好的。

Tensor Core 的矩阵乘法，是有固定的一些 shape 的。

比如 m64n8k32，一条指令处理 M=64 行；batch-size 不足 64（或不是 64 的整数倍）时，多余的 lane 在空转，等效 MFU 就被拉低了。

对 MoE 层来说更苛刻：平均每个 routed 专家只分到 B×8/256 = B/32 个 token，要让每个专家都喂满 m64，batch-size 得到 2048 才行，这也是推理引擎喜欢超大 batch 的一个原因（当然，实际上是远不会跑到这么大的）。

当然，针对 Prefill 阶段，因为可以有很长的 context，可以切分到 M，所以单 batch-size 也是 Tensor Core 友好的。

对于网关的影响

对于通算的在线服务，通算网关通常按照流量（请求量）做好均衡，每个服务实例的负载就是均衡的了。

本质上，推理网关承担的，不再是请求流量的分配，而是推理任务的调度。

从全局来看，推理网关的全局调度，与推理引擎上的本地调度器，共同完成了集群级推理请求（计算任务）到 token 粒度 GPU 执行的调度。

作为全局调度器，推理网关，核心价值主要是两个：

1. 降低时延（通过负载均衡）
2. 降低成本（满足 SLO 的前提下）

对于单个推理服务实例而言，batch-size 是影响服务时延、吞吐的重要因素。

对于推理网关而言，控制好每个推理服务实例的 batch-size 就很重要了。

除了 batch-size，当然还有其他的因素也是需要综合考虑的，留着下篇再写了。

DeepSeek moment 确实是把整个行业都震撼到了，几百 B 的大稀疏 MoE 架构，多头潜在注意力（MLA）把成本打下来，模型能力也有了质的飞跃。

V3 发布（2024 年底）后的半年多里，模型架构没有太大的变动。

一年半后的今天，业务场景已经从简单的 Chat，发展到了 Agentic，上下文从百 K 发展到了 1M，模型架构也有了新一轮的明显跃迁。

本文主要从推理的视角，谈谈个人的看法。

一、模型大小：参数量与激活量双增长

671B/37B（V3）→ 1.6T/49B（V4-Pro）→ 2.8T/104B（K3）

估计后续的主流 SOTA 模型，都得是 T 级参数量，100B 级激活量了。

参数、激活量的上涨，加剧了显存容量和带宽的压力，存储股票最近涨得一塌糊涂也是有原因的。

二、FFN/MoE：继续稀疏化，叠加压缩

256 选 8（V3）→ 384 选 6（V4-Pro）→ 896 选 16（K3），专家数量变多，专家激活比例变少。

有趣的是，Kimi K3 把 MLA 的低秩压缩思路也用到了 MoE 上（LatentMoE），可以节约显存、通信带宽。

三、注意力：四条路线，混合发展

压缩。 MLA 之后，V4 更进了一步：CSA（KV 沿序列维 4:1 压缩后再稀疏选择）与 HCA（128:1 激进压缩 + 稠密）按 1:1 交错堆叠，压缩程度更深。

稀疏化。 V3.2 首提 DSA：Lightning Indexer + top-2048 选择；GLM-5.2 再加 IndexShare——每 4 层共享索引，78 层仅 21 层保留独立索引。

线性。 Kimi KDA 与 Qwen Gated DeltaNet 同为 3:1 混合：75% 线性层 + 25% 全注意力锚层，KV cache 减少 75%。

滑动窗口。 V4-Flash 前 2 层是纯 SWA 层；V4 的 CSA 与 HCA 层也都保留最近 128 token 的完整 KV 滑窗分支；Step 3.5 Flash 则是 SWA:Full=3:1 的混合。

四条路线也不是分开演进的，DeepSeek V4 系列是玩得最花的，混合注意力还是很有希望的。

四、投机采样成了标配

解码是 memory-bound：即使只产 1 个 token，也要读一遍权重，带宽利用率太低。

投机采样的思路就是，拿算力换显存带宽：用一个便宜的 draft（比如一个小的 MTP 头）一次猜出多个 token，大模型一次前向并行验证，猜中的直接收下。验证是并行的，多花的算力本来利用率也不高，换来的却是实打实的解码提速。

有意思的是，DeepSeek 还专门发布了 DSpark 投机采样框架，根据算力需求和接受概率来动态决定投机长度，避免傻大粗式的算力浪费。

参数量、激活量越来越大，显存带宽又很有限，Agentic 场景下对时延的要求也更高了。用本来利用不满的算力换解码速率，也是众望所归了。

五、残差流改进

层数从 61（V3）堆到 93（K3），模型越堆越深，逐层均匀累加的残差流开始出问题：每层的贡献被不断稀释，信息混合方式太单一，也被动刀了

K3 的 AttnRes 把残差换成跨层选择性检索，V4 的 mHC 则把残差流扩成 4 通道，用双随机矩阵流形约束保深层稳定。

虽然带来一些额外开销，但对整体推理成本影响不大，收益主要在模型能力。

小结

回看这一年半的模型架构演进，几条线索其实都指向同一个方向：推理成本。

参数量上去了，靠更稀疏的 MoE 压住激活量；上下文长了，靠压缩、稀疏、线性、滑窗把 KV cache 打下来；解码慢了，靠投机采样拿闲置算力换带宽。

当然，残差流这条线，钱花在了深度能力上，不在成本上。

模型架构的竞赛，已经从单纯的”更聪明”，变成了”更聪明的同时，把每个 token 的成本和时延做得更低”。

国内的开源模型厂商，在算力受限的情况下，把成本打下来的同时，模型能力还能继续追赶国际 SOTA，很有希望。

最后，虽然模型架构有了很多演进，不过大基调还是没有变动，依旧是 Transformer 架构，Attention is All You Need 还是真理。

大模型的本质是信息的压缩，推理过程本质是，海量参数读取、矩阵乘的暴力计算，这个范式依旧没变。

下一篇再来分析下，从通算在线服务，到大模型推理服务，这两种范式的跃迁，对于计算机基础设施的影响。

附：主流模型架构对比

参考

• DeepSeek-V3 Technical Report
• DeepSeek-V4 Technical Report
• Kimi K3 技术报告（GitHub: MoonshotAI/Kimi-K3）
• GLM-5 Technical Report（GLM-5.2 共用同一骨干，IndexShare 见 arXiv:2603.12201）
• DSpark：DeepSeek 投机采样框架

1. 大模型太吃资源了，各种计算、memory、带宽 bound，导致引擎并发能力很弱，对负载均衡依赖很高

2. 往后看，AIGW 要做的，不仅是要均衡，而是要承担时延 SLO

确实好久没写了，这一年都在 “卷” AI 网关，内部落地，业界演进，节奏都非常快，忙也是现实

今儿开个头，开启一个新阶段，后面保持节奏继续走起

负载均衡

今儿从负载均衡开始聊起，在通算时代，对于网关来说，这是经典的基础能力

Round-robin，权重轮询，最小连接数，一致性哈希，也可谓是脍炙人口

但是，在智算时代，负载均衡是 AI 网关的核心价值，已经逐步在成为行业共识了

为什么呢，小小负载均衡，有这么重要（难搞）么？

推理的计算特征

这要从大模型推理的计算特征说起了

（大模型推理的计算过程，要讲清楚了，也不容易，咱们这里只聊跟负载均衡有关系的）

计算量大

大模型推理请求的计算量都很大，相比通算的业务请求，多了好几个数量级

以 deepseek v3 为例，一个 4k token 输入的请求，纯 prefill 阶段，就需要 8 卡的 H20 计算几百毫秒

单点并发小

对于通算应用，单点几千几万的并发也很常见

而在推理场景下，单点的并发能力就弱很多了，prefill 阶段可以认为没并发（开启 dp 也算有点），decode 阶段一般也就是几十上百

波动很大

推理请求的计算量，随着输入输出长度变化，差异也非常大，不同请求的计算量，相差个几十上百倍，也很常见

尤其是输出长度，由于自回归特性，都不好提前感知

prefix 语义 KVCache

大模型的计算结果也可以缓存（KVCache），对于提升性能也很重要，但是，缓存复用需要遵守 prefix 语义

通算场景下的缓存，通常是基于某个 key 来做哈希的规则，相对来而，推理这个要复杂多了

难在哪

简单说，在推理场景，因为推理引擎抗并发小（各种 计算、memory bound），更需要负载均衡，但是，也更难做好负载均衡

那么，难在哪里呢

在通算场景下，服务的负载通常和请求数，或者并发数正相关，只需要做到请求/并发数均衡基本就够了

但是，由于上述推理的计算特征，推理服务的负载，跟请求数并不是正相关

于是，有了这三个关键的具体问题：

1. 哪些指标可以反映负载
2. 如何获取到，时效性如何
3. 什么样的负载算法来决策

具体怎么解，就留到下篇了

最后

关于推理的计算特征，看 Mooncake 论文里的这个图，可以有一些直观的体感

2024 的年度总结，比以往时候来得更晚一些，倒也不是变懒了，只是确实太“卷”了 …

今年最后几个月，公众号也断更了，也是确实没空写字了 …

趁着年关，还是先停下来，写点文字，记点流水账 …

一入 AI 深似海，从此周末是路人

今年最大的感悟是，AI 大模型太 “卷” 了

前年过年，GPT 3.5 是热议话题，去年过年被 Sora 震惊，今年过年 DeepSeek 都火到了美国

下半年有幸参与了 AI 推理业务，也是切身体会到其中的 “卷”

有一次，同事顺嘴问了一句，最近周末去哪里玩，我才意识到，好像都没有周末了 …

之前听一些分享，说国外的 AI 厂商也很卷，很多都是自愿加班开卷，完全不是以往 work-life balance 的形势

参与其中之后才深刻体会，AI 大模型就是一阵旋风，只要进来，就会自然卷了 …

记得阿里有个提法，叫 “饱和式投入 AI”，所谓饱和式，那就是多头下注，不允许错过

不只是对外多方投资，对内也是鼓励不同方向的尝试，有点重复建设也不是啥问题

如此行业级的重兵投入，不卷成麻花，那才怪了 …

自然卷

之所以会自然 “卷”，主要还是发展太快了，新东西太多了，完全学不过来

以往学习，还可以找经典的教材，而现在的学习，必须得看新材料，读论文，层出不穷的论文

因为要想参与其中，干点事情，首先就得跟上发展趋势

大约年中的时候，跟合作方聊起推理引擎的调度算法（半年前调研的材料），说网关上可以搞点事情

结果，对方说，那个都是去年的了，现在都不这么玩了…

对于网络这种 infra 的角色，需要面对多方的快速发展，对下得跟上各种硬件的发展，对上还得了解大模型，各种算法的发展

只会让人觉得脑容量不够，时间不够

单纯的求知欲，就足够驱使人停不下来了，更何况还有外部高强度的竞争

还卷得动

那么，还卷得动么？嗯，至少目前还是卷得动

那么，面对全新的领域，饱和式投入，以往十年的工作经验，还有用么？

有用，但是不多 …

对于传统的 CPU 计算应用，已经沉淀了一套成熟的微服务架构体系，每个服务的逻辑都不是那么复杂，计算量也相对较小，单个 CPU core，就足够支持不低的并发了

到了 AI 大模型，因为庞大的计算量，天然就需要并行计算，几十 B 模型的推理，就需要多卡并行计算了，更别提几千上万卡的大规模训练集群了

而并行计算，也带来了一次通信的升级，从机内的 NVLink，HCCS，到机间的 InfiniBand，RoCE 都是大模型业务带来的腾飞

虽然很多也还不懂，但是，今年卷了几个月，也算有些眉目，自我感觉还不错，至少还卷得动

更何况，这一波是划时代的升级，把时间拉长，暂时的不懂，影响也不那么大，拥抱变化，迎头赶上，赶上这波浪潮才是关键

流水账

好吧，可能确实有点卷过头了，脑子里就剩下大模型了

还是稍微回顾下，今年都干了啥

上半场

今年跟去年有一点很类似，就是上下半场风格完全不同

去年年终总结的时候，还想的是安心搞好网关，等着推理业务起来，迎来一波行业大发展，带动一波网关业务的红利

所以，上半年，主要还是在搞老本行，云原生网关

只是，更多在内部落地，需要有节奏的推进把控，也不轻松，开源搞得也相对少了

AI gateway

印象中 2023 年，蚂蚁就提了 AI First 战略，也知道公司有在训练大模型，但是感觉离得很远

到了 23 年底，原来的网关玩家，都开卷 AI gateway，做推理 API 的统一入口

虽然 API gateway 的底色很浓重，但是也确实有些推理 API 的亮点

今年初，也想在公司里搞个 AI gateway 的业务场景玩玩，只是问了一圈，也没有找到落地点

先训练再推理

不只是蚂蚁，很多国内大厂，都想卷自己的大模型，而不甘心用别人的大模型，来搞新应用

所以在资源投入上，更多在买卡先搞训练，先让自己的模型跻身业界一线，保持模型不掉队

而 AI gateway 是用在推理，搞新应用的场景 …

开卷 AI Gateway

到了下半年，又有了一些新的变化，推理被更多的提起，很幸运我们找到了合作方，可以开卷 AI gateway 了

作为专业的 Gateway 团队，我们首先卷的是性能

按照传统的网关分类划分，AI Gateway 应该属于业务网关，这类网关一般被认定为业务量不大，性能要求不高的

但是，在推理将成为大趋势的共识下，卷性能也很有意义了

好在基于过去几年的技术积累，我们的 MoE 架构，使用 Golang 来开发扩展，很快就支持了 AI Gateway 的落地

性能也比原来的 Java 实现了 10x 提升，之前折腾的 cgo 优化，也派上了用场

大模型推理

搞 AI Gateway，除了卷性能，也更多的了解了大模型推理的业务

Gateway 再卷也属于原来的舒适区，背后的推理业务，才是全新的挑战

AI Gateway 下一站

当前推理成本过高，是行业级的问题

每一层都在解决这个问题，NVIDIA 在造性价比更高的硬件，模型层也在优化，比如 MiniMax-01 的线性 Attention，还有推理引擎运行时，各种算法、架构的优化

那么，AI Gateway 作为推理流量入口，最适合的是，做全局最优调度，提升整理资源效率

推理过程微服务化

另外，大模型推理的自回归特性，也存在明显的 Prefill 和 Decode 两个阶段，对应不同的计算模式

年中，kimi 的 PD 分离架构 + 全局 KVCache 调度，将推理服务拆分推到了一个新的高度，有点类似通算业务的微服务拆分了

而对应的，中间的 KVCache 传输，就需要高速的网络传输方案，也有点类似于通算场景的 RPC 框架

最后

10 月的时候，听了老黄在印度的演讲

有一点触动很大，过去几十年，围绕 CPU 的编程生态，一直在享受摩尔定律的红利，现在摩尔定律失效了，是时候开始新的编程模式，CUDA 编程了

最后，祝大家新年快乐，在新的浪潮下都有自己的 aha moment ～

本地限流因为使用简单，执行高效，可以算是最常用的了

在 Envoy 里，local rate limit 可以用于不同的 Envoy Filter 扩展阶段，从而实现不同行为的限流：

1. HTTP Filter，限制 HTTP 请求频率
2. Network Filter，限制 TCP 建连频率
3. Listener Filter，限制TLS 握手频率

配置用法

以常用的 HTTP localrate 为例来感受一下配置：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

http_filters:
- name: envoy.filters.http.local_ratelimit
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
    stat_prefix: http_local_rate_limiter
    token_bucket:
      max_tokens: 1000
      tokens_per_fill: 1000
      fill_interval: 2s
    status: 429
    response_headers_to_add:
    - append_action: OVERWRITE_IF_EXISTS_OR_ADD
      header:
        key: x-local-rate-limit
        value: 'true'

Envoy local ratelimit 采用令牌桶算法，限流的核心配置是这三个：

1. max_tokens 桶的最大 token 容量，也是初始的默认值
2. tokens_per_fill 每个周期增加的 token 数量
3. fill_interval 填充 token 的时间周期

那么，上面配置的效果就是：

1. 一个最大容量为 1000 的桶，每 2s 往桶里加 1000 个 token
2. 每来一个请求，消耗桶里一个 token，如果桶里没有 token 了，就会拦截请求

对于拦截请求的响应，还可以配置：

1. 响应状态码，默认是 429
2. 和响应的请求头

细粒度限流

上面的示例是一个粗粒度的策略，针对这个 listener 端口上的所有请求。

如果想实现一个细粒度的，比如域名级，或者接口级的呢？

也是可以做到的，ratelimit 也支持 route 级别的配置：

1
2
3
4
5
6
7
8
9
10
11

routes:
- match: {prefix: "/path/with/rate/limit"}
  route: {cluster: service_protected_by_rate_limit}
  typed_per_filter_config:
    envoy.filters.http.local_ratelimit:
      "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
      stat_prefix: http_local_rate_limiter
      token_bucket:
        max_tokens: 10000
        tokens_per_fill: 1000
        fill_interval: 1s

如果是同一个路由内，还想实现更细粒度限流呢？

Envoy 还有路由级别的 descriptors，比如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

- match: {prefix: "/foo"}
  route:
    cluster: service_protected_by_rate_limit
    rate_limits:
    - actions:  # any actions in here
      - request_headers:
          header_name: x-envoy-downstream-service-cluster
          descriptor_key: client_cluster
  typed_per_filter_config:
    envoy.filters.http.local_ratelimit:
      "@type": type.googleapis.com/envoy.extensions.filters.http.local_ratelimit.v3.LocalRateLimit
      stat_prefix: test
      token_bucket:
        max_tokens: 1000
        tokens_per_fill: 1000
        fill_interval: 60s
      descriptors:
      - entries:
        - key: client_cluster
          value: foo
        token_bucket:
          max_tokens: 10
          tokens_per_fill: 10
          fill_interval: 60s

可以根据请求中的特征（上面示例是一个请求 header），实现路由内，不同的限流配置

实现机制

从配置方式理解，Envoy 的实现也不需要很复杂

1. 在配置解析阶段，配置中的每一个 token_bucket，就会生成一个 RateLimitTokenBucket 桶实例

2. 在请求处理阶段，通过 route/descriptors 匹配到 token_bucket 之后，就从对应的桶里取值即可

在 1.31.0 之前，是每个桶都有一个定时器，每 fill_interval 给桶里注入 tokens_per_fill 的令牌

在 1.31.0 里，做了个优化，不再依赖定时器

原因是，定时器运行在 main thread，而 main thread 在 Envoy 里面还有一个重要职责就是加载来自控制面的配置，当配置量很大的时候，可能会长时间的阻塞这些 timer，就影响限流了

与 NGINX 对比

在 NGINX 里，与 Envoy local rate limit 最接近的就是 limit_req 了

首先是限流算法上的区别，Envoy 是令牌桶算法，而 NGINX 是漏桶算法

漏桶算法可以实现流量整形，比如上面示例的 1000/2s 在 NGINX 会被处理为 500/s，也就是每 2ms 放行一个请求，从而让请求更均匀的转发给后端应用

而令牌桶算法的限制值，更接近人类的理解，X 时间放行 Y 个请求

动态限流 key

不过，在我看来，最大的区别还是，NGINX 可以指定动态限流 key，从而实现每个 IP 限制 10/s 这样的效果，而 Envoy 却做不到。

从实现机制上来说，NGINX 是基于 shared memory zone 来实现的，可以灵活的开辟大内存来实现很多 key 的存储，同时，基于 lru 的淘汰算法，也可以保证内存可控

shared memory zone 是 NGINX 内部的一个通用的底层组件，而 Envoy 还没有这类基建

从使用场景上来说，NGINX 主要用于南北向接入网关，防 DDOS/cc 攻击需求强烈，而基于 IP 的限流策略则是最常用的防攻击策略

而 Envoy 多用于东西向场景，流量来源多是可信的，限流策略主要是用于保护后端服务不被打爆，所以对于这种动态 key 的诉求相对没那么强烈

集群限流

Envoy 的 local ratelimit 虽然是本地限流，但是也可以配置为集群级别的限流效果

1.31.0 新增了 local_cluster_rate_limit 的配置，可以让 token 的限流值，按照 Envoy 集群数量来平均分配，并且随着 Envoy 实例数量自动调整

当前，这里有个假设前提是，流量在 Envoy 节点上是均匀的

NGINX 的 shared memory zone 是单机内共享的，不过商业版里，也增加了一个跨机同步的机制，这样也可以实现集群级别的限流

最后

个人观点，简单点评几句：

Envoy 的本地限流，好的是应用场景多，HTTP 请求，TCP 连接，TLS 握手 都可以用

NGINX 呢，优势是动态限流 key，用来防 cc，应对公网不可信的流量，确实很香

嗯，至少目前如此，后面 Envoy 加上动态限流 key，也不是太大的问题

上一篇 HTTP json 转 gRPC 中，我们提到了一起 Golang runtime panic，这篇就稍微展开介绍的

报错

单测的时候，运行倒是正常，跑压测的时候，很快就会出现 Golang runtime panic

比如：

1

runtime: marked free object in span 0x7fef96df8658, elemsize=24 freeindex=83 (bad use of unsafe.Pointer? try -d=checkptr)

这个是 Golang 的 GC 在 sweep 阶段，发现有一个内存块，标记被使用，也就是有一个指针指向这个内存块，但是，这个内存块同时也是被标记 free 的，不应该被使用的

简单说，就是有内存指针指向了 free 内存块，是个非法指针

原因

虽然 panic 的时候，会把所有 goroutine 的调用栈，都全部打印出来

但是，由于 panic 发生在 sweep 阶段，显然已经不是非法指针写入的时候了，调用栈并没有太多分析价值了

不过，好在我们是 demo 演示场景，代码本身比较简单，经过一番折腾，主要是 review 代码，发现坑在 copyHeaderMapToGo 中的这段：

1
2
3
4
5

len = value.length();
go_strs[i].n = len;
go_strs[i].p = go_buf;
memcpy(go_buf, value.data(), len); // NOLINT(safe-memcpy)
go_buf += len;

这里是将 C++ 侧保存的 header map，copy 到 Golang 提前准备好的内存中

其中涉及到两个操作：

1. 为 Golang string 的 p 指针和 n 长度赋值

2. 将字符串内容 copy 到 go_buf 内存块中

问题就出现在第一步，因为 value 有可能为空，那么 go_buf 有可能就已经是非法的了，超出了预定的总长度

刚好，我们压测的这个 grpc 场景，Golang 的 grpc server 总是会返回

1
2

grpc-status: 0
grpc-messages

grpc-message 这个 trailer 的 value 总是为空，所以，压测场景很容易就 panic 了

知道原因，修复方案也简单，当 len 为 0 时，我们直接跳过即可

这是已经合并的 PR: https://github.com/envoyproxy/envoy/pull/35930

骚操作

在 C 里面，修改 Golang 指针的值，是 Golang 不建议的玩法，可以说是实锤的骚操作

不过，我们这么玩也是理论上安全的，只是需要非常小心，玩不好就踩坑了

至于，为什么我们选择这种骚操作，主要还是在保证内存安全的前提下，还提供不错的性能，具体可以看之前的 Envoy Go 扩展之内存安全

最开始实现的时候，只考虑了 Golang string 的使用场景，因为长度为 0，那么指针地址就算是非法，也是会被忽略的

但是，到了 GC 环节，GC 是不看类型的，只看指针引用，所以就悲剧了

彩蛋

顺便在 copyHeaderMapToGo 中还发现了一处优化点：

1

auto value = std::string(header.value().getStringView());

这里的 std::string 是没有必要的，因为反正都要 copy 到 Golang 里面，C++ 侧再 copy 一次是没必要的了

于是，又有了这个 PR，简单场景压测了一把，Golang 的 header 初始化，可以有 10%+ 的提升，~400ns

当然，还有一些 Golang 侧的优化空间，后面有空再继续搞了