xAI 开发者文档页面列出了 Grok 4.3 的 API 基本信息。
模型名是 grok-4.3，别名是 grok-4.3-latest。最醒目的数字是 1,000,000 tokens 上下文窗口。价格也写得很直接：输入 $1.25/百万 tokens，缓存输入 $0.20/百万 tokens，输出 $2.50/百万 tokens。
但我更在意的不是“又多了一个新模型名”。
文档没有 benchmark，没有发布会叙事，也没有证明它比 GPT、Claude 或上一代 Grok 更强。现在能判断的只有一件事：Grok 4.3 已经被放进开发者可以计算、可以接入、可以压测的 API 选项里。
这件事的核心矛盾也很清楚：100 万上下文降低了很多应用的架构麻烦，但 200K 之后的更高计费规则，会决定它到底是省钱，还是只是看起来省事。
核心参数：它更像给开发者看的工程入口
Grok 4.3 这页文档有几个信息，比模型宣传词更重要。
| 项目 | 文档信息 | 对开发者的直接影响 |
|---|---|---|
| 模型名 | grok-4.3，别名 grok-4.3-latest | 可固定版本，也可跟随 latest 调用 |
| 上下文窗口 | 1,000,000 tokens | 可处理长文档、长会话、代码库片段 |
| 能力 | function calling、structured outputs、reasoning | 能接工具、返回结构化结果，适合业务流程 |
| 区域 | us-east-1、eu-west-1 | 当前主要覆盖美东和西欧 |
| 限流 | 1,800 RPM，10,000,000 TPM | 可支撑一定规模并发，但仍要按业务峰值压测 |
100 万 tokens 的价值，不只是“能塞更多字”。
过去做长文档问答、合同审阅、代码库分析，常见做法是切片、向量检索、摘要链，再把结果拼回模型上下文。这个方案能用，但会带来召回误差。模型没看到的材料，后面再会推理也补不回来。
更长上下文会让一部分应用少绕几步。
比如单个项目的代码分析、较长的客服会话、企业制度包、合同附件包，原来可能要拆成多轮处理。现在可以把更多原始材料放进一次调用里，让模型直接在更完整的上下文里工作。
但这里不能偷换概念。
文档只说明它支持 1,000,000 tokens 上下文，不等于每个任务都应该塞到 100 万。长上下文会增加输入成本，也会影响延迟和稳定性。对工程团队来说，窗口变大只是少了一道墙，不是不用做取舍。
价格：便宜的是常规调用，分水岭是 200K
Grok 4.3 的 API 价格看起来有吸引力，但要按 token 账本读，不能按 C 端订阅价理解。
| 计费项 | 文档价格 |
|---|---|
| 输入 tokens | $1.25 / 1M tokens |
| 缓存输入 tokens | $0.20 / 1M tokens |
| 输出 tokens | $2.50 / 1M tokens |
| 超过 200K context window | 文档显示采用更高计费规则 |
缓存输入是这里最该看的数字。
很多企业应用并不是每次都给模型一段全新的材料。系统提示词、产品文档、制度手册、固定代码仓库、客服知识库，经常会重复出现。缓存输入降到 $0.20/百万 tokens，意味着这类重复上下文的边际成本可能明显下降。
这会影响开发者的设计选择。
如果一个内部知识助手每天反复读取同一批资料，团队可以更积极地测试缓存命中率，而不是只盯着原始输入价。如果一个代码问答工具总是在同一个仓库里工作，缓存策略就不再是优化项，而是成本模型的一部分。
问题在 200K 之后。
文档明确写到，超过 200K context window 的请求会采用更高计费规则。这里不能拿 $1.25/百万 tokens 直接推满 100 万 tokens 的账。真实成本要分两段看：200K 内是一种账，200K 外是另一种账。
所以，技术负责人不应该只问“它有没有 100 万上下文”。更该问三件事：
- 真实业务请求里，有多少比例会超过 200K？
- 超过 200K 的请求，是必须完整放入，还是可以用检索、摘要、分段来压回去？
- 缓存输入能覆盖多少重复材料，平均成本能降到什么水平？
这比比较单次标价更有用。
没有公开 benchmark 的情况下，也不适合把 Grok 4.3 写成某个模型的替代品。现在更稳妥的判断是：它提供了一个长上下文、较低常规输入价、带缓存机制的 API 选择，但性能、延迟、稳定性和任务质量都要靠真实业务样本验证。
谁最该动：开发者先压测，技术决策者先算边界
受影响最大的不是普通聊天用户，而是两类人。
一类是 AI 应用开发者。
如果你在做文档审阅、长对话助理、代码库问答、企业知识助手，Grok 4.3 值得进评估表。动作不复杂：拿真实样本跑三组测试，分别控制在 200K 内、接近 200K、超过 200K。看回答质量、延迟、缓存命中率和总成本，而不是只看最大上下文。
另一类是技术决策者。
如果团队已经接入其他模型，不必因为“100 万上下文”立刻迁移。更现实的做法是延后采购拍板，把 Grok 4.3 加进候选池，用同一批业务样本横向压测。没有性能数据时，贸然替换主模型，风险大于收益。
区域也是硬约束。
文档列出的区域是 us-east-1 和 eu-west-1。对服务美国、欧洲用户的团队，这至少给了部署选择。对有亚洲低延迟、数据驻留或合规要求的企业，是否能直接用，还要看自己的网络、合规和数据流转要求。
限流同样不能只看数字。
1,800 RPM、10,000,000 TPM 对很多应用已经不低，但高峰流量、长上下文请求和大输出会一起吃掉 TPM。一个请求如果塞入大量上下文，消耗的不是“1 次调用”这么简单，而是整块 token 预算。
接下来最该看的，不是宣传口径，而是四个硬变量：
| 变量 | 为什么重要 | 建议动作 |
|---|---|---|
| 200K 之后的实际计费 | 决定 100 万上下文能不能常用 | 把超长请求单独建成本模型 |
| 缓存命中率 | 决定平均输入成本 | 用固定知识库和重复提示词压测 |
| 延迟和稳定性 | 决定能不能进生产链路 | 用高峰并发模拟真实流量 |
| 区域与合规 | 决定能不能直接部署 | 对照数据驻留和跨境要求 |
Grok 4.3 现在给开发者的不是一个确定答案，而是一张值得重算的账单。
它让长上下文应用少了一些架构绕路，也让缓存输入有了更明确的成本价值。但 200K 之后的计费规则，会把“能不能做”和“值不值得做”分开。
看清这条线，比记住 100 万这个数字更重要。