AI From U AI FROM U.COM

ブログ / ガイド

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が自分の再試行の間隔を測っているのがこのヘッダーだからで、それを落として中継されたレート制限は、あなたのクライアントが当て推量するしかないレート制限です。

どこにも当てはまらない名前は推測されません。リクエストは拒否され、その文面が四つのモデルの名前を挙げます。ですから設定の誤りは、請求書の上で見つけるものではなく、最初の呼び出しで目に見えるものになります。

本記事は機械翻訳です。ネイティブによる確認は未了で、英語版が正本です。