WaveSpeedにおけるGLM-5の推論速度：レイテンシとスループット

オンボーディングメールの下書き中に、素早い返答が欲しかった。GLM-5 は賢いと感じたが、最初のトークンが出るまで少し時間がかかり、気づけばカーソルをじっと見つめていた。大問題ではないが、この小さな間が何度も繰り返された。こういうとき、私はいつも実際に何が起きているのかを確認したくなる。

私はDoraだ。ワークフローを科学実験にすることなく、GLM-5の推論速度をどこまで引き出せるかを試すため、シンプルなテストを実施した。派手なことは何もしていない。ラボではなく、実際の作業の中で差を感じられる程度のものだ。

テスト方法論（ハードウェア、設定、プロンプト長）

3つのアクセス経路を試した：

WaveSpeed：リクエストの整形とクライアント/ゲートウェイ側のキャッシュを処理する、テスト中の軽量アクセラレーションレイヤー。
Z.ai APIダイレクト：プロバイダー経由でGLM-5に直接アクセスするルート。
OpenRouter：いくつかの追加機能を備え、モデルプロバイダーにリクエストを転送するブローカー。

ハードウェアとコンテキスト

ローカルクライアント：MacBook Pro（M2 Max、64 GB RAM）。安定した光回線（下り約500 Mbps、米国の主要エンドポイントまで約30 ms）。
サーバーサイド：カスタムサーバーなし、クライアントからの直接呼び出し。ただしWaveSpeedは、キャッシュとバッチ整形を管理するための小さなローカルゲートウェイを実行する。

特に記載がない限り固定した設定

モデル：GLM-5（チャット/補完）、temperature 0.2、top_p 0.9、max_tokens 512。
ストリーミングON（実際の作業スタイルに合わせて）。
ネットワークエラー以外はリトライなし。

使用したプロンプト

短め：60〜80トークン（2〜3つの制約を持つ簡潔な指示）。
中程度：約350トークン（ブランドノートと例を含むメール下書き）。
長め：約1,500トークン（製品コンテキスト、トーンメモ、do/don’tリストを含む簡単なブリーフ）。

各条件につき25回繰り返し、以下を記録した：

最初のトークンまでの時間（TTFT）：リクエスト送信から最初のストリームトークンまで。
スループット（トークン/秒）：トークン開始後のストリーム出力速度。
「思考モード」（プロバイダーの推論トレース）のオン/オフ切り替え。

主要メトリクス

最初のトークンまでの時間（TTFT）

良いルートでは、短いプロンプトのTTFTは250〜400 msの範囲に収まった。中程度のプロンプトでは450〜700 msに近づいた。長いプロンプトはキャッシュが機能しない限り1秒を超えた。増加は線形ではなく、プロンプト長と同じくらい、キューイングと検証のオーバーヘッドが影響しているように感じた。

私の感想：400 ms未満はレスポンシブに感じる。1秒を超えるとフローが途切れる。ライブコピーを編集しているとき、最終的なスループットよりも最初のトークンの方が重要だ。

トークン/秒（スループット）

ストリーミング開始後、思考モードなしの実行では35〜70 tok/sが出た。コピーには十分な速さだが、コードのdiffにはギリギリのレベルだ。長い出力ではスループットが低下したが、純粋なモデル速度よりもサーバーサイドの整形と安全性チェックが原因だと思われる。

思考モードと非思考モード

「思考」をオンにすると、TTFTが30〜80%増加し、場合によってはスループットが半減した。難しいプロンプトでは文章がより一貫していたが、日常的な下書き作業には必要なかった。最初は時間の節約にはならなかったが、何度か試すうちに、複雑な編集での精神的負荷が減ることに気づいた。シンプルなタスクではオフにしている。

WaveSpeedアクセラレーションのGLM-5への適用方法

WaveSpeed はモデルの重みに一切触れなかった。私の側でシンプルかつ有用な2つのことを行った：冗長な処理を減らし、プロバイダーがより速く動けるようにリクエストを整形すること。GLM-5では、繰り返しプロンプトでのTTFT改善と、中程度のプロンプトでの小さな改善として現れた。

ParaAttentionとキャッシュ技術

ParaAttention（私のメモより）：関連のないリクエストをバッチ処理する代わりに、WaveSpeedは繰り返しのスキャフォールディングを検出すると、単一の長いプロンプト内でアテンションフレンドリーなチャンクを並列化する。実際には、プレリュード（システム + 共有例）を再利用し、差分のみをプッシュした。内部の動作は確認できないが、ゲートウェイレベルでの部分的なKVの再利用のように見えた。
キャッシュ：プロンプトプレリュードと短いシステムテンプレートのエンベディングをメモ化した。軽微な編集で同じタスクを繰り返すと、TTFTが約120〜180 ms短縮された。コールドプロンプトでは恩恵は小さかった（約40 ms）が、それでも体感できた。

遭遇した制限

最初のコールド実行は依然としてアップストリームに縛られる。奇跡はない。
プロンプトを約20%以上変更すると、キャッシュは機能しなかった。
思考モードはほぼゲインを無効化した：推論トレースが別のストリームのように振る舞った。

比較：WaveSpeed vs Z.ai APIダイレクト vs OpenRouter

ここでは小さな差が重要になる。

Z.ai APIダイレクト：安定している。TTFTのばらつきが最小。デモで予測可能なスタートが必要なときはこちらを選んだ。長いプロンプトではTTFTのペナルティが実際にあったが、一定だった。
OpenRouter：平均TTFTがわずかに高く、ばらつきも少し多いが、セットアップが簡単でルーティングの柔軟性がある。複数のモデルを使い分けるときに便利だ。ドキュメントも充実している：OpenRouterガイド参照。

WaveSpeedレイヤー：ウォームプロンプトと中程度の入力で最良のTTFT。おそらくキャッシュとリクエスト整形によるものだ。本当にコールドで長いプロンプトでは、ダイレクトと同等だった。

これらのいずれもGLM-5のコア動作を変えなかった。変わったのは、モデルが「起動する」速さと、反復作業のスムーズさだった。

決め方に迷っているなら：

安定したパフォーマンスとシンプルな構成が必要？プロバイダー経由のダイレクトが良い。参考：ZhipuAI APIドキュメント。
マルチモデルルーティングやツール間での共有キーが必要？OpenRouterで問題ない。数ミリ秒の追加を受け入れよう。
一日中似たようなプロンプトを繰り返し試している？軽量アクセラレーションレイヤーは、純粋な速度向上よりも精神的な安定という形で恩恵をもたらす。

本番ワークロード向け最適化のヒント

実際に役立ったこと：

プレリュードをウォームアップする：システムプロンプトと共有例を安定させる。クライアントサイドでもキャッシュしよう。TTFTの節約効果：繰り返し時に約100〜200 ms。
テールを削る：本当に必要なmax_tokensに上限を設ける。1,000トークンの上限を400に削ると、下書きの総時間が10〜20%短縮された。
構造的なリトライを優先する：リトライが必要なら、ストリームを再起動するのではなく再開する。闇雲なリトライはTTFTを悪化させた。
ばらつきをコントロールする：本番では temperature ≤0.3 に。エントロピーが低いと、サーバーのパスが減り、スループットが安定する。
思考モードを遅延させる：過去に失敗したプロンプトにのみ有効にする。「難しいプロンプト」をマッピングし、ルートごとにフラグを切り替えている。
長いコンテキストを上流でチャンク化する：参照を一度要約し、その要約を保存して再利用する。2回目以降の実行は劇的に軽くなる。
トークナイズに注意する：SDKによってトークナイズが微妙に異なる。クライアントを固定して再測定しよう。これだけで見かけ上のリグレッションが発生したことがある。
p50だけでなくp95を計測する：スパイクの多いテールが、ユーザーが記憶する目に見えるラグを引き起こす。