Cómo 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 necesitas la etiqueta qwen3.8:27b. Desde el 21 de octubre de 2026, la biblioteca de Ollama la ofrece como etiqueta que se puede descargar localmente: 27.3 billion parameters, cuantización Q4_K_M, licencia Apache 2.0, una ventana de contexto de 256K y una descarga de 18 GB que incluye un proyector de visión de aproximadamente 0.9 GB. Ollama añadió la compatibilidad con Qwen 3.8 27B en v0.32.12, publicada el 14 de agosto de 2026. Por tanto, primero debes actualizar una instalación más antigua. A fecha de 29 de octubre de 2026, la versión estable más reciente es v0.40.13, publicada el 28 de octubre de 2026.

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

Las etiquetas 27B anteriores todavía están disponibles en la biblioteca: qwen3.6:27b y qwen3.5:27b son compilaciones Q4_K_M de tamaño similar. Qwen3.8-27B conserva la arquitectura de Qwen3.6-27B, y los archivos de configuración oficiales de ambos modelos muestran la misma distribución de capas, por lo que los cálculos de memoria siguientes se aplican a cualquiera de los dos. Comprueba la lista actual antes de copiar cualquier comando en la página de etiquetas qwen3.8 de Ollama. Estos cálculos dependen del número de parámetros, los bits por peso y la distribución de la atención, no del número de versión.

Qué etiqueta de Ollama descargar y cómo comprobarla

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

ollama --version
ollama pull qwen3.8:27b
ollama show qwen3.8: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.3B 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.8:27b-q8_0 y qwen3.8:27b-bf16 para los mismos pesos con mayor precisión, variantes 27b-mtp y las etiquetas 27b-nvfp4, 27b-mxfp8, 27b-mlx y 27b-mlx-bf16, que la página de etiquetas identifica como MLX, un formato orientado a Apple Silicon en lugar de un VPS Linux. A diferencia de qwen3.6, la entrada qwen3.8 no tiene etiquetas 35b-a3b. Esos modelos MoE (mezcla de expertos) siguen estando dentro de qwen3.6 y funcionan de forma muy diferente en la CPU. Más información sobre ellos a continuación.

Cantidad de parámetros por bytes por peso

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.98,
    "notes": "published tag qwen3.8:27b, language model file"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.5,
    "bits_per_weight": 5.7,
    "notes": "computed, no official library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 18,
    "bits_per_weight": 5.27,
    "notes": "published tag 27b-nvfp4, MLX build, one file including the vision encoder"
  },
  {
    "label": "Q8_0",
    "size_gb": 29,
    "bits_per_weight": 8.5,
    "notes": "published tag 27b-q8_0, language model file"
  },
  {
    "label": "BF16",
    "size_gb": 55,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16, language model file"
  }
]

La fórmula ocupa una línea. Bytes de pesos = parámetros * bits por peso / 8. Con 4 bits exactos, 27.3 mil millones de parámetros ocuparían 13.7 GB. El archivo del modelo de lenguaje incluido en la etiqueta Q4_K_M es de 17 GB, lo que equivale a 4.98 bits por peso en la práctica.

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 reciben más bits. El listado de tensores de Ollama para el archivo qwen3.8:27b incluido muestra estos tensores en Q6_K: la capa de salida, aproximadamente la mitad de las proyecciones down de feed-forward, las proyecciones V de atención en aproximadamente la mitad de las capas de atención completa y aproximadamente la mitad de las proyecciones QKV fusionadas en las capas de atención lineal. Los tensores pequeños de normalización mantienen una precisión completa de 32 bits. La embedding de tokens, las proyecciones Q y K de atención y las proyecciones gate y up de feed-forward permanecen en Q4_K, como la mayor parte del modelo. El nombre del formato indica un promedio, y el promedio se acerca a 5. El mismo efecto aparece en el otro extremo de la escala: 55 GB para BF16 equivalen a 16.1 bits por peso, en lugar de un valor fijo de 16. En ese caso, la embedding de tokens está en BF16 como todo lo demás, y el pequeño exceso procede de los metadatos del archivo, los tensores de normalización que se mantienen a 32 bits y el tamaño mostrado, redondeado al gigabyte más cercano.

Reserve memoria para toda la etiqueta, no sólo para el archivo del modelo de lenguaje. Cada etiqueta GGUF de qwen3.8:27b incluye también un proyector de visión de aproximadamente 0.9 GB, por lo que la etiqueta Q4_K_M aparece con un tamaño de 18 GB.

Q5_K_M no tiene una etiqueta publicada en la entrada oficial de la biblioteca qwen3.8, por lo que la fila de 19.5 GB se calcula con los 5.7 bits por peso habituales de ese formato, en lugar de medirse. Q8_0 casi duplica Q4 hasta 29 GB. En un equipo que sólo usa 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 aquí. Si quiere evaluar la calidad 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 son 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 las personas se queda sin RAM.

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

Esas cifras proceden del archivo de configuración del propio modelo. Qwen3.8-27B, al igual que Qwen3.6-27B, es un modelo de atención híbrida. Sólo 16 de sus 64 capas usan atención completa y mantienen una caché que crece con cada token. Esas capas tienen 4 cabezas de clave/valor mediante GQA (atención de consultas agrupadas) y una dimensión de cabeza de 256. Las otras 48 capas usan atención lineal (Gated DeltaNet) y mantienen un estado de tamaño fijo que, según mis cálculos, ocupa unos 150 MB por slot de conversación, independientemente de la longitud del contexto. Eso equivale a 64 KiB por token en f16: 2 GB con 32k tokens y 8 GB con 128k. No des por válidos mis cálculos sin comprobarlos en tu propio equipo. Carga el modelo y lee la columna SIZE de ollama ps, que muestra los pesos, la caché y la sobrecarga como una sola cifra.

El contexto de 256K que indica la ficha del modelo está al alcance de esta arquitectura, pero no es gratuito. Llenarlo en f16 consume unos 16 GB de caché adicionales a los pesos, en una máquina que ya ha usado 17 GB para los pesos. Ollama no te asigna de forma predeterminada toda la ventana. Su documentación sobre la longitud del contexto establece el valor predeterminado según la VRAM: 4k tokens con menos de 24 GiB, 32k entre 24 y 48 GiB, y 256k con 48 GiB o más. Una VPS que sólo usa CPU no tiene VRAM, por lo que queda en el nivel de 4k. Puedes aumentarlo deliberadamente con OLLAMA_CONTEXT_LENGTH. Esa variable global del servidor no es el único control. Configurar num_ctx en la petición individual permite mantener un valor predeterminado bajo para el resto de las tareas mientras un trabajo largo obtiene una ventana mayor. Auméntalo por pasos y comprueba ollama ps después de cada cambio.

Dos opciones permiten reducir la caché. OLLAMA_KV_CACHE_TYPE=q8_0 almacena la caché con 8 bits en lugar de 16, y reduce el uso con 32k tokens de 2 GB a 1 GB. Necesita flash attention, así que configura también OLLAMA_FLASH_ATTENTION=1 y confirma la reducción en ollama ps en lugar de suponer que se aplicó. Si nunca has cambiado el tipo de caché, esta guía sobre q8_0 frente a f16 para la caché KV de Ollama explica cómo configurar ambas variables y leer las cifras anteriores y posteriores. OLLAMA_NUM_PARALLEL=1 es igual de importante. Ollama puede atender varias peticiones al mismo tiempo, y cada slot obtiene su propia parte del contexto, por lo que aumentar el paralelismo multiplica silenciosamente la caché que debes presupuestar. El valor predeterminado actual ya es 1, y la opción siguiente lo fija en ese valor. Si más de una persona va a usar este equipo, esa multiplicación es donde empiezan los problemas. El número de usuarios simultáneos que puede atender un modelo autoalojado se determina por los slots de caché y la profundidad de la cola mucho antes que por el número de núcleos.

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": 128,
    "q8_max_ctx_ktok": null,
    "notes": "Q4 fits with room for long context. Q8 weights fit, but usable context needs a measured total memory budget."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 256,
    "q8_max_ctx_ktok": 256,
    "notes": "Both fit with the full 256K window."
  }
]

Interprete los dos números como miles de tokens de contexto que caben junto con los pesos y el proyector de visión, con una caché f16, en un VPS Linux sin interfaz gráfica, con aproximadamente 1.5 GB reservados para el sistema operativo y un pequeño margen adicional. Un cero significa que los propios pesos no caben, por lo que no cabe nada; null significa que los pesos caben, pero no se ha confirmado una cifra de contexto utilizable para ese nivel.

8 GB y 16 GB no son casos dudosos. 17 GB de pesos no caben en 16 GB de RAM, y ningún ajuste de contexto cambia eso. Añadir swap tampoco lo soluciona. Ollama asigna mediante memory mapping el archivo GGUF, así que, cuando las páginas residentes superan la RAM, el kernel empieza a expulsarlas y volver a leerlas, y cada token extrae entonces gigabytes del disco. El equipo permanece con un iowait elevado y produce bastante menos de un token por segundo.

32 GB es el punto de entrada. Los pesos ocupan 17 GB, el proyector de visión añade aproximadamente 0.9 GB y quedan unos 12.5 GB, que permiten aproximadamente 128k tokens de contexto f16 con margen. Los pesos Q8_0, con 29 GB, caben en 32 GB, pero el contexto utilizable también depende del proyector de visión, la caché, el sistema operativo y la memoria del runtime. Compruebe el consumo total en su equipo antes de considerar Q8 ejecutable en este nivel.

64 GB ofrece un margen cómodo. Q4 deja espacio para toda la ventana de 256k, y los pesos Q8_0 también caben con los 256k completos 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. Q4 ya alcanza 128k tokens con un plan de 32 GB, y esa es la mejor relación coste-beneficio para casi todo el mundo.

¿Qué velocidad ofrece la inferencia de 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 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. Con 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 indicada, 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 máximo de 3 tokens por segundo, así que debe esperar unos 2. Un servidor con DDR5-4800 de dos canales tiene un máximo de 4.5, así que debe esperar unos 3.

Las filas correspondientes a servidores grandes requieren una advertencia. Una plataforma EPYC de doce canales ofrece 460.8 GB/s y un máximo de 27.1 tokens por segundo, pero usted no 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 porción de 8 vCPU no incluye doce canales de ancho de banda exclusivos. Las guías centradas en GPU omiten este aspecto, y por eso 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 el mismo motivo. 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. Ollama no tiene una variable de entorno global para definir el número de hilos, así que establezca num_thread en la petición options con el número de núcleos físicos, mida el resultado y pruebe después con la mitad. 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 recorrido 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 petición.

Si el modelo denso de 27B es demasiado lento, revise las etiquetas qwen3.6:35b-a3b antes de descartar la CPU. Estas activan aproximadamente 3 mil millones de parámetros por token en lugar de los 27.3 mil millones completos, por lo que el tráfico de memoria por token se reduce casi un orden de magnitud aunque el archivo del disco sea más grande. A cambio, aumenta el consumo de RAM. La elección del runtime también es importante, 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 es una diferencia que se cierre ajustando el número de hilos. La tarjeta ejecuta su memoria a 1008 GB/s, mientras que tu VPS funciona a decenas de GB/s.

Por tanto, establece el límite según la carga de trabajo y no según tus 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 un trabajo de clasificación mientras duermes. Alquila una GPU en cuanto una persona esté esperando la salida o en cuanto las solicitudes lleguen más rápido de lo que tu equipo puede procesarlas. Los runtimes de CPU no están limitados a una sola solicitud cada vez: el servidor de llama.cpp documenta la decodificación en paralelo y el batching continuo en CPU y GPU, y Ollama también puede atender solicitudes en paralelo, a cambio de usar más caché. Lo determinante es la tasa de atención medida frente a la tasa de llegada, así que mide un lote realista en tu propio equipo. Cuando las solicitudes lleguen más rápido que esa tasa, la cola crecerá.

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 el alquiler de una GPU por horas separa los costes de cómputo de los costes de almacenamiento, que pueden continuar después de detenerla. Si tu uso real es de dos horas al día, la GPU alquilada puede ser más rápida y también más barata. Calcula primero tu ciclo de uso y después compara los precios. Elegir un VPS con GPU explica qué debes comprobar en la propia instancia, y vLLM supera a Ollama cuando atiendes solicitudes simultáneas en una GPU porque las agrupa correctamente.

Hay una tercera opción que suele olvidarse. Mantén el 27B en la CPU para trabajos por lotes y coloca un modelo de API alojado delante de la ruta interactiva. No es necesario que un solo modelo atienda ambos usos.

Instala Ollama y mide tu 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 debe mostrar 0.32.12 o una versión posterior, la primera versión compatible con Qwen 3.8 27B. Comprueba free -g antes de descargar nada. Muestra GiB, por lo que un plan anunciado con 32 GB de RAM puede mostrar aproximadamente 29 en la columna total; compara la memoria disponible con los pesos y el presupuesto de caché indicados arriba.

Configura las opciones de ejecución en una anulación de systemd, no en el shell. El modelo se ejecuta dentro del servicio, por lo que nunca ve tu 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.8:27b
ollama run qwen3.8:27b --verbose "Name two Linux distributions."

La salida de --verbose es la medición que necesitas. 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 tardó en leer los pesos del disco, por eso se establece OLLAMA_KEEP_ALIVE=60m: en CPU, volver a cargar 17 GB del disco en cada solicitud cuesta más que la propia solicitud. El tiempo de espera inactivo predeterminado es de cinco minutos, lo bastante corto para que una cola de procesos por lotes con pausas entre elementos pague ese coste de carga una y otra vez, y las opciones para mantener un modelo residente cubren tanto el campo keep_alive por solicitud como la persistencia del ajuste tras un reinicio.

Mientras el modelo está cargado, comprueba el consumo desde una segunda 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 el proyector de visión más la fila correspondiente a tu longitud de contexto en la tabla de KV. Con 8192 tokens y una caché de 8 bits, la parte creciente de la caché ocupa sólo aproximadamente un cuarto de gigabyte, frente a 0.5 GB si se mantuviera en f16, además del estado fijo de atención lineal. La columna PROCESSOR debe mostrar 100% CPU. Si muestra cualquier otro valor, algo ha reclamado una GPU y las cifras de velocidad de esta guía no describen tu 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 comprueba los recursos antes de asignarlos, en lugar de dejar que intervenga el kernel. Reduzca la longitud del contexto, cambie a una etiqueta más pequeña o use 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. Si aparece una línea con Out of memory: Killed process ... (ollama), significa que el OOM killer del kernel terminó el proceso. 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 inmediatamente. Error: pull model manifest: file does not exist significa que la etiqueta no está disponible en la biblioteca. Un número de versión que aún no se ha publicado produce exactamente este error, al igual que cualquier error tipográfico en la etiqueta. qwen3.8:27b existe realmente, por lo que, si esa etiqueta exacta falla, busque primero un error tipográfico. Confirme la etiqueta en la página de la biblioteca antes de culpar a la red. Si una etiqueta válida se descarga pero no se ejecuta, compruebe ollama --version con respecto a 0.32.12.

Todo funciona, pero es insoportablemente lento. Obtener menos de un token por segundo en un equipo con suficiente RAM suele indicar 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 wa alto y estable sin actividad de swap significa que los pesos asignados en memoria se están leyendo de nuevo desde el disco, lo que indica que no caben realmente 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 debe procesarse en cada petición 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 sólo con CPU

Ajuste las expectativas a partir de los números, no de la esperanza. A dos a cuatro tokens por segundo, una respuesta de 500 tokens tarda entre dos y cuatro minutos. Eso no sirve para el chat, pero funciona perfectamente para una cola. Un modelo que piensa antes de responder empeora ese cálculo, porque los tokens de razonamiento ocultos se generan a la misma velocidad lenta que la respuesta, así que ajustar el nivel de esfuerzo de razonamiento al trabajo es una de las pocas palancas que acortan una respuesta sin cambiar de modelo. El resumen de documentos, el etiquetado masivo, la extracción de campos de un conjunto pendiente de archivos y la revisión de código desatendida toleran esa velocidad, porque nadie está esperando la respuesta. La asistencia para programación está justo en ese límite, así que asignar un agente de programación a un modelo que aloja resulta útil para trabajos en segundo plano, como mensajes de commit y estructuras iniciales de pruebas, pero no para las sugerencias en línea que debe esperar mientras se generan.

El argumento de privacidad es el importante. El modelo se ejecuta en hardware que alquila y controla, ninguna solicitud sale del servidor y no hay una factura por token. Eso vale mucho para los datos regulados incluso a tres tokens por segundo. Compárelo honestamente con la alternativa: alojar uno mismo un modelo de escala frontier requiere un orden de magnitud más de hardware, y un 27B en CPU es el punto más barato de esa curva en el que la salida todavía merece la pena leerla.

Para comparar cualquiera de esas opciones necesita una entrada estructurada real, y la mayoría de las API públicas de datos exigen una cuenta antes de permitirle medir siquiera el rendimiento. El esquema de demostración de Strasmore, que gestionamos, documenta SQL de sólo lectura sobre datos de acciones y opciones de Estados Unidos, sin key ni registro, mediante nombres de tabla cualificados por la base de datos: https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM global_markets.delayed_stocks_minute_aggs LIMIT 5. La demostración limita cada llamada a 500 filas y 20 segundos, con historial desde el 1 de enero de 2025, bastante más de lo que consumirá un equipo de dos tokens por segundo. La lista completa de columnas está en https://ai.strasmore.com/api/demo/schema.

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. La API local de Ollama no requiere autenticación, por lo que cualquier cliente que alcance el puerto puede usar su modelo.

FAQ

¿Hay un modelo Qwen 3.8 27B en Ollama?

Sí. A fecha del 21 de octubre de 2026, la biblioteca de Ollama tiene una entrada qwen3.8, y qwen3.8:27b (también etiquetada como latest) es una compilación Q4_K_M de 18 GB de un modelo denso de 27.3 mil millones de parámetros, con un proyector de visión y una ventana de contexto de 256K. Se ejecuta localmente y necesita Ollama v0.32.12 o posterior. Las etiquetas antiguas qwen3.6:27b y qwen3.5:27b siguen disponibles. Consulte https://ollama.com/library/qwen3.8/tags para ver la lista actual. 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 proyector de visión añade aproximadamente 0.9 GB, el sistema operativo necesita alrededor de 1.5 GB y la caché KV añade aproximadamente 1 GB por cada 16,000 tokens de contexto en f16, porque sólo 16 de las 64 capas del modelo mantienen una caché creciente. Un plan de 16 GB no puede contener los pesos, y el swap no ayuda porque el archivo está mapeado en memoria y el kernel simplemente lo vuelve a leer del disco en cada token. 64 GB dejan espacio para la ventana completa de 256K, incluso con pesos Q8_0 de 29 GB.

¿Cuántos tokens por segundo ofrecerá un modelo 27B en CPU?

Divida el ancho de banda de memoria por el tamaño de los pesos y tome después entre el 50 y el 70 % 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 equipo 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, así que mida el suyo con ollama run qwen3.8:27b --verbose y lea la línea eval rate.

¿Debo usar Q4 o Q8 en un VPS sólo con CPU?

Q4_K_M, en casi todos los casos. Q8_0 ocupa 29 GB frente a 17 GB, por lo que sus pesos caben en 32 GB, pero el proyector, la caché, el sistema operativo y el runtime dejan poco margen; 64 GB dejan espacio para un contexto largo. Mueve casi el doble de memoria por token, lo que 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. Dedique la RAM a un contexto más largo, porque eso cambia lo que puede hacer el modelo y no sólo la forma en que lo expresa.

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

Cuando el ciclo de actividad es bajo o hay una persona esperando. Una GPU con 24 GB de memoria tiene un límite teórico aproximado de 59 tokens por segundo con estos pesos, frente a los 2 o 3 estimados de un VPS típico; el coste por hora del procesamiento de la GPU se detiene cuando se detiene la instancia, pero el almacenamiento persistente aún puede costar dinero. Un VPS de 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. El punto de equilibrio depende de las tarifas de alquiler, el tiempo de ejecución y los costes del almacenamiento persistente. El procesamiento por lotes continuo y de baja prioridad es donde gana el VPS siempre activo.