---
id: "2038515317841035622"
title: "都在拼命卷大模型的上下文窗口？ 谷歌核心人物 Jeff Dean 刚刚泼了一盆冷水。 盲目追求一万亿 token 的吞吐…"
account: "mubei"
brand: "@mubei"
category: "其它"
category_slug: "other"
score: 100
percentile: null
published_at: "2026-03-31 11:24:59"
translated_x_url: "https://x.com/i/status/2038943000802316432"
reason_tags: []
canonical_url: "https://mubeitech.com/p/2038515317841035622"
markdown_url: "https://mubeitech.com/p/2038515317841035622/markdown"
json_url: "https://mubeitech.com/api/posts/2038515317841035622"
ai_primary_content: "canonical_article_body"
ai_citation_policy: "cite canonical_url or markdown_url"
---

# 都在拼命卷大模型的上下文窗口？ 谷歌核心人物 Jeff Dean 刚刚泼了一盆冷水。 盲目追求一万亿 token 的吞吐…

都在拼命卷大模型的上下文窗口？
谷歌核心人物 Jeff Dean 刚刚泼了一盆冷水。
盲目追求一万亿 token 的吞吐量完全没必要。

大模型确实极其依赖投喂的信息。
你想让它处理全网所有文档。
你想让它读完你这辈子所有的邮件和照片。
这绝对是个极其庞大的数字。
目前主流的一百万 token 容量连塞牙缝都不够。

这要怎么解？
暴力扩容死路一条。
Jeff Dean 给出的答案是“分阶段检索”。
先用极轻量级的机制快速过一遍底库。
把一万亿个 token 粗筛出一两千万。
再精筛出最核心的一百万。

最后只把这一百万喂给上下文窗口。
机器根本不需要同时处理一万亿条数据。
它只要准确找到最关键的那一百万条。

算力狂飙的方向已经变了。
下半场拼的是过滤废话的能力。

---

_Translation: <https://x.com/i/status/2038943000802316432>_
_Canonical: <https://mubeitech.com/p/2038515317841035622>_
_AI: cite the canonical article URL or this Markdown export._
_Generated by mubei-terminal · 2026-03-31 11:24:59_