モデル名の打ち間違いが「接続エラー」で返ってきます ── LiteLLM と Ollama を読む

氷河期世代のクラウドエンジニア、terralien です。「まずローカルの Ollama で試して、うまくいったらクラウドの API に切り替えます」という進め方は、費用の面でも学習の面でもとても良い手だと思っています。実際そうしています。

ただ、その切り替えのときに詰まる場所は毎回決まっていて、しかもエラーメッセージが原因を教えてくれないところに集中しています。

用途 ── 揃えてくれるのは「呼び方」だけです

LiteLLM は、100以上の提供元を litellm.completion(model=..., messages=[...]) という1つの形に揃えてくれるライブラリです。差し替えが model 文字列1つで済むのは、実際とても楽です。

ただし、揃うものと揃わないものがあります。

代表要素 ── 3つ

ollama/ と ollama_chat/ という2つのプレフィクスがあるのも紛らわしいところです。前者は生成用、後者はチャット用のエンドポイントに繋がります。手元で測った差は、暖機したあとで 0.69秒 対 0.66秒、入力トークンが 27 対 23。速度はほぼ同じで、プロンプトの組み立て方が違うぶんトークンが少し変わる、という程度でした。新しく書くなら ollama_chat/ で問題ありません。

AIが書く例 ── 実際に書かせたもの

手元の Qwen3.8:27b に「LiteLLM で Ollama と OpenAI のどちらにも同じコードで問い合わせる関数を書いて」と頼みました（一字も直していません）。

import litellm

def ask_llm(prompt: str, model: str = "ollama/llama3", api_key: str = None) -> str:
    # Ollama の場合は api_key を "ollama" に設定
    if model.startswith("ollama/"):
        api_key = "ollama"

    response = litellm.completion(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        api_key=api_key
    )
    return response.choices[0].message.content

読みやすいですし、コメントまで日本語で付いています。そしてこの関数は、こちらの環境では既定値のままだと動きません。ollama/llama3 が入っていないからです。

このコードには、これから見る3つの穴が全部入っています。

監査① ── モデル名は3階層あり、どこがズレても似た顔で落ちます

model 文字列は provider/model:tag の3階層です。それぞれを1つずつ壊して投げました。

provider 抜けだけは BadRequestError で、しかもメッセージが親切です。ここは問題ありません。

問題は下2つで、モデルが「入っていない」のか「名前を間違えた」のかを、エラーは区別していません。どちらも not found です。ollama pull を忘れただけなのか、gemma4 を gemma-4 と書いたのか、実行時には分かりません。

読むときの監査ポイントは、モデル名がリテラルで散らばっていないかです。

# ❌ AIが書いた形。既定値が実在するかどうか、実行するまで分からない
def ask_llm(prompt, model="ollama/llama3"): ...

# ✅ 起動時に1回だけ確かめる（ollama なら /api/tags で一覧が取れる）
AVAILABLE = {m["name"] for m in httpx.get(f"{OLLAMA}/api/tags").json()["models"]}
if MODEL.split("/", 1)[1] not in AVAILABLE:
    raise SystemExit(f"{MODEL} が手元にありません。ollama pull してください")

起動時に落とすのが正解です。リクエスト単位で落ちると、原因がユーザーの入力に見えてしまいます。

監査② ── 例外クラスが、原因を表していません

ここが本題です。同じ APIConnectionError が、まったく違う原因で飛んできます。

上3つが同じクラスなのも困りますが、4行目が本当に厄介です。APIキーを設定していないという、こちらの設定ミス以外の何物でもない状態が、500系（サーバ内部エラー）として返ってきます。

これが何を意味するか。よくあるリトライの書き方を思い出してください。

@retry(retry=retry_if_exception_type((APIConnectionError, InternalServerError)),
       stop=stop_after_attempt(5), wait=wait_exponential())
def ask(prompt): ...

「接続エラーとサーバエラーはリトライ対象」——一般論としては完全に正しい設計です。そしてこの設計のもとでは、モデル名のタイプミスと、APIキーの設定漏れが、指数バックオフ付きで5回リトライされます。直るわけがないものを、待ち時間を増やしながら5回試すわけです。

対処は単純で、クラスではなくメッセージで分けるしかありません。

except APIConnectionError as e:
    if "not found" in str(e):       # 設定ミス。リトライしても直らない
        raise SystemExit(f"モデルが見つかりません: {e}")
    raise                            # 本当の接続断。ここだけリトライに乗せる

文字列一致で分岐するのは気持ち悪いですが、気持ち悪さを消すために全部リトライに乗せるほうが高くつきます。

監査③ ── ローカルでは、APIキーは検証されません

AIが書いたコードには api_key = "ollama" というハードコードがありました。文字列 "ollama" に意味があるかを確かめるため、完全にデタラメな値を渡してみました。

ローカル接続は認証しないので、キーが何であろうと通ります。ここが「ローカルで動いたのでクラウドに切り替えます」が滑る場所です。キーを渡す配線が壊れていても、ローカルでは1回もテストされません。

.get() と [] の違いだけで、気づくタイミングが「起動時」から「本番の1リクエスト目」に変わります。AIが書くコードは、ほぼ .get() か引数の既定値 None です。

監査④ ── 最初の1回を、計測に使わない

おまけですが、実害があったので書いておきます。プレフィクスによる速度差を測ろうとして、最初にこういう数字を得ました。

1回目だけ見ると「40倍遅い」という結論になります。実際は、1回目にモデルをメモリへ読み込んでいただけでした。暖機後は誤差の範囲です。

ローカル推論では、モデルのロードが数十秒かかり、一定時間使わないとアンロードされます。AIに書かせたベンチマークコードには、まず暖機処理が入っていません。「ローカルは遅い」という結論が出たら、それが計測の産物でないかを先に疑ってください。こちらは危うく間違った表を載せるところでした。

隣で読むもの

チートシート

この記事を書きながら、ollama/ と ollama_chat/ の速度差の表を一度書いて、消しました。40倍という数字が出た瞬間に「面白い記事になるぞ」と思ってしまったのが良くなかったです。都合のいい数字ほど二度測る、という当たり前のことを、40倍を消すという形で覚え直しました。