LLMストリームからの不明なエラー：原因と修正方法

メッセージが実際に伝えていること

unknown error from llm stream learn moreを検索した場合は、チャットフロントエンド、エディタープラグイン、またはエージェントフレームワークのトーストや赤い行を表示している可能性があります。この表記はクライアント由来です。これはアプリがストリーミングされた応答をリクエストしたが、ストリーミングの前または中に問題が発生し、アプリがそれを説明する方法がなかったことを意味します。API自体はHTTPステータスとJSONエラー本文で問題を報告し、クライアントはその詳細を破棄しました。

これは良い知らせです。つまり、詳細を取り戻すことができるということです。クライアント外で同じリクエストを送信し、ステータス行とボディを読み取ってください。1 回または 2 回の試行で原因が明らかになることがほとんどです。このページの残りの部分では、この API で発生する傾向のある順序で原因を調べ、隠さずに実際のエラーを出力する小さなストリーミングクライアントを提供します。

最初から覚えておくべきことの1つ：ストリーミングリクエストには2つの失敗ポイントがあります。最初のバイトが届く前に失敗するか、サーバーがリクエストを拒否した場合（キーが間違っている、URLが間違っている、制限に達した）です。または、テキストの一部が到着した後に接続が切断された場合、ストリームの途中で失敗する可能性があります。修正方法は異なるため、どちらのタイプが発生したかに注意してください。応答が開始しない場合は、セクション2〜4を参照してください。応答が開始して途中で停止する場合は、プロキシとタイムアウトに関するセクションを参照してください。

Base URL、キー、モデルを最初に確認する

新しいセットアップでのストリーミングエラーのほとんどは、3 つの小さなミスから発生します。これらを確認するには数分かかります。

1. Base URL。 https://api.uncensoredllmhub.com/v1 である必要があります。/v1 を含み、末尾に /chat/completions を付けないでください。クライアントはパスを自身で付加します。Base を期待するフィールドに完全なエンドポイントを貼り付けると、存在しないパスがリクエストされ、曖昧な失敗が報告されます。
2. キー。 ヘッダーは Authorization: Bearer YOUR_KEY です。余分なスペース、キーと一緒にコピーされた改行、または別のサービスのキーは、すべて同じ方法で失敗します。確実でない場合は、API キーページからキーを再作成またはコピーしてください。
3. モデル ID。 唯一のモデルは uncensored です。ドロップダウンを提供するクライアントは、他のプロバイダーの名前を事前に入力することがよくあります。ID を手動で入力し、サーバーがリストしている内容を確認する場合は GET /v1/models を呼び出してください。

これら 3 つを一度にテストする簡単な方法は、models 呼び出しを使用することです。ストリーミングしないため、接続またはキーの問題をストリーミングの問題から分離できます。

Copycurl -i https://api.uncensoredllmhub.com/v1/models   -H "Authorization: Bearer $API_KEY"

これが通常のリストを返す場合、URL とキーは正常であり、それらを疑うのをやめられます。ストリーミングに関する操作を行う前に、失敗の場合はそれを修正してください。また、アカウントにクレジットがあることを確認してください。API はレスポンスの X-Balance-USD ヘッダーに残高を送信します。これは、キーが大量の使用後に突然機能しなくなった際に便利です。料金ページ でチャージの仕組みが説明されており、新しいアカウントはキーページから $0.50 のトライアルを受け取ることができます。

レート制限とスロットを保持するストリーム

次に多い原因はHTTP 429です。3つの種類があり、クライアントはそれらすべてを同じ役に立たないメッセージにまとめます。

同時実行数の制限は、ストリーミングの仕組みにより、人々を驚かせるものです。ストリーミングリクエストは、最初のトークンが届くまでではなく、ストリームが終了するまでスロットを占有します。アプリがメッセージごとにストリームを開き、古いストリームを閉じない場合（例えば、ユーザーがナビゲーションを離れ、UI がリクエストをキャンセルすることを忘れた場合）、それらのスロットは占有されたままになります。制限が 2 のトライアルキーでは、2 つの放棄されたストリームだけで、3 番目のメッセージが失敗する可能性があります。

症状は一貫しています。最初の数回のメッセージは機能しますが、その後エラーが発生し、短い待機後にすべてが再び機能します。これが一致する場合、不要なストリームを中止（ブラウザでは AbortController、サーバーでは応答を閉じる）し、独自のコードでの同時呼び出しの数を制限してください。エージェントは通常、違反者です。一度に 10 の関数呼び出しを発生させるプランナーは、トライアルキーですぐに制限に達します。

応答ヘッダーは、現在の状況を確認するのに役立ちます。X-RateLimit-Limit-Requests と X-RateLimit-Limit-Concurrency は、使用したキーに適用される制限を示し、X-Request-Id は、サポートに問い合わせる必要がある場合に呼び出しを識別します。

リクエストサイズとコンテキストの長さ

リクエストが大きすぎるため拒否されることもあります。2 つの数字が重要です。ボディは最大 8 MB まで、プロンプトと補完は 100,000 トークンのコンテキストウィンドウに収まる必要があります。すべてのターンで会話全体を再送信するチャットフロントエンドは、これらの制限にゆっくりと到達し、その後一気に到達します。チャットは 1 時間機能しますが、1 つの長いメッセージや貼り付けられたファイルがそれを超過し、履歴がリクエストに含まれたままになるため、後続のすべてのターンが失敗します。

エラーが長いセッションの後に始まる場合は、短い新しい会話でテストしてください。それが機能する場合、履歴が原因です。古いターンを削除するか、それらを 1 つのメッセージに要約するか、新しいチャットを開始することで履歴を削減してください。貼り付けられた大きなドキュメントも他のトリガーです。数 100 キロバイトのテキストファイルは問題ありませんが、base64 ブロブや非常に大きなログは、予想以上に早く 8 MB に達する可能性があります。

ウィンドウの残りを補完が使用できるため、max_tokens を設定する必要はありません。設定する場合は、プロンプトトークン数と max_tokens の合計が 100,000 を下回ることを確認してください。長い履歴の上に大きな max_tokens をハードコードしたクライアントは、プロンプト単体では問題ないように見えても、合計をウィンドウを超えてしまう可能性があります。

プロキシ、バッファリング、タイムアウト

ストリーミングはサーバー送信イベントを使用します。これは、生成されるたびに小さなチャンクを配信する長期の HTTP 応答です。あなたと API の間に、全体が到着するまで待機してから転送するものがあれば、それが壊れます。結果は、長い沈黙に続くバースト、またはタイムアウトと一般的なエラーのいずれかになります。

独自のセットアップでこれらを探してください。

• リバースプロキシ。 API を nginx や類似のプロキシ経由でルーティングする場合は、そのパスでレスポンスバッファリングを無効にし、読み込みタイムアウトを期待する最長の回答より長く設定してください。100,000 トークンのコンテキストウィンドウからの長い回答には時間がかかる場合があります。
• 企業用またはアンチウイルスプロキシ。 一部のプロキシは HTTPS トラフィックを監視し、ボディを保持します。これを除外するために、携帯電話のホットスポットからテストしてください。
• サーバーレス関数。 多くのプラットフォームは、ストリーミングをオプトインしない限り、実行時間または応答のバッファリングを制限します。ストリームが毎回同じ秒数で死亡する場合、プラットフォームの実行時間制限が原因である可能性が高いです。
• ブラウザ拡張機能と VPN。 稀ですが、アイドル接続を切断する可能性があります。

ここを指す手がかりは、応答の途中でエラーが発生し、すべての試行で同じ切断時間があることです。レート制限はリクエストの開始時に拒否するため、ストリーミング途中の切断で、例えば30秒で常に発生するものは、ほとんどが制限ではありません。

実際のエラーを表示するクライアント

丁寧なメッセージではなく、実際のエラー詳細を知りたい場合に使用します。これは OpenAI SDK の例外をキャッチし、ステータスとエラーボディを出力し、リトライのヒントがある場合はそれを読み取ります。

Copyimport time
from openai import OpenAI, APIConnectionError, APIStatusError, RateLimitError

client = OpenAI(
    base_url="https://api.uncensoredllmhub.com/v1",
    api_key="YOUR_API_KEY",
)

def stream_once(messages):
    stream = client.chat.completions.create(
        model="uncensored",
        messages=messages,
        stream=True,
    )
    for chunk in stream:
        if chunk.choices and chunk.choices[0].delta.content:
            print(chunk.choices[0].delta.content, end="", flush=True)
        if getattr(chunk, "usage", None):
            print("\n[usage]", chunk.usage)

messages = [{"role": "user", "content": "Write two sentences about harbours."}]

for attempt in range(4):
    try:
        stream_once(messages)
        break
    except RateLimitError as e:
        wait = int(e.response.headers.get("retry-after", 5))
        print("429:", e.body, "- waiting", wait, "s")
        time.sleep(wait)
    except APIStatusError as e:
        print("status", e.status_code, e.body)
        print("request id:", e.response.headers.get("x-request-id"))
        break
    except APIConnectionError as e:
        print("connection problem:", e)
        time.sleep(2)

Node での同じアイデア。中止シグナルにより、放棄されたストリームはスロットを解放します。

Copyimport OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.uncensoredllmhub.com/v1",
  apiKey: process.env.API_KEY,
});

const controller = new AbortController();

try {
  const stream = await client.chat.completions.create(
    {
      model: "uncensored",
      messages: [{ role: "user", content: "Write two sentences about harbours." }],
      stream: true,
    },
    { signal: controller.signal }
  );
  for await (const chunk of stream) {
    process.stdout.write(chunk.choices[0]?.delta?.content ?? "");
  }
} catch (err) {
  console.error("status:", err.status, "body:", err.error);
}
// call controller.abort() when the user leaves the page

生 curl 呼び出し。これにより、クライアント層が完全に除外されます。-N は curl 自身のバッファリングを無効にし、-i はステータス行とヘッダー（X-Request-Id を含む）を出力します。

Copycurl -N -i https://api.uncensoredllmhub.com/v1/chat/completions   -H "Authorization: Bearer $API_KEY"   -H "Content-Type: application/json"   -d '{"model":"uncensored","stream":true,"messages":[{"role":"user","content":"Say hello."}]}'

curl でテキストのストリーミングが正常に動作し、アプリがストリーミングしない場合、API は正常であり、問題はアプリ、そのプロキシ、またはその設定にあります。curl が 429 または他のステータスを返す場合、すでに正確な原因が分かっています。

状況を悪化させないリトライルール

再試行は一時的な問題には役立ちますが、恒久的な問題には逆効果です。短いポリシー設定にしておけば、トラブルを避けることができます。

• 429 と接続の切断を再試行します。存在する場合は Retry-After を待ち、存在しない場合は数秒バックオフし、並列ワーカーがロックステップで再試行しないようにランダムなジッターを追加します。
• 認証の失敗やリクエストサイズの超過は再試行しないでください。結果は変わらず、各再試行はノイズを追加するだけです。
• 試行回数を 3〜4 回に制限し、その後、ユーザーに実際のエラーテキストを表示します。
• 並列実行数をキーの制限値以下に抑えてください。フルキーに対してセマフォを6に設定すると、同じキーを使用する2番目のツールのための余裕が生まれます。
• ストリームが途中で切断された場合、部分的なテキストを保持してください。そのテキストをアシスタントメッセージとして再送信し、モデルに継続を依頼してください。

失敗または拒否されたリクエストは課金されないため、繰り返しテスト呼び出しでデバッグしてもクレジットが枯渇しません。成功した呼び出しは、1M 入力トークンあたり $0.15、1M 出力トークンあたり $0.50 で課金され、通常完了する部分的なストリームは単に短い応答です。リクエスト形式の詳細は API ドキュメント にあります。

上記のすべてを行い、それでもメッセージが表示される場合は、失敗した呼び出しの X-Request-Id を試行時刻と、失敗が最初のトークンの前か後かを示す情報とともに サポートページ に送信してください。この情報で何が起きたか追跡するのに十分です。

その他のガイド

• LLMを自分でホストする方法、またはAPIでスキップする方法
• Uncensored LLM Hub：チャットとエージェントの単一エンドポイント
• 検閲なし Ollama モデル vs ホスト API