GPU VRAM on KnightLi Blog

Cómo calcular el costo de ejecutar Agent en una tarjeta gráfica de consumo: factura de electricidad, depreciación y costo por tarea

Sat, 11 Jul 2026 10:30:00 +0800

Si desea saber si vale la pena ejecutar una tarjeta gráfica de consumo con un agente local, no puede simplemente mirar “cuánto cuesta la tarjeta gráfica”, ni puede simplemente comparar el precio unitario por millón de tokens de la API. Los agentes llamarán repetidamente a modelos, herramientas y navegadores; Los contextos largos, los reintentos fallidos y el modo de espera inactivo cambiarán el costo real.

La forma más práctica es dividir el costo en cuatro elementos: electricidad, depreciación del hardware, equipo de soporte y mantenimiento manual, y luego calcularlo de acuerdo con “cada tarea exitosa” y “por millón de tokens de salida” al mismo tiempo.

Primero determine qué costos desea calcular

calibre	Preguntas aptas para ser respondidas.	Elementos que se pasan por alto fácilmente
costo incremental	Ya tengo una consola de juegos. ¿Cuánto cuesta ejecutar Agent en mi tiempo libre?	La tarjeta gráfica ya está, ¿está incluida en la depreciación?
costo total	¿Es rentable comprar una máquina específicamente para agentes locales?	Host, memoria, SSD, refrigeración y depreciación
Costo por tarea	¿Cuánto cuesta automatizar un documento y una tarea de código?	Fallo, reintento y revisión manual
costo de rendimiento	¿Cuál es el costo por millón de tokens para crear un servicio de inferencia autoconstruido?	Ingrese el token, la caché KV y el tiempo de inactividad

Si la tarjeta gráfica se usó originalmente para juegos u otro trabajo, sería más honesto calcular primero el costo incremental; Solo cuando se compra toda la máquina para el Agente, la depreciación de toda la máquina está incluida en su totalidad.

Fórmula de costo total mensual

Primero use el calibre mensual, los datos son más fáciles de obtener:

月度总成本 = 电费 + 硬件月折旧 + 配套服务费 + 人工维护成本

电费 = 实测整机平均功耗(kW) × 实际运行小时数 × 电价(元/kWh)
硬件月折旧 = (购入总价 - 预估残值) ÷ 使用月数
单次成功任务成本 = 月度总成本 ÷ 月成功任务数
每百万输出 token 成本 = 月度总成本 ÷ 月输出 token 数 × 1,000,000

El “consumo de energía promedio de toda la máquina” debe provenir de un medidor de energía de enchufe o UPS tanto como sea posible, en lugar de simplemente mirar el TBP nominal de la tarjeta gráfica. El Agente también se ejecuta con CPU, memoria, SSD, ventiladores y monitores; Usar solo el consumo de energía de la GPU subestimará la factura de electricidad. Por el contrario, los períodos en los que la máquina está en espera pero no procesando tareas no deben mezclarse con los costos de inferencia pura y es mejor registrarlos por separado.

Un ejemplo de parámetros reemplazables.

Supongamos que una máquina tiene un consumo de energía promedio medido de 280 W bajo la carga de trabajo real del Agente, funciona 6 horas al día y 30 días al mes; el precio local de la electricidad se calcula en 0,8 yuanes/kWh. El hardware adquirido específicamente para este fin se amortiza en 7.000 yuanes, en 36 meses, y se ignora el valor residual.

1
2
3

电费 = 0.28 × 6 × 30 × 0.8 = 40.32 元/月
硬件折旧 = 7,000 ÷ 36 = 194.44 元/月
月度基础成本 = 234.76 元/月

Si se completan 600 tareas aceptadas este mes, el costo básico será de aproximadamente 0,39 yuanes/tarea. La “finalización” aquí no solo puede contarse como devolución del modelo; debe basarse en resultados comerciales, como la ejecución exitosa de scripts, el cierre de órdenes de trabajo y la aprobación de inspecciones manuales.

Este es sólo un cálculo de ejemplo, no un precio universal. Sólo tiene sentido reemplazar el consumo de energía, el tiempo de uso, el precio de la electricidad, el monto de la compra y el volumen de tareas con sus propios datos.

¿Por qué es más difícil estimar el agente que el chat normal?

Los modelos de chat a menudo se facturan por token y el costo del Agente también se ve afectado por la ruta de ejecución:

Una tarea puede incluir planificación, recuperación, llamadas a herramientas, lectura de resultados y múltiples rondas de correcciones.
Cuanto más largo sea el contexto, más caché KV estará ocupada; cuando no hay suficiente memoria de video, se ralentizará, descargará la CPU/RAM e incluso activará reintentos.
La automatización del navegador, las pruebas de código y el procesamiento de archivos pueden alargar los tiempos de las tareas incluso si la GPU no está completamente cargada constantemente.
La paralelización de múltiples agentes aumentará el rendimiento, pero también puede aumentar la contención de memoria, las colas y las tasas de fallas.
Para reducir el retraso del primer token, el modelo residente aumentará el consumo de energía en reposo.

Por lo tanto, no utilice los tokens de una pregunta y respuesta cortas para representar el costo del Agente. Seleccione al menos un conjunto de tareas reales, ejecútelas continuamente durante una semana y registre los tokens de entrada/salida, la tasa de éxito, la cantidad de reintentos, el tiempo del reloj de pared y el consumo general de energía de la máquina.

Dos unidades que hay que ver al mismo tiempo

cada tarea exitosa

Esto es lo más cercano a las decisiones comerciales. Es adecuado para comparar procesos fijos como “el agente local procesa automáticamente las relaciones públicas”, “recopilación de datos por lotes”, “generación de borradores de servicio al cliente”, etc.

`1`	`每个成功任务成本 = (本周期全部成本) ÷ 成功且验收通过的任务数`

Las tareas fallidas no se pueden eliminar del numerador. La energía, el tiempo de inferencia y la resolución manual de problemas que consumen son los verdaderos costos operativos de los sistemas locales.

por millón de tokens

Esto es adecuado para comparar servicios de inferencia locales y API en la nube, pero distinguiendo entre entradas y salidas. La entrada de muchos agentes incluye largos registros de herramientas y contexto histórico, y los tokens de entrada son mucho más que los tokens de salida; si se divide solo por los tokens de salida, el número será alto. Un enfoque más confiable es registrar los tokens de entrada, salida y totales al mismo tiempo y mantener el mismo calibre estadístico.

Cómo recopilar tus propios datos

No es necesario crear un sistema de seguimiento complejo desde el principio. Primero cree una tabla y registre los siguientes campos para cada ejecución:

Campo	Método de grabación
hora de inicio y fin	Registro de agente o cola de tareas
Consumo de energía de toda la máquina	Tomacorriente inteligente, medidor de energía o UPS
ficha de entrada/salida	Registros de servicios de inferencia o estadísticas de clientes.
Éxito, fracaso, reintento.	Estado de la tarea y registro de errores
Tiempo de revisión manual	Orden de trabajo, PR o registro de inspección aleatoria
Modelo y versión cuantificada.	Evite mezclar diferentes modelos en el mismo conjunto de datos

Comience con entre 20 y 50 tareas representativas como base. Luego, las tareas con contextos cortos, contextos largos, muchas llamadas a herramientas y muchos reintentos se prueban por separado para ver el impacto de la memoria y la selección del modelo en los costos. La planificación de la memoria de video se puede juzgar junto con [Cuantificación del modelo local y selección de memoria de video] (/es/2026/07/11/rtx-3060-qwen3-best-quantization-guide/).

Cómo calcular la depreciación para no engañarte

No existe una respuesta única para la depreciación, pero primero se deben anotar los supuestos.

Tarjeta gráfica existente: solo puede calcular la factura de electricidad y el mantenimiento adicional como costos incrementales; También puedes establecer un costo de oportunidad para la tarjeta gráfica como un costo total más conservador.
Equipo nuevo adquirido: la tarjeta gráfica, el host, la memoria, el SSD y el radiador deben incluirse juntos; no se limite a repartir el precio de la tarjeta gráfica.
Vida útil: 24, 36 o 48 meses funcionarán; la clave es comparar el sistema local con el de la nube utilizando los mismos supuestos.
Valor residual: Cuando se espera revender el equipo, el valor residual estimado se puede deducir del precio de compra; si es incierto, póngalo en 0 y la conclusión será más conservadora.

Los NAS o hosts pequeños suelen consumir menos energía, pero las capacidades de memoria, refrigeración y expansión también limitan los modelos y la simultaneidad. Si considera esta ruta, primero puede leer [Sentencia de rendimiento de la implementación de NAS Ollama] (/es/2026/07/11/nas-ollama-performance-cpu-memory-gpu-guide/).

Al comparar con las API de la nube, no se limite a comparar el precio unitario

El lado de la nube también se puede convertir en costo por tarea:

`1`	`云端每任务成本 = 模型 API 费用 + 工具/API 费用 + 必要的存储与网络费用 + 人工复核成本`

El local suele ser más adecuado para estas situaciones:

Hay una carga de trabajo estable y predecible todos los días y la utilización de las máquinas es alta.
Los datos no pueden o no se espera que se envíen a servicios externos.
Ya tengo una GPU en funcionamiento, el costo incremental es principalmente electricidad.
Se aceptan modelos, controladores, servicio y recuperación de fallas automantenibles.

La nube suele ser más adecuada para estas situaciones:

La carga es esporádica y la máquina estará parada la mayor parte del tiempo.
Las tareas requieren modelos grandes, contextos muy largos o una concurrencia máxima que supera con creces la memoria de vídeo local.
El equipo no está dispuesto a encargarse del conductor, las actualizaciones del modelo, el seguimiento y la resolución de problemas.
Los resultados de la tarea son de gran valor y primero se requiere el modelo más sólido o las capacidades multimodales.

La implementación local no es sólo una elección entre dos opciones. Se colocan localmente escalones estables y sensibles a la privacidad; Los pasos complejos y de baja frecuencia o los pasos que requieren modelos más sólidos se llaman a la nube, lo que a menudo es más fácil de controlar el costo total.

Una línea de decisión práctica

Registre el costo fijo mensual local como F, los costos variables de energía y mantenimiento por tarea como v y el costo por tarea de la nube como c. Cuando c > v, la cantidad aproximada de tareas necesarias para lograr el punto de equilibrio local es:

`1`	`每月盈亏平衡任务数 = F ÷ (c - v)`

Si c es menor o cercano a v, el local no será significativamente más barato debido a la escala; La privacidad, la latencia, la controlabilidad y las capacidades fuera de línea deben considerarse más en este momento. Esta fórmula es sólo un filtro financiero y aún requiere tasas de falla y tiempo de revisión manual.

Malentendidos comunes

Mire solo el consumo de energía de la tarjeta gráfica: También se deben pagar la energía, el modo de espera y la refrigeración de toda la máquina.
Piense en los tokens nominales como rendimiento: los agentes reales se verán ralentizados por el contexto, las herramientas, la red y los pasos de prueba.
Ignorar tareas fallidas: el proceso que se reintenta con mayor frecuencia suele ser un agujero negro de costos.
Solo se calculan los cargos del modelo: también pueden aplicarse cargos por navegador, búsqueda, biblioteca de vectores, almacenamiento y revisión humana.
Mezcla de datos de diferentes modelos: la versión de cuantificación, la longitud del contexto y la simultaneidad son diferentes y los resultados no se pueden comparar horizontalmente.

Resumir

El costo de ejecutar Agent en una tarjeta gráfica de consumo no debería cubrirse simplemente con “unos pocos kilovatios-hora de electricidad por hora”. Primero use el consumo de energía medido de toda la máquina para calcular el costo de electricidad, luego agregue el costo del hardware de acuerdo con sus propios supuestos de depreciación y, finalmente, use la cantidad de tareas exitosas y la cantidad de tokens para amortizarlo. Después de registrar continuamente un período de carga de trabajo real, puede juzgar claramente si continuar ejecutándose localmente, expandir la memoria de video o transferir algunos pasos a la API de la nube.

Si el rendimiento de Ollama de la implementación de NAS es insuficiente: cómo juzgar la CPU, la memoria y la tarjeta gráfica

Sat, 11 Jul 2026 09:40:43 +0800

NAS puede implementar Ollama, pero “se puede instalar” y “lo suficientemente rápido para usar” son dos cosas diferentes.

Si el objetivo es realizar resúmenes ocasionales, preguntas y respuestas sobre archivos, automatización del hogar y llamadas API de baja frecuencia, el NAS x86 puede usar CPU para ejecutar modelos pequeños; Si desea tener conversaciones continuas como software de chat, ejecutar modelos de código 7B/8B o realizar múltiples llamadas de servicio, la clave es la memoria de video, la memoria y la disipación de calor, no cuántos TB tiene el disco duro.

Primero demos la conclusión:

**NAS sin GPU disponible es adecuado para modelos pequeños y tareas de baja frecuencia; Sólo las GPU NVIDIA reconocidas correctamente por Ollama son más adecuadas para utilizar los modelos 7B/8B como servicios diarios. **

Primero confirme a qué categoría pertenece su NAS

No se limite a mirar “chip AI”, “NPU” o “transcodificación 4K” en la página de promoción del producto. Que Ollama pueda acelerar depende de si el sistema, el controlador, los permisos del contenedor y el hardware se reconocen en el entorno de ejecución real.

estado del NAS	idoneidad	Usos más realistas
CPU ARM, 8 GB de RAM, no hay GPU disponible	limitado	Modelo mínimo, clasificación simple, tareas fuera de línea.
CPU x86, 8 GB de RAM, no hay GPU disponible	Apenas utilizable	1B–3B Modelo cuantitativo, procesamiento de textos de baja frecuencia
CPU x86, memoria de 16 GB a 32 GB, sin GPU disponible	comprobable	3B–7B Modelo de cuantificación baja, pero respuesta generalmente más lenta
NAS x86 + memoria de vídeo NVIDIA de 8 GB	Disponible todos los días	Chat cuantitativo 7B/8B, asistencia de código ligero, API de usuario único
NAS x86 + memoria de vídeo NVIDIA de 12 GB o superior	más adecuado	El modelo 8B es más cómodo y se pueden elegir algunos modelos cuantitativos 14B según el contexto.

La tabla es un punto de partida para juzgar la implementación, no una promesa de rendimiento. El modelo de CPU, los canales de memoria, el formato del modelo, la longitud del contexto, la cantidad de concurrencias, las limitaciones del sistema NAS y la disipación térmica variarán los resultados reales.

Primero veamos “almacenamiento” y “razonamiento” por separado.

El gran disco duro del NAS resuelve principalmente el problema del almacenamiento de archivos de modelos: puede guardar muchas bibliotecas de documentos y capas de modelos GGUF, Ollama. La velocidad de inferencia está determinada principalmente por los siguientes elementos:

Rendimiento del núcleo de la CPU y ancho de banda de la memoria;
Si la memoria del sistema es suficiente para instalar el modelo y el tiempo de ejecución;
Si la GPU está disponible y si la memoria de video puede adaptarse al modelo y al contexto;
Si los carriles, controladores y contenedores PCIe se transmiten correctamente de forma transparente;
Longitud del contexto, cuantificación del modelo, concurrencia y longitud de salida.

Entonces, la respuesta a “¿Puede un NAS ejecutar un modelo de 32 B si tiene un disco duro de 40 TB?” Por lo general, los archivos se pueden colocar, pero es posible que no se puedan inferir a una velocidad aceptable.

NAS solo con CPU: ¿Cuándo vale la pena implementarlo?

Es posible ejecutar Ollama sin una GPU. La imagen oficial de Docker admite el arranque puro de CPU:

docker run -d \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

Sólo CPU apto para:

Resumen nocturno de lotes, clasificación de documentos, extracción de etiquetas;
tareas de texto de baja frecuencia en domótica;
Validar llamadas API, canalizaciones RAG y lógica de permisos;
Herramientas personales que son insensibles a la latencia inicial del token y la velocidad de generación.

No muy adecuado para:

Servicio de chat para varias personas;
Agente de código de largo tiempo;
Los modelos grandes se generan continuamente;
Asistente de voz en tiempo real o preguntas y respuestas web de alta frecuencia.

La estrategia correcta para solo CPU es utilizar primero un modelo pequeño, un contexto breve y limitar la concurrencia. No descargue primero el modelo más grande y luego espere obtener una experiencia similar a la de la nube “confiando en el NAS y calculando lentamente”.

¿Cuánta memoria se debe reservar al menos?

La memoria del sistema no sólo se utiliza para los pesos de los modelos, sino también para el propio NAS, el caché de archivos, Docker, tareas de descarga, índice de fotografías, contenedores y KV Cache.

Un principio práctico: **No dejes que Ollama se coma la memoria del NAS hasta que empiece a intercambiarse mucho. ** Una vez que el intercambio intervenga con frecuencia, el tiempo de respuesta se deteriorará significativamente y el intercambio de archivos y otros servicios también se verán afectados.

Memoria	sugerencia
8GB	Sólo se recomiendan modelos pequeños y pruebas ligeras; Sea más conservador cuando el NAS esté ejecutando múltiples servicios.
16GB	Se puede utilizar como punto de partida para asistentes locales exclusivos de CPU, dando prioridad a modelos pequeños o versiones poco cuantificadas.
32GB	Más adecuado para la coexistencia de modelos de baja cantidad de nivel 7B, RAG y múltiples contenedores livianos
64GB+	Bueno para la descarga CPU/híbrida de modelos más grandes y documentos largos, pero no equivale a una generación lo suficientemente rápida

El tamaño del archivo del modelo es solo un límite inferior. La carga del modelo, el contexto y el tiempo de ejecución seguirán ocupando memoria, así que no confíe en “archivo de 8 GB, máquina de 8 GB” para juzgar si se puede ejecutar.

La mayor diferencia en experiencia se ve con las GPU NVIDIA

Si el NAS es x86 Linux y tiene una tarjeta gráfica NVIDIA compatible, Ollama puede usar la aceleración de GPU. Ollama enumera oficialmente el rango de soporte de la capacidad informática de NVIDIA 5.0+ y el controlador 531+, entre los cuales la serie RTX 30 también se incluye en la lista de soporte.

La solución Docker requiere que el host configure primero NVIDIA Container Toolkit y luego use los parámetros de GPU para iniciar el contenedor:

docker run -d \
  --gpus=all \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

Una vez iniciado el contenedor, verifique la transmisión transparente de la GPU en lugar de descargar directamente el modelo grande:

`1`	`docker run --gpus all ubuntu nvidia-smi`

Cuando este comando no muestra la tarjeta gráfica correctamente, el contenedor Ollama no puede usar la GPU. En este momento, primero debe verificar si el controlador, el Container Toolkit, el tiempo de ejecución de Docker y el sistema NAS admiten la transmisión transparente de GPU PCIe.

¿Se pueden utilizar directamente los gráficos principales, la NPU y las capacidades de transcodificación del NAS?

Esto no se puede asumir por defecto.

Los gráficos centrales de muchos NAS se utilizan principalmente para decodificación, transcodificación o salida de gráficos de video; Es posible que la NPU anunciada por algunos dispositivos solo esté abierta a las aplicaciones del propio fabricante. Que Ollama pueda utilizarlos depende del backend, el sistema operativo, el controlador y los permisos del dispositivo admitidos por Ollama.

Se deben ver pruebas reales antes del despliegue:

Si el host puede ver el dispositivo GPU;
Si nvidia-smi o la herramienta de detección del fabricante correspondiente se pueden ejecutar en el contenedor;
¿Los registros de Ollama muestran claramente el uso de GPU?
Bajo el mismo mensaje, ¿es razonable la diferencia de velocidad entre GPU y CPU?

Cuando no vea esta evidencia, planifique de acuerdo con las expectativas de la CPU únicamente. No compre un modelo basado en el rendimiento de gráficos discretos sólo porque el dispositivo tiene un “motor de transcodificación”.

Cómo elegir un modelo para no derribar el NAS

El núcleo de la implementación de NAS no es perseguir el modelo más grande, sino permitir que las tareas comunes se completen primero de manera estable.

escena	Ideas de selección de modelos
Resumen del documento familiar, clasificación, preguntas y respuestas sencillas.	Pruebe primero los modelos 1B–4B
Chat chino, secuencias de comandos ligeras, API de usuario único	Puedes probar el modelo de cuantificación 7B/8B cuando tengas 8 GB de memoria de vídeo.
Código largo, agente complejo	Priorice los hosts o nubes con mayor memoria. No se recomienda confiar únicamente en CPU NAS normales.
Incrustación/RAG	Los modelos integrados suelen ser más ligeros y adecuados para NAS; Los modelos generados se llaman bajo demanda.
Llamado por varias personas al mismo tiempo.	Primero establezca límites de cola y concurrencia, no permita que todas las solicitudes carguen directamente modelos grandes en paralelo

Una vez que el modelo es demasiado grande, los síntomas comunes de NAS no son fallas inmediatas, sino cargas prolongadas, primera generación lenta de tokens, baja velocidad de generación y aumento continuo de la memoria del sistema, lo que en última instancia afecta la estabilidad de los servicios de archivos y contenedores.

Estructura de implementación recomendada

Para la mayoría de las familias o equipos pequeños, se recomienda utilizar NAS como “nodo de razonamiento ligero y de datos”:

NAS
├─ Ollama：小模型、Embedding、低频 API
├─ 文档与向量库：私有文件、备份、RAG 数据
├─ 反向代理：局域网访问控制
└─ 监控：CPU、内存、GPU、容器日志

高显存主机或云端
└─ 大模型、长上下文、复杂 Agent、高并发推理

Esta división del trabajo es más estable que forzar todas las inferencias en el NAS: los archivos confidenciales permanecen locales y las tareas pesadas se enrutan a dispositivos más apropiados.

Prueba de cinco minutos antes del despliegue

No descargues primero docenas de modelos de GB. Primer juez según este proceso:

Confirme la arquitectura del NAS, la compatibilidad con Docker y la memoria restante.
Inicie el contenedor Ollama y confirme que http://NAS地址:11434 sea accesible.
Saque un modelo pequeño y haga de 5 a 10 preguntas fijas seguidas.
Observe el uso de CPU, memoria, intercambio, E/S de disco y GPU.
Luego cambie a un modelo que se acerque a los requisitos reales y aumente gradualmente el contexto y la concurrencia.

Puede utilizar el siguiente comando para ver los recursos del contenedor:

`1`	`docker stats ollama`

Si tienes una GPU NVIDIA, observa al mismo tiempo:

`1`	`nvidia-smi`

Siempre que las tareas de intercambio de archivos, publicación de fotografías o copias de seguridad sean notablemente más lentas cuando se ejecuta un modelo, el modelo actual o la concurrencia no son adecuados para NAS, y el tamaño del modelo debe reducirse o la inferencia debe trasladarse a otras máquinas.

No ignores la red y la seguridad

El puerto de servicio local predeterminado de Ollama es 11434. Si desea que otros dispositivos en la LAN lo llamen, primero implemente el control de acceso en el firewall del NAS o en la capa de proxy inverso, y no exponga directamente el puerto de inferencia no autenticado a la red pública.

Especialmente cuando hay fotos familiares, copias de seguridad, documentos y archivos privados en el NAS, el servicio de modelo, el servicio de archivos y el backend de administración deben utilizar límites de permisos diferentes. Para llamadas que se pueden completar en la LAN, no es necesario abrir el puerto de la red pública.

Resumir

Si Ollama es suficiente para la implementación de NAS se puede juzgar de la siguiente manera:

只做摘要、分类、Embedding
-> CPU-only NAS 可以尝试

想要 7B/8B 模型的日常交互体验
-> 需要可用 GPU，优先看显存

想做长上下文、复杂 Agent 或多人并发
-> 更适合高显存主机或云端推理

Primero use un modelo pequeño para verificar los recursos y la estabilidad, y luego decida si agregar una tarjeta gráfica, expandir la memoria o dividir los nodos de inferencia. NAS es excelente para alojar datos privados y servicios de modelos livianos, pero no es un servidor de modelos grandes natural.

referirse a:

Qué hacer si vLLM KV Cache no tiene suficiente memoria: resolución de problemas de memoria de video, contexto y concurrencia

Sat, 11 Jul 2026 09:36:02 +0800

Cuando se produce el siguiente error al iniciar vLLM, normalmente no se debe a que la descarga del peso del modelo esté interrumpida:

`1`	`The model's max seq len ... KV cache is needed, which is larger than the available KV cache memory`

Significa que después de que los pesos del modelo y la sobrecarga del tiempo de ejecución ocupan la memoria de video, el espacio restante no es suficiente para preparar el caché KV para la longitud máxima de contexto que establezca. La secuencia de procesamiento más directa es: ** Primero reduzca --max-model-len, luego verifique la concurrencia y finalmente considere mejorar la utilización de la memoria, cuantificar el caché KV o expandir la capacidad. **

No lleves --gpu-memory-utilization a 1 desde el principio. Eso puede permitir que vLLM pase la inicialización, pero sea más propenso a OOM cuando solicitudes reales, gráficos CUDA u otros procesos compiten por la memoria de video.

Primero comprenda: por qué KV Cache llena la memoria de video

El peso del modelo determina “si el modelo se puede cargar” y KV Cache determina “cuántos tokens puede recordar el modelo al mismo tiempo y cuántas solicitudes atiende”. Cada vez que se genera o lee un token, la capa de atención debe guardar el estado de clave/valor correspondiente.

Por lo tanto, el uso de KV Cache aumentará con los siguientes elementos:

max_model_len: cuanto más largo sea el contexto máximo permitido, mayores serán los requisitos de caché.
Número de solicitudes simultáneas: cada solicitud simultánea ocupará su propio espacio de contexto.
Estructura del modelo: la cantidad de capas, la cantidad de cabezales KV, el tamaño oculto y el tipo de datos afectan el tamaño de la caché.
Precisión de la caché: el valor predeterminado suele seguir el tipo de datos del modelo; Las cachés de baja precisión, como las del FP8, pueden ahorrar espacio, pero tienen límites de compatibilidad y calidad.

Lo que más se pasa por alto es la concurrencia. Incluso si a cada solicitud solo se le proporciona un contexto de 8K, la demanda total de KV Cache seguirá creciendo rápidamente cuando se ejecuten varias solicitudes simultáneamente.

Primero determine qué tipo de problema es a partir de los registros.

Los registros de inicio suelen proporcionar tres datos clave:

La longitud máxima de secuencia especificada por el modelo o configurada por usted.
¿Cuántos GiB requiere KV Cache?
El espacio real disponible actualmente para KV Cache y la longitud máxima factible estimada por vLLM.

Si el registro dice “La longitud máxima 32768 requiere caché KV de 10 GiB, pero actualmente solo 4 GiB”, no se preocupe primero si el modelo admite 32 K. El modelo Soporte no significa que su tarjeta pueda atender 32 000 solicitudes con la configuración actual.

Comience tomando nota de la longitud máxima estimada proporcionada por el registro, establezca su primera prueba entre el 60% y el 80% de ella y luego vaya subiendo.

Primera prioridad: menor `--max-model-len`

Este es el ajuste con mayor tasa de éxito y el impacto más predecible. Por ejemplo, el modelo admite de forma nativa 32K y su negocio real solo maneja conversaciones ordinarias, códigos cortos y documentos pequeños; puede comenzar con 8K:

1
2

vllm serve Qwen/Qwen3-8B \
  --max-model-len 8192

Si aún no es suficiente, inténtalo de nuevo:

1
2

vllm serve Qwen/Qwen3-8B \
  --max-model-len 4096

No escriba el contexto nominal de 128K, 256K o más de la tarjeta del modelo directamente en los parámetros de servicio. Para implementaciones de una sola tarjeta, la longitud real disponible depende del peso, la memoria de video, la simultaneidad y la precisión de la caché.

Un punto de partida práctico:

Memoria de vídeo y uso	Longitud del contexto para probar primero
Tarjeta única de 12 GB a 16 GB, modelo Clase 8B	4096 o 8192
Tarjeta única de 24 GB, modelos 7B-14B	8192 o 16384
Tarjeta única de 24 GB, modelo cuantificado de nivel 30 B	Empezar con 4096
Documento largo/RAG/Servicio multiusuario	Tome decisiones basadas en estimaciones logarítmicas y pruebas de estrés, no se limite a seguir la tabla

Estos valores son un punto de partida para la resolución de problemas, no compromisos de memoria. El tamaño de la caché KV puede variar significativamente entre modelos.

Segunda prioridad: limitar la simultaneidad y el procesamiento por lotes

El hecho de que el servicio pueda iniciarse no significa que será estable en condiciones de alta concurrencia. Primero, controle la concurrencia a un valor pequeño:

1
2
3

vllm serve Qwen/Qwen3-8B \
  --max-model-len 8192 \
  --max-num-seqs 4

--max-num-seqs limita el número de secuencias que se pueden procesar en una iteración. Un número mayor puede dar como resultado un mayor rendimiento, pero también una mayor caché KV y presión de programación.

Si las solicitudes suelen contener mensajes largos, también debe prestar atención a --max-num-batched-tokens. Determina la cantidad máxima de tokens que se pueden procesar al mismo tiempo; si es demasiado alto, la fase de precarga puede ocupar más recursos al instante. Sea conservador al solucionar problemas y luego amplíelo gradualmente después de confirmar la estabilidad.

Se recomienda realizar pruebas de estrés en este orden:

Solicitud única, contexto 4K, estabilidad del servicio confirmada.
Solicitud única, contexto de 8K, observe la latencia del primer token y la memoria de video.
Dos solicitudes simultáneas confirman que no habrá OOM.
Luego, aumente gradualmente max_num_seqs o la cantidad de tokens por lotes.

No ajuste la cuantificación de contexto, concurrencia, lote y modelo al mismo tiempo; de lo contrario, será difícil localizar qué parámetro está provocando que se agote la memoria de vídeo.

Tercera prioridad: `--gpu-memory-utilization` configurado correctamente

--gpu-memory-utilization especifica la proporción de memoria GPU que puede utilizar la instancia vLLM actual, con un valor entre 0 y 1. vLLM planificará el peso, el tiempo de ejecución y la caché KV en función de esta parte del espacio.

Por ejemplo:

vllm serve Qwen/Qwen3-8B \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 \
  --max-num-seqs 4

Cuando el mensaje de error dice claramente “Muy poca caché KV disponible” y no hay otros procesos en la GPU, puede mejorarlo en pequeños pasos, como intentar de 0.90 a 0.92 o 0.94. Agregue poco a poco y pruebe con solicitudes reales.

No se recomienda hacer peso muerto alto en las siguientes situaciones:

En la misma tarjeta también se ejecuta un programa de escritorio, otro servicio de inferencia o una tarea de capacitación.
La memoria de video disponible fluctuará después del inicio.
Es probable que se produzcan picos cuando se utilizan gráficos CUDA, modelos de visión o precargas de alta concurrencia.
Ha encontrado un CUDA OOM sobre la marcha, no solo una verificación de inicialización fallida.

Si varias instancias comparten la misma GPU, debes tener un presupuesto explícito para cada instancia en lugar de configurarlas todas en 0,9.

Caché FP8 KV: confirme el modelo y la versión antes de guardar la memoria gráfica

vLLM admite cambiar el tipo de datos de la caché mediante --kv-cache-dtype. Los entornos CUDA 11.8+ están disponibles con opciones relacionadas con FP8, como:

1
2
3

vllm serve Qwen/Qwen3-8B \
  --kv-cache-dtype fp8 \
  --max-model-len 16384

FP8 KV Cache puede reducir significativamente el uso de caché, pero no lo considere un cambio completamente gratuito:

Primero confirme que el vLLM, CUDA y el hardware actuales admitan este tipo de datos.
Si el punto de control del modelo proporciona una escala KV adecuada afectará los resultados; su ausencia debe evaluarse con cautela.
Los contextos extensos, el razonamiento complejo, las llamadas a herramientas y la salida estructurada deben probarse con la precisión de la caché predeterminada.
Si simplemente desea colocar un modelo grande inadecuado en la tarjeta gráfica, suele ser más estable bajar el contexto primero o cambiar a un modelo más adecuado.

Por lo tanto, el orden más recomendado es: primero usar la precisión predeterminada para ejecutar 4K/8K de manera estable y luego probar si FP8 realmente puede permitir que la empresa obtenga el contexto o la simultaneidad requerida.

Conozca las prioridades al especificar manualmente el tamaño de la caché KV

Los vLLM más nuevos proporcionan kv_cache_memory_bytes para especificar el tamaño de la caché KV con precisión en bytes por GPU. Es adecuado para escenarios en los que varios servicios comparten una tarjeta y requieren un presupuesto fijo de memoria gráfica.

Nota: Establecer explícitamente el número de bytes de caché anulará la inferencia automática del tamaño de caché a través de gpu_memory_utilization. No piense en ambos como ganancias aditivas; Primero decida si utilizará un “presupuesto proporcional” o un “presupuesto de caché fijo”.

El presupuesto fijo es adecuado para servidores con restricciones claras de operación y mantenimiento. Es más intuitivo utilizar --gpu-memory-utilization y --max-model-len para solucionar problemas de una sola máquina.

¿Qué puede resolver la descarga de CPU y qué no?

La nueva versión de vLLM admite la descarga de parte de KV Cache a la CPU o su combinación con capas de caché de procesamiento back-end como LMCache. Esto puede ampliar la capacidad cuando la caché de la GPU es insuficiente, pero a costa de las transferencias de memoria/PCIe y la latencia.

Es más adecuado para:

Ocasionalmente solicitudes de contexto muy largas;
La empresa puede aceptar un mayor retraso del token inicial;
Hay suficiente memoria en el sistema y se han realizado pruebas de estrés reales;
Quiere crear una ruta de degradación para mensajes largos en lugar de buscar el mayor rendimiento.

No es adecuado para encubrir el problema de que “el peso del modelo no se puede reducir”, ni puede reemplazar la gestión de la concurrencia y los límites superiores del contexto. Si todas las solicitudes se intercambian con frecuencia, el rendimiento a menudo disminuirá significativamente.

Una plantilla de solución de problemas replicable

Comience con una configuración conservadora:

vllm serve Qwen/Qwen3-8B \
  --gpu-memory-utilization 0.90 \
  --max-model-len 4096 \
  --max-num-seqs 2

Después de confirmar que la solicitud de pedido se puede procesar de manera estable, ajuste en el siguiente orden:

4096 上下文稳定
-> 8192 上下文稳定
-> max_num_seqs 从 2 调到 4
-> 调整 max_num_batched_tokens
-> 再测试 FP8 KV Cache 或 CPU offload

En cada ronda se registran cuatro datos: número de tokens de caché KV disponibles, retraso del primer token, tokens generados y memoria de video máxima. De esta manera, puede saber si una optimización mejora el rendimiento o simplemente difiere los OOM hacia una mayor concurrencia.

Malentendidos comunes

Malentendido 1: el modelo admite contexto largo, por lo que el servicio debe estar completamente habilitado

El límite superior de capacidades del modelo y el límite superior de capacidad de servicio de su tarjeta gráfica son dos cosas diferentes. El max_model_len del servidor debe configurarse de acuerdo con el límite superior empresarial y de hardware.

Malentendido 2: establezca `gpu_memory_utilization` en 1 para resolver el problema

Esto reduce el margen de seguridad y no reduce la necesidad del caché KV en sí. Es más probable que los picos de tiempo de ejecución activen CUDA OOM.

Malentendido 3: Reducir solo la cuantificación de peso, independientemente de la concurrencia

La cuantificación del peso puede liberar memoria de vídeo, pero la concurrencia y el contexto seguirán haciendo que la caché KV se expanda rápidamente. Las configuraciones del servicio deben limitar tanto la duración como el número de solicitudes.

Mito 4: descargar la CPU es definitivamente mejor que rechazar solicitudes largas

Si la latencia es sensible, la descarga frecuente puede ser peor que enrutar explícitamente solicitudes largas a nodos con mayor memoria. Primero defina los límites de demora y costos del negocio.

Resumir

vLLM KV Cache no tiene suficiente memoria. La prioridad de procesamiento más confiable es:

降低 max_model_len
-> 限制 max_num_seqs 与 batch
-> 小步调整 gpu_memory_utilization
-> 验证 FP8 KV Cache
-> 最后考虑固定缓存预算或 CPU offload

Primero deje que un contexto breve y una configuración de baja concurrencia funcionen de manera estable y luego amplíelos gradualmente de acuerdo con los datos comerciales. Siempre que el peso del modelo, la caché KV, la concurrencia y la longitud del contexto real se analicen por separado, la mayoría de los problemas de “falta de memoria” se pueden localizar más rápidamente.

referirse a:

Cómo configurar la conmutación multimodelo de Ollama: residente, memoria de video y tutoriales de Modelfile

Sat, 11 Jul 2026 09:32:06 +0800

Después de que Ollama haya instalado varios modelos, la primera pregunta que mucha gente tiene es: ¿Cómo cambiar rápidamente entre modelos de chat, código, traducción e incrustación? La segunda pregunta suele ser más práctica: ¿Por qué la anterior desaparece de la memoria de vídeo justo después de cambiar a otro modelo?

Permítanme comenzar con la conclusión: Ollama no necesita servir cada modelo por separado. Utilice ollama run <模型名> para el cambio diario; use ollama ps para ver qué modelos están actualmente en la memoria; utilice ollama stop <模型名> para liberar modelos innecesarios. La posibilidad de que varios modelos residan al mismo tiempo depende de si caben en la memoria o la memoria de video disponible, en lugar de cuántos modelos se descargan en el disco local.

Comandos de conmutación más utilizados

Primero enumere los modelos que ha descargado esta máquina:

`1`	`ollama ls`

Inicie un modelo de chat o código:

`1`	`ollama run qwen3:8b`

Cuando necesite cambiar a otro modelo, ejecute otro nombre directamente:

`1`	`ollama run qwen3:4b`

O cambie al modelo de incrustación para realizar pruebas:

`1`	`ollama run embeddinggemma "测试一段文本"`

Los archivos del modelo permanecen locales y no se volverán a descargar al cambiar. Los pesos deben colocarse en la memoria de video o en la memoria del sistema cuando se carga el modelo por primera vez. Si el modelo aún se conserva en la memoria, será más rápido volver a llamarlo.

`ollama ps`: Primero ver quién ocupa la memoria de video

Cuando el cambio no sea fluido, primero ejecute:

`1`	`ollama ps`

Enumera los modelos que se están ejecutando o que aún residen en la memoria. Lo más interesante a tener en cuenta aquí es el nombre del modelo, el tamaño, la ubicación del procesador y el tiempo de caducidad.

Si sólo tienes una tarjeta gráfica de tamaño medio y lanzas dos modelos grandes uno tras otro, Ollama podrá desinstalar el primer modelo para dejar espacio al segundo. Esta es una programación de recursos normal, no es que el modelo se pierda. El modelo todavía está en el disco y se recargará en la próxima llamada.

Si no desea esperar a que caduque naturalmente, puede detenerlo de forma proactiva:

`1`	`ollama stop qwen3:8b`

Luego use ollama ps para confirmar que se ha liberado la memoria de video.

Tiempo de permanencia predeterminado: 5 minutos

Por defecto, Ollama conserva un modelo durante aproximadamente 5 minutos después de su último uso. Este diseño es adecuado para preguntas continuas: la primera carga es un poco más lenta y las solicitudes posteriores no necesitan mover repetidamente el mismo modelo a la memoria de video.

Si utiliza varios modelos a la vez en una máquina con poca memoria de video, 5 minutos pueden causar la sensación de “acabo de terminar de ejecutar uno y la memoria de video aún no ha sido devuelta”. Existen tres métodos de control en este momento.

Método 1: desinstalar inmediatamente después de una llamada

Establezca keep_alive en 0 a través de API:

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "prompt": "用一句话解释 KV cache",
  "keep_alive": 0
}'

Esto es adecuado para situaciones en las que el modelo es grande, la memoria de vídeo es escasa y cada tarea es independiente.

Método 2: mantener el modelo residente durante mucho tiempo

Si utiliza el mismo modelo de código todo el día, puede establecer keep_alive en un número negativo:

curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:8b",
  "keep_alive": -1
}'

De esta manera el modelo permanecerá en la memoria hasta que manualmente ollama stop o se reinicie el servicio. No configure esto para varios modelos grandes cuando no tenga suficiente memoria de video.

Método 3: modificar globalmente la hora residente predeterminada

OLLAMA_KEEP_ALIVE se puede configurar para los servicios de Ollama. Por ejemplo, si desea que todos los modelos se conserven durante 30 segundos de forma predeterminada:

`1`	`OLLAMA_KEEP_ALIVE=30s`

En Windows, Ollama hereda las variables de entorno del sistema o del usuario. Una vez que se completa la configuración, debe salir de Ollama desde la bandeja y reiniciar desde el menú Inicio. Si Ollama es administrado por systemd en Linux, configure la variable de entorno del servicio y reinicie el servicio.

keep_alive en la solicitud API anulará el OLLAMA_KEEP_ALIVE global, por lo que es más adecuado establecer diferentes políticas para diferentes tareas.

La clave para la persistencia multimodelo: `OLLAMA_MAX_LOADED_MODELS`

OLLAMA_MAX_LOADED_MODELS se utiliza para limitar la cantidad de modelos que se pueden cargar simultáneamente. Por ejemplo, solo desea que el servicio conserve como máximo un modelo:

`1`	`OLLAMA_MAX_LOADED_MODELS=1`

El propósito de esta configuración es evitar llenar la memoria de video durante mucho tiempo cuando se gira el modelo, pero no es un método para “forzar un modelo grande a caber en la tarjeta gráfica”. Durante la inferencia de GPU, un nuevo modelo puede residir simultáneamente con otros modelos solo si puede caber completamente en la memoria de video disponible. De lo contrario, Ollama descargará el modelo antiguo o colocará el modelo en una ruta de memoria más lenta.

Para una única tarjeta gráfica de 8GB, 12GB o 16GB, la estrategia más estable suele ser:

escena	sugerencia
Utilice solo un modelo de chat cada día	`OLLAMA_MAX_LOADED_MODELS=1`, mantener durante 5 minutos o menos
Chat de modelo pequeño + Incrustación	Primero verifique la ocupación real de ambos. Si puedes dejarlos al mismo tiempo, aumenta la cantidad.
El modelo de código y el modelo general se utilizan alternativamente.	No insistas en la doble residencia, cambia según las tareas y toma la iniciativa `ollama stop`
Llamada multiusuario del servidor	Combine el tamaño del modelo, la memoria de video y el volumen de solicitudes, y luego configure la simultaneidad y la cola

No ignore la concurrencia: los contextos también consumen memoria

Los problemas multimodelo no se refieren sólo a los pesos de los modelos. Cada solicitud paralela aumenta el consumo de recursos del contexto y la caché KV.

Ollama también proporciona dos variables de entorno relacionadas:

1
2

OLLAMA_NUM_PARALLEL=1
OLLAMA_MAX_QUEUE=512

OLLAMA_NUM_PARALLEL controla la cantidad de solicitudes que el mismo modelo puede procesar en paralelo. Cuando aumenta el número de concurrencia, los recursos necesarios aumentarán con la longitud del contexto. Cuando se utiliza una sola tarjeta localmente, suele ser más fácil solucionar el problema dejando el valor predeterminado o configurándolo explícitamente en 1; no cargue varios modelos mientras aumenta la simultaneidad.

OLLAMA_MAX_QUEUE es la cantidad de solicitudes que se pueden poner en cola cuando está ocupada. Solo resuelve las colas y no aumenta la memoria de video.

Utilice Modelfile para crear alias fijos para diferentes propósitos

Si siempre configura repetidamente palabras de aviso del sistema, temperatura o políticas de contexto para el mismo modelo base, puede usar Modelfile para crear múltiples alias locales. En lugar de duplicar un conjunto completo de pesos, definen diferentes configuraciones basadas en un modelo.

Por ejemplo, cree un archivo de configuración basado en código Modelfile.code:

1
2
3

FROM qwen3:8b
SYSTEM 你是一个中文编程助手。先说明修改思路，再给出可运行的最小代码。
PARAMETER temperature 0.2

Crea un alias de modelo:

`1`	`ollama create qwen3-code -f Modelfile.code`

Luego ejecuta directamente:

`1`	`ollama run qwen3-code`

También puedes hacer una versión orientada a la escritura:

1
2
3

FROM qwen3:8b
SYSTEM 你是中文写作助手，回答前先给结论，再给必要的结构化说明。
PARAMETER temperature 0.7

1
2

ollama create qwen3-write -f Modelfile.write
ollama run qwen3-write

Nota: qwen3-code y qwen3-write, aunque comparten la misma orientación base, siguen siendo configuraciones de modelo diferentes en tiempo de ejecución. Cuando la memoria de vídeo es escasa, no asuma que pueden residir indefinidamente al mismo tiempo.

Proporcione scripts o API para cambiar modelos por tarea

En la API, el nombre del modelo en sí es el campo de enrutamiento. No es necesario que el script reinicie el servicio, simplemente pase un model diferente según la tarea:

curl http://localhost:11434/api/chat -d '{
  "model": "qwen3-code",
  "messages": [
    {"role": "user", "content": "解释这段 Python 的异常处理逻辑"}
  ],
  "stream": false,
  "keep_alive": "10m"
}'

Una división común del trabajo es:

Modelo pequeño: clasificación, reescritura, resumen, preguntas y respuestas simples;
Modelo de código: interpreta el almacén, genera scripts y corrige errores;
Modelo de incrustación: recuperación de vectores, no responsable del chat;
Modelos más grandes: problemas complejos, cargados bajo demanda, liberados después de su uso.

Escribir “qué modelo elegir” en el enrutamiento de tareas del código hace que sea más fácil controlar la velocidad y la memoria que concentrar todo el trabajo en un modelo grande.

Errores comunes en Windows

La variable de entorno se cambió pero no tuvo efecto.

Después de modificar OLLAMA_KEEP_ALIVE, OLLAMA_MAX_LOADED_MODELS o OLLAMA_MODELS en Windows, debe salir del programa de bandeja Ollama en ejecución y reiniciar. Por lo general, simplemente reabrir PowerShell no es suficiente.

Los archivos de modelo llenan el disco del sistema.

Puede configurar OLLAMA_MODELS para mover el directorio del modelo a otro disco, por ejemplo:

`1`	`OLLAMA_MODELS=D:\OllamaModels`

Guarde y reinicie Ollama. Antes de migrar modelos existentes, confirme el espacio en disco y los permisos del directorio. No elimine el directorio anterior solo para cambiar el volumen.

Pensé que el modelo había sido eliminado.

Después de cambiar, no puede ver el modelo anterior con ollama ps, lo que simplemente significa que se ha descargado de la memoria; aún puedes ver el modelo descargado con ollama ls. Los archivos del modelo local se eliminarán únicamente ejecutando el siguiente comando:

`1`	`ollama rm qwen3:8b`

Un conjunto de estrategias predeterminadas adecuadas para una sola tarjeta.

Si solo tiene una tarjeta gráfica de consumo y cambia con frecuencia entre varios modelos, puede comenzar con esta estrategia:

1
2
3

OLLAMA_MAX_LOADED_MODELS=1
OLLAMA_KEEP_ALIVE=2m
OLLAMA_NUM_PARALLEL=1

Luego llame al modelo qwen3-code, qwen3-write o Incrustación por tarea. Cuando necesite ejecutar un modelo grande, ejecute ollama stop primero para detener modelos innecesarios; cuando encuentre contextos largos o archivos grandes, reduzca la cantidad de simultaneidad y números residentes.

El objetivo de esta configuración no es permitir que la tarjeta gráfica cargue tantos modelos como sea posible al mismo tiempo, sino permitir que cada cambio sea predecible y la memoria gráfica no se llene con modelos que se olvidarán durante mucho tiempo.

Resumir

Solo hay cuatro comandos principales para la conmutación multimodelo de Ollama:

ollama ls
ollama run <模型名>
ollama ps
ollama stop <模型名>

Si desea administrar mejor los modelos para diferentes propósitos, use Modelfile para crear alias; si desea controlar la carga y liberación, use keep_alive, OLLAMA_KEEP_ALIVE y OLLAMA_MAX_LOADED_MODELS. Primero determine la cantidad de residentes simultáneos de acuerdo con la memoria de video y luego considere el enrutamiento y la concurrencia multimodelo. La configuración será mucho más estable.

referirse a:

GPU VRAM on KnightLi Blog

Cómo calcular el costo de ejecutar Agent en una tarjeta gráfica de consumo: factura de electricidad, depreciación y costo por tarea

Primero determine qué costos desea calcular

Fórmula de costo total mensual

Un ejemplo de parámetros reemplazables.

¿Por qué es más difícil estimar el agente que el chat normal?

Dos unidades que hay que ver al mismo tiempo

cada tarea exitosa

por millón de tokens

Cómo recopilar tus propios datos

Cómo calcular la depreciación para no engañarte

Al comparar con las API de la nube, no se limite a comparar el precio unitario

Una línea de decisión práctica

Malentendidos comunes

Resumir

Si el rendimiento de Ollama de la implementación de NAS es insuficiente: cómo juzgar la CPU, la memoria y la tarjeta gráfica

Primero confirme a qué categoría pertenece su NAS

Primero veamos “almacenamiento” y “razonamiento” por separado.

NAS solo con CPU: ¿Cuándo vale la pena implementarlo?

¿Cuánta memoria se debe reservar al menos?

La mayor diferencia en experiencia se ve con las GPU NVIDIA

¿Se pueden utilizar directamente los gráficos principales, la NPU y las capacidades de transcodificación del NAS?

Cómo elegir un modelo para no derribar el NAS

Estructura de implementación recomendada

Prueba de cinco minutos antes del despliegue

No ignores la red y la seguridad

Resumir

Qué hacer si vLLM KV Cache no tiene suficiente memoria: resolución de problemas de memoria de video, contexto y concurrencia

Primero comprenda: por qué KV Cache llena la memoria de video

Primero determine qué tipo de problema es a partir de los registros.

Primera prioridad: menor --max-model-len

Segunda prioridad: limitar la simultaneidad y el procesamiento por lotes

Tercera prioridad: --gpu-memory-utilization configurado correctamente

Caché FP8 KV: confirme el modelo y la versión antes de guardar la memoria gráfica

Conozca las prioridades al especificar manualmente el tamaño de la caché KV

¿Qué puede resolver la descarga de CPU y qué no?

Una plantilla de solución de problemas replicable

Malentendidos comunes

Malentendido 1: el modelo admite contexto largo, por lo que el servicio debe estar completamente habilitado

Malentendido 2: establezca gpu_memory_utilization en 1 para resolver el problema

Malentendido 3: Reducir solo la cuantificación de peso, independientemente de la concurrencia

Mito 4: descargar la CPU es definitivamente mejor que rechazar solicitudes largas

Resumir

Cómo configurar la conmutación multimodelo de Ollama: residente, memoria de video y tutoriales de Modelfile

Comandos de conmutación más utilizados

ollama ps: Primero ver quién ocupa la memoria de video

Tiempo de permanencia predeterminado: 5 minutos

Método 1: desinstalar inmediatamente después de una llamada

Método 2: mantener el modelo residente durante mucho tiempo

Método 3: modificar globalmente la hora residente predeterminada

La clave para la persistencia multimodelo: OLLAMA_MAX_LOADED_MODELS

No ignore la concurrencia: los contextos también consumen memoria

Utilice Modelfile para crear alias fijos para diferentes propósitos

Proporcione scripts o API para cambiar modelos por tarea

Errores comunes en Windows

La variable de entorno se cambió pero no tuvo efecto.

Los archivos de modelo llenan el disco del sistema.

Pensé que el modelo había sido eliminado.

Un conjunto de estrategias predeterminadas adecuadas para una sola tarjeta.

Resumir

Primera prioridad: menor `--max-model-len`

Tercera prioridad: `--gpu-memory-utilization` configurado correctamente

Malentendido 2: establezca `gpu_memory_utilization` en 1 para resolver el problema

`ollama ps`: Primero ver quién ocupa la memoria de video

La clave para la persistencia multimodelo: `OLLAMA_MAX_LOADED_MODELS`