Ejecutar Qwen 27B en un VPS con Ollama sin GPU

¿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 de 4 August 2026, la biblioteca de Ollama no tiene ninguna entrada qwen3.8. La etiqueta 27B publicada más cercana es qwen3.6:27b: 27.8 billion parameters, cuantización Q4_K_M y licencia Apache 2.0. Todos los comandos y números siguientes usan esa etiqueta en Ollama v0.32.5, publicado el 27 July 2026.

La respuesta breve es sí, en un VPS con 32 GB o más, pero funcionará lentamente. 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 habitual 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 parameters, y 27.8 se puede recordar fácilmente más tarde 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 un qwen3.8 real, 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

Descargar una etiqueta que no existe produce un error claro, así que puede comprobarlo rápidamente en el propio servidor. Una etiqueta que sí existe todavía puede no poder ejecutarse de forma local. Esto es lo que suele causar problemas con GLM 5.2, que aparece en la biblioteca pero sólo se ofrece desde la nube de Ollama.

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 de contexto y la cuantización de la etiqueta que tiene realmente. 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 a 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. Más adelante se explican con detalle.

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. Los 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 más calidad pierden con la compresión se conservan con 5 o 6 bits, y las capas de embedding de tokens y de salida suelen dejarse en Q6_K o Q8_0. El nombre del formato representa un promedio, y el promedio se acerca a 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 usa CPU, esa duplicación duplica el tráfico de memoria por token y, por tanto, reduce aproximadamente a la mitad el número de tokens por segundo. Por ese único motivo, Q4_K_M es la opción predeterminada adecuada aquí. Si quiere evaluar la calidad de esa decisión en lugar del consumo de memoria, una comparación más detallada de Q4, Q8 y fp16 muestra en qué punto empieza a degradarse realmente la salida.

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 donde la mayoría de los usuarios se queda realmente 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 asumen la arquitectura que Qwen ha usado en sus modelos densos recientes de esta clase de tamaño: 64 capas, 8 cabezas de claves/valores con GQA (atención de consultas agrupadas) y una dimensión de cabeza de 128. Esto equivale a 256 KiB por token en f16: 8 GB con 32k tokens y 32 GB con 128k. No dé por válida esta aritmética sin comprobarla en su propio equipo. Cargue el modelo y lea la columna SIZE de ollama ps, que muestra los pesos, la caché y la sobrecarga como una única cifra.

Por eso, el contexto de 256K de la ficha del modelo es un dato destacado, no un plan operativo. Completarlo en f16 costaría 64 GB de caché además de los pesos, en una máquina que ya ha dedicado 17 GB a los pesos. Ollama no le asigna por defecto toda la ventana. Carga una ventana mucho menor, que puede ampliar deliberadamente con OLLAMA_CONTEXT_LENGTH. Esa variable se aplica a todo el servidor, pero no es el único ajuste. Configurar num_ctx en la solicitud individual permite mantener un valor predeterminado bajo para el resto de las solicitudes y asignar una ventana mayor a una tarea larga. Auméntelo por pasos y compruebe 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é a 8 bits en lugar de 16, y reduce el consumo con 32k tokens de 8 GB a 4 GB. Necesita flash attention, así que establezca también OLLAMA_FLASH_ATTENTION=1 y confirme la reducción en ollama ps en lugar de suponer que se aplicó. OLLAMA_NUM_PARALLEL=1 es igual de importante. Ollama puede atender varias solicitudes al mismo tiempo, y cada ranura obtiene su propia parte del contexto. Por eso, dejar el paralelismo con el valor predeterminado multiplica silenciosamente la caché que había calculado. Si más de una persona va a usar este equipo, ahí empiezan los problemas. La cantidad de usuarios simultáneos que puede atender un modelo autoalojado depende de las ranuras de caché y de la profundidad de la cola mucho antes que del número de núcleos.

Qué cabe con 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 cambia ese hecho. 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. Entonces, cada token extrae gigabytes del disco. El sistema queda con 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, suficiente 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 cómodo. Q4 deja espacio para unos 128k tokens de contexto, y los pesos Q8_0 caben con unos 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, Q4 con un contexto más largo ofrece una mejor relación entre coste y resultado.

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

Generar un token de un modelo denso implica leer todos los pesos de la memoria una vez. No sólo algunos. Todos. Por tanto, 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 puede esperar unos 2. Un servidor con DDR5-4800 de dos canales tiene un límite de 4.5, así que puede esperar unos 3.

Las filas de servidores grandes incluyen una advertencia. Una plataforma EPYC de doce canales ofrece 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 tenants 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 omiten este punto, y por eso dos planes VPS con el mismo número de vCPU pueden diferir en 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. Configure OLLAMA_NUM_THREAD con 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 prefill, 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 lo que 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 mil millones de parámetros por token en lugar de los 27.8 mil millones completos, por lo que el tráfico de memoria por token se reduce casi en un orden de magnitud, aunque el archivo almacenado en disco sea más grande. Se cambia capacidad de RAM por velocidad. La elección del runtime también es importante aquí, y Ollama y llama.cpp exponen controles de ajuste de CPU diferentes 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 da 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 es una diferencia que se pueda compensar ajustando el número de hilos. La tarjeta ejecuta su memoria a 1008 GB/s, mientras que el VPS funciona a unas decenas.

Por tanto, establezca el límite según la carga de trabajo y no según las preferencias. La inferencia en CPU es la opción adecuada cuando el trabajo es asíncrono y nadie está esperando el resultado: resumir durante la noche una colección de documentos o ejecutar un trabajo nocturno de clasificación mientras duerme. Alquile una GPU en cuanto haya una persona esperando la salida o en cuanto lleguen solicitudes con una frecuencia superior a una cada 30 segundos, porque un equipo que sólo usa CPU no tiene margen para agrupar solicitudes 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 en ejecución. Si el 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 el ciclo de trabajo y después el precio. Elegir un VPS con GPU explica qué debe comprobar en la propia instancia, y vLLM supera a Ollama cuando sirve solicitudes simultáneas en una GPU porque las agrupa correctamente.

Hay 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 aquí y elija un modelo más pequeño, porque descargar 17 GB que no puede ejecutar desperdicia una hora y mucho espacio en disco.

Configure las opciones de ejecución mediante una anulación de systemd, no 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 es 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 del disco. Por eso se establece OLLAMA_KEEP_ALIVE=60m: en la CPU, volver a cargar 17 GB desde el disco en cada petición cuesta más que la propia petición. El tiempo de espera predeterminado es de cinco minutos. Es lo bastante corto para que una cola de procesamiento por lotes con pausas entre elementos pague ese coste de carga una y otra vez. Las opciones para mantener un modelo residente cubren tanto el campo keep_alive por petición como la persistencia del ajuste después de reiniciar.

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

ollama ps

La columna SIZE muestra el consumo real de memoria, incluida la caché KV. Debería aproximarse a la suma de los pesos y la fila correspondiente a la longitud de contexto en el gráfico de KV. Con 8192 tokens y una caché de 8 bits, espere 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 reclamado 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 cargarse. 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 hizo la comprobación antes de asignar memoria, en lugar de dejar que el kernel resolviera 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 a 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. Si aparece una línea con Out of memory: Killed process ... (ollama), el OOM killer del kernel terminó el proceso. Esto ocurre cuando la comprobación previa a la carga se supera, pero la caché crece por encima de la estimación durante una conversación larga. Reduzca la longitud del contexto.

La descarga falla inmediatamente. Error: pull model manifest: file does not exist indica 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 inaceptablemente lento. Obtener menos de un token por segundo en un equipo con suficiente RAM indica paginación, no falta de capacidad de cómputo. Ejecute vmstat 1 mientras genera texto. Un valor distinto de cero en la columna si o so indica que el kernel está usando swap. La solución es reducir el contexto o cargar menos modelos. Un valor alto y constante en wa sin actividad de swap indica que los pesos asignados en memoria se están leyendo de nuevo desde el disco. Esto significa que en realidad 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 aprovecha la caché. Reduzca el prompt de sistema antes de ajustar cualquier otro parámetro.

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

Establezca las expectativas a partir de las cifras, no de lo que espera. A dos o cuatro tokens por segundo, una respuesta de 500 tokens tarda entre dos y cuatro minutos. Ese tiempo no sirve para un chat, pero es perfectamente aceptable para una cola. Un modelo que razona antes de responder empeora ese cálculo, porque los tokens de razonamiento ocultos se generan a la misma velocidad lenta que la respuesta. Por eso, ajustar el nivel de esfuerzo de razonamiento al trabajo es una de las pocas opciones para acortar una respuesta sin cambiar de modelo. El resumen de documentos, el etiquetado masivo, la extracción de campos de un conjunto de archivos pendientes y la revisión de código sin supervisión toleran ese tiempo, porque no hay nadie esperando la respuesta. La asistencia para programar está justo en ese límite. Por eso, dirigir un agente de programación a un modelo que aloja resulta útil para trabajos en segundo plano, como generar mensajes de commit y estructuras iniciales de pruebas, pero no para las sugerencias insertadas que debe esperar mientras trabaja.

El argumento de la privacidad es el más importante. El modelo se ejecuta en hardware que alquila y controla, ninguna petición sale del equipo y no hay ningún 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 por cuenta propia un modelo de escala frontier requiere un orden de magnitud más de hardware, y un modelo 27B con CPU es el punto más económico de esa curva en el que la salida todavía merece ser leída.

Para evaluar cualquiera de esos usos necesita datos estructurados reales, y la mayoría de las API de datos públicas exigen una cuenta antes de permitir siquiera medir el rendimiento. El endpoint de demostración de Strasmore (lo ejecutamos nosotros) responde consultas SQL de sólo lectura sobre 22 años de datos del mercado estadounidense sin clave ni registro: una petición GET a https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 devuelve JSON que puede pasar directamente a un bucle de prompts, junto con la consulta SQL exacta que lo generó. Así, el modelo tiene algo que resumir y usted puede comprobarlo de forma independiente. Los límites son 500 filas y 20 segundos por llamada, bastante más de lo que consumirá un equipo a dos tokens por segundo. La lista completa de columnas está en https://api.strasmore.com/v1/schema.

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

FAQ

¿Existe un modelo Qwen 3.8 27B en Ollama?

No. A fecha del 4 de agosto de 2026, la biblioteca de Ollama no tiene el 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 de 27.8 mil millones de parámetros. El 3.8 del término de búsqueda casi con toda seguridad es el recuento de 27.8B parámetros recordado como un número de versión. Consulte https://ollama.com/library/qwen3.6/tags para ver la lista actual y use qwen3.6:27b si quiere la versión 27B publicada más reciente. 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 con f16. Un plan de 16 GB no puede contener los pesos, y la swap no ayuda porque el archivo está asignado 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 producirá un modelo 27B en CPU?

Divida el ancho de banda de memoria por el tamaño de los pesos y tome entre el 50 y el 70 por ciento de ese resultado. Un VPS con DDR4-3200 de doble canal tiene un límite cercano a 3 tokens por segundo y ofrece aproximadamente 2. Un servidor con DDR5-4800 de doble canal tiene un límite cercano a 4.5 y ofrece aproximadamente 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 tanto, mida el 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 use 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. Use la RAM para un contexto más largo, porque eso cambia lo que puede hacer el modelo, no sólo la forma en que expresa las respuestas.

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

Cuando el ciclo de uso es bajo 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 con 64 GB se factura 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 por horas de una GPU suele ganar tanto en velocidad como en coste. El trabajo por lotes continuo y de baja prioridad es el caso en que gana el VPS siempre encendido.