马斯克在 X 上放了一则简短公告：Grok 基座模型 V9-Medium 已完成训练，参数量 1.5 万亿，评估表现良好，预计 2-3 周内公开发布。最值得注意的不是数字本身，而是他特意提到训练数据中加入了大量 Cursor 数据——一个以代码补全和编辑场景闻名的 IDE 工具。这暗示 xAI 在模型能力方向上做了一个明确选择：把编码能力拉到前台。
1.5 万亿参数意味着什么
1.5 万亿（1.5T）参数在当前公开模型中属于顶级梯队。对比来看：
| 模型 | 公开参数量 |
|---|---|
| Llama 3.1 405B | 4050 亿 |
| DeepSeek V3 | 6710 亿（MoE，激活约 37B） |
| Grok V9-Medium | 1.5 万亿 |
参数量本身不等于质量，但它决定了模型的容量上限——尤其是当训练数据也同步扩展时。V9-Medium 作为 xAI 参数量最大的公开版本之一，大概率采用了 MoE（混合专家）架构来控制推理成本，否则 1.5T 密集模型的部署门槛会极高。马斯克没有披露架构细节，但从实际发布节奏推断，MoE 是最合理的猜测。
Cursor 数据的加入是关键信号
马斯克明确说"加入了大量 Cursor 数据进行补充训练"，并且后续还有更多相关数据会陆续加入。Cursor 是一款基于 AI 的代码编辑器，核心交互是：用户在 IDE 中写代码、发出编辑指令，模型返回补全或修改结果。这类数据包含几个独特维度：
- 多轮编辑上下文：不是单次 prompt-response，而是连续的文件级修改链。
- 意图与代码的对齐：用户的自然语言指令和最终代码变更之间有明确的映射。
- 错误修复轨迹：编译失败、lint 报错后的修正过程，天然包含"发现问题→定位→修复"的推理链。
这意味着 V9-Medium 在代码生成和编辑场景上大概率会有显著提升，不只是"写一段函数"，而是"在现有项目里做精准修改"。对于日常依赖 AI 编程助手的开发者来说，这个方向比通用对话能力更实用。
实际接入：用 xAI API 调用 Grok 模型
V9-Medium 还没发布，但 xAI 的 Grok API 已经可用。当前公开的模型端点以 grok-2 系列为主。下面的示例展示如何用 Python 调用 Grok 完成一次代码编辑任务——这正是 V9-Medium 发布后预期会强化的场景。
先安装依赖：
pip install openai
然后运行以下脚本（需要先在 console.x.ai 获取 API Key）：
import os
from openai import OpenAI
# xAI 的 API 兼容 OpenAI SDK，只需改 base_url
client = OpenAI(
api_key=os.environ.get("XAI_API_KEY"),
base_url="https://api.x.ai/v1",
)
# 模拟一个 Cursor 式的代码编辑任务
system_prompt = """你是一个代码编辑助手。用户会给你一段现有代码和修改意图，
你只输出修改后的完整代码，不输出解释。"""
existing_code = """
def fetch_user_stats(user_id):
resp = requests.get(f"https://api.example.com/users/{user_id}")
return resp.json()
"""
user_intent = "给 fetch_user_stats 加上超时重试：最多重试 3 次，每次超时 5 秒，最终失败抛 ConnectionError。"
response = client.chat.completions.create(
model="grok-2-latest", # V9-Medium 发布后替换为对应模型名
messages=[
{"role": "system", "content": system_prompt},
{"role": "user", "content": f"现有代码:\n{existing_code}\n修改意图: {user_intent}"},
],
temperature=0.2, # 代码编辑场景用低温度减少随机性
)
print(response.choices[0].message.content)
预期输出类似：
def fetch_user_stats(user_id, retries=3, timeout=5):
for attempt in range(retries):
try:
resp = requests.get(
f"https://api.example.com/users/{user_id}",
timeout=timeout,
)
return resp.json()
except requests.exceptions.Timeout:
if attempt == retries - 1:
raise ConnectionError(
f"Failed to fetch stats for user {user_id} after {retries} retries"
)
continue
几点说明：
base_url指向 xAI 的端点，SDK 其余用法与 OpenAI 完全一致。- V9-Medium 发布后，
model参数替换为新模型名（大概率是grok-v9-medium或类似格式），届时关注 xAI 官方文档更新。 - 低
temperature对代码编辑场景很重要——你需要确定性输出，不是创意写作。
如果你想在本地预置类似工作流
Cursor 数据的训练价值在于"上下文感知编辑"。即使不用 Grok API，你也可以在本地用开源模型搭建一个简化版：
# 用 Ollama 拉一个支持代码编辑的模型
ollama pull qwen2.5-coder:7b
# 启动后用 REST 接口调用
curl http://localhost:11434/api/chat -d '{
"model": "qwen2.5-coder:7b",
"messages": [
{"role": "system", "content": "你是一个代码编辑助手，只输出修改后的完整代码。"},
{"role": "user", "content": "现有代码:\ndef hello():\n print(\"hi\")\n修改意图: 改为打印当前时间"}
],
"stream": false
}'
这个本地方案在复杂多文件编辑上远不如 Cursor + 大模型的组合，但作为轻量替代足够处理单文件修改。等 V9-Medium 上线后，你可以把上述 Ollama 调用替换为 xAI API 调用，直接获得更强的编辑能力。
发布前的准备清单
V9-Medium 两三周内就会上线，现在可以做几件事：
- 注册 xAI API Key——如果还没有，去 console.x.ai 申请，目前开放注册。
- 梳理你的代码编辑 prompt 模板——把日常用 Cursor 或 Copilot 的交互模式整理成 system prompt + user prompt 的固定格式，方便切换模型后直接复用。
- 关注 MoE 推理成本——1.5T 参数即使走 MoE 路线，单次调用成本也可能高于当前 grok-2 系列。评估你的批量任务预算。
- 留意数据合规边界——Cursor 数据用于模型训练引发了社区对用户代码隐私的讨论。如果你在团队中引入 Grok，需要确认内部代码是否适合通过第三方 API 传输。
参数量是招牌，Cursor 数据才是 V9-Medium 真正的差异点。一个在"理解编辑意图→精准修改代码"这条链路上专门强化过的 1.5T 模型，对每天和 IDE 打交道的开发者来说，比又一个通用聊天模型有用得多。等它上线，跑几个你日常的编辑任务对比一下，结果会比任何 benchmark 数字更说明问题。