ローカル .gguf & config.json バイナリヘッダー解析（アップロード不要）
ディスク上の4GB〜200GBの .gguf 重みファイルや Transformer の config.json をそのままドロップしてください。VRAMLabはブラウザ内メモリで先頭16 MiBのみを DataView で切り出し、層数、GQA/MLA次元、コンテキスト上限、量子化形式を5ms未満で抽出します。外部へ送信されるデータは0バイトです。
ローカルのモデルファイルを選択、または検証済みサンプルを読込
File.slice() で先頭 0..16,777,216 バイトのみを参照するため、100GB超の .gguf ファイルも重み全体をRAMにコピーせず瞬時に開けます。
または合成バイナリヘッダーですぐに試す：
ブラウザ内メモリで Qwen3-32B-Q4_K_M.gguf（GGUF v3）を解析完了 — 送信データ 0 バイト。
抽出されたアーキテクチャ & 量子化メタデータ
Qwen3-32B-Instruct · MOSTLY_Q4_K_M| ヘッダーキー | 抽出値 |
|---|---|
general.architecture |
qwen3 |
general.name |
Qwen3-32B-Instruct |
gguf.version |
v3 |
gguf.tensor_count |
707 |
gguf.quantization |
MOSTLY_Q4_K_M |
qwen3.block_count |
64 |
qwen3.embedding_length |
5120 |
qwen3.attention.head_count |
64 |
qwen3.attention.head_count_kv |
8 |
qwen3.context_length |
40960 |
抽出ヘッダーからの即時VRAM試算
アップロード不要の GGUF v2/v3 バイナリ解析の仕組み
GGUFバイナリコンテナは、4バイトのASCIIマジック（"GGUF" / 0x46554747）、32bitバージョン整数、64bitテンソル数、64bit KVペア数の直後に全モデルメタデータを格納しており、数ギガバイトの量子化テンソル領域より手前に位置します。ブラウザの File API で先頭16 MiBのみを切り出すことで、VRAMLabはテンソル本体を読まずにUTF-8キー、型付きスカラー、トークナイザ配列長を復号します。
safetensorsシャード形式で配布されるFP16、BF16、FP8、AWQチェックポイントでも、付属の config.json をドロップすれば hidden_size、num_hidden_layers、num_key_value_heads、kv_lora_rank、n_routed_experts、sliding_window_pattern を抽出し、数百GBの重みをダウンロードする前に vLLM や SGLang クラスタをサイジングできます。
VRAMLabは検証済みのTransformer構造寸法から各モデルを計算し、Multi-Head Attention (MHA)、Grouped-Query Attention (GQA)、DeepSeek Multi-head Latent Attention (MLA)、ローカル/グローバル併用スライディングウィンドウを明示的に分岐させることで、vLLM、SGLang、Ollama、llama.cppの実際のメモリ消費と一致する容量計画を導き出します。