GPT-OSS-120B puede ejecutarse muy bien incluso con solo 8 GB de VRAM

• Aprovechando la opción --cpu-moe de llama-cpp, las capas de expertos MOE se procesan en la CPU y solo las capas de atención se descargan a la GPU, logrando un rendimiento rápido de prefill con 5~8 GB de VRAM
• En la GPU solo residen los parámetros no expertos, como caché KV, pesos y activaciones de Attention, tablas de enrutamiento, LayerNorm, etc., por lo que el uso de memoria es bajo
• Incluso con una GPU del nivel de una RTX 3060Ti y 64 GB~96 GB de RAM del sistema, es posible ejecutar con soltura el modelo 120B, y el mejor rendimiento se obtiene con GPUs con soporte BF16 (RTX 3000+)
• Con 5 GB de VRAM registró un rendimiento de 8.15 ms por token (122.66 tokens/s), y con 8 GB de VRAM mejoró hasta 7.44 ms por token (134.44 tokens/s)
• La arquitectura 120B está diseñada para hardware de consumo, por lo que puede ejecutarse a alta velocidad incluso en entornos con recursos de GPU limitados

---

Estructura de CPU-MOE y offloading a GPU

• Con la opción --cpu-moe, las capas de expertos (MOE) se procesan por completo en la CPU
  • Ejemplo: --n-cpu-moe 36 → los 36 bloques MOE se ejecutan completamente en CPU
  • Si hace falta, se puede mover parte del MOE a la GPU para ajustar el rendimiento
• En la GPU solo se mantienen los siguientes elementos para ahorrar VRAM
  • Caché KV (secuencia)
  • Pesos y activaciones de Attention
  • Tablas de enrutamiento
  • LayerNorm y otros parámetros no expertos
• Como los pesos MOE no residen en la GPU, no existe la carga de los grandes parámetros MLP

Requisitos de memoria y hardware

• GPU: 5~8 GB de VRAM son suficientes (por ejemplo, RTX 3060Ti)
• La GPU ofrece el mejor resultado si soporta BF16 (serie RTX 3000 o superior)
• RAM del sistema: mínimo 64 GB, idealmente 96 GB
  • Aprovechando mmap de Linux, aunque el modelo completo no quepa en memoria, las capas de expertos “calientes” se mantienen cargadas

Métricas de rendimiento

Entorno con 5 GB de VRAM

• Procesamiento del prompt: 8.15 ms/token (122.66 tokens/s)
• Inferencia: 55.44 ms/token (18.04 tokens/s)

Entorno con 8 GB de VRAM (--n-cpu-moe 36, el resto en GPU)

• Procesamiento del prompt: 7.44 ms/token (134.44 tokens/s)
• Inferencia: 39.03 ms/token (25.62 tokens/s)

Entorno con 22 GB de VRAM (parte del MOE en GPU)

• Procesamiento del prompt: 6.13 ms/token (163.01 tokens/s)
• Inferencia: 32.45 ms/token (30.82 tokens/s)

Conclusión

• El diseño de GPT-OSS-120B está optimizado para ejecutar modelos de gran escala a alta velocidad incluso en hardware de consumo
• Gracias a la estructura CPU-MOE, que reduce el uso de VRAM sin sacrificar velocidad, resulta especialmente adecuado para entornos con recursos de GPU limitados

---

Preguntas clave y respuestas

P1. ¿Cuánta VRAM se usa realmente con esta configuración?

• Autor original: alrededor de 5 GB de VRAM cuando todo el MOE se ejecuta en CPU, subiendo solo las capas de atención a la GPU
• Explicación adicional: en la GPU solo residen la caché KV, los pesos y activaciones de Attention, las tablas de enrutamiento y LayerNorm

P2. ¿Cuál es la RAM mínima necesaria?

• Autor original: mínimo 64 GB, idealmente se recomiendan 96 GB
• Motivo: mmap de Linux mantiene en memoria las capas de expertos “calientes”, permitiendo acceso rápido sin cargar el modelo completo

P3. ¿Mover algunas capas MOE a la GPU acelera mucho el rendimiento?

• Autor original: puede acelerar un poco, pero no hay una diferencia grande
• Ejemplo:
  • Todo el MOE en CPU: prompt 134 tokens/s, inferencia 25 tokens/s
  • 8 MOE en GPU: prompt 163 tokens/s, inferencia 30 tokens/s
  • El uso de VRAM aumenta a 22 GB

P4. ¿Qué GPU es adecuada?

• Autor original: con una RTX 3060Ti o superior es suficiente; se recomienda soporte BF16 (RTX 3000+)
• Motivo: todas las capas fuera del MOE funcionan en BF16

P5. ¿Cómo se configura el comando?

• Autor original: se proporciona un ejemplo basado en PR #15157

  ~/build/llama.cpp/build-cuda/bin/llama-server \  
      -m $LLAMA_MODEL_DIR/gpt-oss-120b-mxfp4-00001-of-00003.gguf \  
      --n-cpu-moe 36 \  
      --n-gpu-layers 999 \  
      -c 0 -fa \  
      --jinja --reasoning-format none \  
      --host 0.0.0.0 --port 8502 --api-key "dummy"  
  

[kaydash]

De hecho lo probé, pero es demasiado lento.
Casi no usa el clock de la GPU,
llena por completo los 8 GB de memoria dedicada de la GPU y los 64 GB de memoria física,
y de los 16 vCores usa solo la mitad.
Más bien hay que darle valor a que simplemente funciona; no era una forma de usar todos los recursos.
Cada consulta tardó entre 6 y 8 minutos.

[cronex]

Creo que también voy a probarlo de forma similar.

[crawler]

Pensé que con 32 GB sería suficiente...

[cnaa97]

Primero que nada, no corre en lm studio en una M4 Max de 64 GB :(

[jinucho]

Como pesa 65 GB... qué lástima 🥲

[GN⁺]

Opiniones en Hacker News

• Me pregunto si al ejecutar el modelo directamente en hardware propio se pueden desactivar las guardrails
  • Para saltarse las guardrails, habría que encontrar un abliterated finetune que rastree y elimine las rutas neuronales que provocan respuestas de rechazo
  • Según un texto que leí recientemente, GPT-OSS fue entrenado solo con datos artificiales/generados, así que desde el inicio no tiene mucho “conocimiento prohibido”
    Artículo relacionado
  • Se puede eludir con prompts de jailbreak; es algo engorroso, pero funciona bien
  • Las versiones con parte de las guardrails eliminadas pierden bastante rendimiento, así que personalmente creo que no conviene
  • Básicamente está integrado en el modelo, pero existe una comunidad que lo crackea y modifica
• En un entorno con 5950x + 128GB de RAM + GPU 3060 de 12GB, la velocidad de generación de tokens es rápida, pero en cuanto el contexto crece un poco, el procesamiento se vuelve muy lento
  Por eso suelo usar más otros modelos como qwen, mistral o gemma
  • Más que expresiones subjetivas como “rápido” o “lento”, me interesan cifras concretas de tokens
  • Me pregunto qué quieren hacer con este modelo aparte de chat simple/manipulación de texto
• En un entorno con 32GB de RAM + 16GB de VRAM, el modelo 20B puede cargarse completo en la VRAM, pero si amplías la ventana de contexto a más de 8k tokens, falta VRAM
  Otras personas ejecutan el modelo 120B con menos VRAM; quizá se deba a la falta de soporte de ROCm y al uso de Vulkan
  Aun así, es divertido llevar el hardware al límite
  • A medida que aumenta el tamaño del contexto, hay que descargar más capas a la RAM del sistema
    En llama.cpp puedes configurar manualmente cuántas capas se calculan en la GPU, pero ollama lo ajusta automáticamente
    Estaría bien poder ajustar dinámicamente la proporción RAM/VRAM según la longitud de la sesión
• Da risa que llamen “apenas” a 64GB de RAM + 8GB de VRAM; para mí es una configuración de miles de dólares
  • Unos 300 CAD por la RAM y unos 400 CAD por la GPU; en una desktop se puede armar barato
  • Está en el rango medio-bajo de una PC gamer, así que con una mejora de unos cientos de dólares ya se puede correr en casa
  • También hay productos en preventa no tan caros, de alrededor de $1599~$1999
  • Se puede armar con piezas nuevas por menos de 1000 dólares estadounidenses; con usadas sale aún más barato y la GPU incluso podría ser mejor
  • 64GB de DDR5 rondan los $150 y una 3060 de 12GB unos $300; en eBay puede salir más barato
• Me pregunto si alguien ha probado ejecutar el modelo 20B en una MacBook Air M4 o en una RTX 3060
• No tengo suficiente RAM para usar modelos grandes, pero el modelo 20B va rápido en MacBook y es suficiente para mi uso
  Eso sí, en llama.cpp el function calling todavía está roto
  • Ese bug se corrigió en este PR
  • Menos mal que no era un límite de RAM sino un bug; incluso en una MacBook Air con 16GB de RAM corren bien varios modelos
    Planeo alojar un chatbot de IA en mi habitación con una mini PC de $149, y el modelo Qwen3 4B se ve bien
    Plan relacionado
• Me pregunto si en OpenWebUI u otra GUI se puede optimizar la configuración con estas especificaciones; me parece que el modelo 20B sería mejor
• Soy principiante en LLM y me pregunto si esta optimización puede aplicarse a todos los modelos MoE
  • Como funciona aplicando expresiones regulares a los nombres de las capas, si el naming es parecido también puede hacerse en otros modelos
    Por ejemplo, funcionó en Qwen 3, y puedes definir tú mismo la regex para mover ciertas capas a un dispositivo específico
• Me pregunto si la versión optimizada con mlx correrá en una Mac de 64GB
  • Según la estimación de LM Studio, con cuantización de 3-bit (~50GB) debería funcionar sin problemas