国产长文本大模型对比：谁能处理百万 Token 上下文

处理超长文档——合同、研究报告、代码库、法律文书——是企业 AI 落地的高频需求。2025 年以来，国产大模型在长上下文能力上迅速跟进，通义千问 Turbo 已支持 1M tokens，Kimi 和文心也达到 128k+。本文横向对比各厂商长文本模型，帮你选出最合适的方案。

国产长文本模型横向对比

模型	最大上下文	价格定性	多模态	开源	典型场景
通义千问 Qwen-Long	1M tokens	长上下文定价，按实际 token 计费	否（文本）	是（Qwen-7B-Long）	超长文档、书籍级分析
通义千问 Qwen-Turbo	1M tokens	高性价比轻量档	否	是	批量长文档处理
Kimi moonshot-v1-128k	128k tokens	按 token 计费	是（图文）	否	PDF/合同解析，多文档对比
文心 ERNIE Speed-128k	128k tokens	速度型，价格低	是（图文）	否	高并发长文摘要
GLM-4-Long	128k tokens	有免费额度	是（图文）	是	长代码库分析，学术阅读
DeepSeek-V3	64k tokens	国产最低价	否	是	中等长度文档，成本敏感

上下文窗口包含输入+输出 token 总量，超长文档应预留输出空间。

场景化选型建议

超过 64k tokens 的文档（书籍/完整合同/大代码库） → 优先 通义千问 Qwen-Long（1M 上下文，成本可控）

PDF 解析 + 图表识别 → Kimi moonshot-v1-128k（支持图文上传，文档理解成熟）

高并发批量长文摘要（成本敏感） → 文心 ERNIE Speed-128k 或 Qwen-Turbo

64k 以内 + 极致性价比 → DeepSeek-V3（国产最低价，效果不输旗舰级）

长代码库分析 + 工具调用 → GLM-4-Long（工具调用最规范，有免费额度测试）

长上下文为什么又贵又慢：底层发生了什么

选型表看着简单，但你真上手跑一次 100 万 token 的输入就会发现两个直观现象：等待时间明显变长，账单也比处理短文本贵不少。这背后不是厂商在故意”恰饭”，而是 Transformer 架构本身的代价。

模型推理分两个阶段：**prefill（预填充）**和 decode（解码）。prefill 阶段要把你输入的全部 token 一次性喂给模型，计算每个 token 对其它所有 token 的注意力（Self-Attention），这一步的计算量和显存占用大致随输入长度的平方增长——输入翻倍，计算量可能涨到 4 倍左右。这就是为什么”发送请求到收到第一个字”的等待时间（也叫首字延迟，Time To First Token）在长文档场景下会明显变长：模型还在算 attention，压根没到”吐字”那一步。

decode 阶段（逐字生成回答）本身速度和短文本差别不大，但它依赖 prefill 阶段生成的 KV Cache（每个已处理 token 的 Key/Value 向量缓存）。输入越长，KV Cache 占的显存越大，1M token 级别的输入哪怕用了显存优化技术，缓存也是实打实的大头开销——这部分成本最终会摊到你的账单里，所以长上下文定价通常比短上下文贵，且计费是按”实际吃进去的 token 数”而不是按次数，这也是为什么官方文档反复强调”输入 token 是成本主力”。

知道这个原理，你就明白两条实操准则：第一，能截断的地方尽量截断，不要把整份 200 页 PDF 无脑塞进去，先自己筛一遍再喂给模型；第二，同样的钱，短平快的高频调用往往比一次性超长调用更划算，除非任务真的需要模型看到全文的关联关系（比如找一份合同里前后矛盾的条款）。

长上下文 vs RAG：别无脑选贵的那个

很多人一遇到”文档很长”就条件反射选 1M 上下文模型，其实这是两条路线，各有适用边界：

维度	直接塞长上下文	RAG（检索增强生成）
适用场景	需要模型理解全文逻辑关系（合同前后矛盾条款、小说人物关系）	从海量文档中定位某个具体事实（知识库问答、FAQ）
单次成本	高，且随文档长度线性增长	低，只检索相关片段送入模型
首字延迟	长（prefill 计算量大）	短（送入模型的 token 少）
工程复杂度	低，读文件直接扔进 prompt	高，需要向量库、分段策略、召回调优
”遗忘”风险	有 Lost in the Middle 问题	召回不准会漏掉关键片段

判断依据很简单：如果你的问题是”总结这份 200 页报告的核心矛盾点”，模型必须看到全文的上下文关系，这时候 RAG 切片反而会把逻辑链打断，长上下文模型是对的选择；如果你的问题是”我们 2025 年 Q3 的差旅报销标准是多少”，这本质是一次精准检索，硬塞长上下文既贵又慢，RAG 明显更合适。实际项目里更常见的是混合方案：先用 RAG 粗筛出可能相关的几个章节，再把这几个章节（而不是全文）塞进长上下文模型做精细分析，兼顾成本和准确率。

接入示例：长文档摘要（OpenAI 兼容写法）

from openai import OpenAI

# 通义千问长文本示例
client = OpenAI(
    api_key="sk-xxxxxxxxxxxxxxxx",     # 阿里云 DashScope API Key
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)

with open("contract.txt", "r", encoding="utf-8") as f:
    long_document = f.read()

response = client.chat.completions.create(
    model="qwen-long",                 # 或 qwen-turbo / moonshot-v1-128k
    messages=[
        {
            "role": "system",
            "content": "你是专业合同审查律师，请提取关键条款、风险点与付款节点。"
        },
        {
            "role": "user",
            "content": long_document
        }
    ],
    max_tokens=4096,
)
print(response.choices[0].message.content)

这段代码看着简单，但有三个容易踩坑的细节值得展开讲：

1. 为什么用 open(..., encoding="utf-8") 而不是直接 open(path)。Windows 环境默认编码经常不是 UTF-8，如果文档里混了中文、英文、特殊符号（合同里常见的 §、℃、全角标点），不显式指定编码会在读文件这一步就抛 UnicodeDecodeError，跟模型接口毫无关系，纯粹是本地代码的坑，但排查起来容易被误认为是”模型报错”。
2. max_tokens=4096 限制的是输出，不是输入。这里最容易搞混：你的合同全文可能有几十万 token，那是输入部分，走的是上下文窗口配额；max_tokens 只限制模型这次”回答”最多吐多少 token。如果你要模型输出一份详细的逐条审查报告，4096 可能不够用，报告写到一半被截断，这时候要么调大 max_tokens，要么让模型先输出摘要要点、再分批追问细节。
3. long_document 直接塞进 content 是最简单但最不稳妥的写法。生产环境建议在拼 prompt 前先做一次粗略的 token 估算（用 Token 计数器 或对应厂商的 tokenizer），如果预估超过模型上下文上限，提前截断或分段处理，而不是让请求发出去之后被服务端拒绝——那时候你已经浪费了一次网络往返，用户体验也差。

切换 Kimi 只需修改两行：

base_url="https://api.moonshot.cn/v1"
model="moonshot-v1-128k"

各家厂商的 OpenAI 兼容网关本质上都是把自家推理服务包了一层 OpenAI 协议的”翻译层”，所以业务代码基本不用改，只需要换 base_url、api_key、model 三个参数——这也是为什么建议你写业务代码时把这三个值抽成配置项而不是硬编码，方便后续 A/B 测试不同厂商的效果和成本。

真实踩坑：长文本调用常见报错与排查

长上下文场景比普通短对话更容易踩到边界情况，下面几个是实际接入时高频遇到的问题：

报错类似 Error code: 400 - context_length_exceeded 或”输入长度超过模型限制” 根因很直接：你的输入 token 数（文档本身 + system prompt + 历史对话）超过了模型声明的上下文窗口。排查步骤：① 先用 Token 计数器量一下实际长度，别凭感觉估；② 确认调用的是长上下文版本的模型名（比如 qwen-turbo 和走 1M 上下文的长文本档位在计费和限制上可能不同，具体以官方模型列表为准）；③ 如果确实超限，做分段处理或换 RAG 方案，而不是死磕加大 max_tokens——那个参数管不了输入。

首字延迟很高，甚至看起来像”卡住了” 前面讲过原理，prefill 阶段计算量随长度增长，几十万 token 的输入首字延迟到几秒甚至十几秒都是正常现象，不是网络问题。应对方式是把 stream=True 打开，让用户至少看到”模型在动”，而不是傻等一个完整响应，用户体验会好很多：

response = client.chat.completions.create(
    model="qwen-long",
    messages=[{"role": "user", "content": long_document}],
    max_tokens=4096,
    stream=True,
)
for chunk in response:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

偶发超时（Timeout 或连接被重置） 长文本请求本身耗时长，链路上任何一环（本地网络、代理、负载均衡超时设置）都可能提前掐断连接。稳妥做法是给客户端设置比默认值更长的超时，并配合指数退避重试，而不是遇到超时就立刻原样重发（可能造成同一份文档被重复计费两次）：

import time
from openai import APITimeoutError, APIConnectionError

def call_with_retry(client, **kwargs):
    for attempt in range(3):
        try:
            return client.chat.completions.create(timeout=120, **kwargs)
        except (APITimeoutError, APIConnectionError) as e:
            wait = 2 ** attempt  # 1s, 2s, 4s 指数退避
            print(f"第 {attempt + 1} 次调用超时，{wait}s 后重试：{e}")
            time.sleep(wait)
    raise RuntimeError("重试 3 次仍失败，检查网络或降级为分段处理")

429（限流）报错 长文本请求本身占用配额更多，高并发场景下比短对话更容易先撞到速率限制。上面这套指数退避同样适用于 429，区别是最好在重试前额外等待久一点（比如从 3 秒起跳），避免在限流窗口内反复撞墙。

价格说明

截至 2026-06，以官方公示为准：

• 长上下文模型按实际 token 计费，输入 token 通常多于输出，成本主要来自输入；
• 建议对超长文档先用 RAG（分段检索）降低输入量，仅在必须全文理解时用 1M 上下文模式；
• 可用 价格对比表 估算不同文档长度的实际成本。

常见问题

长上下文模型会”遗忘”文档开头的内容吗？ 这是”Lost in the Middle”问题，模型对文档首尾内容关注度高于中间部分。应对策略：① 将关键信息放在 Prompt 开头或结尾；② 用 RAG 结合全文检索定位关键段落；③ 选用 Kimi 等专为文档理解优化的模型。

Kimi 和通义千问 Qwen-Long 在文档理解上有何差异？ Kimi 对 PDF 版式（表格、图注、多栏排版）的解析能力更优，适合结构复杂的合同和报告；Qwen-Long 在纯文本超长场景和多轮对话保持上下文方面更有优势。

超长上下文调用很慢怎么办？ 超长上下文首次调用（prefill 阶段）延迟较高属正常现象。可启用流式输出（stream=True）让用户看到第一个 token 的时间缩短；对批量任务使用 Batch API 异步处理，不占用实时配额。

---

相关阅读：国产大模型 API 全景指南 · 国产多模态模型对比 · 通义千问 API Key 获取

分类导航：国产模型专题

实用工具：价格对比表 · Token 计数器