Escrito por:@KSimback
Compilado por:AididiaoJP
Escenario hipotético: ¿Qué ocurriría si se prohibiera un modelo de vanguardia?
La fecha es octubre de 2026, dentro de solo cuatro meses. Acaba de lanzarse GLM-6, superando a Fable-5.1 (una versión censurada y relanzada del modelo prohibido) en pruebas de referencia principales y empatando con Mythos. El gobierno de EE.UU. no puede apagarlo directamente, por lo que emite una serie de prohibiciones: prohíbe a cualquier proveedor ofrecer el modelo GLM-6, actualizaciones, servicios de inferencia, implementaciones gestionadas o soporte técnico dentro de Estados Unidos o a ciudadanos estadounidenses.
Amazon Bedrock, Google Vertex y Microsoft Azure rápidamente declaran su cumplimiento, negándose a alojar el modelo para sus clientes empresariales. Las principales plataformas de agregación como OpenRouter, Vercel, Cloudflare, TogetherAI, etc., también acuerdan no incluirlo. GitHub elimina todo rastro relacionado de su plataforma. Hugging Face, como último bastión, finalmente elimina las descargas de todos los modelos relacionados con GLM-6.
Este escenario, aunque no es el resultado ideal que deseamos, es un desenlace completamente plausible en un mundo donde los modelos de IA avanzan exponencialmente mientras que las políticas se mueven a paso de caracol.
Este resultado, o un escenario alternativo donde la IA de vanguardia siga monopolizada por unas pocas entidades centralizadas, es la razón fundamental por la que la IA descentralizada es tan crucial.
Este artículo es una pieza complementaria de la guía introductoria anterior del autor, «Proof of Useful Work», adoptando el mismo enfoque pragmático y centrándose en otro rincón clave del crypto-AI (ambos se solapan parcialmente). El autor desglosa en profundidad los problemas que la IA descentralizada debe resolver, los proyectos que está siguiendo, el marco de diligencia debida, y sus juicios personales tras la investigación.
¿Por qué la inferencia descentralizada es imperativa?
Tras el escenario anterior, probablemente ya hayas pensado en la inferencia descentralizada. Si no es así, sigamos el razonamiento.
Una vez publicados los pesos del modelo GLM-6, las copias se propagarían instantáneamente por Internet—ninguna prohibición o medida correctiva podría eliminar las miles de copias que ya existen. Estas copias serían servidas en redes de inferencia descentralizadas, porque allí no existe una autoridad central que pueda actuar contra ellas, y ningún nodo cuyo bloqueo pueda paralizar toda la red.
Quiero dejar algo claro: no estoy argumentando si esto es bueno o malo. Si un nuevo modelo de pesos abiertos se publica y puede causar un daño grave por mal uso, no recomendaría que se ignore. Lo que enfatizo es: los modelos inevitablemente serán obtenidos por aquellos que no quieren ser censurados.
Esta es la premisa central de la inferencia descentralizada—es una cobertura contra el riesgo de censura, ya sea de gobiernos o de laboratorios de vanguardia. Otros beneficios, como tokens más baratos, inferencia verificable, privacidad, son secundarios. La única apuesta central es: mitigar el riesgo de censura.
La inferencia descentralizada es realmente difícil: cuatro grandes problemas
Para la mayoría de las startups, resolver uno o dos problemas ya es un gran desafío. Los proyectos de inferencia descentralizada deben abordar simultáneamente cuatro problemas realmente espinosos. Cómo cada proyecto responde a estos problemas es precisamente lo que distingue la sustancia del ruido, el alfa del ruido.
Problema 1: Ejecutar modelos que no caben en una sola máquina
La idea central es crear un enjambre (swarm) de GPUs, utilizando paralelismo de tubería (pipeline parallelism) para servir los modelos que los usuarios realmente quieren. En esencia, cada nodo solo contiene una pequeña porción o fragmento de los pesos del modelo y su propia parte de la caché KV, fragmentos lo suficientemente pequeños como para caber en GPUs de consumo como las 3090/4090, o incluso en H100 de mayor especificación. Al combinar suficientes nodos, se puede alojar un modelo grande como GLM.
Petals demostró la viabilidad de este enfoque con BLOOM-176B en GPUs de consumo en 2022, usando un estilo de swarm similar a BitTorrent, pero a una velocidad de solo ~1 token por segundo. Evidentemente, esa velocidad es completamente inutilizable, por lo que la innovación posterior se ha centrado en cómo hacer que el modelo corra más rápido.
El cuello de botella realmente mortal es la red. Dentro de un centro de datos, las GPUs se comunican a través de NVLink a velocidades de terabytes por segundo; en la Internet pública, la latencia de ida y vuelta (RTT) puede ser de decenas de milisegundos. El proceso de decodificación es secuencial, y un swarm ingenuo paga un viaje de ida y vuelta en la red por cada token generado.
La solución más común es la decodificación especulativa (speculative decoding): un modelo borrador (draft) pequeño y barato propone primero K tokens candidatos, y el modelo grande fragmentado (sharded) verifica esos K tokens en una sola pasada de tubería, conservando luego la secuencia coincidente más larga. Así, un costoso viaje por la red puede producir varios tokens, no solo uno.
Actualmente se han logrado ~30-40 tokens por segundo en enlaces reales de Internet, un progreso significativo, pero aún no se ha verificado completamente a gran escala y a la velocidad que realmente necesitan los usuarios. Este es un problema que requiere auténticas capacidades de ingeniería.
Atención: Servir inferencia es mucho más que juntar FLOPS
Al comparar cualquier método de swarm con un modelo alojado en la nube, hay una trampa común: se mira solo los tokens por segundo, como si eso fuera todo.
Pero la inferencia a nivel de producción debe hacer muchas cosas bien, y ninguna está relacionada con el poder bruto de cálculo:
- Equilibrio entre el tiempo del primer token (TTFT) y la latencia entre tokens
- Las dos fases: Prefill y decodificación (con requisitos de hardware completamente opuestos)
- Ubicación y transmisión de la caché KV
- Transmisión en flujo (streaming), procesamiento por lotes continuo (continuous batching) y utilización bajo cargas mixtas
- Comportamiento de contexto largo, arranque en frío y calentamiento del modelo
- Inestabilidad (churn) de nodos
Punto clave de diligencia: Cuando un proyecto cita cifras de rendimiento, pregunta siempre con qué está compitiendo. Los despliegues centralizados de vLLM o SGLang (que utilizan prefill desagregado y procesamiento por lotes continuo) son el punto de referencia real, y este punto de referencia se vuelve más rápido cada trimestre. «Alcanzamos 30 tokens por segundo en Internet» suena impresionante, pero aún puede carecer de competitividad.
Problema 2: Demostrar que realmente obtuviste el modelo por el que pagaste
Si no confías en el nodo, ¿cómo sabes que realmente está ejecutando el modelo que dice, y no que lo cambió subrepticiamente por una versión cuantificada más barata? Especialmente en redes con tokens de minería, es fácil para el proveedor «hacer trampa», sirviéndote aparentemente el modelo real mientras en realidad ejecuta algo más barato.
Actualmente hay cinco enfoques principales:
- ZKML: Prueba de conocimiento cero del pase hacia adelante. Imbatible criptográficamente, pero con una sobrecarga de ~10,000x. Para un modelo como Llama-3, generar un token tomaría ~150 segundos. Imposible a escala de vanguardia a corto plazo.
- opML: El resultado viene con un depósito, se abre una ventana de desafío, las disputas se reducen a un solo paso mediante pruebas de fraude (fraud-proof) y un árbitro lo vuelve a ejecutar. Velocidad casi nativa, pero la finalidad requiere esperar el período de la ventana, y existe el «dilema del validador» (si el coste de verificar es mayor que el valor de atrapar un fraude, nadie verifica).
- Re-ejecución determinista: Hacer que la inferencia sea reproducible a nivel de byte, las disputas solo necesitan verificar la igualdad de bytes. Sobrecarga < 2%, asegurada por ETH re-apostado (restaked).
- Huellas estadísticas: Aplicar hash o muestreo barato del cálculo, atrapando la mayoría de las trampas la mayoría de las veces. No es absolutamente correcto, pero es rápido y adecuado para GPUs heterogéneas, necesario para un swarm sin permisos.
- Pruebas de pesos en vivo (Live-weight proofs): Muestrear directamente los tensores que realmente residen en la memoria durante el servicio y compararlos con un manifiesto del modelo aprobado. Verifica «qué se cargó», no «qué se produjo». Sobrecarga de solo ~0.1%. Un enfoque verdaderamente diferente.
La compensación real es: solo puedes tener dos de estos tres—integridad criptográfica, baja latencia, eficiencia de costes. ZKML obtiene la integridad, sacrifica latencia y coste; otros métodos obtienen latencia y coste, pero solo pueden ofrecer integridad económica o estadística.
Punto clave de diligencia: Pregunta qué método usa el proyecto, por qué, y cómo afecta esa compensación al producto final.
Problema 3: ¿Cómo mantener realmente confidencial el prompt?
Demostrar que la salida es correcta es un problema completamente diferente a ocultar la entrada. En un swarm fragmentado (sharded), cada nodo debe descifrar las activaciones para calcular—el cifrado solo protege la línea de transmisión, no el nodo en sí.
Las activaciones de un Transformer son, de hecho, muy fáciles de revertir. Una investigación de CCS 2025 mostró una precisión >90% en la reconstrucción del prompt de entrada a partir de activaciones intermedias. El artículo de ICML 2025 «Hidden No More» logró una recuperación casi perfecta y derrotó las defensas comunes de ruido-y-permutación usadas en swarms.
La única solución robusta hasta ahora es un esquema más pesado de fragmentación por secuencia (sequence-sharded), que nadie en el espacio de GPUs de consumo ha implementado realmente, por lo que sigue siendo un problema en gran parte sin resolver.
Un swarm puede afirmar «ningún nodo tiene el modelo completo», pero aún así filtraría cada prompt a cualquier nodo en el camino. «Ningún nodo tiene el modelo» nunca es una propiedad de privacidad.
Lo que realmente puede proporcionar privacidad son métodos de hardware o matemáticos, no la topología de red. Los TEEs (Entornos de Ejecución Confiables)—como la solución de Phala en GPUs, la de Darkbloom en Apple silicon, el modo Pro de Venice—trasladan la confianza a una raíz de hardware y utilizan atestación.
El Cifrado Totalmente Homomórfico (FHE) puede calcular directamente sobre texto cifrado, sin confiar en nada, pero el coste para modelos grandes es actualmente inaceptable.
Punto clave de diligencia: Un proyecto tiene realmente uno de estos esquemas, o no tiene privacidad, sin importar cómo lo presente en su página de destino.
Recordatorio importante: Privado no es igual a sin confianza (trustless). Los TEE no eliminan la confianza, solo la trasladan del operador del nodo al fabricante del hardware, la cadena de firmware, el servicio de atestación y la implementación del enclave.
La verdadera pregunta es: ¿en qué raíz de confianza estás dispuesto a confiar? ¿El fabricante del chip? ¿Un conjunto de validadores re-apostados (restaked)? ¿Una red de TEEs? ¿O las matemáticas puras?
Problema 4: ¿Cómo construir un verdadero mercado bilateral?
Los primeros tres son problemas técnicos; el cuarto es un problema comercial.
Para una red de inferencia descentralizada que sirve modelos de pesos abiertos, ¿quién es el cliente ideal (ICP)?
La mayoría de los consumidores comunes actualmente obtienen un valor enorme de suscripciones—$20-200/mes por mucha inteligencia. Estos planes subsidiados podrían desaparecer o racionarse en el futuro, pero hoy, vender inferencia bajo demanda por API es muy difícil de vender a los consumidores.
Las empresas tampoco serán grandes compradoras a corto plazo. Quizás cambie en el futuro, pero no cuentes con que sea pronto.
Realmente quedan dos tipos de usuarios: 1) Startups y empresas que integran la inferencia en su pila de productos, que naturalmente necesitan planes de API; y 2) Agentes de IA autónomos que buscan su propia capacidad de inferencia.
La categoría de startups es un mercado en crecimiento, un nicho donde se puede capturar ingresos significativos, pero tiene un límite claro de captura de valor a corto plazo. Los agentes de IA como compradores son más especulativos—a corto plazo, todavía necesita que alguien pague por ellos.
He aquí el problema: ¿cómo agregar una oferta significativa de los modelos que la gente realmente quiere, cuando el grupo de usuarios objetivo probablemente no sea el que más gaste en la red?
El único lugar viable en este momento es el de los proveedores de GPU descentralizados. Proyectos como io.net, Akash, Render, Aethir, Nosana han estado haciendo esto durante años, alquilando GPUs enteras o la capacidad de todo un modelo por nodo a compradores a través de mercados coordinados por tokens. Hay precedentes.
Punto clave de diligencia: Pregunta cuál es el ICP del proyecto y cómo planea captar tanto a los usuarios objetivo como satisfacer al lado de la oferta. Si todo se basa en la expectativa especulativa de que el token suba, es una señal clara.
¿Quién está realmente resolviendo estos problemas? Resumen de proyectos principales
Actualmente hay muchos proyectos clasificados como «inferencia descentralizada», pero la mayoría no abordan los cuatro problemas por igual, sino que se enfocan en diferentes aspectos.
Petals: El auténtico pionero de la inferencia descentralizada. En 2022 demostró que BLOOM-176B podía ejecutarse en GPUs de consumo con un estilo BitTorrent. Importancia conceptual enorme, pero no resolvió incentivos, privacidad o monetización. Cualquier proyecto que sea esencialmente «arquitectura Petals + token» probablemente sea falso (larp).
Dolphin Network: El equipo detrás de la serie de modelos abiertos sin censura Dolphin (más de 5 millones de descargas en Hugging Face). Su origen es una necesidad real de usuarios primero, luego la red. Punto técnico destacado: pruebas de pesos en vivo (0.1% de sobrecarga), combinadas con huellas de logprob, comprobaciones de integridad de software y vinculación a nivel de cuenta. Ha generado más de 3.2 mil millones de tokens, con un ancho de banda sostenido de ~9400 t/s. Representante de enfoque producto-primero con fuerte ejecución.
Inference.net (antes Kuzco): Uno de los intentos más maduros de validación de modelos en la naturaleza. Su mecanismo único LOGIC se basa en pruebas estadísticas de logprob para detectar sustituciones de modelos. En producción durante ~18 meses, flota de miles de GPUs. Uno de los pocos proyectos con primitivas de validación y un historial operativo real.
Morpheus: Capa de enrutamiento y recompensas descentralizada, ofrece una API compatible con OpenAI + un envoltorio para agentes inteligentes. Punto técnico destacado: validación de proveedores respaldada por TEE (Intel TDX + atestación de GPU NVIDIA ya implementada). Hay que vigilar las emisiones de MOR y la evidencia de demanda externa real.
Chutes (Subred 64 de Bittensor): El lado del usuario es una API compatible con OpenAI, el backend son despliegues de chute empaquetados en Docker enviados a mineros de GPU de Bittensor. Ventajas claras en distribución y escala, pero brechas en verificación y privacidad.
c0mpute: Nuevo proyecto nativo de Solana. Su motor Shard divide modelos de vanguardia en GPUs de consumo. Ya ha mostrado demostraciones reales de GLM-5.2 744B y gpt-oss-120B (30-40 t/s). Artefactos técnicos verificables, pero aún extremadamente temprano (repositorio subido hace días, fundadores anónimos, token de micro-capitalización en pump.fun).
Parallax (Gradient Network): Marco de inferencia de LLM distribuido P2P, admite fragmentación paralela de tuberías a través de GPUs de consumo y Apple Silicon, permitiendo que individuos u organizaciones pequeñas ejecuten «clusters soberanos». Respaldo institucional fuerte (ronda semilla de $10M liderada por Pantera y Multicoin), pero el enfoque de privacidad no está claro.
Darkbloom: Permite a los usuarios convertir la potencia de cómputo ociosa de sus Macs en un mercado privado de inferencia. Cada Mac ejecuta el modelo completo, con privacidad asegurada por atestación del Secure Enclave. No sigue el camino del swarm fragmentado (sharded), su pila de atestación es rigurosa. Ha pasado de vista previa de investigación a alpha pública, su tracción real merece atención (descentralizado no necesariamente significa tokenizado).
MeshLLM: Malla de inferencia P2P sin permisos, presentada por Jack Dorsey y construida por un equipo asociado a Block. Descubrimiento de nodos basado en Nostr, sin servidores centrales, más cercano a BitTorrent que a Bittensor. Protocolo primero, sin token, resistente a la censura.
Venice y su ecosistema de reventa: Ejemplar en toda la categoría en la búsqueda de PMF y un modelo de negocio viable. Es en sí mismo un proxy de consumo centralizado pero con privacidad por capas, que ha resuelto efectivamente algunos problemas. A su alrededor ha surgido un sub-ecosistema de revendedores como UsePod, AntSeed, Surplus Intelligence, que se enfocan principalmente en agregar demanda y liquidación, no en proporcionar potencia de cómputo descentralizada directamente.
El campo de batalla de la inferencia descentralizada
La ventaja de costos solo se sostiene cuando se separan la latencia y el rendimiento (throughput). Son dos productos diferentes, y la descentralización es un impuesto para uno y una característica para el otro.
Escenarios donde la centralización gana claramente (descentralización es un impuesto): Chats interactivos tipo ChatGPT, agentes de codificación en tiempo real, voz de baja latencia, llamadas a herramientas de alta frecuencia, SLAs empresariales estrictos de latencia p95, servicio competitivo de modelos densos de vanguardia.
Escenarios donde la descentralización podría ganar (ventaja de agregación de oferta): Generación de datos sintéticos, evaluación fuera de línea (offline), generación de embeddings por lotes, RAG por lotes, tareas de investigación de agentes a largo plazo, colas de generación de imágenes/video, inferencia no urgente en modelos abiertos (costo marginal de hardware inactivo cercano a cero).
Marco simple: cuando la latencia es importante, la descentralización es un impuesto; cuando el rendimiento (throughput) es importante, la descentralización puede ser una ventaja de agregación de oferta.
Valor oculto a largo plazo: El ciclo de datos
Las redes de inferencia descentralizadas también pueden recopilar grandes cantidades de datos valiosos—datos sintéticos de entrenamiento, datos de preferencia, trazas de agentes, salidas de evaluación, datos de ajuste fino (fine-tuning), entornos de RL, trazas de uso de herramientas, etc. Estos datos pueden alimentar redes de entrenamiento descentralizadas (como proyectos al estilo de Nous Psyche, Prime Intellect, Gensyn), produciendo modelos de pesos abiertos actualizados que luego fluyen de vuelta a la red de inferencia.
A largo plazo, esta no es una apuesta separada de «entrenamiento descentralizado» o «inferencia descentralizada», sino un circuito cerrado: la inferencia genera trazas → las trazas se convierten en datos de entrenamiento → el entrenamiento actualiza el modelo → el modelo actualizado vuelve a la inferencia.
Los mejores proyectos incorporarán este ciclo como estrategia central, y los futuros proyectos de entrenamiento e inferencia convergerán aún más.
Lista práctica de diligencia debida: Solo responde estas siete preguntas
- ¿Es realmente descentralizado? ¿En qué capas concretamente? (Muchos solo tienen la etiqueta por tener un token).
- ¿Puedes confiar en que la salida proviene del modelo por el que pagaste? (Determinismo, pruebas, huellas, o nada).
- Después de descontar los costos de tokens y coordinación, ¿es realmente más barato que lo centralizado? (En producción, no en teoría).
- ¿Está el prompt realmente oculto para el operador? (Solo cuentan TEE/FHE, el simple fragmentado no).
- ¿Sigue siendo estable el sistema cuando los nodos son poco fiables y están dispersos por Internet?
- ¿Hay alguien que realmente esté pagando, y por algo que no pueda obtener más barato de forma centralizada?
- ¿Tiene el equipo capacidades técnicas reales de IA? (La más importante).
Consejo adicional: Desconfía de los «esquemas técnicos elegantes» sin un plan de distribución creíble.
Mi juicio final
Soy generalmente escéptico respecto a categorías que solo atraen a nativos del crypto (el TAM me parece limitado). Prefiero ver proyectos que también atraigan a usuarios no-crypto, con mecanismos de crypto ocultos en segundo plano.
La inferencia descentralizada es una de las pocas áreas dentro del crypto con un verdadero potencial disruptivo—todos necesitan inferencia, puede servirse como los proveedores tradicionales, incluso a través de plataformas como OpenRouter para una experiencia fluida. La clave está en el coste, el rendimiento y la privacidad.
Consejo: Apoya a proyectos que puedan explicar claramente qué capa descentralizan y que sepan claramente quiénes son sus compradores. Aléjate de aquellos que solo usan «IA descentralizada» como eslogan, seguido de una moneda.
Divulgación: El autor original posee tokens de algunos de los proyectos mencionados. No está influenciado ni compensado por ningún proyecto, sus juicios son opiniones personales.
