Laplace 3Bの固定状態で考える、長い会話とLLM配信メモリ

i14のLaplace 3Bは、各系列の再帰状態を文脈長によらず29.5 MBに保つ線形Attentionモデルです。AWS Trainium2での事例を起点に、KVキャッシュとの違いと、メモリ・応答品質・配信性能を分けて評価する理由を整理します。

こはるの読みどころ

「固定サイズ」が指す範囲に注目してみよう。会話の長さと同時処理数を分けると、配信メモリの見積もりが読みやすくなるよ。

会話を長く続けられるLLMを選ぶとき、入力できるトークン数と一緒に考えたいのが、履歴を保持するためのメモリです。履歴が伸びるたびに必要量が増えるなら、同時に扱える会話数にも影響します。

2026年10月20日に公開されたAWSのLaplace 3B事例は、この関係を考えるよい題材です。i14が開発したモデルは、文脈長によらず各系列の再帰状態を29.5 MBに保ち、AWS Trainium2上でネイティブPyTorchを使って学習・配信されています。

では、状態が固定なら、長い会話の配信は何を基準に設計すればよいのでしょうか。まず「何を保存しているのか」を押さえると、メモリの利点と、別に測るべき性能が見えてきます。

KVキャッシュと再帰状態では、過去の情報の持ち方が違う

通常の全履歴を保持するAttentionでは、過去のトークンから求めたキーと値をKVキャッシュへ保存し、生成時に再利用します。履歴が増えると保存対象も増えますが、スライディングウィンドウなど、保持範囲を制限する方式もあります。Transformersのキャッシュ解説にも、この違いが整理されています。

線形Attentionは、履歴を行列の状態へ蓄積し、その状態を更新・参照する計算として表せます。この考え方をハードウェア上で効率よく学習する研究として、2023年12月11日に初版が公開されたGLAの論文があります。並列に学習する表現と、逐次的に状態を更新する表現を持てることが背景にあります。

Laplace 3Bの固定状態は、この「履歴をどう表現するか」に関わるものです。一方、TransformersのStaticCacheは、キーと値を保存する領域をあらかじめ最大サイズで確保します。同じ固定サイズという言葉でも、予約した容量までKVを保存する仕組みと、一定の状態へ履歴を蓄積する仕組みは区別したいですね。StaticCacheの仕様を読むと、この違いが分かります。

29.5 MBから見積もれるのは、系列ごとの状態容量

29.5 MBという値は、モデル重みや一時的な計算領域を含む配信プロセス全体のサイズではありません。固定されるのは、1系列が持つ再帰状態です。

状態の複製や管理領域を考えず、報告値をそのまま足す概算なら、100系列では 29.5 MB × 100 = 2,950 MB になります。同時系列数を200にすれば状態分も2倍です。文脈長への依存がなくなっても、同時処理数への依存は残ります。

ここから考えると、容量設計は「何系列分の状態を置くか」と「重み・実行時の領域をどれだけ確保するか」を分けると整理しやすくなります。この計算は状態容量だけの例であり、100系列を所定の速度で処理できることを示すベンチマークではありません。

さらに、一定容量に履歴を収められることと、昔の情報を正確に取り出せることも別です。例えば長い会話の冒頭に条件を置き、その後に無関係な発言を挟んでから条件を尋ねる、といった評価を用意できます。これは採用時の検証案であり、Laplace 3Bの測定結果を示したものではありません。

ネイティブPyTorchでも、カーネルとコンパイルの設計は残る

モデルの状態設計を実際の配信につなぐのが実行基盤です。Laplace 3Bの移植では、GPU向けTritonカーネルを標準PyTorch演算へ書き換えています。「ネイティブ対応」を、専用カーネルまで変更せず動くという意味には読めません。

この事例の周辺事情として、TorchNeuronはTrainiumをPyTorchのデバイスとして扱うためのバックエンドです。2026年10月20日の公開ベータ開始はPyTorch公式の紹介記事で案内されており、2026年10月21日時点のAWS Neuron公式ドキュメントもNeuron 2.33での公開ベータとしています。これは現在の提供状況であり、事例の測定時に使ったSDK版を特定する情報ではありません。

同ドキュメントでは、演算を逐次実行するeagerモードと、計算グラフをまとめて扱うtorch.compileを説明しています。形状やデータ型などが変われば再コンパイルが起こり得るため、モデルの再帰状態が固定でも、実行グラフまで常に同じとは限りません。

配信中にリクエストが完了したり新しく到着したりすると、同時に処理する系列数が変わります。このバッチの幅も形状の一部です。Laplace 3Bの事例では、未コンパイルの幅の初回処理に約11秒かかり、幅を固定するパディングでその負担を解消しています。AWSの配信最適化事例が示すのは、この実装・測定条件での結果です。

配信の採用判断は、合計トークン数と待ち時間を分ける

1台のtrn2.48xlargeで報告された配信性能は、1,280系列を同時に扱い、合計11,544出力トークン/秒というものです。この値はインスタンス全体のスループットであり、1人の利用者へ同じ速さで返答するという意味ではありません。AWSの測定結果は、この区別を保って読む必要があります。

実際の採用評価では、同時系列数を固定して文脈長を変える試験と、文脈長をそろえてリクエストの到着間隔を変える試験を分けると、状態容量の性質と配信処理の性質を切り分けやすくなります。初回コンパイルを含む場合と済んでいる場合で、最初のトークンまでの時間、生成中の待ち時間、合計出力数を比較するのが具体的な進め方です。

費用も、最大スループットだけから安くなるとは判断できません。必要な応答品質と待ち時間を満たした条件で、稼働費用と処理量を対応させる必要があります。

長い会話を配信するとき、Laplace 3Bの固定状態が変えるのは、履歴の長さに応じて状態用メモリを増やすという制約です。そこから先の判断には、必要な情報を取り出せるか、想定する到着パターンで待ち時間を守れるかが残ります。容量・品質・待ち時間を別々に確かめることで、固定状態の利点を自分たちの配信条件に結び付けられます。