[GarupanOjisan]

変更内容

GLM CUDA レーンのコピー（prompt lookup）を、最大 16 行（ドラフト 15 トークン）まで取れるようにした。DFlash の窓は 8 行のまま（ドラフト 7）、MTP ヘッドの吸収も 8 行チャンクのまま。最初のコピー幅は 3 のまま。

ランク 0 だけが環境変数を読む。バッファ自体は全ランクで常に 16 行分を確保する。両ランクには同じ値を渡す。

デフォルト

変数	デフォルト	意味
TF_GLM_COPY_MAX	15	コピーがドラフトできるトークン数。7 で従来の 8 行窓に戻る。1..15 にクランプ。整数でない文字列は 15。
TF_GLM_COPY_REPLY_MATCH	16	続きが返信側から始まるコピーに必要な一致長。プロンプト側のコピーは従来どおり 8。1..64 にクランプ。8 以下は入場条件（8）と同じなので追加のゲートにはならない。
TF_GLM_COPY_EXTEND	オフ	値がちょうど 1 のときだけ有効。context copies と root copies をオンにし、一致が 16 トークン以上ならそのラウンドで TF_GLM_COPY_MAX まで一気に伸ばす。

COPY_REPLY_MATCH や WIDE_GRAPHS は読まない。ネイティブ側の名前は TF_GLM_COPY_REPLY_MATCH。

返信一致のデフォルト 16 はレシピの測定による。レシピのコメントでは、16 トークン一致の reply-copy で code が 55.4→56.2 tok/s、edit が 120→125 tok/s。COPY_MAX=15 の 16 行窓では edit が 84→119 tok/s で、prose と code は変わらなかった、とある。いずれもレシピ側の数字であり、このツリーでの測定ではない。

TF_GLM_COPY_EXTEND=1 では既存の優先順位のまま、root copies が context-copy の追記を止める（!root_copies）。弱い一致はランプ（3 → 7 → 15）に切り詰め、返信の一致が 16 未満ならそのコピーは捨てる。単独ストリームでは context copies が有効なため、一致が足りていれば 1 トークンのコピーも残せる。

共有ラウンドでも幅を伸ばす

共有ラウンドと複数ストリームでも、コピーが全部採用されたら幅を 2 * width + 1（上限 TF_GLM_COPY_MAX）まで伸ばす。以前止めていたのは、KDA の保存が 8 行しかなく、伸ばしたコピーを置けなかったため。今は次が 16 行に揃っている。

• 各ストリームの KDA 保存は 16 行
• 共有のストリームあたりセグメントは 16 行
• 共有フォワード全体は従来どおり最大 32 行で、allocate がバッチに合わせて切る

TF_GLM_SHARED=0 でストリームごとにフォワードしても、ライブが 2 本以上なら alone は false だった。その場合も同じランプで伸びる。

CUDA graph は増やしていない

GLM CUDA はカーネルをその場で起動する。キャプチャしたグラフはなく、16 行用のグラフも足していない。KDA の wide step は行数を 16 行タイルで回すので、16 行窓は 1 タイルに収まる。cuda_q4 は 16 行までを受け付ける。

TF_GLM_COPY_MAX=7 でもバッファ・サンプラ・KDA 保存は 16 行のまま確保する（使わない行がある）。KDA 保存は 8 行のときの約 2 倍。共有のチェーンも 16 行分。

検証

• 環境: この VM（x86_64、GPU なし）。Zig 0.17.0。ベースは c740ba65。nvcc 12.0.140。
• 正確さ: GPU 上の token_sha256 は未測定。ホストの fake バックエンドで、ドラフトありの出力が "draft": false とトークン列で一致することを、greedy と sampled、1 ストリームと 2 ストリームで確認した。
• 速度: 未測定（GPU なし）。
• プロンプト処理: 未測定。prefill の行数は変えていない。
• テスト:
  • zig test zig/src/core/lanes/lanes.zig のコピー窓・ランプ・共有ラウンド: 17 件成功
  • GLM CUDA ホストテスト（cuda_copy のクランプを含む）: 76 件成功
  • zig build install: 成功（tensorfold と tf-cuda-test を生成。fatbin は空イメージ）
  • zig build test: 2451/2457 成功、6 skip。失敗 1 件はローカルの window_fallback_shim.c（GCC 13 と 14 が同居し、-Werror の gcc-install-dir 警告）。GitHub の ubuntu では再現しない既知の環境差
  • zig fmt --check build.zig zig: 成功
  • lean: ベースと同じ 437 件、新規 0
• CUDA コンパイル: .cu は変更なし。glm_kda.cu と glm_glue.cu を nvcc 12.0 で sm_80 の fatbin にコンパイルし、成功した。全カーネルの -Dnvcc と GB10（sm_121）では回していない。
• 未実施: 2x DGX Spark 上のトークン一致、速度、メモリ。GPU がないため。

2x DGX Spark での A/B

両方のランクに同じ環境変数を置く。プロンプトは毎回新しいものにする（キャッシュに当たると edit の数字が読まない）。token_sha256 は同じプロンプトの "draft": false と比較する。

1. ベースライン: TF_GLM_COPY_MAX=7（従来の 8 行、返信ゲートも実質オフにしたいときは TF_GLM_COPY_REPLY_MATCH=8）。echo / edit / code / prose。ストリーム数 1 と 4。
2. この PR のデフォルト: 3 つの変数を未設定（コピー最大 15、返信一致 16、extend オフ）。同じ 4 種のプロンプト、1 ストリームと 4 ストリーム。
3. オプトイン: TF_GLM_COPY_EXTEND=1。同じ組。

見るもの:

• prose の tok/s と、長いプロンプトの prefill（コールドの ttft_s）が落ちていないこと
• edit が伸び、code が落ちていないこと（レシピでは code は横ばい、reply バーでわずかに上昇）
• 各条件で token_sha256 が "draft": false と一致すること（greedy と、温度を付けた sampled）
• 両 GPU の空きメモリ。16 行の KDA 保存と共有チェーンは 8 行のときより大きい。4 ストリームで特に見る

echo は一致の確認用。edit はコピーが伸びる本命。code と prose は退行がないことの確認。