Grok 模型选型判据卡

前面三节分别讲了模型对照、推理强度、长上下文计费，但工程上它们不是三张独立的表，而是一张要落地的判据卡。这一节把三者压成一条可复用的判断，并明确落到主线项目——为中文团队做一个可审计、可控成本的内部文档问答服务——的实际选择上。本节是原创综合，不复述 4.1–4.3 的逐条事实。

选型的底层逻辑只有一句：上下文是硬约束，推理强度按需求而非越高越好，预算决定能否用旗舰。下面把这条逻辑写成可离线跑的代码，再落到主线项目。

一、问题不是「选哪个模型」，而是「把三个约束合成一条判断」

选型要同时平衡三件事：任务需要多大的上下文（硬约束）、需要多强的推理（按需求）、能承受多高的单价（预算）。任何一维单独看都会误导——只看能力会超预算，只看预算会不够用。

二、最小可运行示例：选型判据卡

下面的脚本不联网、不需要真实密钥。它把 4.1–4.3 的结论压成一个 recommend()，并直接应用到主线项目与一条对照任务上。

"""选型判据卡（原创综合）：把上下文、推理强度、成本压成一条可复用判断。"""

from dataclasses import dataclass

@dataclass
class Workload:
    name: str
    max_ctx: int          # 需要的上下文上限
    reasoning: str        # 需要的推理强度档
    latency_sensitive: bool
    budget_per_1m_in: float

def recommend(w: Workload) -> str:
    # 上下文是硬约束；推理强度按需求而非越高越好；预算决定能否用 4.7/4.6
    if w.max_ctx > 500_000:
        base = "grok-4.3 或 grok-4.20 系列（1M 上下文）"
    elif w.budget_per_1m_in >= 2.0:
        base = "grok-4.7 / grok-4.6（500k，旗舰档）；预算紧可选 grok-4.5（缓存价更低）"
    else:
        # 预算 < $2.0 时排除全部 $2.00 档模型（4.7 / 4.6 / 4.5 同价）
        base = "grok-4.3（1M，输入单价更低）"
    effort = w.reasoning if w.reasoning in ("low", "medium", "high", "xhigh") else "high"
    return f"{w.name}：{base}；推理强度 {effort}" + ("；延迟敏感可上 xhigh 但先算账" if w.latency_sensitive else "")

def offline_check() -> None:
    main = Workload("内部文档问答", max_ctx=500_000, reasoning="medium",
                    latency_sensitive=False, budget_per_1m_in=2.0)
    long_ctx = Workload("长合同分析", max_ctx=900_000, reasoning="high",
                        latency_sensitive=False, budget_per_1m_in=1.25)
    tight = Workload("预算收紧", max_ctx=400_000, reasoning="medium",
                     latency_sensitive=False, budget_per_1m_in=1.5)
    print(recommend(main))
    print(recommend(long_ctx))
    print(recommend(tight))
    assert "grok-4.7" in recommend(main)
    assert "1M" in recommend(long_ctx)
    # 预算 < $2.0 时不得出现任何 $2.00 档模型
    assert "grok-4.5" not in recommend(tight) and "grok-4.7" not in recommend(tight)

if __name__ == "__main__":
    offline_check()

真正落地时，Workload 的字段来自你对自己的任务画像；recommend() 只是把硬约束前置、软约束殿后的顺序固化下来，避免每次选型都从零吵一遍。

三、主线项目的实际选择

主线项目最终落在 grok-4.7 + medium 推理强度 + 500k 上下文：能力够用、单价在预算内、推理强度按请求分档而非默认拉满。少数超长文档走 Context Compaction（见 3.2）或拆请求（见 4.3），不为此换模型。

三件要强调的事：

• 选旗舰不是因为「最强」，是因为「500k 上下文 + 单价在预算内」刚好满足。如果未来官方调价让旗舰单价超出预算，判据卡会自动把它排出——选型逻辑不变，只换数据。
• 推理强度默认 medium 而非平台默认的 high。内部文档问答多数请求是检索+抽取，high 已是冗余；把 xhigh 完全排除在默认之外，只在「值得多花」的复杂追问临时升档（见 4.2）。
• 长尾单独处理，不绑架整体选型。因为 1.3 已经证明 2% 的长请求能吃 67% 的账单，长尾的治理（压缩/拆分）是成本工程的事，不是「换一个更便宜模型」能解决的。

四、预期输出与异常分支

运行选型判据卡，预期输出：

内部文档问答：grok-4.7 / grok-4.6（500k，旗舰档）；预算紧可选 grok-4.5（缓存价更低）；推理强度 medium
长合同分析：grok-4.3 或 grok-4.20 系列（1M 上下文）；推理强度 high
预算收紧：grok-4.3（1M，输入单价更低）；推理强度 medium

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

最后一行尤其重要：recommend() 返回空或兜底，往往是 Workload 的画像没定准，而不是模型不够。把任务画像填实，比换模型名有用。

五、判据卡

这张卡的重点是把三约束合成一条前置顺序。五类现象里「推荐为空」和「选型摇摆」常常同源：Workload 没定准，表现一个是筛不出一个是反复横跳，但修法都在「先把画像填实」上。

六、来源与核验

• 官方模型页：https://docs.x.ai/developers/models（核验日期 2026-11-04）。上下文窗口、价目、模型列表以该页为准（F2、F4、F6）。
• 推理强度档位差异来源为官方 release-notes（F31）；长上下文阈值规则见 4.3 与官方 models 页注释（F5）。
• 组合层成本教训来自 1.3（已修正）：2% 长请求约占总账单 67%，以 2026-11-04 参数与单价为准。
• 价格、额度与区域可用性以控制台当前页面为准。

七、动手试

1. 给 recommend() 加一个 long_tail_ratio 参数：当长尾请求占比超过某阈值时，在结论里追加「建议先治理长尾而非换模型」，并说明这条建议的触发逻辑。
2. 把主线项目的 Workload 改成你自己的任务画像重跑 offline_check()，记录推荐结果与你当前实际使用的模型是否一致。想一想：不一致时，是画像错了还是现状错了？
3. 设计一个「选型评审」清单：列出至少三个必须同时确认的信号（上下文够用、单价在预算、推理档按任务），并说明任意一个不满足时该回退到哪一档。