OpenAI SDKのbase URLを差し替える
すでにOpenAI SDKで動いているアプリをここへ向けるには、base URLとキーの二か所を変えるだけです。/v1/chat/completionsと/v1/responsesの両方を提供し、ストリーミングもツール呼び出しもそのまま通ります。四つのエイリアスは直接使え、既存のモデル名も重量級として読みます。
すでにOpenAI SDKと話しているアプリケーションを、私たちと話させるために書き直す必要はありません。動くのは二つだけです。クライアントを組み立てるbase URLと、認証に使うキー。その二行の上と下にあるもの — 呼び出しそのもの、messages、各種パラメーター、返ってきた答えの読み方 — は、あなたが書いたそのままで変わりません。
変えるのはこの二行だけ
Pythonでは、base URLとキーがそのままクライアントを組み立てる二つの引数です。コンストラクタから先の行は、どれも私たちのものではありません。
import os
from openai import OpenAI
client = OpenAI(
base_url="https://aifromu.com/v1",
api_key=os.environ["AIFROMU_API_KEY"],
)
resp = client.chat.completions.create(
model="terra",
messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)
Nodeでも同じ二つを、クライアントを組み立てるオブジェクトの中に置きます。
import OpenAI from "openai";
const client = new OpenAI({
baseURL: "https://aifromu.com/v1",
apiKey: process.env.AIFROMU_API_KEY,
});
const resp = await client.chat.completions.create({
model: "terra",
messages: [{ role: "user", content: "Hello" }],
});
console.log(resp.choices[0].message.content);
キーは顧客ポータルから受け取ります。サインインしてKeysのページを開けば、そこで受け取ったキーが、このクライアントが送るキーです。上の二つの例がどちらもファイルではなく環境変数から、AIFROMU_API_KEYという名前で読んでいるのは、コードと並べて置かれたキーは、誰かがリポジトリをcloneした瞬間に入れ替えなければならないキーだからです。
二つのエンドポイント、ストリーミング、ツール
ここでは/v1/chat/completionsと/v1/responsesの両方を提供しています。ですから、あなたのコードがすでに呼んでいるほうを、そのまま呼び続けられます — 入ってくるために二つの間を移行する必要はありません。ストリーミングはそのまま通り、ツール呼び出しも同じです。リクエストはあなたが書いた形のまま上がり、イベントはSDKがすでに解析している形のまま返ってきます。
書いてあるモデル名はどう扱われるか
四つのエイリアス — astra、sol、terra、luna — はそのまま使えます。どれかを名指したクライアントは、そのカードのモデルをちょうど求めていることになります。一方、OpenAIのモデル名を名指したクライアントは、その名前の重量級として読まれます。miniやnanoの付いた名前はlunaとして、ふつうの4系の名前はterraとして、frontierやo系の名前はsolとして、gpt-6の名前はastraとして提供されます。base URLを移したあとの最初のリクエストでも、手を付けていないmodelの一行がそのまま動くのはこのためです。そして、かかった分がそのまま課金されます — 求めた名前ではなく、実際にそのリクエストを提供した種別で。
どこにも当てはまらない名前は推測されません。リクエストは拒否され、その文面が四つのモデルの名前を挙げます。ですから設定の誤りは、請求書の上で見つけるものではなく、最初の呼び出しで目に見えるものになります。推測するほうが悪い失敗です。黙っているからです — 種別を取り違えて読まれた名前は、ある利用者には原価を割って提供し、別の利用者には受け取っていない性能の代金を請求します。そして、どちらのリクエストにもそれを告げる箇所はありません。
動いたかを確かめ、エラーを読む
最初の呼び出しが、検証のすべてです。答えが返ってくれば、base URLもキーもどちらも正しく、ファイルの他のどこも変える必要はなかったということです。返ってこなければ、その拒否が二つのうちどちらだったのかを教えます — 使えないキーは無効なキーとして答えられ、このゲートウェイが提供していないモデルは、提供している四つの名前とともに答えられます。
そこから先のエラーも同じように正直です。上流がリクエストを拒否したとき、上流が示した検証の理由は、一つの不透明な文字列に潰されるのではなく、そのままあなたに渡ります。ですから、コンテキストが長すぎたことも、どのパラメーターが誤っていたことも、答えそのものが述べます。429ではRetry-Afterが保たれます。各SDKが自分の再試行の間隔を測っているのがこのヘッダーだからで、それを落として中継されたレート制限は、あなたのクライアントが当て推量するしかないレート制限です。
どこにも当てはまらない名前は推測されません。リクエストは拒否され、その文面が四つのモデルの名前を挙げます。ですから設定の誤りは、請求書の上で見つけるものではなく、最初の呼び出しで目に見えるものになります。
本記事は機械翻訳です。ネイティブによる確認は未了で、英語版が正本です。