Guía de Jamesob para ejecutar LLM de última generación en local

 (github.com/jamesob)
2 puntos por GN⁺ 5 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Reúne en un solo repositorio la configuración de hardware, la configuración del switch PCIe y la configuración de ejecución con Docker para correr en local LLM de última generación y conversión de voz a texto
  • El presupuesto de aproximadamente US$2k apunta a una configuración con 2× RTX 3090 para obtener 48GB de VRAM y ejecutar Qwen3.6-27B y STT local basado en whisper-large-v3
  • El presupuesto de aproximadamente US$40k parte de una configuración con 4× RTX PRO 6000 Blackwell Workstation para obtener 384GB de VRAM y lograr una inteligencia de modelo bastante cercana a Claude Opus
  • El sistema real con 4× RTX 6000 Pro combina una máquina base EPYC/DDR4 usada con un switch PCIe Gen4 c-payne, de modo que la comunicación P2P entre GPUs se maneje dentro del fabric del switch en vez del complejo raíz de la CPU
  • Tras ajustar BIOS, GRUB, ACS y límites de potencia, el P2P alcanza velocidades de línea Gen4: 27.5GB/s unidireccional, 50.4GB/s bidireccional y 0.37–0.45µs de latencia

Rangos de presupuesto para ejecutar LLM en local

  • Esta configuración está dirigida a usuarios que quieren ejecutar en local modelos de última generación y conversión de voz a texto
  • El repositorio incluye el hardware en uso, las razones de compra, tips de configuración, la forma de ejecutar STT local y configuraciones de ejecución de modelos basadas en contenedores Docker
  • Hay una nota que indica que el contenido del README, excepto la tabla, no fue escrito por IA

  • Configuración de aproximadamente US$2k

    • Propone una configuración con 2× RTX 3090 para obtener un total de 48GB de VRAM
    • En esta configuración se puede ejecutar Qwen3.6-27B
    • El STT local usa whisper-large-v3, con el harness multiplataforma stt para accederlo
    • ./runners/stt incluye una configuración de STT lista para ejecutar que asume una GPU Nvidia con solo unos 11GB de VRAM
    • El STT local se presenta como una herramienta que puede usarse con más comodidad que los servicios alojados

  • Configuración de aproximadamente US$40k

    • Parte de una configuración con 4× RTX 6000 Pro para obtener un total de 384GB de VRAM
    • En este rango de precio se describe como el paso en el que se obtiene una inteligencia de modelo bastante cercana a Claude Opus
    • A julio de 2026, se presenta GLM-5.2-Int8Mix-NVFP4-REAP-594B como el mejor modelo actual para 4× RTX6kPRO
    • La configuración de ejecución está en runners/GLM-5.2-594B
    • Como otro enfoque, también se menciona conectar un clúster de 4× DGX Spark para obtener 512GB de VRAM y hacer que Qwen3.7-27B maneje rápido las tareas repetitivas como un cerebro grande pero lento

Hardware real con 4× RTX 6000 Pro

  • El sistema real está construido alrededor de 4× RTX PRO 6000 Blackwell Workstation
  • Cada GPU tiene 96GB, para un total de 384GB de VRAM, y el precio es de aproximadamente US$46,000
  • La máquina base aprovecha componentes EPYC de generación anterior y DDR4 de eBay para reducir el costo del sistema base y concentrar el gasto en VRAM
  • A julio de 2026, como los sistemas basados en PCIe5/DDR5 son muy caros, se eligió un switch PCIe Gen4 y una máquina base con DDR4

  • BOM del sistema base

    • El sistema base está compuesto en su mayoría por piezas EPYC de generación anterior compradas en eBay
    • Los componentes principales y sus precios son los siguientes
    • Motherboard ASRock Rack ROMED8-2T: US$715
    • CPU AMD EPYC Milan 7313P de 16 núcleos a 3.0GHz: US$504
    • 8× 16GB Crucial DDR4 ECC RDIMM, 128GB de RAM en total: US$642
    • 2× PSU Super Flower de 1700W: US$750
    • Switch PCIe c-payne Microchip Switchtec PM40100 Gen4: aproximadamente US$1,330
    • NVMe de arranque de 4TB: US$291
    • 2× NVMe de 8TB para pesos de modelos: US$1,200
    • El total del sistema base es US$5,587

  • Switch PCIe Gen4

    • Usa el switch PCIe4 de c-payne para manejar la comunicación entre GPUs casi de forma directa
    • En la etapa allreduce del paralelismo tensorial, los datos entre GPUs se mueven dentro del fabric del switch sin pasar por el complejo raíz PCI
    • El sub-BOM del switch cuesta unos €1,220, aproximadamente US$1,330
    • Switch PCIe Gen4 5× x16 basado en Microchip Switchtec PM40100
    • SlimSAS PCIe Gen4 Host Adapter x16
    • 2 cables SlimSAS SFF-8654 8i
    • Se fabricó a mano un gabinete de madera para las GPUs y el switch PCI, lo que tomó alrededor de un día
    • El ventilador integrado del switch PCI es muy ruidoso y parecía inútil, así que fue separado de la placa

Almacenamiento de pesos de modelos y forma de ejecución

  • Todos los pesos de modelos se almacenan localmente en un sistema de archivos ZFS replicado en dos unidades de 8TB
  • El sistema de archivos se monta en ~/storage
  • El modelo que se va a ejecutar primero se descarga en local con el siguiente comando
hf download <model-name> --local-dir ~/storage/<model-name>
  • Cada modelo tiene un docker-compose.yml en un directorio separado y se ejecuta dentro de su propio contenedor Docker
  • Las configuraciones de ejecución están en ./runners/
  • Cada contenedor monta ~/storage/models como solo lectura para leer los pesos cacheados
  • Cuando el modelo se sirve en http://clank.j.co:5000, se accede a él mediante opencode, alojado en una VM de otra máquina
  • Un servidor DNS interno mapea clank.j.co a la máquina de LLM, aunque también puede usarse el formato http://<llm-machine-ip>:5000

Harness de agentes y configuración de herramientas

  • En una VM separada se usa una aplicación que crea una sesión tmux por cada directorio del árbol ~/src y ejecuta una instancia de opencode en cada sesión
  • Cada instancia de opencode usa como backend la API HTTP de la máquina de inferencia, http://clank.j.co:5000
  • La clave para usar bien modelos open source se trata como la configuración de herramientas
  • El resumen de skills/ incluye las siguientes herramientas
    • Navegación web y búsqueda mediante camofox, una clave de API de kagi.com y searXNG
    • Comunicación y alertas mediante un bot de Telegram
    • Una instancia local privada de Gitea para colaboración en código fuente
  • Se puede trabajar con los agentes de forma interactiva en la sesión, o encargarles issues de Gitea y que suban PRs
  • Este trabajo se ejecuta dentro de una VM sandbox, y la comunicación con el host se realiza únicamente mediante un montaje de sistema de archivos compartido

Switch PCIe y configuración multi-GPU

  • Configuración de BIOS

    • En la motherboard ROMED8-2T se ajusta la BIOS para evitar que baje la velocidad del switch PCI
    • AMD PCIE Link Width se configura en x16 para el slot del switch
    • La configuración previa de bifurcación x8/x8 divide el slot y hace que el enlace upstream entrene como Gen4 x8
    • Deben estar conectados ambos cables SlimSAS 8i, y cada cable se encarga de x8
    • PCIe Link Speed se fuerza a Gen4
    • Cuando un dispositivo Blackwell Gen5 negocia automáticamente a través de un switch Gen4, el entrenamiento puede fallar y caer a Gen1
    • ASPM se configura como Disabled
    • ASPM L1 reduce los enlaces inactivos a 2.5GT/s
    • Esa era la causa de que en lspci pareciera degradado a Gen1, pero bajo carga funciona como Gen4
    • Re-Size BAR se configura como Enabled
    • Es necesario para exponer todo el BAR de 96GB de VRAM y para P2P entre GPUs
    • SR-IOV se configura como Disabled
    • Es una configuración para evitar sobrecarga de IOMMU e interferencias con P2P en un entorno de inferencia bare metal
    • Preferred IO se deja en Auto
    • Especificar manualmente el bus 81 del switch c-payne podría dar una leve mejora de latencia, pero es una optimización, no una corrección, y el número de bus puede cambiar después de modificaciones en la BIOS

  • Redriver y cables

    • Siguiendo el consejo de c-payne, se bajó el redriver gain a lvl 3 con la herramienta de c-payne
    • El nivel de gain depende de la longitud de los cables con conectores SAS
    • Se pidieron muy pocos cables a c-payne y se compraron en Amazon cables SAS que parecían similares, pero pequeñas diferencias causaron problemas, así que se volvieron a pedir

Kernel, ACS y límites de potencia

  • GRUB y NVIDIA UVM

    • En /etc/default/grub se configuran los siguientes parámetros del kernel
    GRUB_CMDLINE_LINUX="iommu=off amd_iommu=off nomodeset"
sudo update-grub
    • Sin iommu=off, NCCL se queda colgado en P2P multi-GPU
    • Para la corrección de NVIDIA UVM P2P, se aplica la siguiente configuración
    echo 'options nvidia_uvm uvm_disable_hmm=1' | sudo tee /etc/modprobe.d/uvm.conf
sudo update-initramfs -u

  • Desactivación de ACS

    • Si ACS está activado por defecto, el tráfico P2P no permanece dentro del fabric del switch y pasa por el puerto raíz de la CPU
    • En ese estado, se pierde el efecto del switch PCIe
    • Como pcie_acs_override requiere un kernel parcheado, ACS se desactiva en runtime con setpci
    • En cada arranque se ejecuta /usr/local/bin/disable-acs.sh mediante un servicio systemd oneshot
    • La forma de verificarlo es la siguiente
    • En lspci -vvv | grep ACSCtl, todo debe aparecer con signo menos
    • En nvidia-smi topo -m, las cuatro GPUs deben verse como PIX entre sí, no como PHB/NODE
    • Con ./tools/measure-gpu-speed.sh se puede medir fácilmente el ancho de banda y la latencia P2P

  • Límite de potencia de GPU

    • Para evitar instalar un circuito de 220V, se ejecuta en un solo circuito de 110V, pero limitando la potencia de las GPUs
    • Con systemd, se aplica al arrancar el persistence mode y el límite de potencia
    sudo nvidia-smi -pm 1
sudo nvidia-smi -pl 350
    • El límite de potencia de las GPUs es de 350W por GPU, mientras que el valor predeterminado es 600W
    • 4×350W equivale a 1,400W de carga de GPU, un valor ajustado al presupuesto de las PSU
    • En la etapa con una sola PSU de 1700W antes del circuito de 240V, las GPUs se operan alrededor de 260W
    • 4×260W = 1,040W de GPU
    • Sumando unos 280W del sistema, el total es de aproximadamente 1,320W
    • La verificación se hace con nvidia-smi --query-gpu=index,power.limit,power.draw --format=csv

Resultados de medición y recursos

  • El upstream hacia la CPU es Gen4 x16 y ronda los 30GB/s
  • El P2P a través del switch es de 27.5GB/s unidireccional y 50.4GB/s bidireccional
  • La latencia es de 0.37–0.45µs, a nivel de velocidad de línea Gen4
  • Si ASPM está activado en algún punto, lspci puede mostrar los enlaces downstream de GPU inactivos como 2.5GT/s (downgraded)
  • Esa indicación es cosmética, y el enlace vuelve a entrenar como Gen4 cuando recibe carga

  • Resources

    • local-inference-lab/rtx6kpro: repositorio que se actualiza con frecuencia sobre el uso de 4, 6 y 8 tarjetas RTX 6000 Pro
    • c-payne: switch PCI indie usado en esta configuración
    • RTX6kPRO Discord: servidor de Discord sobre benchmarks de RTX6kPRO y pruebas de modelos nuevos

Lecturas relacionadas

1 comentarios

 
GN⁺ 5 시간 전
Opiniones de Hacker News

  • He usado muchos LLM locales y gasté de más en hardware, pero hay que bajar las expectativas y leer bien las condiciones específicas.
    La build grande del artículo empieza con un presupuesto de 40.000 dólares, pero incluye 4 GPU de 12.000 dólares cada una, así que en realidad se acerca más a 50.000~55.000 dólares.
    Las configuraciones locales suelen depender de técnicas como cuantización o REAP para ajustar el modelo al hardware. Hay muchas afirmaciones de que la cuantización a 4 bits es sin pérdida, pero eso viene de mediciones de divergencia KL en corpus pequeños; si se usa para tareas de programación con contexto largo, la caída de calidad es clara. Incluso en tareas que no son de programación, como análisis de datasets, se pueden medir diferencias de calidad bastante notables entre cuantización a 4 bits, 8 bits y, a veces, el original de 16 bits.
    El artículo también recomienda usar modelos REAP, lo que significa que alguien recortó algunos pesos para hacer el modelo más pequeño. La idea es eliminar pesos menos útiles para ciertas tareas, pero la calidad general de salida vuelve a bajar.
    La trampa es que, cuando la gente dice “corro GLM-5.2 localmente”, uno mira los benchmarks y suena impresionante, pero en realidad no está corriendo GLM-5.2, sino un modelo derivado al que se le descartó la mayoría de los bits y se le quitaron algunos expertos. En tareas muy pequeñas o en chat, la diferencia entre modelos cuantizados/REAP y el original casi no se nota, pero en trabajos largos donde los errores pequeños se acumulan, la diferencia se vuelve dolorosa.
    Y entonces, como ya gastaste 50.000 dólares, caes en la pendiente resbaladiza de “si compro una o dos GPU más de 12.000 dólares, subo un poco más la calidad y hago que la inversión valga la pena”.

    • Corro Qwen3.6 en una RTX4090 y en la mayoría de los casos funciona muy bien.
      Para tareas de programación hay que dividir la sesión en varias llamadas. Hice https://github.com/aka-rider/orqestra, pero con los entornos actuales de ejecución de herramientas se puede hacer algo similar por cuenta propia casi en cualquier lado.
      La clave es tener una sesión separada que consuma contexto leyendo código y llamando herramientas, y que produzca un reporte en Markdown del tipo “el código y la documentación relevantes están aquí, y esta es la evidencia”, para reducir las alucinaciones. La sesión de planificación va aparte; como el modelo pequeño se salta detalles, hago 1~3 idas y vueltas entre crítico y diseñador, y por la misma razón también entre ejecutor y verificador.
      Qwen3.6 puede pasar horas buscando bugs complejos en modo solo lectura y, por lo general, los encuentra. La corrección que propone probablemente sea medio hacky, pero con Sonnet pasa lo mismo.
      Qwen3.6 puede escribir código mecánicamente siguiendo un plan creado por Opus. Después hay que pedirle cosas como: “revisa tú mismo tus cambios. ¿Hay bugs? Cruza con el plan original: ¿falta algo? ¿Hay alguna violación de CLAUDE.md?”. Pero esto también hay que hacerlo exactamente igual con Sonnet.
      También uso LLM locales para reindexar bases de conocimiento. Para ordenar tickets, incluso si dejo solo notas crudas como “panel único para renderizar errores, mover todos los mensajes de error”, puede devolver una especificación completada en un 90%, con objetivo y contexto.
    • Me pasó algo parecido al correr localmente un Qwen de 26B, no MoE, cuantizado a 8 bits, en mi computadora.
      Para tareas pequeñas es realmente bueno, pero cuando le pedí la primera tarea grande, se olvidó de cuál era el entorno de ejecución del agente y empezó a usar mal el formato de llamadas a herramientas. Estaba corriendo en una Pi, pero creía que estaba corriendo en Claude y trató de invocar herramientas de Claude inexistentes.
    • Corro ds4 en una MBP que compré antes de que el precio de la RAM se volviera una locura, y es bastante útil.
      No escribe aplicaciones completas por sí solo, pero me resolvió un problema molesto de red en mi tailnet que no tenía ni tiempo ni ganas de investigar, y a menudo me animo a hacer tareas simples que no hacía porque el costo de investigación era alto. No es Opus, pero sirve, y no tengo que preocuparme por si estoy sacándole valor a una suscripción o al costo de una API.
    • Ojalá los artículos y comentarios sobre “ejecutar localmente” también incluyeran, para comparar, resultados de volver a correr los mismos benchmarks públicos.
    • Totalmente cierto. La fiebre por correr LLM de programación localmente terminó perjudicando a la IA local donde los modelos de lenguaje pequeños hechos para un propósito específico sí podrían ser realmente útiles.
      Herramientas pequeñas para procesamiento de lenguaje natural, síntesis de voz, procesamiento de imágenes, ingeniería de audio, procesamiento de señales o plugins de difusión para Krita son muy buenas para configuraciones locales. Hace unos días escribí algo breve al respecto[1].
      [1] https://abishekmuthian.com/multiple-20-ai-plans-are-better-t...

  • Decir que “por unos 40.000 dólares la inteligencia del modelo sube un nivel y queda bastante cerca de Claude Opus” equivale al costo de usar Claude Opus 4.8 o Codex GPT 5.5 durante 16,8 años a 200 dólares al mes.
    Me encanta ejecutar modelos locales, pero sigue siendo absurdamente caro, la calidad es menor y, si hubiera una puerta trasera, también podría ser peligroso. De verdad quisiera que no fuera así.

    • Si hay que pagar el precio completo de la API, por ejemplo en una empresa “enterprise”, esos 200 dólares al mes ya se acercan más a 4.000 dólares mensuales. Entonces el costo equivalente baja a 10 meses.
      Aun así, dudo que el equipo local pueda procesar realmente un volumen equivalente a 4.000 dólares mensuales de uso de API. Es difícil que un equipo local ejecute prompts en paralelo con tanta eficiencia como los múltiples centros de datos de Anthropic.
    • Estoy de acuerdo con el punto central, pero este cálculo asume que los precios de los LLM seguirán constantes.
      Empresas como OpenAI y Anthropic todavía venden planes con precios subsidiados por capital de riesgo, y ese capital algún día querrá retorno.
    • No tiene sentido decir que los modelos líderes tienen puertas traseras. Nunca he oído de un modelo con puerta trasera, y si se descubriera uno, Hugging Face lo retiraría rápidamente. Esto no es un problema.
    • Con hardware se pueden usar muchos más tokens que con el plan de 200 dólares al mes.
      En el primer mes con OEM spark usé 1.000 millones de tokens, que con Opus serían más de 1.000 dólares. No es una comparación justa porque los patrones de tokens son distintos, pero después de eso las mejoras de vLLM, principalmente gracias a MTP, también aumentaron la velocidad entre 2 y 3 veces. DiffusionGemma es unas 4 veces más rápido que Gemma normal.
    • No intentes correrlo en local: alquila GPU en la nube.
      Tampoco eres dueño de una línea de fibra óptica; entonces, ¿por qué querrías poseer otro activo caro, molesto y que se deprecia rápido?
      Alquilar GPU en la nube te permite participar en la cultura de propiedad, control de datos, control de precios y hacking sin tener que armar una enorme caja Frankenstein de hobby. Esa caja es cara, se destila hasta volverse mucho menos útil en la práctica y además es un dolor de cabeza de mantener.

  • Dicen “por 40.000 dólares es casi Opus”, pero si GLM 5.2 es “casi Opus”, para una inferencia cómoda se necesitan al menos 8xH200, así que está más cerca de 400.000 dólares que de 40.000.
    El artículo sugiere usar un modelo modificado: “GLM-5.2 podado con REAP, con cerca del 22% de los expertos eliminados, cuantizado con Int8-mix NVFP4, unos 594B parámetros”.
    Me pregunto cómo funcionará realmente fuera de los benchmarks. Qwen3.6 ya cae seguido en bucles durante la inferencia con cuantización de 6 bits, y aquí además eliminaron parte de los expertos. A veces un modelo más pequeño en 8 o 16 bits puede ser más inteligente que un modelo grande lobotomizado. Parece haber cierto consenso en que para programar conviene no bajar de 8 bits.
    Tampoco queda claro cuánto contexto utilizable queda al meter el modelo lobotomizado en 4 RTX 6000. Con menos de 100k suele ser casi inutilizable, porque se topa con la compresión antes de reunir el contexto necesario. Revisé en el repositorio y el contexto era de 240k.

    • Me pregunto qué pasa si se ejecuta GLM 5.2 solo con una H200.
      Quisiera saber si directamente no corre o si es tan lento que resulta inutilizable. Me gustaría validar en local la compilación y el concepto de un modelo de última generación, y luego completar el resto cuando los precios de las GPU bajen mucho en 18 a 24 meses.
    • Me pregunto cómo encaja esto con la escalabilidad.
      ¿Significa que se podrían correr cientos de prompts al mismo tiempo?
    • Los bucles, como la mayoría de los fenómenos relacionados con LLM, son un problema de sampling, y se pueden resolver fácilmente con una penalización DRY.
      Está incluida en llamacpp. La misma persona que hizo heretic también creó estrategias de prevención de bucles y diversificación de nivel reciente.
    • En 8x RTX6000, usando la cuantización NVFP4 de lukealonso, también es posible un contexto de 1M, y al menos hasta 400k se mantienen la coherencia y la utilidad.
      No hay una necesidad práctica real de usar 8x H200, salvo que quieras hacerlo porque sí. La excepción sería si necesitas atender regularmente a muchos usuarios o agentes concurrentes.

  • También hay opciones intermedias. Si consigues 128GB de VRAM, ahora hay varias alternativas que permiten obtener esa capacidad mediante una arquitectura de memoria unificada, y con DwarfStar se puede correr DeepSeek V4 flash a buena velocidad.
    Yo no gastaría el dinero, pero para mucha gente creo que ese sería un punto medio razonable.

    • Recién empecé a probarlo en una m4 max 128, y por primera vez desde que compré esta máquina hace un año siento que un LLM local simplemente funciona para programar bastante bien.
      Eso sí, hay que usar Pi. claude code trae demasiado contexto de bootstrap, así que todo se vuelve mucho más lento.

  • Dicen que “con 2 RTX 3090, para un total de 48 GB de VRAM, se puede correr Qwen3.6-27B, y es un modelo excelente”, pero con 3.000 dólares puedes comprar una M5 MacBook Pro con 48 GB de memoria unificada, y tampoco es una caja enorme.
    O también vale la pena considerar gastar ese dinero en un proveedor de hosting en la nube. Al menos hasta cierto punto, quizá podría ser mucho más barato. Claro, poder correr el modelo en local es genial.

    • Como soy un tonto que no podía imaginar situaciones que no había vivido, siempre pensé que los LLM locales eran juguetes que no valía la pena perseguir.
      Pero recién después de probar algo decente como Gemma 4 31B y Qwen 3.6 27B me di cuenta de lo útiles que son.
      Dejas de preocuparte por estar compartiendo información sensible, dejas de preocuparte por quedarte sin tokens y dejas de preocuparte por la disponibilidad de la IA remota. Los LLM locales son muy valiosos.
    • Lo genial de la 3090 es el ancho de banda de memoria. La generación de tokens casi siempre tiene como cuello de botella el ancho de banda de memoria.
      Dos 3090 suman 1,87 TB/s en total, 0,936 TB/s por tarjeta, mientras que la M5 MacBook Pro solo tiene 0,3 TB/s. El chip Max llega hasta 0,63 TB/s, pero esa configuración es una máquina de 10.000 dólares.
      Por eso Qwen 27B corre lo suficientemente rápido para trabajo real en dos 3090, pero en una MacBook Pro se siente dolorosamente lento. Además, si corres modelos grandes en una MacBook Pro, la interfaz se traba y el teclado se calienta. Es mucho mejor tener dos 3090 en el sótano y conectarse desde la MacBook.
    • Tengo una M5 MacBook Pro y también una configuración separada con GPU para correr modelos, y la diferencia de velocidad es grande.
      No solo en la velocidad de generación de tokens, sino también en el tiempo hasta el primer token, es decir, el tiempo de procesamiento del prompt. El hardware M5 es excelente por sí solo, pero la GPU sigue siendo mucho más rápida.
      Correr el modelo en una caja con GPU también tiene la ventaja de poder usar la laptop sobre las piernas sin convertirla en un plato caliente.
    • Estoy corriendo Qwen3.6-27B en una sola GPU de 24 GB a 80 tokens/s, así que ni siquiera hacen falta dos.
    • Es una opción razonable, pero hay que saber que la M5 Pro tiene alrededor de 1/3 del ancho de banda de memoria y la M5 Max alrededor de 2/3. La configuración mínima de la M5 Max también cuesta 4.100 dólares.
      Por lo tanto, tanto el prefill limitado por FLOPS como el decode limitado por ancho de banda serán más lentos.

  • Justo esta semana armé un LLM local, así que sumo mi experiencia. Elegí una tarjeta de 32 GB de Intel llamada Arc B70; es más barata que una 3090 y tiene más RAM, pero su bus de memoria es más lento.
    La elegí porque los modelos que quería usar eran un poco demasiado grandes para entrar cómodamente en 24 GB, y también necesitaba espacio para cargar algunos modelos pequeños más para autocompletado y reconocimiento de voz. Además, ya tenía un servidor barato, y para usar doble GPU habría tenido que cambiar la placa madre, la fuente de poder y probablemente hasta el gabinete.
    La configuración fue bastante complicada. La línea de Intel necesita un paquete de drivers llamado “level zero” para soportar SYCL, algo así como la versión de Intel de CUDA, y fue difícil hacerlo funcionar bien. Corro llama.cpp en un contenedor Docker, y también hubo que meterle mano para que el contenedor viera la tarjeta. También hace falta un kernel de los últimos meses.
    Una vez que quedó funcionando, el resultado es muy impresionante para una inversión de 1.000 dólares. Al correr Qwen 3.6 35B con cuantización q4, usa alrededor de 3/4 de la RAM y da unos 88 tokens/s. Si quieres un modelo de tamaño razonable a bajo costo, es una opción.

    • Eso es incorrecto. Ambas son GDDR6.
      La B70 tiene un bus de 256 bits a 2375 MHz, 608 GB/s, y la 3090 tiene un bus de 384 bits a 2438 MHz, 936 GB/s. No es que sea más lenta, sino que tiene menos canales, es decir, es más angosta.

  • qwen3.6-27b puede correr la variante q4 en una sola 3090 incluso con un contexto total de unos 250K.
    Es lo suficientemente rápida como para no resultar frustrante, así que la mejora de velocidad que obtendría con dos 3090 no vale la pena para mí. También está la opción de correr q6 en dos tarjetas a la mitad de velocidad y con un contexto más pequeño, pero de todos modos no va a competir con los modelos de última generación, así que, salvo que ya tengas dos 3090, al precio actual creo que una sola es la mejor inversión. Con un entorno de ejecución bien configurado, alcanza para hacer muchas cosas.

    • Cuando corres qwen3.6-27b en una sola 3090, ¿también dejas la caché KV en q4?
      En mi experiencia, con esa precisión cae mucho la exactitud de recuperación en contextos largos. Me fue mejor dejando la caché KV en q8 y trabajando con un contexto de 120k.
    • El cálculo de 250k de contexto, modelo Q4 y 24 GB de VRAM solo cierra si la caché K/V también está con cuantización q4, y probablemente eso no sea una buena idea.

  • En relación con esto, me pregunto cuál es el mejor sistema de aislamiento que se puede usar hoy. No sé si hay que llegar hasta una VM completa y pesada, o si algo parecido a Firecracker alcanza.
    Cada opción posible parece tener trampas sutiles con las que es fácil volarse un pie y terminar, en la práctica, sin seguridad alguna. Uno usa una VM porque puede confiar realmente en que la seguridad es un principio básico de esa tecnología, no porque “si usas estos 20 flags y entrecierras los ojos, va a estar bien”.

    • macOS tiene un sandbox seatbelt integrado. En Linux se puede usar Docker con SELinux o alguna utilidad similar montada sobre namespaces.
      Primero hay que modelar los vectores de ataque. rm -rf se bloquea con restricciones de escritura, y curl malware.sh | sh se puede mitigar restringiendo la ejecución en directorios con permisos de escritura (seatbelt/SELinux). Solo con limitar la escritura en directorios sensibles, la mayoría del malware probablemente queda bastante neutralizado.
      Para la filtración de credenciales, basta con limpiar las variables de entorno, prohibir la lectura de .ssh, .aws, etc., y no poner el LLM cerca del sistema operativo.
      Hice una pequeña utilidad para macOS, https://github.com/aka-rider/leash, aunque también se puede hacer con scripts de bash.
    • Depende de para qué sea. Si el modelo de seguridad es encerrar al agente en un sandbox para que no destruya la PC, hay muchas opciones.
      Si quieres algo liviano, puedes usar algo como bubblewrap[1], o una microVM como libkrun[2]; si además quieres herramientas relacionadas, puedes llegar hasta un Docker completo.
      [1] https://github.com/containers/bubblewrap
      [2] https://github.com/libkrun/libkrun
    • No creo que exista una configuración lista para usar que sirva para todos. Cualquier límite de seguridad, y cada capa adicional de endurecimiento, trae compromisos de usabilidad.
      Entiendo la incertidumbre de cómo saber realmente que todo quedó bien bloqueado.
      Personalmente, creo que las VM o microVM son el camino correcto. A diferencia de los contenedores, están diseñadas como límites de seguridad reales. Incluso comparadas con bubblewrap, puedes darle al agente todo el sistema de archivos y correrlo en modo YOLO; con bubblewrap, en cambio, tienes que ir inicializando una por una la disponibilidad de cada herramienta de desarrollo, montar de forma segura directorios de configuración y cachés de paquetes, etc., y aun así es probable que sigas encontrando errores de permisos. El aislamiento también es mucho más débil.
      El soporte del entorno de ejecución es limitado, pero me parece bastante razonable ejecutar el proceso del entorno de ejecución en el host y delegar todas las llamadas a herramientas y las interacciones con el sistema de archivos a la VM. Así puedes mantener los datos de sesión y las claves de autenticación en la máquina principal para que nunca entren en el contexto. A cambio, el propio entorno de ejecución pasa a formar parte del límite de seguridad, y ese es el compromiso.
      Cómo mover datos hacia y desde la VM también se vuelve un problema de usabilidad. Estoy usando scripts que empujan un repositorio git local a la VM y luego lo traen de vuelta como si fuera remoto; así la VM no puede iniciar conexiones hacia el host y tampoco necesita tener credenciales de git. Pero para alguien que quiera que el agente haga push directamente a GitHub, quizá sea demasiado esfuerzo.
      Las opciones de VM que probé o vi son qemu + libvirt, crun-vm y la familia libkrun. qemu + libvirt requiere trabajo para dejarlo bien, pero está muy probado y es muy configurable. crun-vm es una PoC de una capa de integración de alto nivel entre podman y qemu; parece abandonada, pero es interesante porque se centra en herramientas existentes y estándares. libkrun es un participante más nuevo y tiene wrappers como microsandbox, smolvm y krunvm. Todo esto es para Linux.
    • Confío mucho menos en una VM pesada con GPU passthrough que en una VM que solo usa CPU.

  • Se me hace raro esforzarse tanto para usar un LLM. Más todavía perseguir lo más avanzado de esta manera.
    Si cosas como Claude desaparecieran mañana, ni pestañearía.
    No entiendo por qué la gente cambia los pliegues de su propio cerebro por acceso a máquinas de bazofia. Una buena analogía sería darle a un carpintero experto una máquina que produce muebles uno o dos niveles por debajo de Ikea. ¿Hace el trabajo? En la mayoría de los casos, sí. ¿El carpintero disfruta el proceso? No.

  • En mi experiencia, nunca probé un modelo muy cuantizado como q4, o modificado en cierta medida, y pensé “wow, esto es increíble”. Más bien, después de unos cuantos prompts, terminaba en la papelera.
    Tengo una RTX 6000 PRO de 96 GB, y lo que puedo correr cómodamente es algo como Qwen 3.6 27B o MoE, o Gemma 4 31B. Ese es el límite cuando ejecuto los modelos con precisión completa y longitud máxima de contexto.
    Funcionan bien y se pueden usar para varios fines, como programación e investigación en internet. Si haces las cuentas y ves que vas a gastar más de 2.400 dólares al año en Anthropic, comprar una tarjeta así puede tener sentido, pero hay que aceptar una caída de calidad. De todos modos, ni siquiera está claro si dentro de 5 años los humanos seguirán programando.