سازگاری با OpenAI
سازگاری با OpenAI
داتهوش روی /v1/* همان قرارداد OpenAI را میپذیرد: همان مسیرها، همان سرآیندها و همان شکل پاسخ. برای مهاجرت، فقط آدرس پایه و کلید را عوض کنید.
آدرس پایه و احراز هویت
| مقدار | جا |
|---|---|
| آدرس پایه | https://gateway.dothoosh.com/v1 |
| احراز هویت | Authorization: Bearer $DOTHOOSH_API_KEY |
| ترکیب محلی | http://127.0.0.1:58110/v1 |
import os
from openai import OpenAI
client = OpenAI(
base_url="https://gateway.dothoosh.com/v1",
api_key=os.environ["DOTHOOSH_API_KEY"],
)مسیرهای موجود
| مسیر | متد | وضعیت |
|---|---|---|
| /v1/chat/completions | POST | فعال، غیراستریم و استریم |
| /v1/responses | POST | فعال، غیراستریم و استریم |
| /v1/models | GET | فعال، فهرست پویا برای همین key |
| /v1/images/generations | POST | غیرفعال. با unsupported_capability رد میشود |
تولید تصویر عمداً خاموش است، نه از روی غفلت: تا وقتی مخزن رسانه، قلاب ایمنی محتوا و چرخهٔ حذف آن آماده نشده، روشنکردن آن وعدهٔ نگهداری داده را نقض میکند. تا آن زمان هر فراخوانی /v1/images/generations با کد unsupported_capability رد میشود، حتی اگر کلید معتبر باشد.
انتخاب مدل
شناسهٔ مدل را در کد ثابت نکنید. با همان key فهرست را بپرسید:
curl "https://gateway.dothoosh.com/v1/models" \
-H "Authorization: Bearer $DOTHOOSH_API_KEY"شناسهها دقیق هستند. داتهوش زیر بار خطا نسخهٔ دیگری از همان مدل یا «نزدیکترین مدل موجود» را جای آن نمیگذارد؛ اگر مدل دقیق در دسترس نباشد خطا میگیرید، نه پاسخ یک مدل دیگر. اگر همان مدل روی چند مسیر باشد، تلاش دوباره فقط بین همان مسیرها انجام میشود (مسیردهی و تلاش مجدد).
قالب درخواست
فقط model و messages الزامیاند. بقیهٔ فیلدها فقط وقتی پذیرفته میشوند که این مدل و این مسیر آنها را تأیید کرده باشند:
| فیلد | نکته |
|---|---|
| model | شناسهٔ دقیق از GET /v1/models |
| messages | نقشهای system، user، assistant، developer و tool |
| max_completion_tokens | سقف توکن خروجی؛ نام درست همین است |
| stream | true برای پاسخ تدریجی (استریم) |
| temperature، top_p، stop، n | با بازههای استاندارد OpenAI |
| tools، tool_choice | فقط اگر مسیر مدل tool calling را تأیید کرده باشد |
| response_format | فقط برای مدلهایی که خروجی ساختیافتهٔ آنها تأیید شده است |
قالب پاسخ
پاسخ غیراستریم شکل استاندارد chat.completion را دارد و usage را همیشه برمیگرداند. یک افزونهٔ داتهوش هم وجود دارد: reasoning_content روی پیام دستیار، فقط برای مدلهایی که متن استدلال تولید میکنند. این فیلد را در درخواست بعدی برنگردانید.
{
"id": "chatcmpl_…",
"object": "chat.completion",
"model": "YOUR_MODEL",
"choices": [
{
"index": 0,
"message": { "role": "assistant", "content": "…" },
"finish_reason": "stop"
}
],
"usage": { "prompt_tokens": 42, "completion_tokens": 118, "total_tokens": 160 }
}چه چیزی پشتیبانی نمیشود
- مسیرهایی که در جدول بالا نیستند. embeddings، audio، fine-tuning و assistants/files از این gateway عبور نمیکنند (not proxied) و مسیری برای آنها وجود ندارد.
- پارامترهای مخصوص یک ارائهدهنده که برای این مسیر تأیید نشدهاند: بهجای عبور بیصدا، unsupported_parameter میگیرید.
- قابلیتی که مسیر این مدل آن را اعلام نکرده است (برای نمونه tools روی مدلی که تأیید نشده): unsupported_capability.
این سختگیری عمدی است: پارامتری که بیصدا نادیده گرفته شود، نتیجهای میدهد که نمیتوانید به آن تکیه کنید.
وضعیت فعلی سرویس
سرویس فعال است. اگر سامانه برای نگهداری موقتاً در دسترس نباشد، دامنهٔ عمومی روی /v1/* پاسخ کاتالوگشدهٔ maintenance_mode میدهد: 503 با type: "provider_error"، سرآیند X-Request-Id و Retry-After: 120. جزئیات در شروع سریع آمده است.
مطالب مرتبط
گام بعدی
داتهوش مسیر بومی Anthropic Messages را هم ارائه میدهد: POST /anthropic/v1/messages با همان قالب درخواست، همان رویدادهای استریم و همان پوشش خطا. SDK رسمی Anthropic و ابزارهایی که روی آن ساخته شدهاند فقط به تغییر آدرس پایه و کلید نیاز دارند.
Claude Code از طریق مسیر سازگار با Anthropic به داتهوش وصل میشود. کل کار دو متغیر محیطی و یک فرمان است.
هر دو مسیر داتهوش استریم را به شکل بومی خودشان ارائه میدهند: رویدادهای Server-Sent Events روی مسیر OpenAI و رویدادهای بومی Anthropic روی مسیر Anthropic. کدی که امروز با SDK خودتان استریم میگیرید، بدون تغییر کار میکند.