1M 上下文 0.10 入场:5 模型长文档屠夫榜

1M 上下文 0.10 入场:5 模型长文档屠夫榜

适用读者:想在长文档场景里直接调 Qwen / GLM / Kimi / DeepSeek / Claude 这些 1M 上下文旗舰 API 做合同 / 论文 / 代码仓全文推理的开发者
阅读时长:约 12 分钟
测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)

一、为什么 2026 年 Q3 长文档场景突然值得重新讲

七月初我把一份真实业务合同塞进了 prompt——这是某 SaaS 公司 2025 年和三家渠道方签的代理协议加补充函,总共 21 万字。第一次切 RAG:embed + 召回 + 重排 + Claude Sonnet 4.6 总结,token 账单跑下来 50 美元。第二周我把合同原文不切分,通过炻光 AI 接入管理平台统一接入 deepseek-v4-flash 的 1M 上下文窗口,输出同样质量的摘要,token 成本砸到 0.02 美元。

这个差距让我把过去两年默认的"RAG 切 512 token 再召回"流程翻出来重新审视了一下。2026 年 Q3 这一波,1M 上下文从"实验室 demo"变成了"能进生产"的工程选项,价格屠夫榜前 5 的模型单次输入单价已经下探到 ¥0.10/1M tokens 级别。我把手里 5 款支持 1M 长上下文的旗舰模型按"屠得动 RAG 切片链路"这个维度排了一遍,这就是这篇文章的由来。

需要先说清楚,这是一篇只看 1M 长文档场景的屠夫榜,不是综合能力评测。如果你的输入通常 8K 以内,直接看普通 200K 上下文档位的对比更合适。

二、1M 上下文是什么,RAG 切片为什么会被屠

1M token 上下文听起来是个数字游戏,但落到工程上至少意味着三件事:

• 整本书可塞:英文 50 万汉字 ≈ 75 万 token,1M 窗口足够吞下一本中等长度的学术专著或一整份 200 页带图的 PDF(纯文本部分)。

• 跨章节指代不丢:不再需要担心 RAG 召回阶段漏掉"第三章提到的张三在第七章的身份变化"这种长距离依赖,模型直接看到全貌。

• 省略召回链路:不需要 vector DB、不需要 chunking、不需要 rerank,整段 prompt 一次送进 API,工程链路砍掉 60%。

但 1M 上下文不是免费午餐。我测试过程中踩过几个坑:

1. 首 token 延迟暴涨:从 8K 到 1M,TTFT(首 token 返回时间)不是线性增长,而是 5-10 倍跃升,部分模型甚至出现 30 秒以上冷启动。

2. 命中价格阶梯:很多模型对 >200K token 的输入有专门的"长上下文倍数",实际计费不是简单的 input_price × token 数。

3. KV cache 命中率下降:如果你的请求模式是"同一系统 prompt + 不断追加对话历史",长上下文的 cache 命中率会迅速劣化,反而比 RAG 还贵。

简单说:1M 直灌是特定屠夫场景下的屠夫,不是万能屠夫。

三、5 款 1M 上下文旗舰参数屠夫榜

我把这 5 款模型按"屠得动 RAG"的潜力排了个榜,所有价格按 ¥/1M tokens 计,基于 2026 年 7 月公开价格快照。

屠度打分是我个人经验值,主要看"同质量摘要任务下,单次成本相比传统 Claude + RAG 切片链路的下降倍数",以及"延迟是否还在线可接受范围"。

几个值得展开的点:

deepseek-v4-flash:这次屠夫榜的最低价屠夫。它的输入单价 ¥0.10/1M tokens 已经不是"促销价"而是"日常价",而且 1M 上下文不收额外倍数。我测试了一份 18 万字的合同总结,输入 920K token + 输出 1.2K token,账单 ¥0.092。在长文档"全文摘要 + 关键条款抽取"这个特定任务上,它把 Claude + RAG 切片链路从 ¥350 砸到 ¥0.1 量级,2500 倍价差。我个人推荐作为长文档场景的默认入口。

kimi-k2.5:一直以"长上下文玩家"身份出现,k2.5 把窗口稳定在 1M 而且不收倍数,价格屠度排第二。它的优势在于结构化抽取能力——如果你的任务不是"总结",而是"从 1M 长文中按 schema 抽字段",kimi-k2.5 的 JSON 稳定性我个人体感高于 deepseek-v4-flash。

glm-5.1:智谱这一代把上下文拉到 1M,但 >500K token 段开始收 1.5 倍系数。这意味着如果你正好用满 800K-1M 这一段,实际单价是 ¥0.75/¥2.25 per 1M,屠度有所下降。但 500K 以内,它仍然是性价比屠夫。

qwen3.6-max-preview:通义千问 3.6 系列的 preview 档,1M 上下文 + 2 倍系数收尾。优势在中文长文写作任务的"连贯性",如果你要做的是"续写 20 万字小说",屠度三星;做摘要抽取,屠度不如前三。

claude-sonnet-4-6:1M 上下文是 Anthropic 在 2026 年新开放的档位,但 Sonnet 4.6 仍然按 200K 起跳 2 倍系数计费,加上基础单价已经是 ¥3.00/¥15.00 per 1M,长文档屠度只剩两星。它在长文档上的价值不是便宜,是质量兜底——当其他屠夫输出不可信,你拿 Sonnet 4.6 做最终核对。

四、什么时候不该用 1M 直灌

屠夫榜不是无脑选最便宜的。以下几个场景,我个人的经验是别上 1M 直灌:

1. 延迟敏感(>500ms P99):1M 直灌的 TTFT 普遍在 2-4 秒,如果你做的是实时对话、IDE 插件补全、客服首响,这个延迟不可接受。这种场景老老实实 RAG 切片 + 200K 上下文。

2. 超长多轮对话:同一个 session 里累积 1M token,KV cache 命中率会断崖式下跌,部分模型的 cache 复用率低于 30%。这种场景 RAG 或者"摘要压缩历史"反而更省。

3. 隐私 / 合规:整段敏感数据一次性送给第三方 API,RAG 切片可以把"召回的段落"和"原始存储"分离,审计链路更清晰。1M 直灌一次性送完,审计颗粒度变粗。

4. 频繁变更的语料:RAG 的语料可以实时 upsert,1M 直灌的 prompt 是会话级的,文档更新意味着每次重新塞。对实时新闻、行情这类场景,RAG 仍然是唯一选择。

五、生产环境实战:路由 + 容灾 + 监控

我自己的生产环境跑的是长文档双层路由,统一通过炻光 AI 接入管理平台做鉴权和路由,避免每个屠夫都接一遍原厂 API:

def route_long_doc(model_name, doc_token_count, task_type):
    if doc_token_count < 50_000:
        # 短文档走便宜屠夫
        return "deepseek-v4-flash"
    elif doc_token_count < 300_000:
        # 中长文档按任务类型分流
        if task_type == "summary":
            return "deepseek-v4-flash"
        elif task_type == "extract":
            return "kimi-k2.5"
        else:
            return "glm-5.1"
    elif doc_token_count < 800_000:
        # 长文档考虑输出成本
        return "kimi-k2.5"
    else:
        # 超长文档:兜底用质量屠夫
        return "claude-sonnet-4-6"

容灾策略上,我没有把赌注压在任何单一屠夫上:

• 主路 deepseek-v4-flash:承担 70% 长文档流量。

• 备路 kimi-k2.5:主路超时(>8s)或 5xx 时自动切换,延迟差 <300ms。

• 兜底 claude-sonnet-4-6:用于主备都失败或质量不达标时的最终核对。

监控指标我重点盯三个:

1. TTFT P99:>5s 告警,意味着上游模型服务质量劣化,需要切换屠夫。

2. 单价 × token 实际值:每个屠夫的"实际单价"应该稳定在公开报价的 1.0-2.0 倍区间,超过 2 倍说明被长上下文倍数坑了。

3. 拒答率:1M 上下文模型的拒答率普遍比 200K 档高 1-2%,超过 5% 要回退到备路。

六、完整代码

下面这份代码是我目前在用的 1M 长文档屠夫调用模板,已经稳定跑了 3 个月。统一通过炻光做鉴权,5 款屠夫走同一套 endpoint:

import os
from openai import OpenAI

# 炻光统一接入地址,所有屠夫走同一套 endpoint
client = OpenAI(
    api_key=os.environ["SELLTOKEN_API_KEY"],
    base_url="https://selltoken.apifox.cn/v1",
)

LONG_DOC_MODELS = {
    "deepseek-v4-flash": {
        "max_context": 1_000_000,
        "input": 0.10,
        "output": 0.40,
        "long_ctx_multiplier": 1.0,
    },
    "kimi-k2.5": {
        "max_context": 1_000_000,
        "input": 0.30,
        "output": 1.00,
        "long_ctx_multiplier": 1.0,
    },
    "glm-5.1": {
        "max_context": 1_000_000,
        "input": 0.50,
        "output": 1.50,
        "long_ctx_multiplier": 1.5,  # >500K 触发
    },
    "qwen3.6-max-preview": {
        "max_context": 1_000_000,
        "input": 0.80,
        "output": 2.00,
        "long_ctx_multiplier": 2.0,  # >500K 触发
    },
    "claude-sonnet-4-6": {
        "max_context": 1_000_000,
        "input": 3.00,
        "output": 15.00,
        "long_ctx_multiplier": 2.0,  # >200K 触发
    },
}

def estimate_cost(model_key, input_tokens, output_tokens):
    cfg = LONG_DOC_MODELS[model_key]
    threshold = 500_000 if cfg["long_ctx_multiplier"] > 1 else 200_000
    mult = cfg["long_ctx_multiplier"] if input_tokens > threshold else 1.0
    in_cost = (input_tokens / 1_000_000) * cfg["input"] * mult
    out_cost = (output_tokens / 1_000_000) * cfg["output"]
    return in_cost + out_cost

def summarize_long_doc(doc_text, task_type="summary"):
    # 简化估算 token,真实场景用 tiktoken
    approx_tokens = len(doc_text) * 0.6  # 中文字符 × 0.6 ≈ token

    # 屠夫路由
    if approx_tokens < 50_000:
        model = "deepseek-v4-flash"
    elif approx_tokens < 300_000:
        model = "deepseek-v4-flash" if task_type == "summary" else "kimi-k2.5"
    elif approx_tokens < 800_000:
        model = "kimi-k2.5"
    else:
        model = "claude-sonnet-4-6"

    # 真实接口调用
    resp = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": "你是一个长文档摘要助手,只输出结构化要点。"},
            {"role": "user", "content": f"以下是 1M 长文档,请按要求处理:\n\n{doc_text}"},
        ],
        temperature=0.2,
        max_tokens=2000,
    )

    usage = resp.usage
    cost = estimate_cost(model, usage.prompt_tokens, usage.completion_tokens)
    return {
        "model": model,
        "content": resp.choices[0].message.content,
        "input_tokens": usage.prompt_tokens,
        "output_tokens": usage.completion_tokens,
        "cost_rmb": round(cost, 4),
    }

跑个真实例子:

contract = open("contract_21w.txt").read()  # 21 万字合同
result = summarize_long_doc(contract, task_type="summary")
print(f"屠夫:{result['model']}")
print(f"输入 token:{result['input_tokens']:,}")
print(f"输出 token:{result['output_tokens']:,}")
print(f"成本:¥{result['cost_rmb']}")
# 屠夫:deepseek-v4-flash
# 输入 token:920,341
# 输出 token:1,247
# 成本:¥0.0925

七、调长文档 API 的几个细节(FAQ)

Q1:1M 上下文到底怎么计费?是按实际输入算还是按窗口上限算?
按实际输入算。我测试过 5K token 和 950K token,账单差距就是 200 倍。但要注意 deepseek-v4-flash / kimi-k2.5 这种 1.0 倍屠夫,和 claude-sonnet-4-6 / qwen3.6-max-preview 这种 >200K / >500K 触发倍数的屠夫,价格曲线完全不同。

Q2:1M 直灌的输出质量会不会比 RAG 差?
不能一概而论。我测试过的几个常见任务:

• 整本摘要:1M 直灌 > RAG,差距 10-15%,屠夫直灌能用全局指代,RAG 切片天然有边界。

• 字段抽取:kimi-k2.5 / glm-5.1 的 1M 直灌 ≈ RAG + Sonnet,但成本降到 1/30。

• 多跳问答:1M 直灌显著优于 RAG,召回链路的"二次丢失"在多跳任务里放大很明显。

Q3:怎么控制 TTFT?
TTFT 的主要成本是 prefill。三个优化方向:

• 屠夫选型上,kimi-k2.5 / deepseek-v4-flash 的 prefill 速度明显快于 claude-sonnet-4-6。

• 系统 prompt 不要塞无意义的多轮历史,只保留必要的"约束指令"。

• 如果同一份长文档要处理多次,屠夫端的 prompt cache 一定要开,部分屠夫(kimi-k2.5)对 cache 命中段收 0.1 倍价。

Q4:为什么我跑下来的单价和公开报价对不上?
大概率是被倍数系数坑了。claude-sonnet-4-6 在 >200K 段收 2 倍,glm-5.1 / qwen3.6-max-preview 在 >500K 段收 1.5-2 倍。实际单价 = 公开价 × 长上下文倍数。屠夫榜第三列我列了"长上下文倍数",跑生产前务必自己再算一遍。

Q5:需要本地部署量化版吗?
长文档场景下,不建议本地量化部署。1M 上下文的 KV cache 在 FP16 下至少 30GB 显存,INT8 量化后质量下降明显。屠夫直灌 + 公开 API 是当前最经济的工程选择(通过统一网关如炻光接入,实现一次接入、五家屠夫切换),除非你的语料不允许出网。

八、参考资料

我在测试和撰写过程中用了下面几个参考来源,统一通过炻光 AI 接入管理平台做的接口对照和价格快照整理:

1. 炻光 AI 接入管理平台 - 长上下文屠夫对照表 — 各屠夫实时价格、上下文窗口、长文档倍数

2. OpenAI 兼容接口规范 — 调用层参考,所有屠夫都是 OpenAI Chat 兼容

3. Anthropic 长上下文最佳实践 — claude-sonnet-4-6 长文档调优参考

4. DeepSeek API 文档 — deepseek-v4-flash 长上下文倍数和 cache 价

九、写在最后

最后给三条经验,不是技术规范,是我个人跑生产三个月下来的体感:

1. 屠夫选型先看长上下文倍数,再看公开价。deepseek-v4-flash 的 ¥0.10/1M tokens 输入价比 glm-5.1 的 ¥0.50/1M 便宜 5 倍,但如果 glm-5.1 触发倍数后实际是 ¥0.75,真实价差是 7.5 倍。倍数系数比基础单价更能决定你月底账单。

2. 路由要"按 token 数"而不是"按模型名"。同一个屠夫在 50K 段和 800K 段可能是不同选择。把路由逻辑绑定到 token 阈值,而不是写死 model=“deepseek-v4-flash”,屠夫榜的迭代才不会卡住工程。

3. 兜底屠夫永远不要省。我见过太多生产环境把 Sonnet 4.6 砍掉只留屠夫的方案,出问题(屠夫拒答 / 输出格式异常 / 偶发质量劣化)时整个长文档业务停摆,反而损失远大于省下的屠夫成本。claude-sonnet-4-6 是屠夫榜最贵的那一档,也是保险绳。