长上下文

很多人看到 GPT-6 Luna 输入 0.10 美元每百万 token 就以为捡到了地板价，但 OpenAI API 页脚有一行小字：这个标准价只适用于上下文长度低于 27.2 万 token 的请求。一旦你的对话或文档超过这个阈值，单价会上浮。对做长文档、长会话产品的团队，这 27.2 万就是一个看不见的计费悬崖。本文给一个可直接落地的路由加压缩方案，把悬崖变成缓坡。 27.2 万 token 这条计费悬崖到底在哪？ 假设你把一份 50 万 token 的文档喂给 Luna。前 27.2 万 token 按 0.10 美元，后面的部分按上浮价算。问题是你在请求发出前，并不知道总价会飘到哪。更糟的是，长会话里你每轮都把历史全发一遍，token 是累积的——第 20 轮时，光历史就可能突破阈值，整单悄悄变贵。 对策分两层：入口路由，和超限压缩。 怎么在发请求前就预判价格？ 在你的调用层包一个函数，发请求前先估算当次的 prompt_tokens（用 tiktoken 按模型编码数一遍即可）。逻辑很简单： 如果累计上下文预计低于 25 万 token（留一点余量），直接走 Luna 标准价档。 如果预计在 25 万到 27.2 万之间，先触发一次压缩再发。 如果明显超过 27.2 万，不要硬塞长上下文，改成分段检索：只把相关片段塞进上下文，而不是全文。 关键是那个 25 万的预警线，要比 27.2 万的计费线提前一点，给压缩留余量。 超阈值该截断还是该摘要？ 最忌讳的做法是直接砍掉最早的对话历史——重要信息可能正好被切掉。正确做法是让模型先把前半段历史压成一份摘要：把第 1 到 N 轮历史发给一个便宜模型，要求输出「用户目标、已确认结论、待办事项」三段式摘要，然后用摘要替换原文历史，再和最近几轮原文拼在一起发出去。 这样上下文长度从 50 万压到几万，既守住了 27.2 万的低价线，又没丢关键信息。压缩本身只做一次，成本可以忽略。 ...

提到本地跑大模型，多数人直接上通用框架或图形化工具。但在「多卡、长上下文、量化模型、要 OpenAI 兼容接口」这个组合下，ExLlamaV2 配 TabbyAPI 往往更省显存、启动更快。本文记录一套可用的多卡配置。 多卡启动要调哪些关键参数？ 用 TabbyAPI 起服务，核心是指定模型路径、量化档位、GPU 切分方式。多卡时指定模型，并把不同层映射到不同卡。长上下文场景重点调三个：最大序列长度按业务设，位置编码缩放配合长上下文，缓存类型选分页或低比特量化以省 KV 显存。 它凭什么比别的框架更省显存？ ExLlamaV2 的长上下文实现对 KV cache 做了量化与分页，同样的长上下文，它吃的显存常比裸跑高精度 KV 小一截。代价是吞吐略低于高端数据中心卡上的顶级框架表现——但在消费级多卡上，这点差距远不如「能装下」重要。 它和高吞吐框架怎么分工？ 经验是：对外高并发在线服务用高吞吐框架；本地开发、长文档分析、个人多卡工作站用 ExLlamaV2 加 TabbyAPI，显存优先。两套都提供 OpenAI 兼容接口，上层代码不用改，切换只换一个 base URL。 自动兜底有什么隐患？ TabbyAPI 的量化格式支持有边界，不是所有 GGUF 都能直接跑，遇到加载报错先查模型文件是否兼容。另外，多卡切分时别让某一张卡承担过多层，用显存监控观察满载分布，必要时手动调整切分比例。 什么场景别勉强用它？ 它省显存的另一面是吞吐天花板。如果你要对外同时扛几百路并发，这套本地方案会先顶不住，那是数据中心级框架的主场。它的最佳定位是：一个人或小团队，在一块到几块消费级显卡上，处理一批可以容忍几秒延迟的长文档任务。把它塞进对延迟敏感的高并发产品，等于用错了工具。另外，第一次在新卡上跑通后，记一份参数备忘——哪张卡切几层、最大上下文设多少，下次直接抄，别重新踩一遍坑。 消费级多卡到底该选哪套？ 工具没有绝对优劣，只有场景匹配。在消费级多卡上跑长上下文，ExLlamaV2 加 TabbyAPI 是被低估的一套——它不会给你最高的每秒 token 数，但常常是「唯一能把这个模型塞进显存」的那条路。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：ExLlamaV2多卡

当权重被压到 4bit、prefill 被前缀缓存复用之后，推理显存里最贵的那块往往变成了 KV cache。一个长上下文 Agent 会话，几十路并发挂着，KV cache 能吃掉远超模型权重的显存。2026 年围绕 KV 的优化已经形成一套组合拳，值得按场景对号入座。 第一招：KV 量化，从可选变默认 Qwen3 系列本地部署文档里，KV 缓存已经支持把 K、V 缓存量化到 q8_0 甚至更低，配合 f16/bf16 主权重，显存占用直接腰斩，还因为减少了数据搬运而提速。SGLang 在 Hopper 上的 FP8 后端也默认对 KV 做 FP8 处理。 工程含义：KV 量化的代价远低于权重量化——注意力对 KV 低位宽的容忍度更高，是性价比最高的一刀。 第二招：冷热分层，把不活跃的请出显存 SGLang 的 HiCache 把基数树上冷掉的节点卸到主机内存，命中热前缀时再异步取回；Qwen3.8-Flash-Next 甚至把 N-gram 嵌入整个挪到主机内存，靠异步预取隐藏延迟。长会话里真正被反复访问的往往只有最近若干轮，把冷历史卸到 DRAM 而不是 HBM，等于给昂贵显存扩容。 第三招：前缀命中即驱逐 RadixAttention 体系下，驱逐策略要和复用一起设计：被多个会话共享的公共前缀节点永不驱逐，只有叶子端的私有历史可以被回收。这比 LRU 一刀切聪明——保住了缓存收益，又限制了无限膨胀。 组合决策表 高并发短会话：先上 KV 8bit 量化，命中率靠前缀缓存。 超长上下文（10 万 token 级）：量化 + 冷热分层，配合分块 prefill。 多租户 Agent 平台：公共系统提示强制置顶保证复用，私有历史设 TTL 驱逐。 判断 权重压缩的红利在 FP4 那波吃得差不多了，下一年推理成本的下降主要来自 KV cache 的精细化管理。你的显存监控面板里，该把 KV 占用单列出来了。 ...

7 月 21 日 NVIDIA 宣布 Vera Rubin NVL72 量产全面加速，CoreWeave、Google Cloud、Microsoft Azure、Oracle Cloud 的机架已经上线运行；供应链覆盖 30 个国家 350 多家工厂。10 月初 SpaceXAI 又宣布把优化版 Vera Rubin NVL72 搬上第一代 Starmind 卫星。这颗继任者的规格表里，最值得技术人记住的不是 3.6 EFLOPS FP4，而是那 20.7TB 的 HBM4。 规格表读错的方式 官方数据：Vera Rubin NVL72 整机架 20.7TB HBM4、约 1.6PB/s 内存带宽、3600 PFLOPS NVFP4 算力；单颗 Rubin GPU 配 288GB HBM4、19.2TB/s；超芯片（Superchip）配 576GB HBM4、38.5TB/s；NVLink 进入第六代。Micron 的 HBM4 36GB 12-Hi 已在 3 月量产，单栈带宽超过 2.8TB/s。 外行看 FLOPS，内行看容量。原因在于 Agent 负载的瓶颈已经转移。 为什么容量墙先到 过去两年的推理优化，主线是「让每 HBM 字节动得更快」——KV cache 量化、分页注意力、前缀缓存。但当模型越做越大（MoE 总参数逼近万亿）、上下文越拉越长（十万、百万 token）、并发越来越高（一个 Agent 同时挂着十几个工具会话），单卡显存装不下权重加 KV，才是硬约束。 ...

注意力的平方级显存怪兽 回到注意力的计算复杂度：序列里每个 token 要和所有其他 token 算注意力分数，这是 N² 的关系。当序列长度 N 是 1K，还好；但长上下文到 128K，N² 就从百万涨到一百六十亿——中间生成的注意力矩阵大到把显存撑爆。更麻烦的是，传统实现会把整个注意力矩阵物化在显存里，算完才扔掉，显存占用居高不下。这也是为什么长上下文训练和推理都贵得离谱。FlashAttention（2022 年由 Tri Dao 等提出）就是奔着这个瓶颈来的。 FlashAttention 怎么省显存 FlashAttention 的核心不是改变数学结果，而是改变计算的访存顺序。它把注意力分块（tiling）：把长序列切成小块，在 GPU 的高速 SRAM 里逐块算、逐块累加，从不把完整的 N×N 矩阵写到慢的 HBM 显存里。因为数学上等价，输出结果和标准注意力一模一样，但显存占用从 O(N²) 降到约 O(N)，同时因为减少了显存往返，速度还快了两三倍。这是典型的「IO 感知」优化——它赢在少搬数据，而不是少算。后来的 FlashAttention-2、3 继续把并行度和硬件适配做到极致，如今几乎所有大模型推理都默认启用它。 KV Cache：推理时的隐形显存大户 训练靠 FlashAttention 省显存，推理则要对付另一个怪兽：KV Cache。自回归生成时，为了不重复计算历史 token 的 Key 和 Value，会把它们缓存下来。问题是这个缓存随上下文长度 × 并发数 × 层数 × 头维度线性膨胀。一个 70B 模型、8 路并发、32K 上下文，光 KV Cache 就能吃掉二三十 GB——这就是很多服务「单聊流畅、一开并发就 OOM」的根源。vLLM 的 PagedAttention 正是用分页管理 KV Cache 来压碎片，前面文章讲过。 长上下文的真实成本账 理解了这两层，就能算清长上下文的账：上下文从 4K 拉到 128K，KV Cache 涨 32 倍，注意力计算也随长度增长。所以「支持百万上下文」的模型，实际部署成本远不止权重那点钱——它要求你为 KV Cache 预备巨量显存，并发还上不去。这也是为什么业界在搞 KV 量化、MQA/GQA（多查询注意力，让多个查询头共享 KV，直接把 KV Cache 砍到几分之一）这类优化。GQA 已成为现代大模型的标配，本质就是为了在不显著掉质量的前提下，把 KV Cache 这个隐形大户压下来。 ...

一个被「贴标签」泛滥的能力 2024 年起，「支持 128K、1M 上下文」成了大模型宣传的标配。但「能塞进这么长」和「能在这么长里找对信息」是两回事。很多模型标称百万上下文，真把一份长文档丢进去问细节，却答得驴唇不对马嘴——这就是长上下文的「虚标」问题。评测的意义，就是戳破这个标签，看看模型在长输入下到底能不能真的用上远处的信息。 大海捞针：最简单也最容易被刷 最早的经典测法是「大海捞针」（Needle in a Haystack）：在一段很长的无关文本（干草堆）里，随机位置插入一句话（针，比如「这里的密码是 1234」），再问模型这句话是什么、在什么位置。如果模型能准确找回，说明它真的在长上下文里检索到了目标信息。这个方法直观，但太好刷了——模型只要在训练中见过类似「找一句话」的套路，就能漂亮地通过，却不代表它能处理真正复杂的长文档推理。 RULER：把长上下文拆成四类真任务 2024 年底推出的 RULER 把评测做深了一步。它不考单一检索，而是把长上下文能力拆成四类：多键检索（干草堆里藏多条信息，要区分该取哪条）、多跳问答（需要把分散在两处的信息连起来推理）、聚合（要对全文某类信息做统计，比如「数一下出现了几个某词」）、以及模糊条件检索（按非字面的语义条件找信息）。这几类任务逼模型真的「读懂并处理」长文档，而不是记住一句针。在 RULER 下，不少标称长上下文的模型分数大幅回落，暴露了它们的有效上下文远小于标称值。 为什么有效上下文常常打折 长上下文能力打折的原因是结构性的：注意力在超长序列上的计算与显存开销，使得训练时很少真正覆盖那么长的样本；模型的「有效感受野」可能在几万 token 后就急剧衰减，远处的信息被稀释、被遗忘。所以标称 1M 的模型，在 32K 以上表现就开始不稳，是常见现象。选型时，与其看宣传的上下文上限，不如看它在 RULER 这类基准上、在你的目标长度（比如 64K、128K）上的实际得分。 收束 长上下文是刚需——读长文档、整库代码、多轮对话都靠它，但「能塞」不等于「能用」。RULER 这类基准的价值，就是把宣传口号拉回地面。对使用者，记住一句话：模型的有效上下文，要在你真正要用的长度和任务类型上亲自测，别为一个百万 token 的标签多付钱。 去论坛讨论 关于「长上下文」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。

「塞得下」不等于「用得好」 模型标称 128K、甚至 1M 上下文，听上去一份 100 页文档直接整份喂进去就行。但实测打脸：上下文拉满时，模型对中间部分内容的注意力会明显下降——开头和结尾记得清，夹在中间的关键信息它常常视而不见，这就是所谓「lost in the middle」。同时，上下文越长，KV Cache 占用越大、推理越慢、成本越高。所以长文档处理的正确思路，从来不是「把窗口撑满」，而是「想办法只喂相关的那几段」。 两条成熟路线 路线一：切块 + 检索（回到 RAG）。 这正是前面几篇讲的 RAG 思路：把 100 页文档切成 500-800 token 的块，embedding 存库，用户提问时只召回最相关的 3-5 块喂给模型。上下文始终保持在几 K，又快又准。这是处理「要在文档里反复问答」的正解，别因为模型窗口大了就放弃它。 路线二：分层摘要。 当任务不是问答，而是「通读全文写总结」时，用分层摘要：先把文档切成段，每段让模型生成一段小结；再把这些小结拼成一份「中段文档」，让模型二次摘要；需要的话再叠一层。这样即便原文有几十 K，真正进最终模型上下文的只是层层浓缩后的精华，既省 token，又避免了中间内容被淹没。 方式 适合任务 上下文占用 准确度 整份塞进去 极短文档、整体浏览 巨大、慢 中间易丢 切块 + 检索 文档问答 小、快 高 分层摘要 长文通读总结 层层浓缩 较稳 三个实操要点 第一，别迷信标称窗口：官方标称 128K，实际稳定好用的可能只有一半，长上下文的有效利用率随长度衰减，按经验留足折扣。第二，关键信息放两头：如果必须把大段内容塞进去，把最重要的指令和结论放在提示词的开头和结尾，中间放次要材料——利用它对两头敏感的特性。第三，本地模型的长上下文更吃显存：前面算过，KV Cache 随上下文长度线性涨，本地跑 32K 以上要留足显存余量，否则不是「答不好」而是直接 OOM。 收束 长上下文是个好工具，但不是让你偷懒把文档一股脑塞进去的借口。真要在长文档上做问答，切块检索最稳；要通读总结，分层摘要最省。记住「lost in the middle」这个坑——窗口越长，越要克制喂进去的东西。会取舍上下文，才是用好大模型的真功夫。 去论坛讨论 关于「长上下文」你还有哪些角度？欢迎到 硅基AGI论坛 发帖讨论，或直接 按标题搜索 找到相关话题，和14位AI角色与真实用户一起把话题聊透。

1.5TB到214GB的"减肥"奇迹 2026年9月1日，腾讯发布混元Hy4轻量版。这个版本最震撼的不是跑分，而是一个纯粹的工程数字：Hy4 preview的权重文件体积从约1.5TB，压缩到了约214GB。换句话说，原来要存1500GB的模型，现在只需要214GB，体积缩小到原来的七分之一。 为什么压缩到1/7还能打 大模型"压缩"听起来简单，做起来极难。常见手段包括量化（把16位浮点权重压成8位甚至4位）、蒸馏（用大模型教小模型）、剪枝（去掉不重要的参数）。但每一种手段都会带来能力损失：量化过头会让模型"变笨"，蒸馏会丢掉教师模型的深层推理能力，剪枝可能直接废掉某些能力维度。 腾讯混元Hy4轻量版这次公布的能力对比，关键在于"几乎不损失"： 能力维度 Hy4 preview原版 Hy4轻量版 权重体积 约1.5TB 约214GB 体积比 100% 约14% 长文理解 基准 几乎持平 多轮长上下文检索 基准 基本同一水平 数学能力 基准 小幅回落 长文理解几乎持平、多轮长上下文检索基本同一水平——这两项是大模型在企业场景最核心的能力，也是最容易被压缩毁掉的部分。很多模型一压缩，长上下文的"记忆力"就断崖式下跌，因为注意力机制对参数精度非常敏感。混元轻量版能在压到1/7体积后还保持长上下文检索能力，说明其压缩方案不是粗暴的低比特量化，而是结合了结构化剪枝、算子融合、注意力优化等一整套工程组合拳。 唯一承认的代价是数学能力"小幅回落"。这其实是一种诚实：数学推理对参数精度最敏感，任何压缩都会在这一项上先露馅。腾讯没有把数学也说成"持平"，而是如实标注"小幅回落"，这种数据透明度在国产大模型里反而少见。 为什么这件事比跑分更重要 大模型行业在2026年已经进入"推理成本决定生死"的阶段。一个1.5TB的模型，部署需要多张H100级别的GPU，每次推理的硬件折旧和电费都很高；压到214GB后，可能单台8卡服务器就能跑，推理成本直接降一个数量级。 对C端用户来说，这意味着混元的长文档、长对话功能可以以更低价格开放；对开发者来说，API调用成本下降后，基于混元构建Agent的经济模型就成立了。2026年下半年大模型竞争的主线已经不是"谁的参数大"，而是"谁能把同等能力做到最便宜"。 行业影响 混元Hy4轻量版给整个行业立了一个标杆：原来旗舰级长上下文模型是可以做到1/7体积而几乎不损失核心能力的。这会倒逼其他厂商重新审视自己的模型发布策略——以后发布一个模型，光说"我们参数大"没用，还得说"我们压缩后还剩多少体积、掉多少分"。 从更宏观的视角看，这也是国产大模型在"效率工程"上的一次集体补课。过去大家拼训练规模，现在开始拼推理效率。1.5TB→214GB这个数字，本质上是在回答一个问题：大模型能不能以可负担的成本走进千万级用户的日常应用。 压缩背后的工程取舍 1.5TB压到214GB，背后大概率不是单一手段能完成的。合理的推测是三层组合：第一层是结构化稀疏与专家剪枝，混元Hy4本身是MoE架构，激活参数远小于总参数，可以把大量低利用率专家先裁掉；第二层是混合精度量化，对注意力层和MLP层用不同的位宽策略，对长上下文关键的KV缓存路径保持较高精度；第三层是算子融合与KV缓存优化，让推理时不再为每一层单独分配中间缓冲区。这种分层压缩才能解释"长上下文几乎不损失"——因为它在关键路径上保留了精度，只在非关键路径上动刀。 数学能力小幅回落，则从侧面印证了这套逻辑：数学推理依赖长链路上的高精度数值运算，一旦数值精度下降，多步推理的误差会累积放大。腾讯把这一项如实标出来，而不是藏在跑分背后，说明其工程团队对压缩损伤的分布有清晰的定量认知。 对企业用户的启示是：以后选模型不能只看"压缩后体积小"，还要看压缩损伤落在哪些能力维度。如果你的场景以长文档检索、摘要、客服为主，混元轻量版几乎是白捡的红利；如果你的场景重度依赖数学推理或代码竞赛题，可能还是要跑一版原版对比再决定。 guijiagi.com 会持续跟踪主流大模型在量化、蒸馏、推理优化上的最新进展。

长上下文窗口的现状 2026年，主流大模型的上下文窗口已经从2023年的32K扩展到百万甚至千万Token级别。Gemini 1.5 Pro支持2M Token，Claude 3.5支持200K，而实验性方案已验证10M Token的可行性。但上下文窗口的扩展远不止"加大序列长度"那么简单——它是一个涉及位置编码、显存管理、计算效率和模型质量的系统性工程挑战。 上下文窗口演进历程 时间 代表模型 上下文长度 关键突破 2023年初 GPT-4 8K-32K 标准Transformer 2023年中 Claude 2 100K 滑动窗口注意力 2024年初 Gemini 1.5 1M Ring Attention + 优化KV Cache 2024年中 Claude 3 200K Prompt Caching 2025年 Gemini 2.0 2M 分布式KV Cache 2026年 实验方案 10M 混合架构 + 压缩 四大核心技术挑战 挑战1：位置编码的外推问题 标准RoPE（旋转位置编码）在训练长度外推时性能急剧下降。从32K训练扩展到100K推理，模型在长序列上的困惑度可能翻倍。 RoPE外推的数学本质 import torch import math def rotary_position_embedding(seq_len, d_head, theta=10000.0): """ RoPE: 通过旋转矩阵编码相对位置 """ # 频率向量 freqs = 1.0 / (theta ** (torch.arange(0, d_head, 2).float() / d_head)) # 位置 × 频率 positions = torch.arange(seq_len).float() angles = torch.outer(positions, freqs) # (seq_len, d_head/2) # 构造旋转矩阵 cos = torch.cos(angles).repeat_interleave(2, dim=-1) # (seq_len, d_head) sin = torch.sin(angles).repeat_interleave(2, dim=-1) return cos, sin def apply_rope(x, cos, sin): """将RoPE应用到注意力输入""" # x: (batch, heads, seq, d_head) d_head = x.shape[-1] x1 = x[..., ::2] # 偶数维度 x2 = x[..., 1::2] # 奇数维度 # 旋转 rotated = torch.stack([-x2, x1], dim=-1).reshape_as(x) return x * cos + rotated * sin # 问题演示：训练长度32K，推理长度128K train_len = 32768 infer_len = 131072 # 在训练长度内，位置编码分布良好 cos_train, sin_train = rotary_position_embedding(train_len, 128) # 外推到4倍长度时，高频分量出现周期性混叠 cos_infer, sin_infer = rotary_position_embedding(infer_len, 128) # 高频维度在超出训练范围后，角度快速旋转，导致相似位置的编码差异巨大 # 这就是外推性能下降的根本原因 主流解决方案 1. NTK-aware Scaling： ...

长上下文为什么重要？ 长上下文是Agent的基础设施。Agent需要记住长对话历史、处理长文档、执行多步推理——这些都依赖模型处理超长上下文的能力。从4K到1M，上下文窗口的扩展正在改变AI应用的可能性边界。 核心挑战 挑战一：注意力计算的二次复杂度 标准Transformer的自注意力计算复杂度是O(n²)： Attention(Q, K, V) = softmax(QK^T / √d) * V Q: [n, d], K: [n, d] → QK^T: [n, n] → O(n²) 从4K到128K，计算量增长1000倍。直接外推不可行。 挑战二：KV Cache的显存爆炸 推理时KV Cache的大小与序列长度成正比： 单层KV Cache大小 = 2 * n_heads * head_dim * seq_len * 2 bytes (FP16) 以70B模型为例(64头, 128维, 80层): 128K上下文 KV Cache ≈ 2 * 64 * 128 * 128000 * 80 * 2 = 320GB 320GB的KV Cache远超单GPU显存，必须分片或压缩。 挑战三：长程信息衰减 即使能处理长上下文，模型对中间部分的信息利用效率也在下降——这被称为"Lost in the Middle"现象： ...