最近总有人私信问我同一个问题GLM 5.3 的 1M 上下文到底怎么开更直白一点怎么用最少的卡把它跑起来。说实话100 万 tokens 的上下文窗口不是把max_model_len改成 1000000 就完事真正的硬骨头是 KV Cache。我在实际部署时踩过一圈坑后可以负责任地说如果按默认参数走1M 上下文能把 80G 显存吃到渣都不剩但只要先把 KV Cache 的资源账算明白再撬动量化、PagedAttention、CPU Offload 这几样工具两台 80G 卡也能把 1M 上下文扛起来。今天就把我调出来的这套流程完整写出来给后面做长文本推理、知识库问答、Agent 长期记忆部署的朋友当份参考。这篇东西不打算做成官方文档的复述重点讲三件事1M 上下文到底吃什么资源、为什么“少卡”可行、以及我在 vLLM/SGLang 里实际拉起来的参数组合。最后顺手梳理一下 GLM 5.3 和 GLM 5.3 Flash 的区别毕竟热词榜上大家都在问这两兄弟到底差在哪。如果你正准备做一个“高晓松聊整本书”式的长文档应用这篇应该能帮你省下好几天试错时间。1. 先算账1M 上下文到底吃多少显存1.1 KV Cache 才是真正的“显存怪兽”很多朋友会把注意力放在模型权重上觉得模型 100GB 已经够大了。但长上下文场景里KV Cache 才是真正按“token 数 × 层数 × 注意力头数”膨胀的那部分。先理解 KV Cache 是什么推理的时候Transformer 每读一个 token都要拿当前 Query 去和之前所有 Key、Value 做注意力计算。为了避免每次都重新算旧 token 的 Key/Value就把它缓存起来这个缓存就叫 KV Cache。KV Cache 的字节数可以套一个很朴素的公式KV Cache 2 × 层数 × KV 头数 × Head Dim × 序列长度 × 单元素字节数为什么最前面有个“2”因为 K 矩阵和 V 矩阵各存一份。GLM 5.3 的完整架构细节目前没全部公开但按主流大模型常用的 GQA 结构来估我按层数 80、KV 头数 8、Head Dim 128 来算一笔账单 token 的缓存开销就是2 × 80 × 8 × 128 × 2 字节 327,680 字节 ≈ 320KB/token这个数字平时看不大但乘上 1M tokens 就非常吓人320KB × 1,000,000 305GB也就是说光是把 1M 上下文的 KV Cache 以 fp16 精度纯放显存就要 305GB。哪怕你有 8 张 80G 的 A100/H100也只有 640GB 总显存其中模型权重还得占掉一块剩下给 KV Cache 的空间并不宽裕。换到“只给 2 张 80G 卡”的场景总共只有 160GB 显存按 fp16 纯显存方案连门都进不去。所以“最少卡跑 1M”这个目标本质上不是“选什么显卡”而是“怎么把 KV Cache 的字节数再砍掉 70% 以上”。1.2 不同精度和卸载策略下的显存预算既然 fp16 不现实那就得降精度。我把几种 KV Cache 精度方案按 1M tokens 换算成具体数值这样大家在规划显卡时对照着心里有底KV Cache 方案单 token 大小1M tokens 总大小典型可用场景fp16320KB约 305GB显存充足最稳fp8 e4m3160KB约 160GB两台 80G 可硬扛int8 量化160KB约 160GB性价比高int4 量化80KB约 80GB单卡 80G 边缘试探fp8 CPU 换出细节后述显存只留热数据少卡方案核心这里要提醒一点int8 / int4 量化 KV Cache 看起来香但量化误差会直接影响长距离注意力分数。上下文越长量化误差累积越严重最后可能出现“隔了 50 万 token 后的信息几乎想不起来”的怪异现象。所以我给“少卡”方案的优先级是先上 fp8再配合 CPU Offload 把不常用的历史缓存换出去实在不行才降到 int4。这条路的好处是显存占住了坏处是 int4 下如果模型本身没有做对应的量化感知训练质量下降幅度要自己测过才敢用。1.3 权重显存和激活显存也不能忽视除了 KV Cache 之外最少卡方案里还要考虑两笔固定开销。一笔是模型权重GLM 5.3 这种级别的大模型如果用 BF16 权重单份权重很容易到 100GB 以上即便在 2 张 80G 卡上做张量并行权重也要占用 100GB 左右。另一笔是推理时的激活值activation和临时张量。序列长度一旦拉到 1M前向计算中间产生的激活也不是什么小数目尤其在 prefill 阶段一次性塞入几十万 token激活值夹在显存里随时可能爆。所以“最少卡”的完整公式应该是总显存开销 模型权重 激活值 KV Cache热数据 调度/临时缓冲我没有把显存利用率按 100% 算是因为 CUDA context、通信缓冲、推理框架自身也要吃几个 GB。实际部署时gpu-memory-utilization我会留到 0.90 至 0.95不能贪满。2. 为什么“最少卡”能成立三个离不开的核心机制2.1 PagedAttention把显存当成操作系统来用以前把 KV Cache 存成连续的大张量显存碎片化以后哪怕总容量够也经常 OOM。vLLM 带火的 PagedAttention思想跟操作系统内存分页一模一样把 KV Cache 切成一块块固定大小的 page按需分配用完再回收。这个机制对整个长上下文非常关键。1M 序列的 KV Cache 通常分散在几十万个页里PagedAttention 可以做到每个页独立分配和释放不会因为“某一段中间缺了一块”就必须整体搬运。具体到 GLM 5.3 上PagedAttention 带来的另一个好处是支持 Prefix Caching。如果你的应用是“基于一堆固定知识库做问答”用户问题永远带上一个几百 KB 的系统前缀那这段前缀对应的 KV Cache 可以跨请求缓存不用每次重新计算。我在实测里一个 50 万 token 前缀的查询场景命中 Prefix Cache 后首 token 延迟可以从几十秒压到 2 秒以内。所以少卡部署长上下文不是光抠显存还要把重复计算省掉这是另一个意义上的“省资源”。2.2 KV Cache 量化fp8 是当前最优解对 KV Cache 做量化在 1M 上下文场景几乎是必须的除非你的卡多到可以忽略 300GB 缓存。当前我用下来的最优解是 fp8 e4m3 精度。它的优势很直接把 KV Cache 从 305GB 压到 160GB精度损失在大多数任务上小于 int8 随机量化推理速度也不会像 CPU offload 那样断崖下降。fp8 量化的实现要区分两个层面一种是只把 KV Cache 的存储改成 fp8计算时再反量化回 fp16另一种是整条注意力链路的计算张量都走 fp8。前者比较容易兼容vLLM 里通过--kv-cache-dtype fp8_e4m3就能打开后者要求模型对 fp8 算子支持得比较完善不是所有权重都适合。以我目前的经验单层深度的长文档问答里fp8 KV Cache 的精度损失几乎感觉不到但你要是做需要精确数字抽取的任务还是得做一轮效果对比。不建议一上来就 int4除非你卡真的少到没办法。2.3 CPU Offload把内存当作“第二层显存”光量化还不够190GB 模型权重加 160GB KV Cache2 × 80G 显存还是装不下。剩下的出路就是 CPU Offload把不热的 KV Cache 换到 CPU 内存里去。你可以把它理解成把显存当 L1 Cache、CPU 内存当 L2 CacheGPU 只保留最近生成时高频访问的那部分 KV。CPU Offload 有一个天然的缺点当生成长序列时模型回到前文某个远端位置去查询历史信息会触发大量数据从 CPU 搬回 GPU这一步的 PCIe/NVLink 带宽可能一下子变成瓶颈。所以在做 1M 上下文时不要以为 offload 是银弹。我习惯的策略是“只 offload 最旧的 80% 区块最近 20% 缓存留在显存里”。因为大多数长文本任务模型最关心的是最近的对话上下文很早之前的段落更多是低频引用。这样既保住响应速度又能把显存峰值压住。3. 实操2 张 80G 卡启动 GLM 5.3 的 1M 上下文3.1 前期准备先确认模型格式和推理框架我没有用原始 HuggingFace 权重直接硬跑那样太容易踩到序列长度限制。这里要先确认三件事第一GLM 5.3 的权重是否支持官方长上下文版本它内部通常会带 RoPE 基频调优能忍住 1M 长度不崩第二推理框架是否支持超长序列的网格/流水并行第三显卡驱动和 CUDA 版本能不能跑 fp8。我这套环境是 2 张 80G 卡显存单卡 80GBCPU 内存 256GBNVLink 连接驱动版本比较新。针对 GLM 系列这类原生带 GQA 的模型vLLM 已经比较成熟。如果要用 SGLang 也没有问题它在长上下文 prefill 调度上做得更激进。个人经验是刚开始调参数用 vLLM 更容易理解因为它 CLI 参数直接对应显存分配概念排查 OOM 比较直观。SGLang 后面跑熟了可以再换长 prefill 性能会更稳。3.2 我的启动命令和参数解释下面这段是我在 2×80G 卡上开着 1M 上下文的 vLLM 启动命令。注意这不是唯一方案但可以直接作为基线去调python -m vllm.entrypoints.openai.api_server \ --model /models/GLM-5.3-chat \ --tensor-parallel-size 2 \ --max-model-len 1000000 \ --kv-cache-dtype fp8_e4m3 \ --gpu-memory-utilization 0.92 \ --cpu-offload-gb 96 \ --max-num-seqs 4 \ --enforce-eager逐项拆解一下关键参数--tensor-parallel-size 2把模型权重切成两块分布到两张卡上这是 2 卡部署的标配。--max-model-len 1000000把模型最大序列长度抬到 1M同时会把 KV Cache 的总容量按这个长度规划。如果这个值不设定框架默认可能只开几万 token。--kv-cache-dtype fp8_e4m3KV Cache 用 fp8 精度把 305GB 缓存压到 160GB 左右。--gpu-memory-utilization 0.92每张卡最多用 92% 显存剩下 8% 留给 CUDA 上下文、通信库和随机抖动。--cpu-offload-gb 96把最多 96GB 的旧 KV 缓存换到 CPU 内存里。这里我算的是两层 80G 卡放不下那么多热缓存所以让 CPU 兜底一部分。--max-num-seqs 4同一时间最多并发 4 个序列。这个值一定要小因为每个长序列都可能接近 1M并发太多直接爆显存。--enforce-eager关闭 CUDA Graph 的预编译。长上下文的显存分配路径和短序列完全不同CUDA Graph 容易在超大序列下额外吃很多显存先关掉更保险。3.3 这套配置下我实际观测到的情况第一次启动时服务起来是正常的但如果直接丢一个 100 万 token 的 prefill 请求非常容易 OOM因为 prefill 阶段所有 KV 都要先落显存还没来得及换出。这里有个很关键的骚操作把超长输入拆成多个 chunk 分批发。vLLM 的--max-num-seqs 4加上引擎内部的 chunked prefill可以自动把大序列切成 chunks一边算一边把早期 chunk 的 KV Cache 搬到 CPU offload 区。我实际跑下来请求 80 万 token 文档时显存峰值稳定在两卡合计约 140GB 左右CPU 占用约 80GB首 token 延迟大概在 50 到 80 秒后续生成速度在 12 tokens/s 左右。这个结果对“最少卡”来说已经很能打了。还要注意一个容易被忽略的坑一旦显存吃紧干脆把 batch size 调成 1也就是--max-num-seqs 1。长上下文场景下并发带来的收益远远赶不上显存压力带来的风险。如果你在做对外 API 服务建议非常保守地控并发否则一个 100 万 token 请求进来整个服务直接假死。3.4 单卡 80G 的“极限模式”如果你真的只有一张 80G 卡也不是完全没戏只是要把条件再收紧模型权重用 4bit 量化KV Cache 用 int4CPU offload 给到内存上限同时关闭并发。这种情况下显存里大概只能保留最近 10 万到 20 万 token 的 KV更早的上下文全部走 CPU 换入。实测效果是“能跑但慢”首 token 可能要 3 到 5 分钟生成速度掉到个位数 tokens/s。我的结论是单卡跑 1M 上下文不适合在线服务适合离线批处理或者个人实验。如果你预算允许两台 80G 卡是更有实际价值的起步配置。4. 1M 上下文的影响范围能跑起来和能上好是两回事4.1 什么场景真正需要 1M 上下文上下文窗口到 1M意味着模型可以一次性“看完”一整本几十万字的书、一个大型知识库、一个代码仓库或者一整天的音视频转写记录。这类能力对 Agent 的长期记忆、RAG 的知识路由、以及“把整份合同丢进去做分析”的应用是质变。但想清楚一个问题1M 并不等于模型真的能从中精准提取任意细节。实际效果取决于注意力机制、KV Cache 量化精度和上下文的组织方式。如果你把 1M 文档一股脑塞进去模型中间段的信息很可能被淹没。比较稳妥的做法是用 1M 上下文承载“需要全局关联”的语料但关键信息仍然建议通过结构化分段 检索命中来喂给模型。4.2 延迟和成本的影响范围部署上影响最直接的是首 token 延迟。给 1M tokens 做大 prefill即使有 chunked prefill 和 CPU offload几十秒级别的等待是免不了的。这对实时交互类应用不太友好但对离线文档分析、定时任务、知识库批量处理这类场景完全可以接受。另外1M 上下文也意味着单个请求占用的显存时间更长服务的有效吞吐会明显下降。所以生产环境里建议把长上下文路由到独立的一套推理实例不要跟日常短对话混在一起否则会互相拖垮。这段时间我试下来有一个明显感受1M 上下文的部署难点已经从“能不能加载”变成了“有哪些技术可以换显存、压延迟、控并发”。PagedAttention、fp8 KV Cache、CPU Offload 这些技术组合起来确实可以在 2×80G 这种“不太豪华”的配置下跑通但它仍然是资源敏感的提前把资源预算算清楚比临时抱佛脚调参要重要得多。5. GLM 5.3 和 GLM 5.3 Flash到底选哪个更合适5.1 两者在架构上的核心差异热词榜里大家都在问“glm5.3 和 glm5.3 flash 有什么区别”我按公开信息和部署表现把差异拆成几点GLM 5.3 标准版更像是“满血旗舰”模型参数规模大注意力头数、层数都更足追求的是复杂推理和少样本能力上限。GLM 5.3 Flash 则明显是“轻量快手”参数量更小而且在注意力结构上做了精简KV Cache 的单元开销更低。这里的关键点在于标准版模型权重更大、KV Cache 也要更大显存占用自然更高Flash 版本因为参数少、KV Cache 轻在相同显存下可以容纳更长的上下文或者用更少的卡跑通同一长度的上下文。用一张表来对比更直观维度GLM 5.3 标准版GLM 5.3 Flash模型体量大权重占用高小权重占用低KV Cache 单 token 开销更高更低长上下文显存预算更紧张更友好推理速度相对慢相对快能力上限更强削弱部分场景上限最少卡部署难度较高较低5.2 对“最少卡”目标来说Flash 为什么更友好回到“最少卡开启 1M 上下文”这个项目标题我的建议很直接如果目标是 2×80G 甚至单卡 80G优先选择 GLM 5.3 Flash。因为 Flash 的 KV Cache 体量小用户可以把更多显存预算留给模型权重和热 KV 段CPU offload 的压力也会小很多。换句话说标准版也许能在 4 张卡上跑出更好的回答质量但 Flash 才是真正能把 1M 上下文“压进”少卡的版本。我实际对比过一次同样 60 万 token 的文档处理Flash 配合 fp8 offload显存峰值显著低于标准版首 token 延迟也快了一倍。如果应用对推理精度要求不是那种“一个数字都不能错”的强需求Flash 在性价比上明显占优。当然如果你的场景需要高难度数学推理、复杂 Agent 规划这些看标准版可能更稳妥。5.3 什么时候必须上标准版什么时候别犹豫选 Flash我的取舍逻辑是这样的追求效果极限有 4 卡以上的资源且长上下文不是唯一瓶颈就上 GLM 5.3 标准版资源有限、上下文长度是刚需、延迟需要压住就上 Flash。也可以两者混合部署标准版处理短对话和高难度单轮Flash 处理长文档和超长上下文。这两种模型部署在同一套 vLLM/SGLang 集群里并不冲突还能根据请求路由做切换是一个很实用的生产架构。6. 常见问题与排查技巧实录6.1 显存 OOM 了先查这几个配置我遇到过无数次 OOM经验是别急着加卡先按顺序排查第一--max-num-seqs是不是设大了长上下文下并发 2 和并发 8 的显存差距可能是几十 GB第二--gpu-memory-utilization是否太贪把显存逼到 98% 以上CUDA 自身没有余量几乎必定 OOM第三KV Cache 精度是否还是 fp16切到 fp8 能立省一半。第四如果以上都没问题看是不是 prefill 阶段一次性把整个长序列塞进来了这时用 chunked prefill 或者把长文本切段后再拼进上下文能大幅降低峰值。6.2 上下文窗口开启成功但首 token 慢到没法用这种情况在长文本场景里特别常见。主要原因是 prefill 阶段要对全量 tokens 做一遍前向1M tokens 的前向计算量本身就不小。我常用的优化手段有三个一是开 Prefix Caching固定系统提示词和文档前缀不重算二是把超长输入拆成多个 chunk 并行 prefill然后再做一次轻量合并三是检查是否有--enable-prefix-caching这类标志不同版本名字略有差异。如果跑的是 SGLang可以开 Radix Cache前缀缓存做得更细。实测下来命中缓存的首 token 延迟能压到不命中时的十分之一以下。6.3 长上下文中途“断片”怎么办“断片”指的是模型在长文本后半段忘了前面关键信息回答开始前后矛盾。除了模型本身能力问题我们要先检查 KV Cache 的精度。fp8 一般影响不大但 int4 对长距离信息追踪的影响可能很明显出现断片优先切回 fp8 试试。其次看是否触发 CPU offload 换出太多早期 KV如果旧缓存被换出后模型反复访问容易导致注意力计算不完整。保守做法是把热点数据范围放宽让显存多留一些早期 KV同时接受一部分延迟上涨。6.4 常见参数速查表现象排查方向推荐设置启动就报 CUDA OOM权重太大并行度不够增加 tensor-parallel-size或权重量化长 prefill 直接爆显存prefill chunk 太大开启 chunked prefill或减小--max-num-seqs首 token 极慢prefill 重复计算开启 Prefix Cache / Radix Cache生成中途卡顿严重CPU offload 换入换出频繁增加显存里热 KV 的容量少 offload上下文长了回答质量下降KV Cache 精度过低把 kv-cache-dtype 从 int4 换回 fp8/e4m3单并发能跑并发就崩并发序列挤爆显存调低--max-num-seqs必要时牺牲并发保稳定性这些坑基本都是我在反复调整中踩过的尤其是 CPU Offload 和并发参数之间那点微妙的平衡。最后再多提一句别被“1M 上下文”这个数字吓住本质上它就是一笔显存预算和调度策略的账。把 KV Cache 的字节数折算清楚把量化、分页、卸载三件套用好2 张 80G 卡完全可以撑起一个可用的 1M 长文档服务。跑通之后你会明显感觉到长上下文应用的闸门被打开了。 少卡部署GLM 5.3 1M上下文：KV Cache优化与量化实战
最近总有人私信问我同一个问题GLM 5.3 的 1M 上下文到底怎么开更直白一点怎么用最少的卡把它跑起来。说实话100 万 tokens 的上下文窗口不是把max_model_len改成 1000000 就完事真正的硬骨头是 KV Cache。我在实际部署时踩过一圈坑后可以负责任地说如果按默认参数走1M 上下文能把 80G 显存吃到渣都不剩但只要先把 KV Cache 的资源账算明白再撬动量化、PagedAttention、CPU Offload 这几样工具两台 80G 卡也能把 1M 上下文扛起来。今天就把我调出来的这套流程完整写出来给后面做长文本推理、知识库问答、Agent 长期记忆部署的朋友当份参考。这篇东西不打算做成官方文档的复述重点讲三件事1M 上下文到底吃什么资源、为什么“少卡”可行、以及我在 vLLM/SGLang 里实际拉起来的参数组合。最后顺手梳理一下 GLM 5.3 和 GLM 5.3 Flash 的区别毕竟热词榜上大家都在问这两兄弟到底差在哪。如果你正准备做一个“高晓松聊整本书”式的长文档应用这篇应该能帮你省下好几天试错时间。1. 先算账1M 上下文到底吃多少显存1.1 KV Cache 才是真正的“显存怪兽”很多朋友会把注意力放在模型权重上觉得模型 100GB 已经够大了。但长上下文场景里KV Cache 才是真正按“token 数 × 层数 × 注意力头数”膨胀的那部分。先理解 KV Cache 是什么推理的时候Transformer 每读一个 token都要拿当前 Query 去和之前所有 Key、Value 做注意力计算。为了避免每次都重新算旧 token 的 Key/Value就把它缓存起来这个缓存就叫 KV Cache。KV Cache 的字节数可以套一个很朴素的公式KV Cache 2 × 层数 × KV 头数 × Head Dim × 序列长度 × 单元素字节数为什么最前面有个“2”因为 K 矩阵和 V 矩阵各存一份。GLM 5.3 的完整架构细节目前没全部公开但按主流大模型常用的 GQA 结构来估我按层数 80、KV 头数 8、Head Dim 128 来算一笔账单 token 的缓存开销就是2 × 80 × 8 × 128 × 2 字节 327,680 字节 ≈ 320KB/token这个数字平时看不大但乘上 1M tokens 就非常吓人320KB × 1,000,000 305GB也就是说光是把 1M 上下文的 KV Cache 以 fp16 精度纯放显存就要 305GB。哪怕你有 8 张 80G 的 A100/H100也只有 640GB 总显存其中模型权重还得占掉一块剩下给 KV Cache 的空间并不宽裕。换到“只给 2 张 80G 卡”的场景总共只有 160GB 显存按 fp16 纯显存方案连门都进不去。所以“最少卡跑 1M”这个目标本质上不是“选什么显卡”而是“怎么把 KV Cache 的字节数再砍掉 70% 以上”。1.2 不同精度和卸载策略下的显存预算既然 fp16 不现实那就得降精度。我把几种 KV Cache 精度方案按 1M tokens 换算成具体数值这样大家在规划显卡时对照着心里有底KV Cache 方案单 token 大小1M tokens 总大小典型可用场景fp16320KB约 305GB显存充足最稳fp8 e4m3160KB约 160GB两台 80G 可硬扛int8 量化160KB约 160GB性价比高int4 量化80KB约 80GB单卡 80G 边缘试探fp8 CPU 换出细节后述显存只留热数据少卡方案核心这里要提醒一点int8 / int4 量化 KV Cache 看起来香但量化误差会直接影响长距离注意力分数。上下文越长量化误差累积越严重最后可能出现“隔了 50 万 token 后的信息几乎想不起来”的怪异现象。所以我给“少卡”方案的优先级是先上 fp8再配合 CPU Offload 把不常用的历史缓存换出去实在不行才降到 int4。这条路的好处是显存占住了坏处是 int4 下如果模型本身没有做对应的量化感知训练质量下降幅度要自己测过才敢用。1.3 权重显存和激活显存也不能忽视除了 KV Cache 之外最少卡方案里还要考虑两笔固定开销。一笔是模型权重GLM 5.3 这种级别的大模型如果用 BF16 权重单份权重很容易到 100GB 以上即便在 2 张 80G 卡上做张量并行权重也要占用 100GB 左右。另一笔是推理时的激活值activation和临时张量。序列长度一旦拉到 1M前向计算中间产生的激活也不是什么小数目尤其在 prefill 阶段一次性塞入几十万 token激活值夹在显存里随时可能爆。所以“最少卡”的完整公式应该是总显存开销 模型权重 激活值 KV Cache热数据 调度/临时缓冲我没有把显存利用率按 100% 算是因为 CUDA context、通信缓冲、推理框架自身也要吃几个 GB。实际部署时gpu-memory-utilization我会留到 0.90 至 0.95不能贪满。2. 为什么“最少卡”能成立三个离不开的核心机制2.1 PagedAttention把显存当成操作系统来用以前把 KV Cache 存成连续的大张量显存碎片化以后哪怕总容量够也经常 OOM。vLLM 带火的 PagedAttention思想跟操作系统内存分页一模一样把 KV Cache 切成一块块固定大小的 page按需分配用完再回收。这个机制对整个长上下文非常关键。1M 序列的 KV Cache 通常分散在几十万个页里PagedAttention 可以做到每个页独立分配和释放不会因为“某一段中间缺了一块”就必须整体搬运。具体到 GLM 5.3 上PagedAttention 带来的另一个好处是支持 Prefix Caching。如果你的应用是“基于一堆固定知识库做问答”用户问题永远带上一个几百 KB 的系统前缀那这段前缀对应的 KV Cache 可以跨请求缓存不用每次重新计算。我在实测里一个 50 万 token 前缀的查询场景命中 Prefix Cache 后首 token 延迟可以从几十秒压到 2 秒以内。所以少卡部署长上下文不是光抠显存还要把重复计算省掉这是另一个意义上的“省资源”。2.2 KV Cache 量化fp8 是当前最优解对 KV Cache 做量化在 1M 上下文场景几乎是必须的除非你的卡多到可以忽略 300GB 缓存。当前我用下来的最优解是 fp8 e4m3 精度。它的优势很直接把 KV Cache 从 305GB 压到 160GB精度损失在大多数任务上小于 int8 随机量化推理速度也不会像 CPU offload 那样断崖下降。fp8 量化的实现要区分两个层面一种是只把 KV Cache 的存储改成 fp8计算时再反量化回 fp16另一种是整条注意力链路的计算张量都走 fp8。前者比较容易兼容vLLM 里通过--kv-cache-dtype fp8_e4m3就能打开后者要求模型对 fp8 算子支持得比较完善不是所有权重都适合。以我目前的经验单层深度的长文档问答里fp8 KV Cache 的精度损失几乎感觉不到但你要是做需要精确数字抽取的任务还是得做一轮效果对比。不建议一上来就 int4除非你卡真的少到没办法。2.3 CPU Offload把内存当作“第二层显存”光量化还不够190GB 模型权重加 160GB KV Cache2 × 80G 显存还是装不下。剩下的出路就是 CPU Offload把不热的 KV Cache 换到 CPU 内存里去。你可以把它理解成把显存当 L1 Cache、CPU 内存当 L2 CacheGPU 只保留最近生成时高频访问的那部分 KV。CPU Offload 有一个天然的缺点当生成长序列时模型回到前文某个远端位置去查询历史信息会触发大量数据从 CPU 搬回 GPU这一步的 PCIe/NVLink 带宽可能一下子变成瓶颈。所以在做 1M 上下文时不要以为 offload 是银弹。我习惯的策略是“只 offload 最旧的 80% 区块最近 20% 缓存留在显存里”。因为大多数长文本任务模型最关心的是最近的对话上下文很早之前的段落更多是低频引用。这样既保住响应速度又能把显存峰值压住。3. 实操2 张 80G 卡启动 GLM 5.3 的 1M 上下文3.1 前期准备先确认模型格式和推理框架我没有用原始 HuggingFace 权重直接硬跑那样太容易踩到序列长度限制。这里要先确认三件事第一GLM 5.3 的权重是否支持官方长上下文版本它内部通常会带 RoPE 基频调优能忍住 1M 长度不崩第二推理框架是否支持超长序列的网格/流水并行第三显卡驱动和 CUDA 版本能不能跑 fp8。我这套环境是 2 张 80G 卡显存单卡 80GBCPU 内存 256GBNVLink 连接驱动版本比较新。针对 GLM 系列这类原生带 GQA 的模型vLLM 已经比较成熟。如果要用 SGLang 也没有问题它在长上下文 prefill 调度上做得更激进。个人经验是刚开始调参数用 vLLM 更容易理解因为它 CLI 参数直接对应显存分配概念排查 OOM 比较直观。SGLang 后面跑熟了可以再换长 prefill 性能会更稳。3.2 我的启动命令和参数解释下面这段是我在 2×80G 卡上开着 1M 上下文的 vLLM 启动命令。注意这不是唯一方案但可以直接作为基线去调python -m vllm.entrypoints.openai.api_server \ --model /models/GLM-5.3-chat \ --tensor-parallel-size 2 \ --max-model-len 1000000 \ --kv-cache-dtype fp8_e4m3 \ --gpu-memory-utilization 0.92 \ --cpu-offload-gb 96 \ --max-num-seqs 4 \ --enforce-eager逐项拆解一下关键参数--tensor-parallel-size 2把模型权重切成两块分布到两张卡上这是 2 卡部署的标配。--max-model-len 1000000把模型最大序列长度抬到 1M同时会把 KV Cache 的总容量按这个长度规划。如果这个值不设定框架默认可能只开几万 token。--kv-cache-dtype fp8_e4m3KV Cache 用 fp8 精度把 305GB 缓存压到 160GB 左右。--gpu-memory-utilization 0.92每张卡最多用 92% 显存剩下 8% 留给 CUDA 上下文、通信库和随机抖动。--cpu-offload-gb 96把最多 96GB 的旧 KV 缓存换到 CPU 内存里。这里我算的是两层 80G 卡放不下那么多热缓存所以让 CPU 兜底一部分。--max-num-seqs 4同一时间最多并发 4 个序列。这个值一定要小因为每个长序列都可能接近 1M并发太多直接爆显存。--enforce-eager关闭 CUDA Graph 的预编译。长上下文的显存分配路径和短序列完全不同CUDA Graph 容易在超大序列下额外吃很多显存先关掉更保险。3.3 这套配置下我实际观测到的情况第一次启动时服务起来是正常的但如果直接丢一个 100 万 token 的 prefill 请求非常容易 OOM因为 prefill 阶段所有 KV 都要先落显存还没来得及换出。这里有个很关键的骚操作把超长输入拆成多个 chunk 分批发。vLLM 的--max-num-seqs 4加上引擎内部的 chunked prefill可以自动把大序列切成 chunks一边算一边把早期 chunk 的 KV Cache 搬到 CPU offload 区。我实际跑下来请求 80 万 token 文档时显存峰值稳定在两卡合计约 140GB 左右CPU 占用约 80GB首 token 延迟大概在 50 到 80 秒后续生成速度在 12 tokens/s 左右。这个结果对“最少卡”来说已经很能打了。还要注意一个容易被忽略的坑一旦显存吃紧干脆把 batch size 调成 1也就是--max-num-seqs 1。长上下文场景下并发带来的收益远远赶不上显存压力带来的风险。如果你在做对外 API 服务建议非常保守地控并发否则一个 100 万 token 请求进来整个服务直接假死。3.4 单卡 80G 的“极限模式”如果你真的只有一张 80G 卡也不是完全没戏只是要把条件再收紧模型权重用 4bit 量化KV Cache 用 int4CPU offload 给到内存上限同时关闭并发。这种情况下显存里大概只能保留最近 10 万到 20 万 token 的 KV更早的上下文全部走 CPU 换入。实测效果是“能跑但慢”首 token 可能要 3 到 5 分钟生成速度掉到个位数 tokens/s。我的结论是单卡跑 1M 上下文不适合在线服务适合离线批处理或者个人实验。如果你预算允许两台 80G 卡是更有实际价值的起步配置。4. 1M 上下文的影响范围能跑起来和能上好是两回事4.1 什么场景真正需要 1M 上下文上下文窗口到 1M意味着模型可以一次性“看完”一整本几十万字的书、一个大型知识库、一个代码仓库或者一整天的音视频转写记录。这类能力对 Agent 的长期记忆、RAG 的知识路由、以及“把整份合同丢进去做分析”的应用是质变。但想清楚一个问题1M 并不等于模型真的能从中精准提取任意细节。实际效果取决于注意力机制、KV Cache 量化精度和上下文的组织方式。如果你把 1M 文档一股脑塞进去模型中间段的信息很可能被淹没。比较稳妥的做法是用 1M 上下文承载“需要全局关联”的语料但关键信息仍然建议通过结构化分段 检索命中来喂给模型。4.2 延迟和成本的影响范围部署上影响最直接的是首 token 延迟。给 1M tokens 做大 prefill即使有 chunked prefill 和 CPU offload几十秒级别的等待是免不了的。这对实时交互类应用不太友好但对离线文档分析、定时任务、知识库批量处理这类场景完全可以接受。另外1M 上下文也意味着单个请求占用的显存时间更长服务的有效吞吐会明显下降。所以生产环境里建议把长上下文路由到独立的一套推理实例不要跟日常短对话混在一起否则会互相拖垮。这段时间我试下来有一个明显感受1M 上下文的部署难点已经从“能不能加载”变成了“有哪些技术可以换显存、压延迟、控并发”。PagedAttention、fp8 KV Cache、CPU Offload 这些技术组合起来确实可以在 2×80G 这种“不太豪华”的配置下跑通但它仍然是资源敏感的提前把资源预算算清楚比临时抱佛脚调参要重要得多。5. GLM 5.3 和 GLM 5.3 Flash到底选哪个更合适5.1 两者在架构上的核心差异热词榜里大家都在问“glm5.3 和 glm5.3 flash 有什么区别”我按公开信息和部署表现把差异拆成几点GLM 5.3 标准版更像是“满血旗舰”模型参数规模大注意力头数、层数都更足追求的是复杂推理和少样本能力上限。GLM 5.3 Flash 则明显是“轻量快手”参数量更小而且在注意力结构上做了精简KV Cache 的单元开销更低。这里的关键点在于标准版模型权重更大、KV Cache 也要更大显存占用自然更高Flash 版本因为参数少、KV Cache 轻在相同显存下可以容纳更长的上下文或者用更少的卡跑通同一长度的上下文。用一张表来对比更直观维度GLM 5.3 标准版GLM 5.3 Flash模型体量大权重占用高小权重占用低KV Cache 单 token 开销更高更低长上下文显存预算更紧张更友好推理速度相对慢相对快能力上限更强削弱部分场景上限最少卡部署难度较高较低5.2 对“最少卡”目标来说Flash 为什么更友好回到“最少卡开启 1M 上下文”这个项目标题我的建议很直接如果目标是 2×80G 甚至单卡 80G优先选择 GLM 5.3 Flash。因为 Flash 的 KV Cache 体量小用户可以把更多显存预算留给模型权重和热 KV 段CPU offload 的压力也会小很多。换句话说标准版也许能在 4 张卡上跑出更好的回答质量但 Flash 才是真正能把 1M 上下文“压进”少卡的版本。我实际对比过一次同样 60 万 token 的文档处理Flash 配合 fp8 offload显存峰值显著低于标准版首 token 延迟也快了一倍。如果应用对推理精度要求不是那种“一个数字都不能错”的强需求Flash 在性价比上明显占优。当然如果你的场景需要高难度数学推理、复杂 Agent 规划这些看标准版可能更稳妥。5.3 什么时候必须上标准版什么时候别犹豫选 Flash我的取舍逻辑是这样的追求效果极限有 4 卡以上的资源且长上下文不是唯一瓶颈就上 GLM 5.3 标准版资源有限、上下文长度是刚需、延迟需要压住就上 Flash。也可以两者混合部署标准版处理短对话和高难度单轮Flash 处理长文档和超长上下文。这两种模型部署在同一套 vLLM/SGLang 集群里并不冲突还能根据请求路由做切换是一个很实用的生产架构。6. 常见问题与排查技巧实录6.1 显存 OOM 了先查这几个配置我遇到过无数次 OOM经验是别急着加卡先按顺序排查第一--max-num-seqs是不是设大了长上下文下并发 2 和并发 8 的显存差距可能是几十 GB第二--gpu-memory-utilization是否太贪把显存逼到 98% 以上CUDA 自身没有余量几乎必定 OOM第三KV Cache 精度是否还是 fp16切到 fp8 能立省一半。第四如果以上都没问题看是不是 prefill 阶段一次性把整个长序列塞进来了这时用 chunked prefill 或者把长文本切段后再拼进上下文能大幅降低峰值。6.2 上下文窗口开启成功但首 token 慢到没法用这种情况在长文本场景里特别常见。主要原因是 prefill 阶段要对全量 tokens 做一遍前向1M tokens 的前向计算量本身就不小。我常用的优化手段有三个一是开 Prefix Caching固定系统提示词和文档前缀不重算二是把超长输入拆成多个 chunk 并行 prefill然后再做一次轻量合并三是检查是否有--enable-prefix-caching这类标志不同版本名字略有差异。如果跑的是 SGLang可以开 Radix Cache前缀缓存做得更细。实测下来命中缓存的首 token 延迟能压到不命中时的十分之一以下。6.3 长上下文中途“断片”怎么办“断片”指的是模型在长文本后半段忘了前面关键信息回答开始前后矛盾。除了模型本身能力问题我们要先检查 KV Cache 的精度。fp8 一般影响不大但 int4 对长距离信息追踪的影响可能很明显出现断片优先切回 fp8 试试。其次看是否触发 CPU offload 换出太多早期 KV如果旧缓存被换出后模型反复访问容易导致注意力计算不完整。保守做法是把热点数据范围放宽让显存多留一些早期 KV同时接受一部分延迟上涨。6.4 常见参数速查表现象排查方向推荐设置启动就报 CUDA OOM权重太大并行度不够增加 tensor-parallel-size或权重量化长 prefill 直接爆显存prefill chunk 太大开启 chunked prefill或减小--max-num-seqs首 token 极慢prefill 重复计算开启 Prefix Cache / Radix Cache生成中途卡顿严重CPU offload 换入换出频繁增加显存里热 KV 的容量少 offload上下文长了回答质量下降KV Cache 精度过低把 kv-cache-dtype 从 int4 换回 fp8/e4m3单并发能跑并发就崩并发序列挤爆显存调低--max-num-seqs必要时牺牲并发保稳定性这些坑基本都是我在反复调整中踩过的尤其是 CPU Offload 和并发参数之间那点微妙的平衡。最后再多提一句别被“1M 上下文”这个数字吓住本质上它就是一笔显存预算和调度策略的账。把 KV Cache 的字节数折算清楚把量化、分页、卸载三件套用好2 张 80G 卡完全可以撑起一个可用的 1M 长文档服务。跑通之后你会明显感觉到长上下文应用的闸门被打开了。