文本对话
使用 /v1/chat/completions 完成同步文本生成，从最小消息开始，再按业务需要增加上下文与生成参数。
同步请求适合等待完整结果后再继续处理的场景。需要边生成边展示时，请改用 流式响应。
最小请求
curl -X POST "${BASE_API_URI}/v1/chat/completions" \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer <access-credential-secret>' \
-d '{
"model": "qwen-plus",
"messages": [
{
"role": "user",
"content": "用一句话介绍GGPU API。"
}
]
}'这个请求只保留两个必填信息：model 决定调用哪个模型，messages 描述本轮输入。确认最小请求成功后，再增加可选参数。
组织 messages
messages 是按先后顺序排列的消息列表。每条消息由 role 和 content 组成：
[
{
"role": "system",
"content": "你是产品支持助手，回答保持准确、简洁。"
},
{
"role": "user",
"content": "如何判断一次 API 调用成功？"
}
]多轮对话需要由客户端保存并重新发送必要历史。只保留与当前任务相关的消息，避免无关上下文持续增长。
控制生成结果
例如，在最小请求验证通过后增加生成参数：
{
"temperature": 0.7,
"max_tokens": 512
}读取返回结果
{
"id": "chatcmpl_xxx",
"object": "chat.completion",
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "GGPU API 是一个统一的模型调用入口。"
},
"finish_reason": "stop"
}
],
"usage": {
"prompt_tokens": 20,
"completion_tokens": 18,
"total_tokens": 38
}
}客户端通常按以下顺序处理：
- HTTP 状态码不是
2xx时，进入错误分支并保存响应信息。 - 成功时先确认
choices非空，再读取choices[0].message.content。 - 记录
finish_reason，判断生成是否按预期结束。 - 响应包含
usage时，记录输入、输出与总 Token 用量，便于核对成本。
不要假设每次成功响应都一定有可展示文本。客户端仍需处理空结果、字段缺失和模型返回差异，避免直接解引用导致业务报错。