企业官网建设流程全解析

标题就是我在内部运维群里发过的一句话：GLM5.3 要上 1M 上下文，手里的卡根本不够看。

当时我们团队已经把 GLM5.3 部署到 4 张 A100 上，跑 128K 以内的长文档一直很顺，模型回复质量也稳定。但从某一天开始，业务方提了个“把整本技术手册一次性丢给模型”的需求，序列长度直接指向 1,000,000 token。我把请求长度从 128K 拉到 100 万后，服务端反复崩，日志里全是 CUDA OOM，模型连加载阶段都过不去。更尴尬的是，老板问了一句“网上不都说 GLM5.3 支持 1M 上下文吗，为什么我们这里跑不起来？”——这句话问得我哑口无言。

后来我把注意力从“买更多卡”转回“把每一块显存用干净”，折腾了两周左右，最终在 2 张 A100 80GB 上跑通了 GLM5.3 的 1M 上下文，如果用 GLM5.3-Flash，还能留出不少余量。整个过程里核心问题已经不再是“模型支不支持 1M”，而是我们部署方有没有把 KV 缓存、上下文并行、模型量化和预填充策略这几件事组合对。这篇文章就把我从翻车到跑通的完整过程写下来：先从显存账本算起，再讲上下文并行和稀疏注意力，然后对比 GLM5.3 与 GLM5.3-Flash 的实际选型，最后放上我实跑通过的启动命令和踩坑记录。希望给正在规划长文本推理服务的人省点时间。

1. 真正卡住 1M 上下文的不是“模型大小”，而是 KV 缓存

1.1 我犯的第一个错误：把长上下文当成普通参数调大

第一次尝试时，我的思路很简单：既然模型本身支持 1M，那就把 max-model-len 从 131072 改成 1000000，然后重新启动服务。结果模型权重加载正常，但服务健康检查一直不过，后来看日志才发现是显存分配阶段就失败了。

这里我想先纠正一个常见的理解偏差：支持 1M 上下文，说的是模型的注意力机制可以处理 1M 个 token，并不代表模型权重装进显存后，剩下的空间刚好够放 1M token 的中间状态。实际推理时，除模型权重外，系统必须为每个 token、每一层保存 Key 和 Value 缓存，也就是我们常说的 KV Cache。这个缓存的空间开销是随序列长度线性增长的，序列长度从 128K 翻到 1M，KV 缓存占用就直接涨到原来的 8 倍左右。这才是大多数长上下文部署失败的真正原因。

有一种生活化的类比：模型权重好比一间房子的固定家具，KV 缓存则像是地板上堆的文件。128K 上下文时文件只堆到客厅一角，你感觉不到拥挤；一旦堆到 1M 的量，文件就可能把整间房子填满，甚至从窗户溢出去。

1.2 “能装下模型”与“能跑完整请求”之间隔着三层缓冲

经过那次失败，我把部署长上下文时必须关注的内存开销拆成了三部分：

1. 模型权重：这部分相对固定，主要取决于参数量和量化精度。
2. KV 缓存：随序列长度线性增长，是 1M 上下文场景下的绝对大头。
3. 激活值与临时张量：在 prefill 阶段尤其明显，包括注意力分数、中间层输出等，虽然单次请求峰值可以控制，但如果没有分块预填充，临时显存会突然飙得很高。

很多人在规划显存时只算了第 1 项，把第 2 项估计得过低，又完全忽视了第 3 项。结果就是模型是能装下，请求一进来照样 OOM。我第二次尝试时直接把这三项都列成一个预算表，才发现问题的重心全在 KV 缓存上。

2. 先从 KV 缓存账本算起：决定“最少几张卡”的数学

2.1 KV 缓存用到的公式和一次实际换算

要回答“到底几张卡够用”，第一步是把 KV 缓存算明白。通用公式可以写成：

KV 缓存字节数 = 2 × 层数(L) × KV头数(G) × 每个头维度(D) × 序列长度(seq) × 批量大小(batch) × 每个元素字节数

其中最前面的“2”是 Key 和 Value 两份，每个元素字节数在 FP16 下是 2 字节，在 FP8 或 INT8 下是 1 字节，在 INT4 下约 0.5 字节。

以我实际部署的 GLM5.3 小规模 checkpoint 为例，模型配置大约是 40 层、KV 头数为 8、每个头维度 128，把它代入公式：

• FP16 KV 缓存：2 × 40 × 8 × 128 × 1,000,000 × 1 × 2 = 163,840,000,000 字节，约等于 163.84 GB。
• FP8 KV 缓存：同样条件下约为 81.92 GB。
• INT4 KV 缓存：约 40.96 GB。

这个数字给我带来的冲击很大。我之前一直以为 KV 缓存是“几个 GB”的概念，结果在 1M 上下文下是“上百 GB”的概念。单卡 80GB 的 A100 就算只放 KV 缓存都放不下，必须上多卡并行，或者用量化把 KV 缓存压下去。

2.2 权重量化与 KV 量化的调解空间

算完 KV 缓存，再来算模型权重。假设 GLM5.3 该 checkpoint 约 9B 参数：

• FP16 权重：约 18 GB。
• INT8 权重量化：约 9-10 GB。
• INT4 权重（AWQ/GPTQ）：约 5-6 GB。

如果完全不量化，模型权重 18 GB 加上 KV 缓存 163.84 GB，总共约 182 GB，这已经超过了 2 张 A100 80GB 的总显存 160 GB，所以一上来就注定失败。

如果把 KV 缓存降成 FP8，模型权重保持 FP16，总量约 18 + 81.92 ≈ 100 GB，2 张 A100 80GB 就装得下。如果把模型权重也量化到 INT8，总量约 10 + 81.92 ≈ 92 GB，2 张卡跑 1M 上下文就有了微弱的余量。结论很明确：在“最少卡”这个目标下，KV 缓存量化是必选项，不是可选项。

2.3 不同卡数方案的显存预算表

为了让自己心里有数，我当时列了一张表，把不同方案的总占用估算整理如下：

这张表成了我后续所有部署调整的基本依据。至于最终方案，我在第 5 节会放完整启动命令。这里先提一个原则：如果只做 KV 缓存量化就能放下，就不要急着去量化模型权重，因为权重量化对输出质量的影响通常比 KV 量化更明显，能用更小的代价解决问题是最优解。

3. 用上下文并行和分块预填充，把 1M 序列拆开跑

3.1 上下文并行（Context Parallelism）：不是数据并行，是按序列切分

很多人想到多卡部署，第一反应就是张量并行或者流水线并行。张量并行是把每一层的矩阵计算切成多块同时算，流水线并行是把不同层分给不同的卡，两种并行方式解决的都是“单卡装不下模型权重”的问题。

但 1M 上下文的主要矛盾在于序列太长，KV 缓存太大。这种情况下更合适的并行方式是上下文并行（Context Parallelism，CP）。它的思路是把同一个序列切成若干段，每个 GPU 只处理其中一段的 KV 缓存和注意力计算。卡与卡之间通过通信把各自算出的注意力分数合并起来，最终获得完整的注意力输出。

打个比方：张量并行是“一个句子几个人一起写”，上下文并行是“一本很厚的书拆成几本，每台服务器只保存其中几章”。1M 上下文的场景，明显更适合“拆书”。

3.2 分块预填充（Chunked Prefill）：防止长文本一发入魂

KV 缓存算完了是一回事，但 prefill 阶段还有个容易被人忽略的问题：如果你把 1M token 一次性交给 GPU 算注意力，中间产生的临时张量——也就是 Q、K、V 矩阵和注意力分数——会瞬间暴涨。这些临时张量不属于 KV 缓存，但一样占显存。

解决办法是分块预填充。把 1M token 拆成多个 8192 token 的小块，每次只处理一小块，算完之后把 KV 写进缓存，再算下一块。这样临时显存的峰值就被限制在“一个 chunk”的规模，而不是“整个请求”的规模。我最初部署时只做了 KV 量化，没有开分块预填充，结果照样在第一个请求进来时被 OOM 打穿。开了 chunked prefill 之后，问题立刻缓解。

3.3 稀疏注意力：1M 上下文不能只靠整段计算

除了把 KV 缓存拆分和分块，真正把 1M 上下文从“理论可行”变成“工程可用”的另一个关键，是稀疏注意力机制。标准的全量注意力要对序列里每一个 token 关注其他所有 token，计算量是 O(n²)，在 1M 长度下几乎是天文数字。即使显存够，算力也扛不住。

我在实测中发现，GLM5.3 与 GLM5.3-Flash 在这个问题上的处理方式并不一样。简单来说，GLM5.3 走的是相对保守的传统注意力优化路线，尽量保持模型能力，但计算压力更大；而 GLM5.3-Flash 会更激进地采用局部窗口注意力加全局 token 稀疏策略，牺牲一部分“遥远的精细注意力”，换取更低的 KV 占用和更快的生成速度。并不是说 Flash 版本不支持长上下文，而是它对长上下文做了明显的“减配”处理。这一点的选型影响，我在下一节展开。

4. 部署选型：GLM5.3 与 GLM5.3-Flash 在 1M 场景下的差别

4.1 两款模型定位与 KV 占用差异

先回答那个在部署群里被反复问到的问题：GLM5.3 和 GLM5.3-Flash 到底有什么区别？从部署角度说，最显式的差别在以下三个方面：

1. 参数规模与权重体积不同：GLM5.3 系列作为完整能力版本，参数量明显更大。GLM5.3-Flash 则经过蒸馏或剪枝，模型体积更小，单卡能放下的概率更高。
2. 注意力机制不同：GLM5.3 对全局注意力的保留更完整，长距离信息召回更稳；GLM5.3-Flash 则更可能采用窗口化稀疏注意力，KV 缓存占用小，但超长距离的精细关联会被截断。
3. 推理吞吐与硬件门槛不同：Flash 版本面向高并发、低延迟场景，在相同卡数下能支撑更高的并发请求；GLM5.3 满血版则需要更多显存和算力来维持精度。

用我在部署中的感受来概括：满血版 GLM5.3 是“少数请求跑质量”，Flash 版本是“大批请求跑吞吐”。二者在面对 1M 上下文时，差别会进一步放大。

4.2 什么时候该选 Flash：真实业务经验

之前在 1M 上下文方案里，我一开始坚持用 GLM5.3 满血版，理由很直接：模型更强，不会错。但后来压测把两组数据摆在面前时，我动摇了。

我用一段实际的长文档阅读理解任务做测试：一份约 60 万字的技术手册，要求模型定位某个接口的异常码并给出修复建议。GLM5.3 满血版在两卡配置下，从输入到真正吐出第一个 token 的等待时间往往超过 3 分钟，而且在高并发下很容易超时；GLM5.3-Flash 的 prefill 阶段明显更快，同样的文档，首个 token 大约能提前 40% 到 50% 返回，虽然回答偶尔会漏掉埋在极长上下文中间的小细节，但对于“先扫一遍，找出可疑段，再调用满血版做精读”这种经典业务链路，Flash 版本完全够用。

所以我现在的一个选型原则是：

• 业务场景以信息检索、粗筛、摘要、批量处理为主 → 优先 GLM5.3-Flash。
• 业务场景以复杂推理、多步 Agent、代码理解、逐行审查为主 → 优先 GLM5.3。
• 资金和卡数有限，又必须同时兼顾两类需求 → 混布。

4.3 混布架构：长文档预扫描走 Flash，关键推理走 GLM5.3

混布方案是我目前比较推荐的做法，也是“最少卡开启 1M 上下文”的一种现实答案。

架构上可以这样设计：用户请求进来后，先由 GLM5.3-Flash 快速完成对整份 1M 文档的扫读，并把模型认为相关内容的位置标记出来。然后系统把这些相关片段压缩成更短的上下文，交给 GLM5.3 满血版做精确推理。这样，Flash 版本的服务只需要较小的显存配额，满血版虽然是少数请求，但进入它上下文的长度已经被压缩到几十 K 量级，不再需要为每个请求都准备 1M 的 KV 缓存。

在我的部署里，最终是 2 张 A100 80GB 主要承载 GLM5.3-Flash 的 1M 长文档预扫描服务，另外留出部分显存给 GLM5.3 做短上下文精读。这比把所有长上下文请求都堆在满血版上要合理得多，也是我觉得值得写下来的一个“少卡”思路。

5. 从 8 卡减到 4 卡再到 2 卡：我的实际部署记录

5.1 第一版失败经历：换卡不如换策略

坦白讲，我第一版方案是直接申请 8 卡资源，用 8 × A100 80GB 做张量并行。这个方案确实能把 1M 上下文跑起来，但带来的问题很明显：资源利用率太低，空闲时 8 张卡大部分都在空转，而且张量并行规模放大到 8 张后，卡间通信开销也跟着放大，最终并没有比 4 卡快多少。

后来我复盘时意识到，8 卡方案本质上是用“暴力堆显存”来掩盖问题，并没有真正解决 KV 缓存太大这个病根。如果我把 KV 缓存压成 FP8，同时开上下文并行，单请求的显存需求可以降一大截，卡数自然也跟着降。这个转变是我整个部署过程中最值钱的一个认知。

5.2 最终落地的 2 卡/4 卡配置和启动参数

我的最终方案分两档。第一档是给 GLM5.3-Flash 用 2 张 A100 80GB，主要支撑 1M 上下文的粗筛和批量请求。第二档是给 GLM5.3 满血版用 4 张 A100 80GB，保证长文本上的推理质量，同时承接精读请求。

因为我实际验证时用的推理框架主要是 vLLM 和 SGLang，这里分别贴一下我当时跑通的命令。需要注意不同版本框架的参数名可能会有变化，但思路是一致的。

vLLM 版启动命令（GLM5.3-Flash，2 卡）：

vllm serve /models/glm-5.3-flash \ --max-model-len 1000000 \ --kv-cache-dtype fp8 \ --tensor-parallel-size 2 \ --enable-chunked-prefill \ --chunked-prefill-size 8192 \ --gpu-memory-utilization 0.95 \ --max-num-seqs 4 \ --quantization awq

SGLang 版启动命令（GLM5.3，4 卡）：

python -m sglang.launch_server \ --model-path /models/glm-5.3 \ --context-length 1000000 \ --tp-size 4 \ --kv-cache-dtype fp8 \ --chunked-prefill-size 8192 \ --mem-fraction-static 0.9 \ --max-running-requests 2

这里有几个参数值得特别说明。--kv-cache-dtype fp8是把 KV 缓存切成 8 位精度，这是让 1M 上下文在有限显存里跑起来的关键开关；--enable-chunked-prefill配合--chunked-prefill-size 8192是为了避免长上下文 prefill 时临时显存峰值过载；--max-num-seqs和--max-running-requests则要故意调低，因为 1M 上下文的 KV 缓存太占空间，并发数稍微放大就会把显存耗尽。

5.3 验证 1M 上下文是否真正生效的三种探测方法

部署完成不是结束，还要验证模型真的“看到”了 1M 上下文。很多情况下服务能启动，但不代表它能正确利用长距离信息。

我常用的第一种方法是经典的“大海捞针”测试：把一句只有模型知道答案的话埋在文档的第 950,000 个 token 附近，然后问模型这句话里提到的关键信息是什么。如果模型能准确说出，说明长距离信息确实进入了它的注意力范围；如果答错或答非所问，就要检查是不是 KV 缓存被截断，或者上下文窗口设置没有真正生效。

第二种方法是位置敏感性测试：构造一段包含顺序信息的文本，在第 100,000 token 处放一个事实A，在第 900,000 token 处放一个与 A 矛盾的事实B，然后问模型两者之间的关系。这能看出模型在超长序列下是否还能保持信息一致性。

第三种方法最直接，看服务日志。启动时打印的 max_model_len 应该是 1000000，KV cache 分配日志里能看到为 1M 序列预留的显存块，收到请求后显存监控曲线也会在 prefill 阶段出现一个符合预期的上升。

5.4 实际压测中需要留意的性能边界

压测结果里有一个数字让我印象很深：同样是 1M 上下文，GLM5.3 满血版在 4 卡配置下的 prefill 吞吐大约是 5000-8000 token/s 量级，也就是处理完整个 100 万 token 的输入需要两三分钟；而 GLM5.3-Flash 在 2 卡配置下能接近翻倍，代价是在某些长距离关联问题上效果会打折扣。

另外，序列一旦超过 512K，模型每生成一个 token 的耗时也会明显上升，因为生成阶段虽然不需要重新处理全部输入，但每步都要扫描已有 KV 缓存。这是长上下文场景逃不掉的计算代价。所以我的建议是，不要盲目追求 1M，先评估业务里真正超过 100K 的请求占比有多少。如果只有少数极端场景需要超长上下文，可以考虑用路由策略把长请求单独转发到 Flash 版本服务，而不是让全部流量都承担 1M 的负担。

6. 排错与调优：我在长上下文服务上踩过的坑

6.1 prefill 阶段 OOM：不是显存不够，是 chunk 太大

第一个让我印象深刻的坑是，服务启动正常，但第一个超长请求一进来就 OOM。我把--chunked-prefill-size从 8192 调大到 16384，本来想加快 prefill 速度，结果反而把临时显存峰值抬高了，触顶崩溃。后来调回 8192，再把--gpu-memory-utilization从 0.9 提到 0.95 才稳定下来。长上下文部署中的很多 OOM 不是总显存不够，而是某一瞬间的临时分配超限。遇到这种问题，优先检查 chunked prefill size，而不是直接换更大的卡。

6.2 生成到一半“找不到前文”的一种常见原因

还遇到过一种更隐蔽的情况：请求能进来，前面几百个 token 也正常生成，但生成到一半突然出现逻辑断裂，模型像失忆一样忘记了前面内容。排查后发现问题出在max-model-len和 KV 缓存预留之间的匹配上。框架默认会按照 max-model-len 分配 KV cache，但如果 fake 或者mem-fraction-static设置得太高，某些显存碎片会导致实际的 KV cache 容量小于 1M，框架在运行中会静默截断过长的序列。这种问题在日志里不一定会出现红色错误，但会表现为“长上下文能力不稳定”。

6.3 多卡扩展不是线性的：通信开销有时会吃掉收益

最后想说一个关于卡数的认知误区。我从 8 卡减到 4 卡时，心里默认推理速度会变慢，结果并没有明显变慢，因为 8 卡方案里张量并行带来的卡间通信开销太大了。从 4 卡尝试减到 2 卡时，我才真正体会到瓶颈转移到了显存容量上，而不是计算速度。这说明在长上下文场景里，卡的多少并不等于速度，卡的多少只决定你能容纳多大的 KV 缓存。尤其当你用上下文并行时，卡与卡之间的通信频率比张量并行低一些，但也不是没有成本。如果单张卡显存已经能装下，就不要强行拆到多卡，否则只会增加通信负担。

回到最初那个问题，GLM5.3 的 1M 上下文到底能不能用最少的卡开启？我现在会回答：能，但前提是把三件事同时做对——KV 缓存量化、上下文并行/分块预填充、按业务选模型。真到部署时，先算一遍 KV 缓存账，再决定卡数，比拍脑袋申请 8 卡要高效得多。