AI 大模型为什么越来越大？参数、Token、Context Window 与 JSON 数据处理详解

阅读前速览

概念	一句话	和 JSON 的关系
参数	模型里可学习的权重数量，近似「容量」	影响能否稳定吐出合法 JSON
Token	模型读写文本的计长与计费单位	括号、引号、重复键名都要付钱
Context Window	单次请求能装下的 token 上限	大 JSON 与多轮 tool 结果最先撞墙

更大 ≠ 更会处理 JSON。参数给容量，Token 是账单，Context Window 是水桶。水桶变大后，第一反应不该是把整份 API 响应倒进去。

大模型为什么越来越大？

经验规律很简单：在数据和算力跟上的前提下，参数更多、训练更久，损失曲线通常更好。厂商因此把「更大」写成默认叙事——评测榜、演示和采购清单都更好讲。

2024–2026 年「大」其实裂成了三条轴，不再只等于参数个数：

• 参数规模：稠密模型继续涨；MoE 用「总参数很大、每次激活一部分」控制推理成本。
• Context Window：从 8K、32K 扩到 128K，再到百万级。Agent 和长文档是主要借口。
• 输出约束：Structured Outputs / JSON Schema 让「更大」必须换成「更稳的对象」，而不是更长的散文。

对写 JSON 的人，真正要问的不是「这个模型有多少 B」，而是：它吐 Schema 的稳定度、每千 token 的价格、以及你那份 tool 结果还装不装得进窗口。

参数是什么？

参数是训练结束后留在模型里的权重。推理时它们不再更新，只参与计算。参数量常被写成 7B、70B、405B——B 是十亿。它描述的是容量，不是这一次请求读了多少字。

参数变多，通常带来三件事：

• 拟合复杂约束的能力上升。 嵌套对象、enum、required 不再动辄写错。
• 推理更贵、更慢。 同一段 JSON，大模型每个 token 的延迟和单价都更高。
• 不等于 Context Window 更大。 小参数模型也可以挂 128K 窗口；大参数模型也可能只有 32K。

2026 年的产品页还喜欢把 MoE 的「总参数」和「激活参数」写在一起。采购时要问清楚：账单按哪一个算，延迟按哪一个算。GPT-6 Astra 指南 里写过：对 JSON 开发者，稳的 Structured Outputs 往往比再大一号的稠密模型更值钱。

Token 是什么？

Token 是分词器切出来的片段，不是字符，也不是单词。英文常见 1 token ≈ 4 个字符；中文、代码、JSON 标点往往更「碎」，同样视觉长度会更贵。

API 按 token 计费，也按 token 截断。你贴进去的系统提示、工具定义、对话历史、工具返回的 JSON、模型吐出的 JSON，全部进同一本账。

JSON 天生贵。括号、引号、逗号、缩进空格、重复的键名，每一个都可能占 token。下面这份「完整订单」读起来友好，送进模型却浪费：

{
  "order": {
    "order_id": "A-1042",
    "customer": {
      "full_name": "Ada Lovelace",
      "email": "ada@example.com",
      "locale": "en-GB"
    },
    "line_items": [
      {"sku": "KB-1", "title": "Keyboard", "qty": 1, "price": 99.00}
    ],
    "shipping": {"city": "London", "method": "express"},
    "debug": {"trace_id": "tr_9f", "retries": 0}
  }
}

同一笔业务，Agent 下一跳往往只需要：

{
  "order_id": "A-1042",
  "amount": 99.00,
  "status": "paid"
}

先在本地 格式化 看清结构，再用 JSONPath 提取 抽出 order_id / amount / status，然后 minify 再送进模型。调试用美化，推理用瘦身——不要把两者当成同一份 payload。

Context Window 是什么？

Context Window 是单次请求能同时装下的 token 上限。不同厂商把输入、输出算进同一个窗口，或给输出另留一截。文档没写清之前，按「输入 + 预留下的输出 ≤ 窗口」来做预算。

窗口从 8K 涨到 128K、再到百万级，并不自动让 JSON 处理变简单。它只是让「把整份响应贴进去」变得看起来可行。可行和便宜、稳定，不是一回事。

Agent 循环里，窗口通常被这样吃掉：

{
  "context_window": 128000,
  "spent": {
    "system": 1200,
    "tools": 3400,
    "history": 18000,
    "tool_result_json": 42000
  },
  "reserved_output": 4000,
  "remaining": 59400
}

上表是示意，不是某一家的官方账单。要点是：tool 结果的 JSON 往往比 prompt 更肥。多轮 AI Agent 完整指南 如果不做投影和摘要，第三跳就会截断半个对象——下游把它当成完整订单。

参数、Token、Context Window 怎么叠在一起？

三个词经常被写成「模型更大」。拆开之后，职责完全不同：

1. 参数决定质量上限：能不能跟上 Schema、会不会在 additionalProperties 上自由发挥。
2. Token决定每一跳的账单和延迟。同一窗口里，肥 JSON 会挤掉历史和输出余量。
3. Context Window决定一次能看见多少。窗口再大，也补不回「参数太小、约束跟不住」或「token 太贵、不敢重试」。

2026 年的默认事故是：买了大窗口，就把 2MB 的 pretty-printed JSON 倒进去，再抱怨模型「忘记」前面的字段。它不是忘了，是你先把窗口喂满了。

对 JSON 数据处理意味着什么？

把上面三层落到日常流水线，差别会非常具体：

• 美化给人类，压缩给模型。 缩进和换行在编辑器里值回票价，在 token 账单上是纯浪费。
• 投影优于原文。 工具返回 80 个字段时，只把下一跳 required 的键留下。
• Schema 是重试保险。 Structured Outputs 用校验换「少生成几次非法 JSON」，直接省输出 token。
• arguments 的字符串化 JSON 会算两遍形态。 转义引号既难读又占额度，宿主侧必须二次 parse。
• 长上下文不是数据库。 需要查询时用工具；需要对比时在本地 Diff，而不是把两个 5000 行文件塞进同一条消息。

AI Agent 为什么开始需要 JSON Schema 把 Schema 写成运行时门禁；语法见 JSON Schema 教程。版本漂移时，先 JSON Diff 上周能跑的对象和今天被拒的对象，再决定要不要换更大的模型。

2026 年怎么控成本（先动 JSON，再换模型）

1. 给每个 Agent 步写一份「允许进入上下文的字段清单」，而不是 JSON.stringify(fullResponse)。
2. 工具定义本身也要瘦：description 写清约束，删掉不会改变调用的散文。
3. 打开 strict: true / json_schema，用校验换重试。
4. 历史只留状态对象，不留完整 tool 原文。checkpoint 用小 JSON，不用聊天记录。
5. 密钥和用户字段本地看、本地裁，不上传到公共 JSON 站点，也不应无必要地进模型。

控成本的顺序是：投影 → 压缩 → Schema → 再考虑换更小或更大的模型。倒置这个顺序，窗口和参数都会被浪费。

常见误区

• 把参数量当成 Context Window。 70B 和 128K 是两件采购项，写在同一张幻灯片上也不等于绑在一起。
• 按字符数估 token。 JSON 标点和中文会让「看起来不长」的对象先触顶。
• 窗口更大就不再投影。 百万上下文仍然按 token 计费，肥 JSON 只是把账单变长。
• 用更大的模型修非法 JSON。 先检查 Schema 和宿主校验。许多「模型变笨」是多了一个 required。
• 把 pretty JSON 和线上 payload 当成同一份。 编辑器里的空格，不该出现在推理请求里。

FAQ

参数越大，JSON 就会越合法吗？

倾向更好，不是保证。没有 Schema 和宿主校验，大模型一样会漏字段、把数字写成字符串。容量帮你降低事故率，门禁决定事故会不会进入下一跳。

Token 和字符可以按 4:1 换算吗？

英文散文大致可以当经验值。JSON、代码、中文不行。以厂商 tokenizer 或官方计数接口为准，不要用编辑器里的字数估算账单。

Context Window 包含模型输出吗？

多数 Chat / Responses API 把输出算进同一预算，或单独设 max output。按「输入 + 预留输出 ≤ 窗口」做最坏打算，避免最后一个花括号被截断。

已经有 1M 窗口，还要不要裁 JSON？

要。窗口解决「塞得下」，不解决「付得起」和「下跳还稳」。投影和 minify 仍然是默认动作。

怎么在本地检查一份 JSON 会不会撑爆上下文？

先格式化看结构，再按字段投影，最后把将要发送的字符串拿去计数。JSONSort 在浏览器本地做格式化、提取和 Diff，不上传数据。

结论

大模型变大，是因为更大的参数、更长的窗口和更多的数据，在评测上仍然好卖。对处理 JSON 的人，参数是容量，Token 是账单，Context Window 是水桶。把整份 pretty JSON 倒进更大的桶，只是换一种方式超支。

从今天起，先写「这一跳只允许哪些键」，再决定要不要换更大的模型。模型还会再大；口径应该先变小。

延伸阅读

• AI Agent 是什么？Tool Calling 与 JSON 指南 运行时、工具调用与 JSON 契约
• AI Agent 为什么开始需要 JSON Schema 从 Tool Calling 到结构化工作流
• GPT-6 Astra 与 JSON / API 指南 Structured Outputs 在新模型上的用法
• JSON Schema 是什么 required、enum 与 additionalProperties
• JSONSort 本地工具箱 格式化、提取、Diff
• 全部文章 更多 JSON 与 AI 开发笔记

更新记录： 2026-09-05 首次发布；2026-09-07 修正繁中用语与中文用词