分组与倍率
Astra 覆盖全部 6 个 GPT 分组，价格档位与 6 Sol 接近。
| 分组 | 倍率 | 特点 |
|---|---|---|
| GPT-超低价（不保稳定） | 0.1x | 低价混池，价格最低，稳定性不作保证 |
| GPT-pro | 0.2x | 纯 pro 号池，速度与稳定性最好 |
| GPT-稳绿不降智 | 0.24x | 不降智，首字更快 |
| GPT-不降智 | 0.24x | 不做降智处理 |
| GPT-企业 | 0.32x | 企业号池，基本不断线；pro 正常时没必要用 |
| GPT-专用 | 0.4x | 专用号池，含图像生成与 5.x 全系 |
接入信息
接入参数与 6 Sol 相同，只有模型名不同。
| 项目 | 填什么 |
|---|---|
| 模型名（model） | gpt-6-astra |
| Chat Completions 端点 | https://turingapi.space/v1/chat/completions |
| Responses 端点 | https://turingapi.space/v1/responses |
| Base URL（OpenAI SDK） | https://turingapi.space/v1 |
| 认证方式 | Authorization: Bearer sk-xxx |
调用示例
三种写法。
curl（Chat Completions）
curl https://turingapi.space/v1/chat/completions \
-H "Authorization: Bearer $TURING_KEY" \
-H "content-type: application/json" \
-d '{
"model": "gpt-6-astra",
"messages": [{"role": "user", "content": "你好"}]
}'输出长度用 max_completion_tokens 控制；老参数 max_tokens 在新一代模型上可能不被接受。
Python（openai 官方 SDK）
from openai import OpenAI
client = OpenAI(
api_key="sk-你的密钥",
base_url="https://turingapi.space/v1", # 含 /v1
)
r = client.chat.completions.create(
model="gpt-6-astra",
messages=[{"role": "user", "content": "你好"}],
)
print(r.choices[0].message.content)OpenAI SDK 的 base_url 必须带 /v1，这和 Anthropic SDK 正好相反。
Responses 协议
curl https://turingapi.space/v1/responses \
-H "Authorization: Bearer $TURING_KEY" \
-H "content-type: application/json" \
-d '{
"model": "gpt-6-astra",
"input": "你好"
}'Codex CLI 这类新工具走的是 Responses 协议。同一把密钥两个端点都通用。
怎么选分组
长上下文的费用主要不在倍率，在 token 量：
倍率再低，塞进去的 token 还是要付钱。一份几万字的文档反复请求十次，费用会明显高于分段处理。能用检索解决的不要用长上下文硬塞。
长系统提示、固定参考文档放在对话最前面，且保持内容不变，可以命中上游缓存，重复请求的成本会显著下降。
上下文超限会直接报错，不会自动截断。做法是按章节切分、逐段摘要、再合并，比硬凑更稳。
在客户端里用这个模型
长文档类任务常用这几个客户端：
常见问题
上下文长度和费用是两个高频问题。
上下文上限是多少？
以上游号池与分组配置为准，不同分组可能不同。以控制台模型广场展示的数值为准确依据，不要用别处的参数表硬套。
为什么大文件请求会失败？
三种常见原因：超出上下文上限、请求体太大被网关限制、超时。先减半文档重试，能过就说明是体积问题。
多轮长对话怎么控成本？
保留最近若干轮原文，更早的做摘要。不要无脑把全部历史带上——那是长上下文场景最常见的一笔冤枉钱。
和 6 Sol 的差别大吗？
短任务上几乎没差别，长上下文的稳定性上 Astra 更明显。日常问答用 6 Sol 就够。
支持流式吗？
支持，"stream": true 即可。长输出建议一定开流式，否则等待时间长到像卡死。
相关模型
接入过程卡住了？到 QQ 群 1128182538 说明「客户端 + 报错码 + 时间点」，比只说"用不了"好排查得多。其他通用问题见 常见问题。