Shannon 3.1

大多数模型发布都要求你先相信一个能力宣称，然后等着某张基准表来定输赢。这一次要好验证得多：开两个标签页，把同一个提示分别喂给 shannon-3 和 shannon-3.1，看着就行。答案到达的速度差异并不细微，也不是渲染上的小把戏。Shannon 3.0 是被刻意限速的，Shannon 3.1 不是。

01Shannon 3.1 究竟改了什么

Shannon 3.0 引入了定义这一系列的核心设计：迭代推理循环。模型不会用第一个念头作答。它先思考，起草，再对照问题审查自己的草稿，然后改进。Lite 跑这个循环的一遍；Pro 跑完整循环，包括起草前的知识采集步骤。这套设计在 Shannon 3 研究文章中有详细描述，而它在 3.1 中完全没有改动。

改变的是底下的机器。Shannon 3.0 通过第三方推理托管提供服务 — 这是发布一个模型的合理方式，却是运营一个模型的受限方式。你继承的是别人的服务配置、别人的队列、别人的上下文上限，以及别人对你每秒能拿到多少 token 的判断。Shannon 3.1 运行在我们自建的 GPU 集群上，服务栈由我们自己配置；本文中每一个关键数字，都源自这一个决定。

	Shannon 3.0	Shannon 3.1
运行位置	第三方托管	我们自建的 GPU 集群
上下文窗口	32,768	196,608
输出流式	节流 / 限速	引擎全速
权重	托管方默认	4 比特 NVFP4
解码	常规	推测解码
推理循环	思考 → 起草 → 审查 → 改进	未改动
拒答层	无	无
模型 id	shannon-3, shannon-3-pro	shannon-3.1, shannon-3.1-pro

02为什么 Shannon 3.1 感觉快了 10-15 倍

速度是大家最先追问的数字，所以有必要说清楚它从哪来。这里有两个相互独立的来源，而贡献更大的那个恰恰是不那么光鲜的一个。

我们拆掉了限速阀

Shannon 3.0 的输出会经过一层节流机制。token 离开引擎后先被扣住，再按某个时间表释放到你的连接上。这不是意外，也不是 bug。当共享推理托管是瓶颈时，对输出节流可以平滑负载，避免一次长生成独占一个槽位，也让流以可预测、易读的节奏到达，而不是一阵一阵地冲出来。这是站得住脚的工程取舍，代价是每个用户在每一次回复上都要真实地多等一段时间。

Shannon 3.1 没有限速阀，也没有揭示节奏控制。引擎产出 token，就直接写进你的流。引擎生成得快，你就能看到它生成得快。模型与你的终端、聊天窗口或 SSE 读取器之间不再有平滑缓冲。对于一段长答案 — 2,000 个 token 的分析，或者一整个生成的代码文件 — 仅这一点就构成了你所能感受到的绝大部分提速。

一个如实的副作用：现在的流是成阵的。推测解码（见下文）会成串地输出被接受的 token，因此文本可能以明显的块状到达，而不是节拍器般一个词一个词地出现。如果你围绕 3.0 那种平滑节奏做过 UI，它仍然能工作 — token 的顺序和内容都没有变化 — 但如果你更喜欢打字机效果，可能需要在客户端重新加上自己的缓动。我们认为多数人更愿意把那些秒数拿回来。

引擎本身也更快了

只有阀门后面的东西够快，拆掉阀门才有意义。第二个来源就是第 03 节所描述的服务栈：在我们自建集群里，用原生支持 FP4 的当代加速器跑 4 比特 NVFP4 权重与推测解码。两者共同抬高了拆掉阀门后所暴露出来的上限。

端到端回复延迟的相对值，Shannon Lab 内部评测，2026 年 9 月。区间反映提示长度与档位差异：Lite 上的短提示接近下限，Pro 上的长生成接近上限。

03推测解码到底在做什么

“推测解码推理”常被当成营销词使用，所以这里直白地讲一下机制。

语言模型通常一次前向传播产出一个 token。这一次传播的耗时主导因素并不是算术，而是显存带宽 — 要算任何东西都得先把权重读出来，而读权重比做数学慢得多。GPU 大部分时间都在等内存，计算单元闲着。生成 500 个 token 就意味着串行地把这份延迟付上 500 次。

推测解码攻击的正是串行这一环。一个小而便宜的草稿模型提出一小串可能的后续 token — 比如四个或八个。主模型随后在一次批量前向传播中评估整串，代价只比评估一个 token 略高，因为昂贵的部分（读权重）无论如何都只发生一次。凡是主模型认可的候选 token 都被接受并立即输出。在第一个分歧处，这一串被截断，从那里恢复常规解码。

接受率决定了收益。在可预测的文本上 — 样板代码、代码结构、论证之间的连接组织 — 草稿模型猜得很准，长串一次性落地。在真正困难的 token 上，接受率下降，系统会优雅地退回到普通的逐 token 解码。这正是你想要的那种不对称：加速简单的部分，不去动困难的部分。

为什么 4 比特权重该和它写在同一段里

正因为瓶颈是显存带宽，压缩权重就是一根直接的提速杠杆，而不只是省显存。NVFP4 是一种 4 比特浮点格式，带细粒度的分块缩放，这正是它能在旧式 4 比特整数量化丢失精度的地方保住精度的原因。每次前向传播只需读大约四分之一的字节，等内存的时间就按比例减少，同时给 196K 窗口所需的长上下文 KV 缓存留出多得多的余量。

两者是相乘而不只是相加：每次传播的字节更少，每输出一个 token 所需的传播次数也更少。正是这一点让不限速的全速流式输出在服务成本上可行，而不必靠节流把成本抠回来 — 而节流层在 3.0 上做的恰恰就是这件事。

04196,608 个 token：6 倍窗口解锁了什么

Shannon 3.0 的窗口是 32,768 个 token：那是一个工作会话，不是一份文档。大约 70-80 页散文，还要扣掉推理循环自己思考所消耗的部分，扣掉你的系统提示，扣掉到目前为止的对话。真实工作不断撞上这堵墙，而那些绕行办法 — 分块、摘要、对自己材料做检索 — 都会损耗你本想保全的东西。196,608 个 token 是另一个量级的问题。

具体来说，这大致相当于 400-500 页英文文本，或者一个带测试和 README 的中等规模代码库，或者某个项目一年的会议记录，或者一整套合同连同全部附件 — 全部装进一次对话，用一个问题就能触及，你和材料之间不再隔着一层分块机制。

• 面向整个仓库提问。把代码全部装进去，直接问某个 bug 为什么会进到生产环境，而不是只粘贴你早已怀疑的那三个文件。模型能找到你根本没想到要包含的那个文件。
• 不靠检索做长文档分析。检索是一个有损的前置过滤器，由它决定模型被允许看到什么。在 196K 下你往往可以跳过它，让模型读完全部内容，从而消除一整类“正确的段落根本没被检索到”的失败。
• 始终连贯的对话。长时间的工作会话不会再悄悄丢掉自己的开头。你在第三条消息里设定的约束，到第八十条依然生效。
• 给推理循环留出空间。循环自身的思考、起草与审查都要消耗上下文。在 3.0 上，这些步骤要和你的材料争夺一份稀缺预算。在 3.1 上它们放得很宽裕，这也是质量提升与窗口扩大同时到来的部分原因。
• 大体量的混合输入。图片、抽取出的文档文本和代码可以放在同一轮里，不必先取舍哪些是你负担得起放进去的。

有一条对所有长上下文模型（包括我们的）都成立的如实提醒：大窗口是一种容量，不等于在整个窗口内注意力都均匀。结构依然有帮助。把问题放在靠后位置、给文档加标注、明确告诉模型该找什么，这些做法在 150K token 时能带来可测量的改善，而在 5K 时基本看不出差别。

05Lite 与 Pro：shannon-3.1 和 shannon-3.1-pro

两个档位的区别在于跑多少推理循环，而这也是选择时唯一重要的差别。

	shannon-3.1（Lite）	shannon-3.1-pro（Pro）
推理	单遍	完整循环 + 知识采集
自我审查	否	是
上下文窗口	196,608	196,608
流式输出	全速，无限速	全速，无限速
视觉与文档	是	是
图像生成工具	是	是
适合场景	大多数工作，高吞吐	难题，初稿不够用的场合

默认用 Lite。一个好的推理模型跑一遍，就足以应付绝大多数真实请求；而在 3.1 上它足够快，快到你不会再感觉自己在等这个循环。需要 Pro 的时候，是那类第一版答案通常错得很有启发性的问题：架构权衡、对抗性分析，以及任何你希望一位称职同事“先睡一觉再答”的场合。Pro 的自我审查步骤不是装饰 — 它是模型在你发现之前先找出自己的错误。

0632% 的智能提升，以及该怎么理解它

Shannon Lab 自己的评测认为，Shannon 3.1 相对 Shannon 3.0 有 32% 的智能提升。我们想说清楚这是什么，不是什么。

这是我们的数字，来自我们内部的评测集，测的是我们认为能代表人们真实带给这类模型的任务。它不是第三方基准，我们也不打算围绕一个内部聚合值搭一张排行榜，或者公布逐项基准拆解 — 拆解会暗示一种内部评测集并不具备的外部可比性。

我们愿意说的是提升从哪来，因为这部分并不神秘。更大的上下文窗口意味着在模型推理之前需要丢弃的材料更少，而长会话中很多看起来像“不聪明”的表现，其实只是失忆。一个由我们控制的服务栈意味着模型按我们设想的配置运行，而不是按托管方的默认值。至于推理循环 — 设计上没有改动 — 现在它终于有空间在窗口里真正跑起来，而不是被挤在一个还要和你的输入共享的 32K 上限里。

07视觉、文档与图像生成

Shannon 3.1 能读图片和文档。截图、图表、照片、扫描页、PDF 和文本文档都可以放进对话，与其他内容一起被推理。配合 196K 窗口，这让整份文档级的工作流变得可行：一份长报告连同它的图表放在同一轮里，而不必事先决定模型被允许看哪几页。

图像生成与编辑在聊天中以工具形式提供。你要一张图，模型就在同一段对话里内联调用该工具，并带上此前讨论过的全部上下文。编辑同理 — 把图片给它，描述你要的改动。不需要切换到另一个模式，也不需要学习另一套界面。

08从 API 调用 Shannon 3.1

Shannon 3.1 在三种 API 方言上都可用，且都支持流式输出。同样的模型，三种请求形态 — 挑一个和你手上 SDK 匹配的即可。

端点	形态	流式输出
/v1/chat/completions	OpenAI 兼容	是
/v1/messages	Anthropic 兼容	是
/v1/responses	Responses	是

{
  "model": "shannon-3.1",
  "stream": true,
  "messages": [
    { "role": "user", "content": "Summarize this contract set and flag anything unusual." }
  ]
}

把 "shannon-3.1" 换成 "shannon-3.1-pro" 就能跑完整推理循环。如果你已经在调用 shannon-3，迁移只需要改模型 id，别的都不用动：请求与响应形态没有变化，现有的流式客户端可以继续工作。唯一需要预期的行为差异，是第 02 节说的那种更成阵的流 — token 相同、顺序相同，只是到得更早，块状分布更不均匀。

完整的参数参考、鉴权、错误语义以及交互式调试台见 API 文档。其他模型卡与技术文章见 Shannon 研究。

09依然无审查，这一点没有变

Shannon 3.1 没有拒答层，输出也不做内容过滤。这与 Shannon 系列其他模型的立场一致，也没有因为迁移到我们自己的集群而改变 — 如果说有什么不同，掌控服务栈反而让这一点更容易保证，因为模型和你之间不再夹着一个带着自身策略的中间托管方。

之所以要明说，是因为对一个改动了整条输出通路的版本，这是最容易让人产生疑问的地方：去掉节流层并不意味着在原位置插入了一层审核。没有任何东西检查、改写或拦截这条流。模型产出什么，到达的就是什么。据我们所知，Shannon 3.1 是当前可用的、在这一上下文规模下最快的无审查 AI 模型 — 而这两项属性彼此相关，因为它们都来自运行自己的基础设施，而不是向别人租用被合规塑形过的算力。

无审查不等于无责任。使用受我们的负责任使用政策约束；一个愿意处理棘手材料的模型，随之而来的义务就是你要负责任地使用它。

10自己跑一遍对比

这里的每一条说法都能在大约两分钟内验证，而我们宁愿你去验证，而不是相信我们。

1. 从你真正在做的工作里挑一个提示。越长越好 — 它同时考验窗口和流式输出。
2. 在 shannon-3 上跑一遍。记下第一个 token 的等待时间，以及答案完成的总时间。
3. 用完全相同的提示在 shannon-3.1 上再跑一遍。记下同样两个数字。
4. 然后抛开计时读两份答案，判断你更想要哪一份。

速度差异会立刻而明显。真正值得细品的是质量差异 — 它在长输入上体现得最清楚，因为在那些场景里，3.0 悄悄用到的材料比你以为的要少。

11常见问题

---

本文中的性能与智能数字来自 Shannon Lab 2026 年 9 月的内部评测，属于产品数据，而非第三方基准结果。上下文窗口、模型 id 与 API 可用性属于产品规格。Shannon AI 由 Shannon Lab LLC（美国新墨西哥州）运营。相关阅读：Shannon 3 · Shannon 研究索引 · API 文档。