Política de privacidad y garantía de ejecución sin subida de archivos

1. Inspección local de .gguf y config.json sin subidas

Cuando selecciona o arrastra un checkpoint .gguf o un archivo config.json al Inspector GGUF, el navegador lee únicamente el segmento inicial de bytes locales mediante File.slice() y DataView en la memoria volátil de la pestaña. Jamás se transmite por la red ningún byte de sus pesos, nombres de ajustes finos propios ni manifiestos de despliegue.

El contenedor binario GGUF almacena todos los metadatos del modelo inmediatamente después de la marca mágica ASCII de 4 bytes ("GGUF" / 0x46554747), el entero de versión de 32 bits, el recuento de tensores de 64 bits y el recuento de pares KV de 64 bits, mucho antes de los bloques de tensores cuantizados de varios gigabytes. Al cortar solo los primeros 16 MiB con la File API del navegador, VRAMLab decodifica claves UTF-8, escalares tipados y longitudes de arreglos del tokenizador sin leer las cargas útiles de tensores.

Para checkpoints FP16, BF16, FP8 o AWQ distribuidos como fragmentos safetensors, soltar el archivo config.json adjunto extrae hidden_size, num_hidden_layers, num_key_value_heads, kv_lora_rank, n_routed_experts y sliding_window_pattern para dimensionar clústeres de vLLM o SGLang antes de descargar cientos de gigabytes de pesos.

2. Distribución estática en el borde y controles de almacenamiento local

Todas las páginas de vram.codeap.com se sirven como recursos estáticos con cabeceras estrictas Cross-Origin-Resource-Policy: same-origin y frame-ancestors 'none'. Las preferencias opcionales de tema e idioma se guardan localmente mediante codeap_color_scheme y codeap_lang, junto con telemetría agregada de vistas de página a través de Google Tag Manager (GTM-N64WPS2P) que nunca captura entradas de las herramientas.