Ejecutar Qwen 3.8 27B en un VPS con Ollama

¿Se puede ejecutar Qwen 3.8 27B en un VPS sin GPU?

Para ejecutar Qwen 3.8 27B en un VPS, primero necesita una etiqueta de modelo que exista. A fecha del 4 de agosto de 2026, la biblioteca de Ollama no tiene ninguna entrada qwen3.8. La etiqueta 27B publicada más cercana es qwen3.6:27b: 27.8 mil millones de parámetros, cuantización Q4_K_M y licencia Apache 2.0. Todos los comandos y números siguientes usan esa etiqueta con Ollama v0.32.5, publicado el 27 de julio de 2026.

La respuesta corta es sí, en un VPS con 32 GB o más, pero con lentitud. Un modelo denso de 27B en Q4 necesita aproximadamente 17 GB de RAM sólo para los pesos, antes de almacenar un solo token de contexto. Por tanto, los planes de 8 GB y 16 GB quedan completamente descartados. En un VPS común con DDR4 de doble canal, el límite es de aproximadamente 3 tokens por segundo, una velocidad inferior a la de lectura de la mayoría de las personas.

¿De dónde sale el 3.8? Lo más probable es que proceda del número de parámetros. La página de Ollama para qwen3.6:27b indica 27.8B parámetros, y 27.8 puede recordarse fácilmente después como 3.8. También existe qwen3.5:27b, la misma compilación Q4_K_M de la versión anterior. Compruebe la lista actual antes de copiar cualquier comando, en la página de etiquetas qwen3.6 de Ollama. Si más adelante se publica una versión real de qwen3.8, los cálculos de aquí seguirán siendo válidos, porque dependen del número de parámetros y de los bits por peso, no del número de versión.

Qué etiqueta de Ollama descargar y cómo comprobarla

Si intenta descargar una etiqueta que no existe, se muestra un error claro. Por eso, puede resolverlo rápidamente en el propio servidor.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show muestra la arquitectura, el número de parámetros, la longitud del contexto y la cuantización de la etiqueta que tiene instalada. Si la línea de parámetros muestra 27.8B y la línea de cuantización muestra Q4_K_M, tiene la compilación en la que se basa esta guía. La biblioteca también incluye qwen3.6:27b-q8_0 y qwen3.6:27b-bf16 con los mismos pesos en mayor precisión, además de un conjunto de etiquetas 35b-a3b que corresponden a modelos MoE (mezcla de expertos) y se comportan de forma muy distinta en la CPU. A continuación se explica este punto con más detalle.

Cantidad de parámetros por bytes por peso

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

La fórmula ocupa una sola línea. Bytes de los pesos = parámetros * bits por peso / 8. Con 4 bits exactos, 27.8 mil millones de parámetros ocuparían 13.9 GB. La etiqueta Q4_K_M publicada ocupa 17 GB, lo que equivale en la práctica a 4.89 bits por peso.

Esa diferencia no es un error. Los formatos K-quant no almacenan cada tensor con el ancho nominal. Los tensores que pierden más calidad con la compresión se conservan con 5 o 6 bits, y las capas de embedding de tokens y de salida normalmente se dejan en Q6_K o Q8_0. El nombre del formato representa un promedio, y el promedio se sitúa cerca de 4.9. El mismo efecto aparece en el otro extremo de la escala: 56 GB para BF16 equivalen a 16.1 bits por peso en lugar de 16 exactos, porque el archivo también contiene metadatos y una tabla de embeddings con precisión completa.

Q5_K_M no tiene una etiqueta publicada para este modelo, por lo que la fila de 19.8 GB se calcula con los 5.7 bits por peso habituales de ese formato en lugar de medirse. Q8_0 casi duplica Q4, hasta 30 GB. En un equipo que sólo use CPU, esa duplicación duplica el tráfico de memoria por token, por lo que también reduce aproximadamente a la mitad los tokens por segundo. Por ese único motivo, Q4_K_M es la opción predeterminada adecuada en este caso.

El coste de la caché KV a medida que crece el contexto

Los pesos tienen un coste fijo. La caché KV (la caché de claves y valores, es decir, el estado de atención que el modelo conserva para cada token que ya ha visto) crece de forma lineal con la longitud del contexto. Es ahí donde la mayoría de los usuarios se queda sin RAM.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

Estas cifras suponen la arquitectura que Qwen ha utilizado en sus modelos densos recientes de esta clase de tamaño: 64 capas, 8 cabezas de clave/valor con GQA (atención de consultas agrupadas) y una dimensión de cabeza de 128. Eso equivale a 256 KiB por token en f16, es decir, 8 GB con 32k tokens y 32 GB con 128k. No des por válidos mis cálculos para tu equipo. Carga el modelo y lee la columna SIZE de ollama ps, que muestra los pesos, la caché y la sobrecarga en una sola cifra.

Por eso, el contexto de 256K que aparece en la ficha del modelo es una cifra destacada, no un plan de uso. Llenarlo con f16 costaría 64 GB de caché además de los pesos, en una máquina que ya ha destinado 17 GB a los pesos. Ollama no te asigna toda la ventana de forma predeterminada. Carga una ventana mucho menor y debes aumentarla de forma explícita con OLLAMA_CONTEXT_LENGTH. Auméntala por pasos y comprueba ollama ps después de cada cambio.

Dos ajustes reducen la caché a la mitad o incluso más. OLLAMA_KV_CACHE_TYPE=q8_0 almacena la caché con 8 bits en lugar de 16, y reduce el consumo con 32k tokens de 8 GB a 4 GB. Necesita flash attention, así que configura también OLLAMA_FLASH_ATTENTION=1 y confirma la reducción en ollama ps en lugar de asumir que se aplicó. OLLAMA_NUM_PARALLEL=1 es igual de importante. Ollama puede atender varias solicitudes a la vez, y cada ranura recibe su propia parte del contexto. Por tanto, dejar el paralelismo con el valor predeterminado multiplica silenciosamente la caché que habías presupuestado.

Qué cabe en 8, 16, 32 y 64 GB de RAM

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

Interprete los dos números como miles de tokens de contexto que caben junto con los pesos, con una caché f16, en un VPS Linux sin interfaz gráfica, con unos 1.5 GB reservados para el sistema operativo y un pequeño margen adicional. Un cero significa que los pesos no caben, por lo que no cabe ningún contexto.

8 GB y 16 GB no son casos límite. 17 GB de pesos no caben en 16 GB de RAM, y ningún ajuste de contexto puede cambiarlo. Añadir swap tampoco lo soluciona. Ollama asigna mediante mmap el archivo GGUF, por lo que, cuando las páginas residentes superan la RAM, el kernel empieza a expulsarlas y volver a leerlas. Cada token debe entonces leer gigabytes del disco. El sistema mantiene un iowait alto y genera bastante menos de un token por segundo.

32 GB es el punto de entrada. Los pesos ocupan 17 GB y quedan aproximadamente 13 GB disponibles, suficientes para unos 32k tokens de contexto f16 con margen. Los pesos Q8_0 de 30 GB no caben en este nivel.

64 GB ofrece un margen amplio. Q4 deja espacio para unos 128k tokens de contexto, y los pesos Q8_0 caben con aproximadamente 64k tokens disponibles. Antes de pagar por 64 GB para usar Q8, tenga claro qué está comprando: una salida ligeramente mejor a la mitad de velocidad, en una máquina que ya era lenta. Para casi todos los usuarios, Q4 con un contexto más largo ofrece un mejor equilibrio.

¿Qué velocidad alcanza la inferencia en CPU en un VPS?

Generar un token de un modelo denso implica leer todos los pesos desde la memoria una vez. No sólo algunos. Todos. Por eso, el límite de velocidad no es el número de núcleos, sino el ancho de banda de memoria dividido por el tamaño de los pesos. En Q4, eso supone 17 GB de tráfico de memoria por token.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

Esos valores son límites máximos, no mediciones. La salida real suele situarse entre el 50 y el 70 por ciento de la cifra mostrada, porque la latencia de memoria y la precarga imperfecta impiden alcanzar el máximo teórico. Un VPS con DDR4-3200 de dos canales tiene un límite de 3 tokens por segundo, así que debe esperar unos 2. Un servidor con DDR5-4800 de dos canales tiene un límite de 4.5, así que debe esperar unos 3.

Las filas de servidores grandes incluyen una advertencia. Una plataforma EPYC de doce canales tiene 460.8 GB/s y un límite de 27.1 tokens por segundo, pero no se alquila un EPYC completo. El ancho de banda de memoria es un recurso de todo el host que comparten todos los clientes de esa máquina, por lo que una instancia con 8 vCPU no incluye doce canales de ancho de banda exclusivo. Las guías centradas en GPU suelen omitir este aspecto. Es la razón por la que dos planes VPS con el mismo número de vCPU pueden diferir por un factor de tres con el mismo modelo.

Añadir más vCPU deja de ayudar pronto por la misma razón. Cuando los núcleos solicitan datos más rápido de lo que el controlador de memoria puede entregarlos, los hilos adicionales sólo añaden sobrecarga de planificación. Establezca OLLAMA_NUM_THREAD en el número de núcleos físicos, mida el rendimiento y pruebe después con la mitad de ese número. En muchos planes compartidos, el valor más bajo es más rápido.

El procesamiento del prompt se comporta de otra forma. El prellenado, es decir, el procesamiento de la entrada antes de que aparezca el primer token, está limitado por la capacidad de cálculo y no por el ancho de banda. Por tanto, escala con el número de núcleos. En la práctica, esto produce una pausa larga antes de que empiece la salida con un prompt grande, seguida de la velocidad estable y lenta indicada arriba. Mida ambas fases por separado con --verbose, que muestra un prompt eval rate y un eval rate para cada solicitud.

Si el modelo denso de 27B es demasiado lento, revise las etiquetas qwen3.6:35b-a3b antes de descartar la CPU. Esas etiquetas activan aproximadamente 3.000 millones de parámetros por token en lugar de los 27.800 millones completos, por lo que el tráfico de memoria por token disminuye casi un orden de magnitud aunque el archivo del disco sea más grande. A cambio, se utiliza más RAM. La elección del runtime también importa aquí, y Ollama y llama.cpp ofrecen distintos controles de ajuste de CPU sobre el mismo código de inferencia subyacente.

Cuándo alquilar una hora de GPU

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

La misma fórmula aplicada al ancho de banda de memoria de GPU publicado produce una respuesta de otra categoría. Una tarjeta de consumo de 24 GB tiene un techo de 59 tokens por segundo con estos pesos. Una tarjeta actual de centro de datos alcanza 197. No se puede cerrar esa brecha ajustando el número de hilos. La tarjeta ejecuta su memoria a 1008 GB/s, mientras que el VPS funciona a decenas de GB/s.

Por tanto, trace el límite según la carga de trabajo y no según sus preferencias. La inferencia en CPU es la opción adecuada cuando el trabajo es asíncrono y nadie espera el resultado: resumir durante la noche un conjunto de documentos o ejecutar cada noche una tarea de clasificación mientras duerme. Alquile una GPU en cuanto una persona tenga que esperar la salida, o en cuanto las peticiones lleguen con una frecuencia superior a una cada 30 segundos, porque un equipo que sólo usa CPU no tiene margen para agrupar peticiones y la cola simplemente crece.

La comparación de costes es menos evidente de lo que parece. Un VPS de 64 GB se factura todas las horas del mes, tanto si el modelo está cargado como si no, mientras que una instancia con GPU sólo factura las horas que permanece activa. Si su uso real es de dos horas al día, la GPU alquilada puede ser más rápida y también más barata. Calcule primero su ciclo de actividad y después el precio. Elegir un VPS con una GPU explica qué debe comprobar en la propia instancia, y vLLM supera a Ollama al atender peticiones simultáneas en una GPU porque las agrupa correctamente.

Existe una tercera opción que suele olvidarse. Mantenga el modelo 27B en la CPU para trabajos por lotes y coloque un modelo de API alojada delante de la ruta interactiva. No es necesario que un solo modelo atienda ambas cargas.

Instale Ollama y mida su propio equipo

El script de instalación es el oficial y configura un servicio de systemd que se ejecuta con un usuario dedicado ollama.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version debería mostrar 0.32.5 o una versión posterior. Compruebe free -g antes de descargar nada. Si la columna total de la línea Mem muestra un valor inferior a 32, deténgase y elija un modelo más pequeño, porque descargar 17 GB que no puede ejecutar desperdicia una hora y mucho espacio en disco.

Defina las opciones de ejecución en una extensión de systemd en lugar de hacerlo en el shell. El modelo se ejecuta dentro del servicio, por lo que no ve su entorno interactivo.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

La salida de --verbose contiene la medición que necesita. eval rate es el número de tokens por segundo durante la generación. prompt eval rate es la velocidad de prellenado. load duration es el tiempo que se tardó en leer los pesos desde el disco. Por eso se establece OLLAMA_KEEP_ALIVE=60m: en la CPU, volver a cargar 17 GB desde el disco en cada solicitud cuesta más que procesar la propia solicitud.

Mientras el modelo está cargado, compruebe el consumo desde un segundo terminal.

ollama ps

La columna SIZE muestra el consumo de memoria real, incluida la caché KV, y debería aproximarse a los pesos más la fila correspondiente a la longitud de contexto que use en el gráfico de KV. Con 8192 tokens y una caché de 8 bits, se espera aproximadamente un gigabyte adicional a los pesos, frente a 2 GB si la caché permaneciera en f16. La columna PROCESSOR debería mostrar 100% CPU. Si muestra cualquier otro valor, algo ha ocupado una GPU y las cifras de velocidad de esta guía no describen su equipo.

Modos de fallo y las cadenas exactas que verá

El modelo se niega a cargar. Ollama muestra una línea que incluye ambas cifras, con el formato model requires more system memory (18.6 GiB) than is available (15.2 GiB). Este es el fallo esperado, porque Ollama comprueba la memoria antes de asignarla, en lugar de dejar que el kernel resuelva la situación. Reduzca la longitud del contexto, cambie a una etiqueta más pequeña o pase a un plan con más recursos.

El proceso desaparece en mitad de una respuesta. El cliente no muestra información útil y journalctl -u ollama -n 50 muestra que el servicio se está reiniciando. Ejecute dmesg -T | tail. Una línea que indique Out of memory: Killed process ... (ollama) significa que el kernel activó el OOM killer. Esto ocurre cuando la comprobación previa a la carga se completa correctamente, pero la caché supera la estimación durante una conversación larga. Reduzca la longitud del contexto.

La descarga falla de inmediato. Error: pull model manifest: file does not exist significa que la etiqueta no está en la biblioteca. Escribir qwen3.8:27b produce exactamente este resultado, al igual que cualquier error tipográfico en el número de versión. Confirme la etiqueta en la página de la biblioteca antes de atribuir el problema a la red.

Todo funciona, pero el rendimiento es insoportablemente lento. Obtener menos de un token por segundo en un equipo con suficiente RAM indica paginación, no falta de capacidad de cálculo. Ejecute vmstat 1 mientras genera texto. Una columna si o so distinta de cero significa que el kernel está usando swap. La solución es reducir el contexto o cargar menos modelos. Un valor alto y estable en wa sin actividad de swap significa que los pesos asignados en memoria se están leyendo de nuevo desde el disco. Esto indica que realmente no caben en la memoria disponible.

El primer token tarda 30 segundos y después la salida se acelera. Eso es el prellenado y es normal. Un prompt de sistema largo se procesa en cada solicitud que no puede usar la caché. Reduzca el prompt de sistema antes de ajustar cualquier otro parámetro.

Para qué sirve realmente un modelo 27B que se ejecuta sólo con CPU

Establezca las expectativas a partir de las cifras, no de lo que espera obtener. A una velocidad de dos a cuatro tokens por segundo, una respuesta de 500 tokens tarda entre dos y cuatro minutos. Es un tiempo inaceptable para un chat, pero perfectamente viable para una cola de trabajos. El resumen de documentos, el etiquetado masivo, la extracción de campos de un conjunto acumulado de archivos y la revisión de código desatendida toleran ese tiempo porque no hay nadie esperando la respuesta.

El argumento de la privacidad es el principal. El modelo se ejecuta en hardware que usted alquila y controla, ninguna solicitud sale del servidor y no hay un coste por token. Esto tiene mucho valor para los datos regulados, incluso a tres tokens por segundo. Compárelo de forma realista con la alternativa: alojar usted mismo un modelo de escala de vanguardia requiere un orden de magnitud más de hardware, y un modelo 27B en CPU es el punto más económico de esa curva en el que la salida todavía merece la pena leerla.

Si es la primera vez que instala Ollama, la guía completa para ejecutar Ollama en un VPS cubre la configuración del servicio, la API HTTP y las reglas del firewall que esta guía da por configuradas. No exponga el puerto 11434 a Internet. Ollama no incluye autenticación propia, por lo que cualquier cliente que alcance el puerto puede usar el modelo y leer sus prompts.

FAQ

¿Existe un modelo Qwen 3.8 27B en Ollama?

No. A fecha de 4 August 2026, la biblioteca de Ollama no tiene ningún espacio de nombres qwen3.8. Las etiquetas 27B disponibles son qwen3.5:27b y qwen3.6:27b, ambas compilaciones Q4_K_M de un modelo denso con 27.8 billion parameters. El 3.8 del término de búsqueda casi seguro corresponde al número de parámetros 27.8B, recordado como un número de versión. Consulte https://ollama.com/library/qwen3.6/tags para ver la lista actual y ejecute pull qwen3.6:27b` si quiere la versión 27B más reciente publicada. Una etiqueta inexistente falla con Error: pull model manifest: file does not exist`.

¿Cuánta RAM necesito para ejecutar un modelo Qwen 27B en un VPS?

32 GB es el mínimo práctico para Q4_K_M. Los pesos ocupan 17 GB, el sistema operativo necesita alrededor de 1.5 GB y la caché KV añade aproximadamente 1 GB por cada 4000 tokens de contexto en f16. Un plan de 16 GB no puede contener los pesos, y el espacio de intercambio no ayuda porque el archivo se asigna en memoria y el kernel simplemente lo vuelve a leer del disco en cada token. 64 GB dejan margen para un contexto largo o para pesos Q8_0 de 30 GB.

¿Cuántos tokens por segundo obtendré con un modelo 27B en la CPU?

Divida el ancho de banda de memoria entre el tamaño de los pesos y tome entre el 50 y el 70 por ciento de ese resultado. Un VPS DDR4-3200 de doble canal tiene un máximo cercano a 3 tokens por segundo y ofrece alrededor de 2. Un equipo DDR5-4800 de doble canal tiene un máximo cercano a 4.5 y ofrece alrededor de 3. Las plataformas de servidor con más canales parecen mucho mejores sobre el papel, pero el ancho de banda de memoria se comparte entre todos los tenants del host. Por eso, mida el rendimiento del suyo con ollama run qwen3.6:27b --verbose y lea la línea eval rate.

¿Debo usar Q4 o Q8 en un VPS que sólo usa la CPU?

Q4_K_M en casi todos los casos. Q8_0 ocupa 30 GB frente a 17 GB, por lo que necesita un plan de 64 GB y mueve casi el doble de memoria por token. Esto reduce aproximadamente a la mitad los tokens por segundo. La diferencia de calidad entre Q4_K_M y Q8_0 en un modelo 27B es pequeña para la mayoría de las tareas. Es mejor usar la RAM para un contexto más largo, porque eso cambia lo que el modelo puede hacer y no sólo la forma en que redacta las respuestas.

¿Cuándo es más barato alquilar una GPU que contratar un VPS con mucha RAM?

Cuando la utilización es baja o hay una persona esperando. Una GPU con 24 GB de memoria alcanza aproximadamente 59 tokens por segundo con estos pesos, frente a 2 o 3 en un VPS típico, y sólo se factura por las horas que está en ejecución. Un VPS de 64 GB se factura durante todo el mes, tanto si el modelo está cargado como si no. Calcule cuántas horas al día genera tokens realmente. Por debajo de dos o tres horas, el alquiler de una GPU por horas suele ganar tanto en velocidad como en coste. El procesamiento por lotes continuo y de baja prioridad es el caso en el que gana el VPS siempre activo.