Metodología de memoria · v0.3

Cambios frente a v0.1

Fórmulas implementadas

P son parámetros totales, U parámetros sin cuantizar, L capas, H dimensión oculta, S contexto, B microbatch y V vocabulario. Los parámetros introducidos en B se multiplican por 10⁹. Todas las memorias calculadas se convierten mediante bytes / 10⁹.

• Pesos: (P − U) × bits/8 × (1 + metadatos) + U × 2 + U32 × 2, si hay cuantización, donde U32 es el subconjunto que conserva FP32. GPT-OSS aplica a 4 bits un mínimo de 6,25 % de escalas. En 16 bits, U32 permanece a 32 bits; en 32 bits, todo utiliza 32 bits. No se añade el porcentaje de metadatos en 16/32 bits.
• Embeddings Qwen: U ≈ 2 × V × H, por embeddings y salida no enlazados. Se presupone BF16, pero un artefacto concreto puede cuantizarlos. Se puede cambiar en modelo personalizado.
• TP: divide pesos. Cabezas KV locales = máximo(1, techo(cabezas KV / TP)). Cuando TP supera las cabezas KV, estas se replican. MLA comprimida se presupuesta replicada por rango TP.
• PP: capas de la etapa mayor = techo(L/PP). Pesos del cuerpo por GPU = cuerpo × capas_etapa/L/TP; U se presupuesta entero en cada etapa, dividido por TP. Es una cota de colocación conservadora, no una asignación tensor a tensor.
• KV MHA/GQA/MQA: 2 × capas_etapa × cabezas_KV_locales × dimensión_cabeza × tokens_residentes × bytes_KV. MHA usa las cabezas Q y MQA una.
• KV MLA: capas_etapa × (latente + RoPE) × tokens_residentes × bytes_KV. Solo válido para un backend que almacene la representación comprimida.
• Residencia: réplicas = equipos × GPU/(TP × PP); solicitudes/réplica = techo(usuarios/réplicas); activas = mínimo(lote, solicitudes/réplica). La política seleccionada reserva KV para todas o solo para las activas.
• Bloques y prefijo: prefijo compartido redondeado hacia abajo a bloques completos; parte privada redondeada hacia arriba por secuencia. Ventana: mínimo(S, ventana) exclusivamente en las capas declaradas. PP usa la combinación de capas con mayor KV como presupuesto.
• Activaciones: 2 × K × tokens × H. En inferencia tokens = mínimo(activas × S, presupuesto de prefill), sin multiplicar por L porque se reutiliza la memoria entre capas. En entrenamiento tokens = B × S y se multiplica por las capas de la etapa. No se dividen estas activaciones por TP: presupuesto conservador sin sequence parallelism.
• Logits: 4 × V × activas en inferencia (solo último token); 4 × V × B × S en entrenamiento. Se presupuestan sin partición de vocabulario. Sin atención eficiente se añade una matriz aproximada de 2 × cabezas_Q/TP × B × S² bytes, multiplicada por capas de etapa en entrenamiento.
• Entrenamiento: por parámetro entrenable, 8 bytes de AdamW, 2 o 4 de gradientes y 4 opcionales de copia maestra. Los adaptadores añaden sus propios pesos BF16. La base LoRA queda en BF16 y QLoRA en 4 bits con metadatos configurables.
• Comunicación: dos buffers BF16 de tokens × H por cada dimensión TP/PP activa. En inferencia los tokens se limitan al presupuesto de prefill. Es un presupuesto propio editable indirectamente por chunk; no una calibración publicada de NCCL.
• Total por GPU: componentes anteriores + staging de offload + margen porcentual + contexto del motor. Disponible = capacidad nominal × (1 − reserva). El estado se decide comparando estos valores por GPU.
• Offload: añade staging del cuerpo de una capa por GPU. La descarga no puede superar los pesos cuantizados del cuerpo ni, sumada en todas las GPU, el 80 % de RAM del equipo. Es un límite de capacidad sin simulación de transferencia, carga inicial o granularidad real de capas.

Supuestos que no deben interpretarse como datos medidos

Predeterminados propios: K=20, contexto del motor=1,073741824 GB/GPU, margen=15 %, reserva=10 %, metadatos cuantizados=5 %, bloques KV=16 tokens y prefill=2048 tokens. El margen no sustituye los componentes explícitos ni representa una medición.

El motor, la interfaz y el informe usan GB decimales: 1 GB = 1.000.000.000 bytes. Por ejemplo, 8.000 millones de parámetros FP16 ocupan 16 GB antes de otros componentes. Las capacidades de catálogo conservan los GB nominales publicados, sin reinterpretarlos como unidades binarias. Es un presupuesto de planificación, no una medición de bytes físicos: confirma la memoria visible al motor. Los presupuestos binarios previos de motor y SO se convierten a GB conservando sus bytes. Anchos de banda en GB/s y discos en TB decimales (1 TB = 1.000 GB).

No se aplica el multiplicador aproximado 0,04 a todos los modelos MLA: se usan sus dimensiones. Tampoco se reduce la VRAM de MoE con una curva probabilística de expertos activos: todos los pesos siguen residentes. La selección de GPU no garantiza soporte de kernels o formatos.

Persisten límites: no hay atención lineal/DSA/CSA, encoders multimodales explícitos, ZeRO/FSDP, checkpointing, paralelismo entre nodos, speculative decoding ni predicción medida de TPS o TTFT. El rango orientativo de inferencia se explica a continuación. La tarjeta de red no modifica por sí misma los bytes del modelo.

Panel visual y velocidad orientativa (v0.3)

El círculo representa el presupuesto de la GPU más exigida dividido entre su VRAM utilizable, después de la reserva. Hasta 60 %: holgada; de 60 a 85 %: con margen; de 85 a 100 %: ajustada; más de 100 %: no cabe sin cambios o descarga a RAM. Son categorías de planificación propias, no umbrales del fabricante. Cuando hay exceso, el círculo se llena y el porcentaje conserva el valor superior al 100 %; el texto muestra los GB que faltan.

La velocidad sigue el enfoque de techo de cálculo y ancho de banda con fórmulas y supuestos de planificación. Solo se ofrece para modelos densos precargados con atención estándar de contexto completo, atención eficiente, TP=PP=1 y memoria suficiente sin descarga. MoE, MLA, ventanas deslizantes y dimensiones especiales no tienen estimación de velocidad. No se asignan cifras a entrenamiento, modelos personalizados, GB300 NVL72 ni comunicación TP/PP sin calibrar.

Por réplica ocupada: B = mínimo(lote, techo(usuarios/réplicas)). Por paso de decode se leen los pesos completos más la KV de B secuencias al contexto máximo seleccionado. No se descuenta el prefijo compartido en las lecturas de KV. FLOPs aproximados = B × (2P + 4LHS). Tiempo de paso = máximo(bytes/ancho de banda efectivo, FLOPs/cómputo efectivo) / penalización + 0,002 segundos. Para pesos de menos de 8 bits la penalización es 0,92; no se promete aceleración aritmética INT4/FP8. Se usan TFLOPS BF16 densos, sin sparsity.

El escenario conservador usa 35 % del ancho de banda y 20 % del cómputo; el favorable usa 70 % y 45 %. Son supuestos ilustrativos, no percentiles, intervalos de confianza ni resultados medidos. Tokens/s por usuario = (B / solicitudes por réplica) / tiempo de paso. Si hay cola es un promedio con reparto equitativo a largo plazo, no una cadencia continua garantizada. Se presupone distribución equilibrada entre réplicas y suficiente alimentación desde CPU.

Prefill sin cola: máximo((2PN + 4LHN²)B/cómputo efectivo, bytes de pesos/ancho de banda efectivo) + 0,002 s, con N limitado al contexto. Es una aproximación de procesamiento del prompt, no TTFT extremo a extremo: omite tokenización, carga del modelo, red, planificación, contención y espera. La barra compara el extremo conservador de tokens/s con el objetivo introducido; se satura en 2× el objetivo y la cifra conserva el rango completo.

CPU, RAM y red no reciben multiplicadores arbitrarios de tokens/s: su efecto real exige medir el motor, topología, tráfico y alimentación de datos. Añadir réplicas puede atender a más usuarios; no acelera automáticamente una solicitud. La cuantización y el backend deben estar soportados por la GPU.

Las cifras marcadas como sparse en las fichas se dividen por dos para obtener la referencia densa. No se equiparan GB/s decimales con GiB/s.

Catálogo ampliado

311 entradas revisadas: 224 calculables y 87 excluidas por datos o soporte insuficientes. Se cargan dimensiones y límites propios; no se reutiliza la arquitectura de Qwen para otras familias. Consultar alcance, fuentes y limitaciones por modelo.

Comprobación

Pruebas numéricas automatizadas: ejemplo GQA, precisión mixta, MLA, residencia, prefijo, bloques, SWA, TP/PP, replicación KV, cola, AdamW, offload y rechazo de configuraciones inválidas. No sustituyen una medición con un LLM real.