Grok 4.7 与旧版本怎么选

选模型不是选「谁更强」，是选「够用且成本可控」。很多团队一上来就锁旗舰，等到账单出来才发现：自己 90% 的请求根本用不到旗舰的上下文，却一直按旗舰单价付钱。这一节把在售模型的上下文、价目、推理档位摆成一张带核验日期的对照表，再给一个能离线跑的「按需求筛模型」函数。

本教程不评价「谁更强」——那是基准测试的事，且数字会过时。我们只解决一个工程问题：给定上下文需求和预算，哪些模型满足，其中哪个最便宜。

一、问题不是「哪个最新」，而是「哪个刚好够」

模型选择有两个硬约束和一个软约束：

• 硬约束 1：上下文窗口。你的任务一次最多要带多少 token 进场，决定了哪些模型根本不在候选里。
• 硬约束 2：预算。单价（尤其输入与输出）决定了长跑成本。
• 软约束：推理强度档位。部分模型支持调推理强度，影响延迟与消耗（见 4.2）。

下面用 2026-11-04 官方 /developers/models 页的可核验数据，写筛模型的函数。

二、最小可运行示例：按需求筛模型

下面的脚本不联网、不需要真实密钥。数据来自 2026-11-04 官方 models 页的 <200k 档单价与上下文窗口（USD / 1M tokens）。它按「最少上下文」与「单价上限」两道门槛筛候选。

"""按上下文需求与每 1M token 预算选模型（mock，数据来自 2026-11-04 官方 models 页）。"""

## 2026-11-04 官方 /developers/models：上下文窗口与 <200k 档单价（USD / 1M tokens）
MODELS = [
    {"id": "grok-4.7", "ctx": 500_000, "in": 2.00, "cached": 0.50, "out": 6.00, "reasoning_tiers": 4},
    {"id": "grok-4.6", "ctx": 500_000, "in": 2.00, "cached": 0.50, "out": 6.00, "reasoning_tiers": 4},
    {"id": "grok-4.5", "ctx": 500_000, "in": 2.00, "cached": 0.30, "out": 6.00, "reasoning_tiers": 3},
    {"id": "grok-4.3", "ctx": 1_000_000, "in": 1.25, "cached": 0.20, "out": 2.50, "reasoning_tiers": None},
    {"id": "grok-4.20-0309-reasoning", "ctx": 1_000_000, "in": 1.25, "cached": 0.20, "out": 2.50, "reasoning_tiers": None},
    {"id": "grok-build-0.1", "ctx": 256_000, "in": 1.00, "cached": 0.20, "out": 2.00, "reasoning_tiers": None},
]

def select_by_context(min_ctx: int, budget_in: float) -> list[dict]:
    """返回上下文够用、且输入单价不超过预算的模型，按输入单价升序。"""
    pool = [m for m in MODELS if m["ctx"] >= min_ctx and m["in"] <= budget_in]
    return sorted(pool, key=lambda m: m["in"])

def offline_check() -> None:
    # 需求：至少 800k 上下文，输入单价不超 $1.5
    picks = select_by_context(800_000, 1.5)
    ids = [m["id"] for m in picks]
    assert "grok-4.3" in ids and "grok-4.20-0309-reasoning" in ids
    assert "grok-4.7" not in ids, "500k 上下文不满足 800k 需求"
    print("满足 800k / $1.5 的候选：", ids)
    # 预算收紧演示：256k 需求下，$2.0 含全部，$1.3 排除 4.5/4.6/4.7
    wide = select_by_context(256_000, 2.0)
    narrow = select_by_context(256_000, 1.3)
    print("256k / $2.0：", [m["id"] for m in wide])
    print("256k / $1.3：", [m["id"] for m in narrow])

if __name__ == "__main__":
    offline_check()

真正选型时，把 MODELS 换成你抓取当日的官方数据即可；函数逻辑不变。注意 grok-build-0.1 的上下文最小（256k），多数通用任务不该默认选它；它的具体适用场景以官方模型页为准。

三、各模型对照（带核验日期）

三件要强调的事：

• 带日期，不带「长期不变」一类表述。上表单价是 2026-11-04 官方页的值，官方会在 release-notes 调整价目，写作时与上线时都应以官方页与控制台当前显示为准。
• 跨 200k 阈值会整请求跳档（见 4.3），所以表中的 <200k 单价不是全量单价；长上下文请求要按高档重算。
• 推理档位数目因模型而异：grok-4.7 与 grok-4.6 是四档，grok-4.5 的发布说明只列三档（默认 high）。不同模型的档位以各自官方页为准，不要假设全部四档通用。

四、预期输出与异常分支

运行筛模型函数，预期输出：

满足 800k / $1.5 的候选： ['grok-4.3', 'grok-4.20-0309-reasoning']
256k / $2.0： ['grok-build-0.1', 'grok-4.3', 'grok-4.20-0309-reasoning', 'grok-4.5', 'grok-4.6', 'grok-4.7']
256k / $1.3： ['grok-build-0.1', 'grok-4.3', 'grok-4.20-0309-reasoning']

换成真实选型时，若出现异常，按下面顺序定位：

最后一行尤其重要：候选为空往往不是「没有模型」，而是「门槛写反了」。把 select_by_context 的两个参数打印出来对照需求，比换模型名有用。

五、判据卡

这张卡的重点是先筛再评。五类现象里「候选为空」和「选了旗舰」常常同源：预算门槛没设对，表现一个是筛不出一个是筛出贵的，但修法都在 select_by_context 的参数上。

六、来源与核验

• 官方模型页：https://docs.x.ai/developers/models（核验日期 2026-11-04）。上下文窗口、<200k 与 ≥200k 单价、模型列表以该页为准。
• 官方 grok-4.7 概览：https://docs.x.ai/developers/grok-4-7。推理强度档位差异（四档 vs 三档）来源为官方 release-notes（F31）。
• 价格、额度与区域可用性以控制台当前页面为准；grok-4.3 等模型的推理档位以各自官方页当前显示为准。

七、动手试

1. 给 select_by_context() 加一个 max_out 参数，按输出单价再筛一层，验证「既要长上下文又要低输出价」时会剩下哪些模型。
2. 把 MODELS 换成你今日抓取的官方数据重跑 offline_check()，记录与 2026-11-04 的差异。想一想：如果官方调价，你的选型脚本需要改几处？
3. 设计一个「候选为空」的回退策略：当没有任何模型同时满足上下文与预算时，给出至少两种降级路径（例如降低上下文需求、改用检索而非全量带文），并说明各自代价。