公開2026.09.10更新2026.09.27 LLM・RAG

Groqとは？LPU推論APIをOpenAI互換で差し替える手順と400・429の回避

Q: OpenAIのSDKをそのまま使えますか？

base_urlを https://api.groq.com/openai/v1 に変え、api_keyにGroqのキーを渡せば、chat.completionsの基本呼び出しは動きます。ただし logprobs 、 logit_bias 、 top_logprobs 、 messages[].name は400になり、 N は1固定です。公式はGroq独自のPython／TypeScriptライブラリの利用も推奨しています。

Groqは、LPU（Language Processing Unit）という自社設計のプロセッサでLLMの推論を提供するクラウドサービスです。実装者から見た実体は、https://api.groq.com/openai/v1 というOpenAI互換のエンドポイントで、既存のOpenAI SDKのコードは接続先とキーの2行を書き換えるだけで動きます。ただし互換は完全ではありません。logprobs や logit_bias は400を返し、N は1しか受け付けず、temperature の0は内部で1e-8に置き換えられます。この記事では、公式ドキュメントで確認できる範囲だけを使って、移行手順、レート制限の読み方と429を前提にした呼び出し方、Production／Preview区分でのモデル選定、そしてxAIのGrokとの取り違えが実装で起こす事故を整理します。

まとめ：GroqをLLM推論基盤に採用する条件とOpenAI互換で詰まる境界

移行そのものは軽い作業です。OpenAI互換ドキュメントが示す変更点は、base_urlを https://api.groq.com/openai/v1 にすることと、api_keyにGroqのキーを渡すことの2点だけ。既存のchat.completions呼び出しはそのまま通ります。

詰まるのは周辺のパラメータです。logprobs、logit_bias、top_logprobs、messages[].name は非対応で400になり、N は1に固定。音声の書き起こしではvttとsrtの出力形式が使えません。評価パイプラインでlogprobsを使っている、あるいはn=3で候補を出し分けている実装は、移行時にそこだけ作り直しになります。

運用設計で効くのはレート制限の粒度です。RPM・RPD・TPM・TPDに加えて、音声はASH・ASD、テキストは入力と出力を分けたITPM・OTPMで管理されます。制限に当たると429が返り、retry-after ヘッダで待つ秒数が示されます。公式のPython SDKは既定で2回リトライし、タイムアウトは1分。この既定値のままだと、429の連続時に呼び出し側の応答が最大で数分に伸びることがあるため、対話UIに載せるならリトライ回数とタイムアウトは明示的に下げます。

採用の線引きは用途で切ります。音声対話、逐次表示のチャット、社内向けの下書き生成など、応答の速さがそのまま体験の質になる用途では有力な選択肢です。一方、モデルのバージョン固定が契約要件になる案件、データの所在地を国内に限定する必要がある案件、SLAを顧客に約束する構成では、Groq単独では組みません。Preview区分のモデルは評価用と明記されており、本番の依存先にはできない点も同じ理由です。

LPUによる推論の位置づけとGroqCloudが提供する範囲の実際

Groqを検討するとき、最初に切り分けたいのは「チップの話」と「使えるAPIの話」です。前者は設計の背景で、実装者が触るのは後者だけになります。

GPU推論で伸びるトークン間レイテンシとLPUが狙う応答の一貫性

LLMの推論は、プロンプトを一括処理するプリフィルと、1トークンずつ順番に生成するデコードに分かれます。デコードは前のトークンの結果を待つ逐次処理で、GPUの並列度をそのままは使えません。メモリ帯域とスケジューリングの揺らぎがトークン間の待ち時間に出ます。

この構造的な壁については、GPUだけでは解決できない低レイテンシ推論の構造的ボトルネックで、テール・レイテンシの要求とGPU・LPUの役割分担という観点から整理しています。LPUは決定的なスケジューリングでこのばらつきを抑える設計として説明されており、Groqが公開するモデル別のトークン速度も、その前提で読む数字です。

モデル別に公開されているトークン速度とコンテキスト長の実数値

公式のモデル一覧には、モデルごとに秒間トークン数とコンテキスト長、最大出力トークンが並びます。2026年9月時点のProduction区分は次の数値です。

モデルID	トークン速度	コンテキスト	最大出力
llama-3.1-8b-instant	560 T/sec	131,072	131,072
llama-3.3-70b-versatile	280 T/sec	131,072	32,768
openai/gpt-oss-120b	500 T/sec	131,072	65,536
openai/gpt-oss-20b	1,000 T/sec	131,072	65,536
groq/compound	450 T/sec	131,072	8,192

注意したいのは、コンテキスト長が同じ131,072でも最大出力が4倍違う点です。llama-3.3-70b-versatileの出力上限は32,768で、長文の一括生成を前提にした設計だと途中で切れます。gpt-oss-20bの1,000 T/secという値は、同じプロンプトをGPU上の70B級モデルで動かした場合と桁が変わる水準ですが、モデルの規模も違うため、速度だけを見て置き換え可否を決めることはできません。

推論エンドポイントだけを借りる提供形態と実行基盤の調整に関する制約

GroqCloudで借りられるのは推論の実行環境で、モデルの重みや実行基盤には手が届きません。自前のファインチューニング済みモデルを持ち込む、量子化方式を変える、KVキャッシュの保持方針を変える、といった調整はできない前提で設計します。

この点は推論基盤を自社側に置く構成と対照的です。基盤側で握れる変数の範囲はLLM Servingとは？推論をAPI提供する仕組みと主要フレームワーク比較で扱っており、vLLMやTGIを自前で運用する場合に何が調整できるかと比べると、GroqCloudは「速いが触れない」側に位置します。

GroqとxAIのGrokを取り違えたときにAPI実装で起きる不具合

綴りが1文字違うだけの別サービスが並存しています。実装現場では、この取り違えが設定ファイルの単位で起こります。

検索クエリの実測から見えるGroqとGrokの混同の起こり方

当社サイトのサーチコンソール実測（2026年8月11日以降）では、「groq api」「groq api ket」というクエリで表示されているのは、xAIのGrok APIを扱った記事でした。検索する側が綴りを取り違えたまま情報にたどり着いている状態です。同じことがコードレビューでも起きます。変数名に grok_client と書かれた実装がGroqを呼んでいる、あるいはその逆という混在は、あとから読む人の判断を確実に狂わせます。

GroqとGrokの接続先ホスト・SDK名・課金主体が別系統になる分岐点

両者は接続先から別物です。GroqのOpenAI互換エンドポイントは api.groq.com/openai/v1、xAIのGrok APIは api.x.ai 系のホストで、キーの発行元も課金先も分かれます。PythonのSDKもGroq側は pip install groq（Quickstart）で、環境変数は GROQ_API_KEY。xAI側の詳細はGrok API（xAI）とは？料金・モデル・使い方とAPIキー取得を徹底解説にまとめてあります。

実務上の防ぎ方は単純で、環境変数名を短縮しないことに尽きます。API_KEY や LLM_KEY のような汎用名を使わず、公式が示す GROQ_API_KEY をそのまま使えば、キーの取り違えは環境変数の段階で止まります。

OpenAI互換エンドポイントへの差し替え手順と400を返す非対応項目

ここからが移行の実作業です。変更点は少なく、落とし穴は限定されています。

base_urlとAPIキーの2行で切り替える最小の移行コード

公式のOpenAI互換ドキュメントは、OpenAIクライアントの初期化で base_url を差し替える形を示しています。既存コードがOpenAIのPython SDKを使っているなら、次の形がそのまま動きます。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ.get("GROQ_API_KEY"),
    base_url="https://api.groq.com/openai/v1",
)

resp = client.chat.completions.create(
    model="llama-3.3-70b-versatile",
    messages=[{"role": "user", "content": "社内規程の要約を3行で書いてください"}],
    max_completion_tokens=512,
)
print(resp.choices[0].message.content)

curlで疎通だけ確かめたい場合は、同じベースURLに /chat/completions を付けて叩きます。ストリーミングは stream=True の指定で有効になるとChat Completionsのドキュメントに明記されています。

curl https://api.groq.com/openai/v1/chat/completions \
  -H "Authorization: Bearer $GROQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openai/gpt-oss-20b","messages":[{"role":"user","content":"ping"}],"stream":false}'

logprobs・logit_bias・N>1の400とtemperature=0置換

互換ドキュメントが非対応として名指ししているのは、logprobs、logit_bias、top_logprobs、messages[].name の4つで、いずれも指定すると400が返ります。N は1に設定する必要があり、複数候補を1回のリクエストで受け取る書き方は通りません。音声の書き起こし・翻訳では、出力形式のvttとsrtが未対応です。

数値の扱いにも差があります。temperature に0を渡すと、内部で1e-8に変換されます。完全な決定性を期待した実装は、Groq側では同じ挙動になりません。評価やリグレッションテストで出力の一致を前提にしているなら、そこは判定方法から見直す対象です。移行前に確認すべき箇所を、影響の大きい順に挙げます。

候補を複数生成して選ぶロジック（n>1）が入っていないか
logprobsを使った信頼度スコアリング、分類の閾値判定がないか
temperature=0で出力の再現性を担保しているテストがないか
messages[].name で話者を区別している会話履歴の組み立てがないか

この4つに当たらなければ、移行は接続情報の差し替えで完了します。当たる場合、作り直しの重さは1つ目と2つ目が大きく、3つ目と4つ目は代替が効きます。

公式SDKのリトライ既定2回・タイムアウト既定1分という設定値

OpenAI互換で動かす方法に加えて、Groq公式のPython SDKを使う方法も選択肢です。groq-pythonのリポジトリには、接続エラー・408・409・429・500以上を対象に既定で2回リトライすること、リクエストのタイムアウト既定が1分であることが記載されています。エラーは groq.APIError を基底に、400は BadRequestError、401は AuthenticationError、429は RateLimitError として型が分かれます。

既定値のままでよいのはバッチ処理だけです。画面の裏で呼ぶ同期処理なら、下のように短く切ります。

from groq import Groq, RateLimitError

client = Groq(max_retries=1, timeout=20.0)

try:
    resp = client.chat.completions.create(
        model="openai/gpt-oss-20b",
        messages=[{"role": "user", "content": "1行で要約してください"}],
        stream=False,
    )
except RateLimitError as e:
    retry_after = e.response.headers.get("retry-after")
    print("rate limited. retry-after =", retry_after)

レート制限RPM・TPM・ITPMの読み方と429前提の呼び出し設計

Groqのレート制限は、単位が複数あります。どれに当たっているかを取り違えると、対策が空振りします。

要求数・トークン数・音声秒数で分かれる8つの制限単位と入力・出力の区別

レート制限のドキュメントが挙げる単位は、RPM（分あたり要求数）、RPD（日あたり要求数）、TPM（分あたりトークン数）、TPD（日あたりトークン数）、ASH（時間あたり音声秒数）、ASD（日あたり音声秒数）、ITPM（分あたり入力トークン数）、OTPM（分あたり出力トークン数）の8種です。テキスト生成でも、入力側と出力側が別枠で管理されるモデルがあります。

長いコンテキストを毎回投げる設計はITPMを、長文を書かせる設計はOTPMを先に使い切ります。RAGで参考文書を大量に詰める構成は前者に当たりやすく、要約や翻訳のバッチは後者に当たりやすい。同じRPMの枠内でも、詰まる場所が変わります。

x-ratelimit系ヘッダの単位が要求と時間で混在する点

レスポンスヘッダは名前が似ていて、指している期間が異なります。公式の記載を整理すると次のとおりです。

ヘッダ名（x-ratelimit-以下）	意味	期間
limit-requests	要求数の上限	1日（RPD）
limit-tokens	トークン数の上限	1分（TPM）
remaining-requests	残り要求数	1日
remaining-tokens	残りトークン数	1分
retry-after（接頭なし）	再試行までの秒数	429時のみ

requests系が日次、tokens系が分次。監視ダッシュボードに並べるとき、この2つを同じグラフの同じ軸に置くと判断を誤ります。分けて表示し、requests系は日次の消化率、tokens系は分あたりのピークで見ます。

429を通常系として扱う待機と対話系・バッチ系のキュー分離の実装

上限超過では429が返ります。retry-after の秒数を無視した即時リトライは、残枠を消費するだけで通りません。SDKの自動リトライに任せる場合も、回数を絞ったうえで、失敗した要求を別のキューへ落とす経路を用意します。

設計として効くのは、対話系と非対話系で接続先の枠を分けることです。ユーザーの画面を待たせる呼び出しは短いタイムアウトで即座に諦め、バッチ側は待てる前提で長く粘る。同じキーで両方を回すと、バッチがTPMを食い切った瞬間に画面側が落ちます。無料枠のRPDで日次上限に当たる構成なら、そもそも本番に載せる前に有料プランへの切り替えが要ります。

受託開発でGroqを採用する条件と本番運用で単独採用しない場面

ここは判断を書きます。速度は魅力ですが、速度だけで選定が決まる案件はほとんどありません。

応答の速さがそのまま体験になる対話や入力補助の用途で採用する条件

採用に踏み切ってよいのは、待ち時間が価値を毀損する用途です。音声を挟む対話、逐次表示の社内チャット、入力補助のように毎キーストロークに近い頻度で呼ぶ処理。gpt-oss-20bで1,000 T/secという公開値は、体感の応答開始の速さに直結します。

加えて、モデルをオープンウェイト系に寄せられることが条件です。llama系とgpt-oss系、whisper系が中心のラインナップなので、特定の商用モデル固有の性能に依存した実装は移せません。プロンプトの作り直しを含めた評価工数を、移行の見積もりに入れておきます。

モデル固定・データ所在・SLAが要件の案件でGroqを採用から外す理由

採らない条件も具体的に示します。第一に、Preview区分のモデルに依存する構成。ドキュメントが評価用と位置づけている以上、提供終了やモデルIDの変更を織り込めない案件では使えません。第二に、データの所在地を国内に限る要件がある案件。処理リージョンの条件は契約と公式資料で確認する話であり、要件が厳しいなら「さくらのAI Engine」とは？料金・無料枠・対応モデルと使い方で扱った国内完結型の推論APIを並べて比較します。第三に、レスポンスタイムをSLAとして顧客に約束する構成。共有基盤のレート制限に依存する以上、上限に当たったときの挙動まで含めて保証はできません。

実装の判断が分かれる段階では、要件の棚卸しから並走する形も採れます。当社の生成AI導入支援では、推論基盤の選定とプロンプト・評価の設計を含めて相談を受けています。

GPU側の高速化手段と外部の推論APIを並べたときの検討・選択順

「速くしたい」という要件に対して、外部APIへの切り替えは唯一の手段ではありません。自社GPUで動かしている構成なら、まずKVキャッシュの扱いと推論エンジンを見ます。KVキャッシュとは？LLM推論を高速化する仕組みとメモリ削減・実装判断とTensorRT-LLMとは？NVIDIA GPUでのLLM推論高速化の仕組みと採用判断で扱った範囲の調整で、期待値に届くケースは珍しくありません。

順序としては、既存構成の見直し、推論エンジンの入れ替え、外部の高速推論APIへの切り替え、の3段です。いきなり3段目に飛ぶと、自社で握れる変数を手放したうえに、レート制限という新しい制約を抱えることになります。推論全体の選択肢はLLM推論とは？仕組みと高速化の手法・推論基盤の選び方で俯瞰できます。

Groqの導入前によくある質問と無料枠・SDK・本番モデルの選び方

検討段階で実際に問い合わせの多い論点を、公式ドキュメントで確認できる範囲で答えます。

GroqとGrokは何が違いますか？

別の会社の別サービスです。Groqは推論用プロセッサLPUを設計し、GroqCloudとして推論APIを提供しています。GrokはxAIが開発するLLMそのものであり、APIの接続先も課金先もそれぞれ別です。実装では環境変数を GROQ_API_KEY のまま短縮せずに使い、変数名やドキュメント上の表記でも綴りを揃えることで取り違えを防げます。

Groqは無料で使えますか？

コンソールでアカウントを作れば無料枠の範囲で試せます。ただしレート制限のドキュメントは、無料プランと有料のDeveloperプランで上限が異なり、バッチ処理やFlexプロセッシングは上位プラン側の機能だと説明しています。モデル別の単価は公式コンソールの料金ページで確認してください（公開ページの構成が変わることがあるため、この記事では単価の数値を載せていません）。

OpenAIのSDKをそのまま使えますか？

base_urlを https://api.groq.com/openai/v1 に変え、api_keyにGroqのキーを渡せば、chat.completionsの基本呼び出しは動きます。ただし logprobs、logit_bias、top_logprobs、messages[].name は400になり、N は1固定です。公式はGroq独自のPython／TypeScriptライブラリの利用も推奨しています。

どのモデルを本番で選べばよいですか？

Production区分から選びます。汎用の応答品質を優先するならllama-3.3-70b-versatile（コンテキスト131,072・最大出力32,768）、応答の速さを優先するならopenai/gpt-oss-20b（1,000 T/sec）やllama-3.1-8b-instant（560 T/sec）が候補です。Preview区分は評価用と明記されているため、本番の依存先には置きません。

429が頻発するときは何を直せばよいですか？

まず、どの単位に当たっているかをレスポンスヘッダで特定します。x-ratelimit-remaining-requestsは日次、x-ratelimit-remaining-tokensは分次なので、消えている側で対策が変わります。トークン側ならプロンプトの圧縮や参照文書の絞り込み、要求数側ならバッチ集約と間隔調整。そのうえで retry-after の秒数を尊重した待機と、対話系とバッチ系のキー・キュー分離を入れます。