Qwen local no es un Opus peor, sino una herramienta distinta
(blog.alexellis.io)- Qwen 3.6 27B en local genera valor real en trabajos difíciles de subir a la nube, como datos de clientes y telemetría interna, pero no reemplaza a los modelos SOTA en la nube
- La fortaleza de los modelos locales no está en competir por puntajes con los modelos de máximo rendimiento, sino en el costo fijo, la privacidad y la mitigación del riesgo de proveedor; la diferencia se nota especialmente en uso intensivo y funciones internas de SaaS
- En SWE-Bench Verified, Qwen 3.6 27B obtiene 77.2 puntos y Claude Opus 4.8 un 88.6%; afirmar que “local está solo 12% detrás de SOTA” ignora la posibilidad de ajustar para benchmarks y las diferencias de dominios reales como Go
- El equipo RTX 6000 Pro Blackwell 96GB, comprado por unos 12,000 USD, recuperó su costo solo con un caso de recuperación de ingresos al detectar subdeclaración de licencias de clientes
- La mayor limitación es el problema de bucles, donde aparecen salidas repetitivas y alucinaciones en tareas largas; Qwen local encaja mejor en soporte al cliente, mantenimiento acotado, lectura y explicación de codebases que en programación no supervisada de largo alcance
Contexto del uso de IA y del negocio
- El equipo opera productos enfocados en infraestructura de bajo nivel y primitivas de Linux como OpenFaaS, SlicerVM, Actuated e Inlets
- Están basados en contenedores, microVM de Firecracker, protocolos de red, túneles, CLI y Kubernetes; en su mayoría escritos en Go, con algo de UI en React
- Se usan herramientas de IA desde la época del autocompletado por pestañas en VS Code, y hoy la mayor parte del código la hacen Claude o Codex; casi ya no se programa a mano
- Para gestionar flujos de trabajo largos en tmux se creó Superterm.dev, usado para manejar sesiones, notas y feedback visual de agentes de código
El punto de inflexión de la inteligencia frontier
- Hubo un punto de inflexión entre noviembre de 2025 y enero de 2026, cuando muchos desarrolladores en X evaluaron que Claude Opus podía hacerse cargo de todo su trabajo
- El costo de los planes top para programar se estabilizó en unos 200 USD al mes por persona, y mientras se eviten tareas excesivamente no supervisadas, se puede trabajar dentro de límites semanales de 5 horas
Por qué son interesantes los modelos locales
- 2026 es una era en la que cualquiera puede copiar una idea de la noche a la mañana con una sola suscripción; SlicerVM y Superterm también ya vivieron casos de clones
- En un mercado donde el costo del software tiende a cero, “gratis y suficientemente bueno” puede ser lo más importante
- Se estima que los modelos líderes tienen entre 0.5 y 2T parámetros, una escala completamente distinta al mejor hardware local
-
Benchmaxxing
- Los benchmarks son públicos, así que se pueden ajustar para subir el puntaje, por lo que cuesta tomarlos como métrica absoluta
- SWE-Bench Verified se basa en issues de Python, donde gran parte del código es monohilo y sincrónico; en cambio, los sistemas distribuidos en Go usan channel, context y struct a lo largo de áreas de ejecución mucho más amplias
- No se puede concluir solo por el benchmark que “local está 12% por detrás de SOTA”; en trabajo real, las características del lenguaje y del sistema pesan mucho en el resultado
-
Costo
- Decir que “los modelos locales no son un tema de costo” no aplica para todo el mundo
- Un plan personal para programar cuesta 200 USD al mes y ofrece mucho uso e inteligencia a nivel SOTA, pero parece estar subsidiado
- GitHub Copilot pasó de ofrecer 1,500 solicitudes por 39 USD al mes a un esquema de cobro por tokens, lo que generó bastante rechazo
- Si se cobra por tokens de API, el punto de equilibrio puede llegar rápido
- Uber limita su gasto en IA a 1,500 USD mensuales por desarrollador y por herramienta
- Con un salario medio de 330,000 USD en Uber, si un desarrollador usa dos herramientas hasta el límite, eso equivale a cerca del 12% del sueldo
- En uso masivo, bucles, análisis con agentes y funciones embebidas en SaaS, los modelos open weight y locales pueden aportar mucho valor
-
Soberanía y privacidad
- En algunos casos no es viable subir datos a planes en la nube por datos de clientes y términos contractuales
- ChatGPT Pro y Claude Max permiten configurar una retención de 30 días, pero incluso ese nivel podría invalidar contratos con clientes
- El caso en que el modelo Fable 5 de Anthropic fue retirado de un día para otro fuera de Estados Unidos funciona como riesgo de proveedor
- Los modelos locales son una respuesta a la pregunta: “¿qué pasa si el laboratorio frontier hace X?”
La analogía del forjado de cuchillas: la naturaleza de los modelos locales
- Así como en el tratamiento térmico del acero, si te pasas aunque sea una etapa tienes que volver a empezar, con los modelos locales también si operan demasiado “calientes”, se pasan del objetivo y caen en bucles
- La única salida es matar el harness y esperar otro resultado con un contexto vaciado
- Así como no se deja el forjado de una cuchilla sin supervisión, no se le encargan tareas de horizonte largo a Qwen 3.6 27B
-
Lo que estaba buscando
- El objetivo era privacidad, costo fijo y defensa frente al riesgo de proveedor
- La decepción vino al tratar al modelo local igual que a Claude o Codex
- Claude puede hacer ciclos eficientes de escribir PRs, revisar código automáticamente e iterar en 5 a 15 minutos solo con una instrucción corta como “do it and test it end to end”
Lecciones aprendidas con la 3090
- Todo empezó en 2023 con una sola 3090, y luego hizo falta agregar otra para cargar modelos y tener suficiente contexto
- Fue el primer momento en que se vio a Qwen 3.5 hacer trabajo real como agente
- Al pedirle “explora la máquina desde todos los ángulos y redacta un informe forense”, leyó archivos uno por uno hasta llenar el contexto y alucinar nombres de archivos y tool calls (
~/faas-netes→~/faaned)- Al acotar la tarea y pedirle “dar una mirada rápida”, produjo un informe claro a unas 40~50 tok/s
- El modelo 27B no cabe a precisión completa en una sola 3090, así que las variables de ajuste fueron cuantización de pesos, longitud de contexto y compresión del caché KV
- La regla general es que la parte de keys del caché KV da problemas en Q4_0; incluso en el ajuste más agresivo, solo se usó keys Q8_0 / values Q4_0
- Incluso en pruebas con vLLM + NVLink + tensor parallelism, la generación fue 3 tokens por segundo más lenta que en llama.cpp, además de aparecer bucles y tardar varios minutos en cargar pesos
- vLLM sirve mejor para servir a gran escala y con concurrencia alta, pero en entornos prosumer importan más el tiempo de arranque, la simplicidad y la latencia para un solo usuario
El gran gasto: adopción de la RTX 6000 Pro
- Para resolver tickets de soporte al cliente con rapidez, se compró una RTX 6000 Pro Blackwell con 96GB de VRAM por unos 12,000 USD
- Luego el precio subió a unos 15,400 USD, así que agregar una segunda tarjeta ya no fue factible
- Por carriles PCI, ancho de banda, separación entre tarjetas y carga de la PSU, no se puede simplemente añadir a una máquina de consumo
- Fue una apuesta calculada y dio resultados, pero no reemplaza una suscripción a Claude
Soporte al cliente sencillo sin fuga de datos
- Se creó una herramienta CLI llamada
diag, fácil de ejecutar por operadores, para capturar un snapshot completo de instalaciones de OpenFaaS en Kubernetes- El dump recibido se analiza dentro de una VM efímera y aislada con modelo local airgapped creada por Slicer
-
Recuperación de ingresos
- Al cargar la base de datos de telemetría en el modelo local, se detectó que un cliente llevaba más de 12 meses subdeclarando licencias y adeudando entre 4 y 5 veces más; solo con esa recuperación se cubrió el costo de la tarjeta
- Ni la telemetría ni los dumps de
diagse suben a ningún plan en la nube, sin importar las políticas de retención de datos - ChatGPT Pro y Claude Max permiten una retención de 30 días, pero incluso eso podría invalidar contratos con clientes
- Los primeros modelos fallaban en aritmética (27.3K lo calculaban como 273,000) y, por haber pocas funciones, ignoraban ejecuciones frecuentes y lo malinterpretaron como churn
- En la práctica, es mejor enfocarlos en análisis más que en interpretación
Setup actual
- En el rig con RTX 6000 se ejecutan juntos la generación más reciente de Qwopus y el Qwen 3.6 27B base, cambiando según nuevos finetunes y point releases
- Qwopus es un modelo finetuneado sobre Qwen que busca mejorar razonamiento y rendimiento de código añadiendo rastreo de Chain of Thought
- Hasta hace poco se operaba con thinking totalmente apagado, y cuando se volvió a encender coincidió con un aumento de los bucles
- Se sirve con dos instancias independientes de llama.cpp para mantener la longitud completa de contexto;
--parallel 2reduce el contexto a la mitad - En decodificación especulativa (MTP) se logra una tasa de aceptación de alrededor de 93%, y la velocidad sube de 67 tok/s estables a 130~200 tok/s, con una sensación de mayor rapidez que la nube
- Es importante seguir las guías de ajuste del model card; Qwopus rinde mejor con thinking apagado y temperature muy alta, entre 0.85 y 1.0
La limitación de la salida repetitiva y las tareas largas
- El mayor problema de Qwen es que cae en bucles en tareas de largo alcance
- Al preguntarle qué comando añadir a
faas-cli, al principio hizo sugerencias razonables, pero luego repitió la misma lista de comandos durante unos 30 minutos consumiendo 600W - Al pedirle agregar
--jsona toda la familia de comandosgetylist, los primeros uno o dos parecían razonables e incluso escribió tests, pero después la situación se deterioró - Cuando se le pidió usar un reverse proxy en Python para evitar la advertencia de TLS inseguro de endpoints remotos
http://en la salida de--json, la primera versión parecía razonable pero estaba mal indentada; al corregirla rompió el archivo y siguió repitiendo el problema - Un integrante del equipo, Han, también vivió bucles parecidos, sobre todo cuando el modelo o agente se quedaba justo en el límite de su capacidad y no pedía ayuda
- Por este problema, cuesta confiar en Qwen local para mucho más que soporte al cliente y análisis de telemetría y
diagpara renovaciones
Medición y distribución del acceso
- Al principio se usaba un único túnel de inlets, y si dos agentes se conectaban a la misma instancia de llama.cpp, los prefijos cacheados se invalidaban entre sí y había que reprocesar todo el prompt
- Cuando varias personas lo usan, deja de ser un prototipo y aparecen problemas de gestión: qué instancia usa cada quien, cuánto usa, qué modelo usa, cuánto cuesta la energía y qué hacer cuando alguien abandona una tarea
- En lugar de editar y desplegar manualmente
opencode.json, se creó el provider “Toilgate” para opencode, con selector de modelos desde la base hasta variantes experimentales de Qwopus- Toilgate está hecho 100% con vibe-coding y abrirlo como código fuente implicaría bastante carga
- El consumo eléctrico se mide en la pared con 2 Shelly Plus Plug, y la RTX 6000 Pro usa 600W en inferencia y es silenciosa, mientras que dos 3090 juntas consumen unos 750W y hacen mucho ruido
-
La comparación equivocada
- Comparar el costo de entrada/salida por millón de tokens con el precio de la API de GPT-5.5 es una comparación equivocada dada la capacidad actual
- “IA local” termina siendo, al final, un problema operativo que exige identidad, control de acceso, medición, cuotas, routing de modelos y monitoreo de energía
Patrones de uso que sí ayudaron en la práctica
- Es clave especializar el modelo local y el harness para tareas concretas
- soporte al cliente
- mantenimiento con alcance bien definido
- pruebas end-to-end
- Agregar instrucciones detalladas en
AGENTS.mdpermitió que el modelo local añadiera nuevos CLI más rápido y con más eficiencia, e incluso los probara por sí mismo- Esto se observó en alexellis/arkade
- Aunque el modelo local tiene límites para escribir código directamente, sí destaca leyendo y explicando un codebase con rapidez
- Agent Skills también ayudó, y hubo un caso donde un agente local configuró Slicer desde cero en una mini PC nueva
- Hace falta generalizar la práctica de correr la misma tarea tanto en un modelo local como en uno en la nube
- Como en este caso comparativo de la misma tarea, a veces el resultado decepciona y otras veces parece cuestión de suerte
- Hay que evitar tareas de agente no supervisadas de largo alcance; ni siquiera un equipo de casi 15,000 dólares resuelve ese problema
Conclusión actual y límites al elegir modelo
- Qwen local no está “cerca del nivel de Opus”, sino que es una herramienta distinta con valor en ciertas tareas y flujos de trabajo
- Qwen 3.5 es evaluado como el primer modelo que dio resultados realmente utilizables, y aunque hay rumores de 3.7, se espera mejora iterativa más que un cambio revolucionario
- La mayoría de los modelos 70B se consideran viejos y de una generación rezagada
- Qwen 35-A3B es popular porque parece rápido en MacBook, pero como solo activa 3B parámetros al generar, aquí se prefiere calidad antes que velocidad
- Modelos más grandes como GLM 5.2, Kimi 2.7, Minimax M3 y Deepseek V4 Flash podrían correr en cierto hardware local, pero incluso las versiones cuantizadas suelen requerir entre 4 y 6 RTX 6000 Pro para cargarse, así que quedan fuera de alcance
- Hoy, un modelo denso de 27B todavía no alcanza para escribir código Go todo el día, y sus límites de conocimiento y atención se hacen evidentes de inmediato en revisión de código
- Qwen no sigue bien la instrucción de ser conciso y en revisiones automáticas de código tiende a escribir de más o a alucinar problemas de concurrencia y race conditions, por lo que los experimentos se frenan rápido
- Grok Coder Fast 1, más barato y veloz, funcionó bien durante algunos meses antes de quedar deprecated
- Casos relacionados están documentados en code review bot y painless customer support and architecture review de OpenFaaS
1 comentarios
Opiniones en Hacker News
Después de usar estos modelos durante mucho tiempo, te das cuenta de que no es algo tan simple como “X es más inteligente que Y” o “Y es más barato que Z”. Son herramientas distintas y la forma de hacer prompting también cambia, así que se parece bastante a tocar un instrumento
A veces, con Claude conviene ser deliberadamente menos explícito o expresarlo de forma indirecta para darle más color a la implementación o sacar resultados creativos. Y, aunque suene raro, si eres amable con Claude te va mejor, y si lo tratas de forma brusca sales perdiendo. Claude tiende a seguir el tono con más fuerza, así que es mejor no caer en un bucle negativo
Con GPT hay que ser preciso y reducir la ambigüedad. GPT intenta resolver la ambigüedad con algo tipo minimax de “haré X pero no Y”, y si no le dices claramente el alcance, tiende a intentar cubrir todos los casos límite y a sobre diseñar
Con Qwen hay que darle una estructura y hacer que la rellene. A Qwen le gustan XML, JSON y las listas, y funciona bien si le muestras muchos ejemplos de trabajos anteriores. No es nada científico, solo una impresión, así que los resultados pueden variar
Pero por fuera todos se ven parecidos, y para averiguar cuál rinde un poco mejor y en qué contexto, uno mismo tiene que hacer pruebas amplias, que consumen mucho tiempo y quizá también bastante dinero
Se lo recomiendo a todo el mundo: no necesitas datos especiales aparte de los que ya usas, y los resultados son bastante impactantes. Hay mucha más aleatoriedad o inestabilidad de la que uno imagina, y cosas que atribuías a una mejor técnica de prompting o a resultados especialmente buenos o malos podrían ser simple casualidad o diferencias de comportamiento entre versiones y tamaños del modelo. Pequeñas diferencias en la entrada pueden sesgar mucho el resultado. En la empresa a algunas de estas cosas les llamamos palabras mágicas: con solo mencionar cierto término técnico o cierta referencia o técnica, el resultado mejora muchísimo
Ahí hay técnica. En un bucle de agente, si el modelo entra en una estructura de autoevaluación donde le cuesta más hacer trampa o tomar atajos, y además coincide con una estructura o dominio que ya aprendió, puede funcionar increíblemente bien. Pero encontrar ese punto óptimo es difícil. Como consejo: si le pides a Opus 4.8 que convierta un modelo de PyTorch a ONNX o a un modelo cuantizado, o que lo haga correr en otro hardware, de verdad rinde como si le hubieras activado una habilidad especial. En cambio, no he logrado que redacte y pruebe correctamente, sin hacer trampa, una formalización en EBNF de un lenguaje o formato general
Lo peor es que este conocimiento cambia demasiado seguido, así que, a menos que seas una de las personas que realmente entrenan el modelo, casi no vale la pena profundizar tanto. Ojalá en el entrenamiento se priorizara más la estabilidad de la salida para que fuera más predecible. Sé que es difícil hacerlo sin caer en sobreajuste o romper los bucles de exploración-explotación, pero si pudiera hacer tareas por lotes de forma más estable, probablemente gastaría mucho más dinero en LLM
Le hice la misma petición a Claude Sonnet 4.6, y el resultado parecía como si ese juego originalmente hubiera sido escrito en JS. Además, no sé por qué, lo convirtió en un solo archivo HTML, eliminó todos los assets, generó los gráficos y la música de forma dinámica, e incluso creó un fondo nuevo y mejor
Yo solo había pedido portar el juego, así que me sorprendió. En realidad me gustaron bastante las decisiones, pero no sé cómo activar o desactivar ese comportamiento. A veces quieres creatividad, y otras veces quieres que haga exactamente lo que pediste
Al ver este artículo y todos los elogios, me da la impresión de que es el traje nuevo del emperador. Ya desde esta frase deja de tener sentido
“These products use very low level Linux primitives like containers, Kubernetes, Firecracker microVMs, and networked protocols.”
De todo eso, lo único que con mucho esfuerzo podría pasar por “primitivas de bajo nivel de Linux” serían los protocolos de red. Y además parece claramente un texto generado por IA. Si al menos el contenido fuera confiable, no importaría, pero no lo es
El texto no fue generado por IA; genero el código con IA, pero el texto lo escribo yo. Me da curiosidad saber qué parte no se entiende. Este artículo describe nuestra propia experiencia y nuestro recorrido, y con gusto puedo aportar fundamentos sobre afirmaciones concretas
Sigo creyendo que la fortaleza de la IA no está en ser otro servicio en la nube al que hay que pagarle para siempre y que con el tiempo empeora para satisfacer la codicia de los accionistas corporativos, sino en aplicarse de forma segura y privada en local
Nunca voy a dejar que ChatGPT o Anthropic aten mis datos de salud a sus sistemas, pero sigo confiando en la capacidad de la IA para encontrar patrones en datos que yo pasaría por alto. Por eso es urgentemente necesario un ecosistema solo local donde datos como esos puedan exponerse y procesarse de forma segura y privada con cosas como Qwen o Gemma
Lo mismo pasa con el hogar inteligente y los asistentes personales. Este enfoque corporativo, donde la empresa A accede a datos guardados por la empresa B, las empresas D y E los procesan y luego se venden a anunciantes y brokers de datos, sin que yo tenga forma de extraerlos o verlos en mi hardware local, no es sostenible para usos tan privados. Mis datos deberían pertenecerme, controlarse y exponerse bajo mis condiciones, y usarse primero para mejorar mi vida, no para mejorar el estado de resultados de alguien más. Quiero que la tecnología vuelva a darme tiempo y mejore los resultados, y como ya me quemé bastante con Big Tech, rechazo tajantemente la idea de que el modelo de negocio de IA-como-servicio tenga alguna nobleza o valor para el bien público
La capacidad ya existe, y creo que la gente que está construyendo herramientas locales para apoyar y liberar el potencial de los modelos locales va en la dirección correcta. Me gusta ver lo que están creando
Si usas modelos como Qwen o DeepSeek, puedes moverte entre proveedores independientes sin quedar atado a una sola empresa, y quizá con mejores garantías de privacidad. Eso permite usar el modelo incluso en dispositivos que no pueden ejecutarlo por sí mismos, siempre que tengan conexión a internet
La fortaleza de la IA está en los modelos open source. Hay que usar modelos que eviten el bloqueo con un proveedor y permitan tanto el uso local como el hosting por proveedores independientes
Buen texto. Pero creo que subestima la posibilidad de mejora
Los propios autores reconocen que no tiene mucho sentido comparar los modelos locales de hace un año con los de ahora. De hecho, mucha gente ve noviembre del año pasado, cuando salió Opus 4.5 —hace 8 meses—, como el primer momento en que el agentic coding se volvió ampliamente viable incluso en modelos frontier alojados
Entonces, ¿por qué fijar ahora una idea rígida de lo que los modelos locales hacen bien o mal? Sea lo que sea hoy, probablemente será distinto dentro de un año. Puede ser un optimismo ingenuo pensar que llegarán a manejar tareas de largo alcance en hardware de consumo y profesional, pero hasta ahora los optimistas ingenuos son los que vienen ganando
Es parecido a comprarse un auto. Lo manejas y te acostumbras a sus características; no estás pensando en cómo ese auto o autos parecidos van a mejorar en el futuro. Es mi herramienta, y quiero sacarle el máximo provecho
Claro, el costo técnico de cambiar de modelo local es muy bajo, pero lleva bastante tiempo exprimir el máximo rendimiento de ese modelo, y ese esfuerzo quizá no sirva con la versión siguiente
Texto interesante. Personalmente me habría gustado que el autor hiciera mejor dos cosas
Primero, debería haber usado vLLM en vez de llama.cpp. En hardware de NVIDIA, la diferencia de vLLM para carga de varios usuarios y caché es enorme. Cuando se quejaba de usar el modelo con más de un usuario o de que desapareciera la caché, mi reacción fue “pues claro”
Segundo, el presupuesto que gastó en una sola tarjeta se habría aprovechado mucho mejor en SPARK. Podría haber usado un clúster de 2 x GX10, con un costo total que incluso hoy es menos de la mitad de lo que pagó el autor, y corriendo vLLM con Deepseek v4 Flash. Comparado con Qwen, la diferencia es enorme. No lo he visto entrar en bucles ni una sola vez, y es el modelo más parecido a Sonnet de todo lo que he probado hasta ahora. antirez parece estar de acuerdo, por eso al parecer hizo el fork ds4
Aquí está cómo lo configuraron en 2 GX10: https://forums.developer.nvidia.com/t/deepseek-v4-flash-offi...
El rendimiento es de 2K tokens/seg en prefilling, así que es muy útil para meter grandes cantidades de código fuente en ventanas de contexto enormes, y al codificar con el harness de pi.dev genera unos 50–60 tokens/seg. Con lo que pagó el autor, podría haber comprado 4 GX10, y como vLLM escala casi linealmente en paralelismo tensorial, ambas cifras podrían haberse duplicado
Puede que más adelante vuelva a probarlo más, pero no tengo tiempo infinito para estar ajustando cosas, y solo compartí el camino y los criterios que he seguido hasta ahora
Para serving concurrente en lotes, vLLM sí es la elección correcta, y lo que dice barrkel abajo es exacto. Pero para nuestra forma de uso, llama.cpp sigue siendo mejor
La ruta Spark/GX10 sí es realmente otra apuesta, y gracias por compartir los números. Hace apenas unos meses, el ambiente general era que GX10 era solo para fine-tuning y que sus cifras de rendimiento eran seriamente bajas
Y además, esa tarjeta no se compró en absoluto para reemplazar una suscripción a Claude Max. En las tareas para las que de hecho la compré, estoy obteniendo 140–200 tokens/seg, y eso es lo importante
El texto era largo, pero sigo sin saber cuál era exactamente el punto central que el autor quería transmitir. Más allá de lo que se puede inferir por el título
Eso sí, me quedó claro que el autor es una persona bastante genial que construye cosas físicas y también software, y que otras personas hasta le dan dinero. No sé si eso tiene relación con el tema que insinuaba el título
Este texto resume bien los modelos locales. A diferencia de cuando a veces se exageran como si fueran herramientas fantásticas para coding y trabajo local con agentes, en la práctica son bastante limitados, débiles para tareas largas o complejas, y tienden a caer en bucles o a olvidar la tarea
Algo que el texto no menciona es que también cuestan bastante. No solo está el costo del hardware, sino también la electricidad. Una máquina con 3090 o 5090 consume mucha energía, y como los modelos en estas máquinas son bastante lentos, el consumo eléctrico por token también aumenta
Donde brillan es en la capacidad de control, la privacidad y la previsibilidad. Por ejemplo, son buenos para tareas repetitivas como clasificar bibliotecas de fotos y videos, y según la tarifa eléctrica, también podrían tener ventajas en costos
Las llamadas a herramientas deberían ser confiables en un 99% y, sobre todo, debería poder decir “esta tarea está fuera de mis capacidades” y entonces derivarla a un modelo online de alto rendimiento en algún enorme centro de datos
Así, todas las tareas simples se procesarían en el dispositivo mientras se recopilan datos y se entiende el contexto del problema, y una vez terminadas las partes fáciles, entraría un modelo más inteligente a resolverlo
Se siente realmente absurdo que una habilidad como
/commit, que un modelo local puede hacer al 100%, termine invocando un modelo online. Aunque esto en su mayor parte es un problema del harness, así que se puede resolver bastanteLo hace muy bien, y para tareas de coding también funciona excelente si sabes cómo usarlo en vez de lanzarle planes grandilocuentes de una sola vez
Eso da alrededor de 8.75 J/token tomando como referencia el máximo
No sé cómo se compara con otras cosas, pero supongo que una 5090 sería un poco más barata porque sería más rápida con el mismo límite de energía
Me pareció interesante que se descartara a vLLM como más lento que llama.cpp
En mi experiencia, vLLM es bastante más rápido que llama.cpp y, en especial, lo supera de forma aplastante en procesamiento por lotes con carga concurrente. La desventaja es que la flexibilidad de ajuste baja de forma dramática. Hay muy pocas opciones para ejecutar pesos cuantizados, y el tiempo de arranque es mucho mayor porque optimiza el grafo de cómputo. Por eso, si un solo usuario está experimentando con un modelo un poco grande para su equipo, vLLM puede sentirse frustrante
“Descartado” es una palabra fuerte, pero dicho con más detalle: en un equipo con 2x 3090 tardó más de 4 minutos en cargar, y en una solicitud individual fue 3 tokens/seg más lento
Lo peor es que, incluso después de todo el esfuerzo de configurarlo y tunearlo, seguía cayendo en bucles. Esperaba que ese consejo que se escucha por todas partes de “solo usa vLLM” fuera una solución universal
Algo con lo que hay que tener cuidado aquí es no empezar a menospreciar llama.cpp como la gente hizo con Ollama. llama.cpp es una herramienta muy competente y encaja mejor para el uso que realmente queremos darles a esas tarjetas
Si un equipo grande quisiera reemplazar suscripciones a Claude, quizá vLLM sea la única opción, pero para levantar algo como GLM 5.2 habría que agregar unas 5 tarjetas RTX 6000 más
Dice que “el modelo corre demasiado caliente, se pasa del objetivo y entra en bucle”, pero más adelante comenta que puso vLLM como experimento reciente y que, incluso con NVLink y paralelismo de tensores, generaba 3 tokens/seg más lento que llama.cpp
En todas mis pruebas, valió la pena correr vLLM. Fue el factor individual que más ayudó con el problema de los bucles, con que los agentes se vuelvan raros, con que pierdan foco en la tarea y con que los contextos largos se vuelvan prácticamente inútiles
En vLLM, usar modelos FP8 y caché no cuantizado mejora la experiencia general un nivel completo frente a cualquier otro stack. Después de eso, puedes dejar de estar manoseando configuraciones y concentrarte en usar el modelo para otras cosas
Y también me pregunto si sientes que hay requisitos mínimos de hardware para que vLLM sea útil de esta manera. Estoy por armar un servidor casero de inferencia como proyecto de fin de semana usando piezas viejas de datacenter, y sigo refinando en mi cabeza la configuración final
A quienes quieran comprar y armar su propio equipo de IA, les recomendaría primero conectarse a alguno de los varios proveedores de inferencia y probar distintos modelos por un tiempo
Casi no cuesta nada, pero da un adelanto bastante bueno de lo que se puede obtener con tu propio equipo. Solo es un consejo amable