DBFの独自フォーマット地獄に懲りたので、別の量子化手法 GSQ (Gumbel-Softmax Quantization) を試すことにした。ISTA(Dan Alistarh研究室、GPTQ/SparseGP
T/QUIPと同じ研究室)発の2026年の手法で、GitHub([IST-DASLab/GSQ](https://github.com/IST-DASL
ab/GSQ))で公開されている。
DBFと決定的に違う点: GSQは量子化後の重みがGPTQ/AWQ互換のscalarフォーマットになる。
つまり推論側は自作カーネル(GemLiteのような)を用意しなくても、既存の枯れた推論カーネル(ExLlamaV2/V3、Marlin、vLLM純正GPTQサポート)にそのまま乗る。今回のDBFで一番苦しかったのは独自フォーマット→専用カーネルが必要→カーネル統合でハマるという部分だったので、これを最初から回避できる設計は魅力的だった。
事前調査でわかったこと
Qwen35WrapperというラッパーがQwen3.5/3.6のGDNハイブリッドアーキテクチャに具体的に対応していた。checkpointのキー命名(model.language_model.layers)やlinear_attn.in_proj_qk v/in_proj_z/out_projという構成まで、今回散々苦労した構造そのものを前提にしたコードになっていて、期待が持てた、
**GPU要件の壁
READMEには「Llama-3.1-8B(dense)ですら1×H100/A100(80GB)必要」との記載が
あり、うちの2×12GB(合計24GB)では厳しそうに見えた。
ただしソースコードを読むと、非アクティブ層の重み・レイヤー間のcalibrationactivationは既にCPU RAMへオフロードする実装が入っており(.detach().cpu()が随所に、offload_to_metaで非アクティブ層をmeta化)、モデルサイズが
VRAMを超える問題自体は解決済みだった。80GBという数字の正体は1層分のキャリブレーション計算(batch_size=64×max_length=4096×nsamples=512)がVRAM上に一括で乗ることに起因していて、レイヤーごとの処理である以上、device_microbatch_sizeを絞って回す回数を増やせば理論上VRAMだけで収まるはず、という結論になった(実際に検証はこれから)
--resumeオプションとprogress.jsonによるレイヤー単位の再開機構が最初から組み込まれていた。
DBF量子化のときに学んだ「再開前にファイルを消すな、追記モードで」という教訓([[feedback-quantization-resume]])をそのまま活かせる設計
未知のリスク
sm_120(Blackwell、うちのRTX5070)での動作実績は公式にはHopper(sm_90)の
み。ただしpyproject.tomlのtorchバージョン(torch==2.11.0+cu130)はうちの環境と完全一致しており、flash-attnのソースビルドがsm_120でnvcc crashするという既知の問題(Issue #2361はSKIP_FLASH_ATTN=1+プリビルドw
heelで回避する方針で対応中
現時点では環境構築中。続きはこのブログの続報で。