OpenAI、ChatGPTの保存層を読む待ち時間を120msから10msへ改善

データベースは、情報を保存し、条件に合う項目を取り出す仕組みです。保存する空きがあるかと、多くの要求を時間内に処理できるかは別の問題です。本棚が空いていても、案内窓口が一つなら人が集中すると待つのと似ています。

Azure Cosmos DBは、CPU・入出力・メモリなどの処理負担をRUという単位で表します。RU/sは1秒あたりの処理容量です。操作ごとに負担が違うため、RUの数をそのままリクエスト件数に変えてはいけません。RUの説明

容量を共有すると、別の仕事で余った分も使いやすくなります。一方、一つの仕事が資源を多く使ってほかまで遅くする「騒がしい隣人」の問題もあります。情報を論理的に分けても、実際の処理資源まで別とは限りません。分割の仕組み

120msは0.12秒、10msは0.01秒です。p50 は、要求を遅延時間の順に並べた真ん中の値、中央値です。OpenAIが今年の性能改善の前後で比べた値は保存層の読み取りについてで、全利用者の最長待ち時間やAIが答えを生成する時間ではありません。

120を10で割ると12、減少した110msを元の120msで割ると約91.7%です。変わったのは、この指標です。応答全体には認証、情報取得、モデルの計算、転送などの時間もかかります。

キャッシュは、よく読む情報のコピーを近くに置き、元の保存先まで取りに行く回数を減らす仕組みです。ただ、元が変わってもコピーが残ると、古い値を表示することがあります。Azureの一般的なキャッシュ文書も、繰り返す読み取り、情報を残す時間と更新条件を説明しています。一般的なキャッシュの説明

その文書のAzure専用ゲートウェイのキャッシュと、HabitatのValkeyによるキャッシュは同じ実装ではありません。OpenAIは、元情報の変更通知でキャッシュを無効にし、次の読み取りで新しい値を入れる方法を説明しています。

架空の店で商品名を変えるなら、「近くのコピーを読む」とともに「変更通知で古いコピーを捨てる」ことも必要です。情報を近くに移す際は、保存地域の要件や実際の地域ごとの容量も考えます。