Grok 4.3

Grok 4.3 是 xAI 在 Grok 4 系列之后推出的旗舰模型,它和上一代最大的区别不在于参数堆叠,而在于产品取向的重新对齐:推理(reasoning)不再是一个可以开关的模式,而是写进了模型的默认行为——每次请求它都会先"想"再答。对应用开发者来说,这意味着你不需要再为"要不要开思考链"纠结,但也意味着你拿到的每一次回复背后都带着推理 token,这一点会直接体现在成本结构上(下文展开)。

xAI 官方对 Grok 4.3 强调的三个卖点很务实:更强的 agentic 工具调用(tool calling)、更强的指令遵循(instruction following)、以及以更低价格提供长上下文能力。换句话说,它不是冲着"作文写得更漂亮"去的,而是冲着"在多步骤、要调外部工具、要严格按指令办事的自动化流水线里更可靠"去的。这正好是做 Agent、做 RAG、做客服自动路由的工程师最在意的几个维度。

它支持原生视觉输入(text + image 进,text 出)、文件输入、Web 搜索和隐式缓存(implicit caching)。配合官方主打的低幻觉率,Grok 4.3 的画像是一个"敢放进生产链路、敢让它自己调工具"的执行型模型,而不是一个只适合做 demo 的演示型模型。

相比 Grok 4 这种上一代旗舰,Grok 4.3 在输入和输出单价上都做了大幅下调——这是 xAI 这次最有攻击性的动作,把一个长上下文 + 强推理的模型拉到了一个对高并发应用友好的价位带。但单价只是故事的一半,具体的输入价、输出价、缓存输入价请以本页上方的实时价格表为准(算盘每日核对官方页,避免你拿到过期的博客数字)。

真正影响实际成本的有三件事。第一是缓存输入价:Grok 4.3 支持隐式缓存,如果你的 Agent 反复带着同一份长 system prompt、同一份知识库前缀或同一段工具定义,命中缓存的那部分会按远低于常规输入的价格计费。对 RAG 和多轮 Agent 来说,这块的省钱幅度往往比单价下调更可观,值得专门设计 prompt 结构去最大化缓存命中。

第二是长上下文的阶梯计价:Grok 4.3 对超过一定 token 阈值(官方在 20 万 token 量级上设了更高的上下文档位)的请求采用更高的单价。也就是说,把整本文档、整个代码仓库一股脑塞进 1M 窗口虽然技术上可行,但越过阈值后每 token 更贵,务必先做检索/裁剪,只把真正相关的片段喂进去。第三是工具调用的额外计费:Web 搜索、代码执行、文件检索这类内置工具是单独收费的,Agent 跑得越自主,工具调用越多,成本的可预测性就越差——做成本核算时一定要把工具费单列,不能只看 token 单价。

最适合 Grok 4.3 的,是那些"多步骤 + 要调工具 + 要严格守规矩"的任务:agentic 研究助手、需要复杂分流的客服自动化、带调试循环的编码助手、以及对事实准确性要求高的信息抽取。它的强指令遵循意味着你写的 JSON schema、输出格式约束、工具使用规则更容易被照做,这对要把 LLM 输出直接喂给下游程序的流水线非常关键——少一次格式纠错的重试,就是少一次成本和延迟。

它同样适合高并发、对成本敏感但又需要真推理的批处理场景。因为推理是默认开启的,你拿到的不是"快但浅"的回答,而是带着思考过程的结论;配合下调后的单价,它在"既要质量又要规模"的中间地带性价比很突出。

不适合的场景也很清楚。第一,需要超过 1M token 上下文的任务——Grok 4.3 的窗口是 1M,如果你的真实需求是塞进比这更大的语料,需要另选窗口更大的型号或改用检索架构。第二,对成本绝对可预测的全自主 Agent:工具调用引入的费用波动会让"每次任务花多少钱"难以锁死,预算极紧的场景要谨慎放权。第三,纯粹追求最低延迟的轻量任务(比如简单分类、短改写),让一个默认带推理 token 的旗舰去做是浪费——这类活该降级到更轻更快的型号。

在 xAI 自己的产品线里,选择逻辑相当干净。如果你之前用的是 Grok 4 / Grok 4 系列的老旗舰,Grok 4.3 几乎是直接的升级路径——更强的工具调用和指令遵循,加上明显更低的单价,大多数 Agent 场景没有理由留在旧型号上。但有一个例外:如果你的核心瓶颈是"上下文窗口要尽可能大"(比如一次性塞超大文档),那么窗口更大的同代型号反而更合适,这是一个"推理质量 vs 最大上下文"的取舍。另外,如果你的任务是纯写代码、追求快和便宜,可以考虑降级到 xAI 专门的代码/快速型号,把 Grok 4.3 留给真正需要推理和工具编排的环节。

横向跟其它厂商的旗舰比,Grok 4.3 的差异化主要在"agentic 可靠性 + 长上下文 + 低价"这个组合拳上,而不是在单一 benchmark 跑分上(各家分数互有高低,建议以你自己的私有评测集为准,别只信任何一家的官方数字)。它特别适合那种"工具调用多、要严格守格式、又跑量大"的工程化场景。

什么时候该升级到它:当你的现有方案频繁出现工具调用调错、不守输出格式、或者长上下文成本扛不住时。什么时候该降级离开它:当任务退化成简单的短文本处理、不需要推理也不需要工具时,继续用旗舰只是在为用不上的推理 token 付费。最稳妥的做法,是先用一小批真实流量做对照评测,把 token 成本 + 工具费 + 重试率一起算进单位任务成本,再决定升降级——别只看价格表上的单价就拍板。