なぜモデルは別の機械で動くのか

このサイトを配信している機械では、言語モデルは動いていません。要約は二台目の装置で計算されます。その装置が依頼を取りに来て、作業をして、文を持ち帰ります。

理由は算数です。3B のモデルは一ギガバイト超のメモリを占め、一回の答えに数秒かかります。このアプリケーション全体で最も重いデータベース問い合わせは 581 ミリ秒です。両方を同じ基板に載せるということは、379,000 のカウンターの画像が文章生成器の後ろで待つということで、そしてその画像こそが本当の製品です。

何を払い、何を買うのか

払うのは二台目の機械と待ち行列です。依頼は一度に多くても二十件しか出ません。行列には上限があり、満杯のあいだは新しいものが生まれません — すでに書かれた文はそのまま見えています。一週間前の要約で構いません。要約がなくても構いません。同じ基板の上で別の何かが考えているせいで遅い統計ページは、構います。

買えるのは、数える経路が予測できないものと機械を共有しないことです。カウンター画像を描くのは小さく、上限のある仕事です。文章を生成するのはそうではありません。ここで実測した一文の幅は 5.4 秒から 54.3 秒、速い場合と遅い場合で十倍の開きがあり、そのどれも Pi には前もって見えません。

家を出るもの

これは何かを作り始める前に決めておかねばならなかった部分です。あとからでは直せない部分だからです。

二台目の機械が受け取るのは、そのカウンター自身の統計ページですでに公開されている数字だけで、しかも統計ページがそもそも公開されているカウンターからだけです — 非公開でもなく、パスワードもかかっていないもの。ワーカーは、そのページの訪問者が開いて読めない情報を何一つ知りません。

これはコードがそう仕上がった幸運な副作用ではありません。候補の問い合わせがそこで絞っており、その絞りがなければ、この機能全体が他人のデータを二台目の装置へ渡す行為になります。「気をつけて扱います」のどの版も、送らないことには及びません。

一般的な形

ここから、機能そのものより値打ちのある規則が二つ出てきました。

上限のない仕事を、上限のある経路に置かないこと。実行時間を一桁の精度でも予測できないものは、ミリ秒で答えねばならない機械に置く場所がありません。「たいてい大丈夫」ではだめです — 効いてくるのは遅い場合であり、それは必ず来ます。

何を作るかを決める前に、何が出てよいかを決めること。もし答えが「ワーカーには非公開のカウンターも必要だ」だったなら、正しい反応は転送を守り固めることではありませんでした。この機能は非公開のカウンターを対象にしない、が正しい反応で、実際そうなっています。