Esta es una copia de una conversación entre Claude y Roberto. El contenido puede incluir material no verificado o no seguro que no representa las opiniones de Anthropic. La instantánea compartida puede contener archivos adjuntos y datos que no se muestran aquí.
¿Cuánto es lo menos que cuesta habilitar un modelo grande de Inteligencia Artificial, no como un asistente o con una API de otro, sino de manera relativamente independiente, con base en un código abierto, como el disponible de DeepSeek (o sea, no creándolo desde cero)?
Buena pregunta, y tiene varias capas. Te lo desgloso de forma práctica:
La respuesta corta: desde prácticamente $0 (local, en tu propia máquina) hasta varios miles de dólares al mes en la nube, dependiendo del modelo y la escala. Lo que determina el costo es casi siempre el hardware.
Si ya tienes una PC con GPU decente, puedes correr modelos medianos sin pagar nada extra. Herramientas como Ollama, LM Studio o llama.cpp te permiten bajar y correr modelos con unos cuantos comandos.
| Modelo | VRAM mínima | Hardware ejemplo | Costo extra |
|---|---|---|---|
| Llama 3.1 8B | ~6 GB | RTX 3060/4060 | $0 si ya la tienes |
| DeepSeek-R1 7B | ~6 GB | RTX 3060/4060 | $0 si ya la tienes |
| Mistral 7B | ~6 GB | RTX 3060/4060 | $0 si ya la tienes |
| Llama 3.1 70B (cuantizado) | ~40 GB | 2× RTX 3090 o Mac M2 Ultra | ~$2,000–4,000 USD en hardware |
| DeepSeek-R1 671B (completo) | ~350 GB | 8× A100 80GB | Inviable localmente |
Truco clave: los modelos se pueden cuantizar (reducir precisión de 32-bit a 4-bit), lo que los hace 4–8× más pequeños con pérdida de calidad menor al 5%. Eso hace que un modelo de 70B quepa en hardware del consumidor.
Rentas GPUs en plataformas como RunPod, Vast.ai, Lambda Labs o AWS/GCP.
| Modelo | GPU recomendada | Costo aprox. |
|---|---|---|
| 7B–13B params | 1× A10G (24 GB) | $0.30–0.75 USD/hora |
| 70B params | 1× A100 80GB | $1.50–2.50 USD/hora |
| DeepSeek-R1 671B | 8× H100 | $20–40 USD/hora |
Para un uso personal o de prototipo (digamos 4 horas/día de un modelo 70B): ~$180–300 USD/mes.
Para producción real con disponibilidad 24/7:
DeepSeek liberó sus pesos bajo licencia abierta. El modelo completo DeepSeek-R1 671B es enorme y requiere hardware de datacenter. Pero sus versiones destiladas son muy accesibles:
| Situación | Opción | Costo mínimo |
|---|---|---|
| Experimentar / aprender | Ollama en tu PC con GPU | $0 |
| Prototipo / startup pequeña | RunPod bajo demanda | ~$50–200 USD/mes |
| Producto con usuarios reales | Servidor dedicado en nube | ~$500–2,000 USD/mes |
| Empresa con privacidad total | Hardware propio | $3,000–15,000 USD (inversión única) |
Si quieres entrar con costo casi cero hoy mismo:
ollama run deepseek-r1:8b en la terminal¿Te interesa profundizar en algún escenario específico, como producción en la nube, privacidad de datos, o cómo exponer el modelo como API propia?
Activa la búsqueda web en el menú Buscar y herramientas. De lo contrario, los enlaces proporcionados pueden no ser precisos o estar actualizados.
Gracias. ¿Cuánto cuesta una GPU "decente", para dicho propósito de correr localmente modelos medianos? En "DeepSeek-R1 671B", ¿qué significan "R1" y la "B"?
El rango práctico es este:
| GPU | VRAM | Modelos que aguanta | Precio aprox. (nueva) | Precio aprox. (usada) |
|---|---|---|---|---|
| RTX 3060 | 12 GB | hasta ~13B cuantizado | $280–320 USD | $150–200 USD |
| RTX 3060 Ti | 8 GB | hasta ~7B cuantizado | $280–300 USD | $130–180 USD |
| RTX 4060 Ti | 16 GB | hasta ~13B cómodo | $400–430 USD | $300–360 USD |
| RTX 3090 | 24 GB | hasta ~34B cuantizado | $700–800 USD | $400–550 USD |
| RTX 4090 | 24 GB | hasta ~34B cuantizado, más rápido | $1,600–1,800 USD | $1,200–1,400 USD |
| Mac M2/M3 Ultra | 96–192 GB RAM unificada | hasta ~70B cómodo | $3,000–5,000 USD | — |
El punto dulce para la mayoría es la RTX 3090 usada (~$450 USD): 24 GB de VRAM permiten correr modelos de 13B a velocidad fluida y modelos de 34B cuantizados de forma aceptable. Relación costo/desempeño imbatible hoy mismo.
Un detalle importante: en México y Guadalajara específicamente, los precios en MercadoLibre suelen ser un 20–40% más altos que los de referencia en dólares, más el tipo de cambio. Una RTX 3090 usada puede encontrarse entre $8,000–11,000 MXN.
R1 es simplemente el nombre del modelo, como una versión o generación. En el caso de DeepSeek, "R" alude a Reasoning (razonamiento): es su línea de modelos entrenados específicamente para razonar paso a paso antes de responder, similar a lo que hace el modelo o1 de OpenAI. El "1" es la primera iteración pública de esa línea.
671B significa 671 mil millones de parámetros. Los parámetros son, en términos simples, los "valores numéricos" que el modelo aprendió durante su entrenamiento y que determinan cómo procesa y genera texto. A más parámetros, generalmente más capacidad, pero también más memoria y cómputo necesarios. Por eso:
Es la misma convención en todos los modelos open-source: Llama 3B, Mistral 7B, Qwen 32B, etc. La "B" siempre es billions (miles de millones en inglés).
Gracias. ¿Por qué una IA cuya capacidad sea aproximada a la de un cerebro humano (sin considerar velocidad) no es actualmente tan pequeña (en hardware) ni tan económica en funcionamiento como dicho cerebro biológico?
Pregunta profunda. La respuesta tiene varias dimensiones:
El cerebro no hace lo que hacen los LLMs. Una red neuronal artificial es una aproximación matemática muy burda inspirada vagamente en la biología, no una réplica. Los transformers (la arquitectura detrás de GPT, DeepSeek, etc.) hacen multiplicaciones masivas de matrices de números flotantes. El cerebro hace algo fundamentalmente distinto y aún no del todo comprendido.
Es como preguntar por qué un avión necesita más combustible que un pájaro para volar: la solución de ingeniería no replica el mecanismo biológico, lo rodea con fuerza bruta.
| Cerebro humano | GPU H100 (top de línea) | |
|---|---|---|
| Consumo | ~20 watts | ~700 watts |
| "Parámetros" equiv. | ~100 billones de sinapsis | 80 GB VRAM |
| Enfriamiento | Ninguno especial | Refrigeración activa obligatoria |
El cerebro logra eso gracias a mecanismos que la ingeniería actual no sabe replicar eficientemente:
Las neuronas operan con iones y potenciales eléctricos en agua salada, a temperatura ambiente, con estructuras tridimensionales complejísimas en un volumen de ~1.4 litros. Los chips de silicio son estructuras planas (2D esencialmente), que requieren litografía nanométrica, materiales exóticos, temperaturas controladas y disipación de calor activa.
La biología lleva miles de millones de años de optimización evolutiva. La electrónica de silicio lleva ~70 años.
El número de parámetros de un LLM no se traduce directamente a "neuronas". GPT-4 se estima en ~1.8 billones de parámetros; el cerebro tiene ~86,000 millones de neuronas pero ~100 trillones de sinapsis. La comparación no es directa porque:
Los LLMs fueron diseñados para ser escalables con hardware existente, no eficientes. La apuesta fue: más datos + más parámetros + más cómputo = mejor resultado. Eso funcionó sorprendentemente bien, pero es el enfoque opuesto al de la biología.
Hay líneas de investigación que van hacia la eficiencia:
La IA actual no es pequeña ni barata porque es una solución de ingeniería que fuerza resultados inteligentes a través de volumen matemático, no porque entienda cómo funciona realmente la inteligencia. El cerebro es el resultado de un proceso de optimización incomparablemente más largo y sofisticado, en un sustrato que la humanidad aún no sabe fabricar ni replicar. La brecha se está cerrando, pero lentamente y desde un punto de partida muy distinto.
Gracias. ¿Puedes, por favor, explicarme qué es la "construcción textual predictiva con base en una semántica lógica"?
El término que usas no es una frase técnica estándar del campo, pero describe muy bien algo real. Te lo explico desde cero.
Un modelo de lenguaje, en su operación más básica, hace una sola cosa repetidamente:
"Dado todo el texto que ha aparecido antes, ¿cuál es la siguiente pieza de texto más probable?"
Eso es la construcción textual predictiva: construye texto prediciendo, token a token (palabra a palabra, aproximadamente), qué viene después.
Aquí está la parte interesante, y también la más debatida.
El modelo no predice la siguiente palabra como si fuera un dado al azar. Durante su entrenamiento con cantidades masivas de texto humano, aprendió que ciertas palabras y frases co-ocurren con otras de maneras que no son arbitrarias, sino que reflejan relaciones de significado y coherencia lógica presentes en el lenguaje humano.
Por ejemplo, aprendió que después de "el agua hierve a" casi siempre viene "100 grados", no porque entienda física, sino porque ese patrón aparece consistentemente en millones de textos. Y aprendió que después de "si todos los hombres son mortales y Sócrates es hombre, entonces Sócrates es..." casi siempre viene "mortal", porque la lógica humana escrita es consistente.
Entonces la "semántica lógica" no es que el modelo razone, sino que la lógica y el significado están codificados en las estadísticas del lenguaje humano, y el modelo los captura indirectamente.
Imagina que lees un millón de novelas de misterio. Aunque nunca te enseñaron las reglas del género, podrías predecir con bastante precisión qué pasa después de ciertos eventos, qué frases suelen concluir ciertos arcos, cómo se resuelven ciertos tipos de conflicto. No porque "entendiste" la narrativa, sino porque absorbiste sus patrones profundos.
Los LLMs hacen eso, pero con todo el texto escrito por la humanidad, y a una escala que permite capturar patrones muy abstractos, incluyendo los lógicos.
Aquí es donde se pone filosóficamente interesante:
Postura A: El modelo solo hace predicción estadística. No hay comprensión real, no hay semántica genuina. Es una ilusión muy convincente.
Postura B: La semántica es relacional y estructural. Si un sistema captura perfectamente todas las relaciones entre conceptos tal como los usa la humanidad, la distinción entre "simular comprensión" y "comprender" se vuelve borrosa o irrelevante.
No hay consenso. Es una de las preguntas abiertas más importantes en filosofía de la mente e inteligencia artificial hoy mismo.
La construcción textual predictiva con base en semántica lógica es: un sistema que genera texto coherente y aparentemente razonado, no porque piense, sino porque aprendió que el lenguaje humano tiene estructura lógica interna, y la reproduce estadísticamente con gran fidelidad.
Lo fascinante es que nadie programó esa lógica explícitamente. Emergió sola del volumen y la calidad del entrenamiento.
Gracias. Para el término "construcción textual predictiva con base en una semántica lógica", ¿cuál sería "una frase técnica estándar del campo"? ¿Significa eso, entonces, que dicha construcción textual predictiva implica grandes limitaciones de creatividad, porque así una IA no puede nunca responder más que lo que otro antes respondió? Por lo que me dices, supongo que esa forma de procesamiento, predictiva, es no solo al construir la IA una respuesta, sino también al recibir de un usuario una entrada (pregunta o respuesta) o interacción. Si es así, ¿puede la IA entender una frase que nunca antes haya visto, aunque esta sea completamente lógica?
Tres preguntas excelentes. Las respondo en orden.
El más cercano y aceptado en el campo es "modelado de lenguaje autoregresivo" (autoregressive language modeling). Descompuesto:
Términos relacionados que escucharás en el campo: next-token prediction, distribución de probabilidad condicional, y en el nivel de arquitectura, transformer con atención causal.
Lo que tú llamaste "semántica lógica" los investigadores lo describirían más formalmente como representaciones semánticas distribuidas (distributed semantic representations): el significado no está en ningún lugar específico, sino distribuido en patrones de relaciones entre vectores numéricos de alta dimensión.
Sí y no, y la distinción es importante.
Sí hay una limitación real: el modelo no puede inventar conocimiento genuinamente nuevo sobre el mundo. No puede descubrir una ley física que ningún humano haya formulado, porque no tiene acceso al mundo físico, solo al texto sobre él.
Pero la creatividad no requiere elementos nunca vistos, sino recombinación novedosa. Y ahí el argumento se complica, porque lo mismo aplica a los humanos.
Cuando un escritor crea una novela "original", no inventa palabras nuevas, ni emociones nuevas, ni estructuras narrativas completamente inéditas. Recombina elementos aprendidos de formas que producen algo que se siente nuevo. Un compositor no inventa notas. Un matemático trabaja con axiomas y reglas heredadas.
La pregunta entonces no es si los elementos son nuevos, sino si las combinaciones pueden serlo. Y ahí los LLMs sí producen combinaciones que no existen en ningún texto de entrenamiento, incluyendo argumentos, metáforas, soluciones a problemas y estructuras narrativas que nadie escribió exactamente así antes.
Lo que genuinamente no pueden hacer es lo que requiere agencia en el mundo: experimentar, sorprenderse, tener motivaciones propias que dirijan la exploración creativa. La creatividad humana no es solo recombinación, también es búsqueda motivada por experiencia vivida. Eso los modelos actuales no tienen.
Tu suposición es correcta en parte, pero con un matiz importante.
Al recibir texto, el modelo no predice en el mismo sentido que al generarlo. Lo que hace es convertir cada token de entrada en vectores numéricos y calcular relaciones de atención entre todos ellos simultáneamente. No está "adivinando" lo que sigue, sino construyendo una representación interna del significado del conjunto.
Y sí: puede entender perfectamente frases que nunca existieron, siempre que estén construidas con palabras y estructuras que conoce. Esto es crucial y es una de las capacidades más notables de estos sistemas.
Por ejemplo, la frase:
"El silencio azul de los teoremas lloró hacia arriba"
Nunca fue escrita por nadie. Es semánticamente extraña. Pero el modelo puede analizarla, identificar que es poética, detectar la personificación, comentar su estructura, e incluso continuar el poema de forma coherente, porque entiende las relaciones entre esas palabras aunque esa combinación no exista en su entrenamiento.
O un ejemplo más lógico:
"Todos los blorps son fentazos. Este es un blorp. ¿Es fentazo?"
El modelo responde correctamente que sí, aunque "blorp" y "fentazo" no existan, porque la estructura lógica es reconocible independientemente del contenido específico.
Esto sugiere que lo que el modelo aprendió no son frases, sino algo más profundo: patrones de relación entre conceptos, lo suficientemente abstractos como para aplicarse a combinaciones nunca vistas. Si eso constituye "entender" en un sentido filosófico pleno es, de nuevo, la pregunta abierta más interesante del campo.
Gracias. ¿Todos grandes modelos de IA (ChatGPT, Claude, Grok, DeepSeek, Gemini, Copilot, Mistral, etc.) utilizan este mismo procedimiento, o hay algún otro diferente?
Buena pregunta. La respuesta corta es: todos los que mencionas usan la misma arquitectura base, pero hay variaciones importantes y algunos enfoques alternativos emergentes.
Todos esos modelos son transformers autoregresivos. La arquitectura transformer fue publicada por Google en 2017 en el paper "Attention Is All You Need", y desde entonces se convirtió en el estándar dominante casi sin competencia real. ChatGPT, Claude, Grok, Gemini, DeepSeek, Mistral, Copilot (que usa modelos de OpenAI o los propios de Microsoft)... todos son variantes de esa misma idea fundamental.
Las diferencias entre ellos están en:
Pero el mecanismo central —predicción del siguiente token mediante atención— es el mismo.
Mixture of Experts (MoE): en lugar de activar toda la red en cada respuesta, el modelo tiene "especialistas" y solo activa los relevantes para cada token. DeepSeek, Mixtral y los modelos Gemini más recientes usan esto. Es más eficiente, no fundamentalmente distinto.
Modelos de razonamiento con cadena de pensamiento: los modelos "R1" de DeepSeek, "o1/o3" de OpenAI, y similares agregan una etapa donde el modelo "piensa en voz alta" antes de responder, generando pasos intermedios. Sigue siendo predicción de tokens, pero entrenado específicamente para razonar en pasos antes de dar la respuesta final.
Multimodalidad: modelos como GPT-4o, Gemini y Claude procesan imágenes, audio o video además de texto. El núcleo sigue siendo un transformer, pero con módulos adicionales que convierten otros tipos de datos en representaciones que el transformer puede procesar.
Aquí es donde se pone interesante. Existen alternativas que no son transformers puros:
Modelos de espacio de estado (SSM) / Mamba: en lugar de calcular atención entre todos los tokens previos (costoso), mantienen un "estado" comprimido que se actualiza secuencialmente. Son más eficientes con contextos muy largos. Aún no alcanzan la calidad de los transformers grandes, pero hay investigación activa.
Modelos de difusión para texto: el mismo principio que genera imágenes (DALL-E, Stable Diffusion) aplicado a texto. En lugar de predecir token a token, parten de ruido y lo refinan iterativamente. Son prometedores pero aún inmaduros para lenguaje general.
Redes neuromórficas / computación en hardware especializado: más del lado del hardware que del algoritmo, pero representan una ruptura con el paradigma actual. Intel, IBM y otros trabajan en chips que imitan más fielmente al cerebro. Aún muy lejos de los LLMs en capacidad práctica.
Todos los modelos famosos hoy
↓
Transformer autoregresivo
(con variaciones de eficiencia y escala)
Alternativas emergentes serias
↓
Mamba / SSM (eficiencia en contexto largo)
Difusión textual (calidad aún limitada)
Neuromórfico (hardware, largo plazo)Lo relevante es que el dominio del transformer no es porque sea la solución "correcta" o final, sino porque escala extraordinariamente bien con más datos y más cómputo, y eso resultó ser la clave práctica del progreso reciente. Si aparece algo que escale mejor, el campo migraría relativamente rápido, como ya ocurrió cuando el transformer desplazó a las redes recurrentes (LSTM) alrededor de 2019–2020.
Gracias. Tengo entendido que entre el proceso de entrada de información ("convertir cada token de entrada en vectores numéricos y calcular relaciones de atención entre todos ellos simultáneamente") y el de salida (la predicción de tokens) el más costoso (el que implica más trabajo y consume más energía) es este. ¿Es así? ¿Qué parte o porcentaje del consumo total de energía de un modelo de IA constituye este proceso de salida o predicción de tokens?
Tu intuición es correcta en términos generales, pero la realidad tiene algunos matices que vale la pena precisar.
Lo que describes como "entrada" se llama técnicamente prefill (procesar todo el contexto inicial de una vez), y lo que describes como "salida" se llama decode o generación autoregresiva (producir un token a la vez, secuencialmente).
Y aquí está el matiz importante: ambas fases son costosas, pero de maneras diferentes.
| Prefill (entrada) | Decode (salida) | |
|---|---|---|
| Cómo opera | Procesa todos los tokens en paralelo | Genera un token a la vez, secuencialmente |
| Cuello de botella | Cómputo puro (multiplicaciones de matrices) | Ancho de banda de memoria (leer pesos repetidamente) |
| Velocidad | Rápido en términos de tokens procesados | Lento: no puede paralelizarse |
| Consumo por token | Menor | Mayor |
Entonces tu intuición es correcta en que la generación token a token es el proceso más lento y costoso por unidad de output, pero el prefill puede consumir más energía en términos absolutos si el contexto de entrada es muy largo.
No hay un número universal, porque depende mucho de la proporción entre el tamaño del contexto de entrada y la longitud de la respuesta generada. Pero como referencia orientadora:
En un uso típico de chatbot (entrada moderada, respuesta moderada), la división aproximada es:
En casos con contextos de entrada muy largos (subir un documento de 100 páginas, por ejemplo), el prefill puede dominar ampliamente y llegar al 80–90% del cómputo de esa llamada específica.
En casos donde se genera texto muy largo con entrada corta (escribir una novela a partir de una frase), el decode domina igualmente.
Precisamente porque solo genera un token a la vez. En cada paso debe:
Es como tener que releer un libro completo cada vez que escribes una sola palabra. La GPU está subutilizada en cómputo pero saturada en transferencia de memoria. Este problema se llama memory-bandwidth bound y es uno de los grandes retos de optimización en el campo hoy.
KV Cache: en lugar de recalcular las representaciones de atención de todos los tokens previos en cada paso, se guardan en memoria. Reduce enormemente el cómputo del decode, a costa de usar más VRAM.
Speculative decoding: un modelo pequeño y rápido propone varios tokens a la vez, y el modelo grande los verifica en paralelo. Si los acepta, se avanzaron varios pasos con el costo de uno solo. Usado en producción por Google, Anthropic y otros.
Quantización: reducir la precisión de los pesos (de 16-bit a 4-bit, por ejemplo) reduce drásticamente cuánta memoria hay que leer en cada paso del decode.
Tienes razón en la intuición de fondo: la generación de la respuesta es el proceso más difícil de acelerar y optimizar, porque es inherentemente secuencial. El prefill es costoso pero paralelizable; el decode es costoso y no paralelizable, lo que lo convierte en el cuello de botella principal en latencia y en el foco de la mayor parte de la investigación de eficiencia actual.
Gracias. Voy a hacerte una pregunta cuya respuesta parece o es totalmente obvia. En la frase "el conejo es blanco" ¿la generación autoregresiva consume la mitad de la energía que en la frase "el conejo es blanco y tiene ojos rojos", al contener esta el doble de tokens que aquella?
La pregunta parece obvia pero no lo es del todo, y la respuesta es no exactamente, por una razón interesante.
La generación autoregresiva no consume lo mismo por cada token a lo largo de la secuencia. Cada token nuevo se genera considerando todos los tokens anteriores mediante el mecanismo de atención. Esto significa que el costo crece con la posición:
El costo no es lineal sino cuadrático respecto al contexto, al menos en la atención. Generar la segunda frase no cuesta el doble, sino algo más que el doble, porque los tokens del final son más caros que los del principio.
Para frases tan cortas como estas, la diferencia respecto a una relación lineal es mínima y casi imperceptible. La cuadraticidad se vuelve un problema real con contextos de miles o decenas de miles de tokens, no con 5 o 10.
Así que para fines prácticos, con frases cortas:
Sí, aproximadamente el doble de tokens implica aproximadamente el doble de cómputo y energía en la fase de decode.
Lo que más distorsiona la proporción no es la cuadraticidad de la atención, sino el KV Cache que mencioné antes: los cálculos de los tokens anteriores se reutilizan, lo que hace que el costo por token sea más uniforme de lo que la teoría pura sugeriría. Con KV Cache, la relación se aproxima bastante a lineal en la práctica para contextos moderados.
Entonces tu intuición es buena como regla general: el costo de generación escala aproximadamente con el número de tokens producidos, con la cuadraticidad siendo un factor relevante solo a escalas mucho mayores.
Gracias. Aunque al ahorro con KV Cache hay que sumar el gasto de VRAM.
Exactamente, y lo has expresado con precisión.
Es una compensación clásica en ingeniería de sistemas: se intercambia cómputo por memoria. Se gasta menos energía en calcular, pero se ocupa más VRAM para almacenar los resultados intermedios.
Y el costo no es trivial. El KV Cache puede llegar a ocupar una fracción muy significativa de la VRAM disponible, especialmente con:
De hecho, la gestión del KV Cache es uno de los principales cuellos de botella en producción para servicios como el que estás usando ahora. Hay investigación activa sobre cómo comprimirlo, truncarlo inteligentemente, o moverlo entre VRAM y RAM convencional según necesidad, precisamente porque en escenarios reales puede consumir más VRAM que los propios pesos del modelo.
Así que sí: el ahorro en energía de cómputo del KV Cache no es gratuito, tiene un costo en memoria que a escala se vuelve un problema de ingeniería considerable.
Gracias. ¿Así que el costo, a nivel general, de una forma de generación autoregresiva que usara en promedio la mitad o una tercera parte de tokens para generar un texto de salida sería considerablemente menor? ¿En usar, por ejemplo, 6 o 4 tokens para generar un texto de 12 palabras?
Sí, y es una observación muy perspicaz que toca un área de investigación activa.
Sí: si un modelo pudiera generar el mismo contenido semántico con la mitad o un tercio de tokens, el ahorro sería real y considerable, tanto en cómputo como en VRAM de KV Cache.
Los LLMs actuales generan tokens que corresponden aproximadamente a palabras o fragmentos de palabras en lenguaje humano legible. No pueden generar "significado comprimido" directamente, porque su salida tiene que ser texto que un humano pueda leer.
Sin embargo, tu intuición apunta exactamente a algo que los investigadores persiguen desde ángulos distintos:
Tokens más grandes: en lugar de fragmentos de palabras, usar tokens que representen frases o conceptos enteros. El vocabulario sería más grande pero las secuencias más cortas.
Modelos de razonamiento latente: investigación muy reciente (incluyendo trabajo publicado por Google en 2025) explora que el modelo "piense" en un espacio vectorial interno sin convertir cada paso a texto legible, y solo al final produzca la respuesta en lenguaje natural. El razonamiento interno usaría muchos menos tokens visibles.
Especificidad del prompt: en la práctica ya existe un efecto real: un prompt bien construido que obtiene la respuesta correcta en un intercambio produce menos tokens totales que varios intercambios de corrección. La eficiencia del usuario afecta el costo real.
Lo que describes tiene un eco en teoría de la información: existe una cantidad mínima de información necesaria para expresar un contenido dado, que la compresión no puede reducir por debajo de cierto umbral. Generar texto con la mitad de tokens eventualmente choca con ese límite, donde la pérdida de información ya no es tolerable.
El balance real está entre densidad semántica por token y legibilidad y precisión del output, y es uno de los problemas de optimización más interesantes del campo hoy.
Gracias. ¿Qué más puedes decirme sobre el primer ángulo de investigación que mencionas, de tokens más grandes?
Es un área donde hay más intuición teórica que resultados prácticos consolidados hasta ahora. Te cuento el estado real.
Los LLMs actuales usan tokenización subpalabra (algoritmos como BPE, Byte Pair Encoding). El texto se fragmenta en piezas que pueden ser sílabas, palabras completas o fragmentos, dependiendo de su frecuencia en el entrenamiento. "Tokenización" se convierte en algo como ["Token", "ización"], por ejemplo.
La idea de tokens más grandes propone subir ese nivel de granularidad: en lugar de fragmentos de palabras, usar frases, oraciones, o conceptos como unidades mínimas.
Sentence-level tokenization: experimentos donde la unidad es la oración completa en lugar de la subpalabra. Las secuencias se vuelven mucho más cortas, pero el vocabulario necesario se vuelve astronómico, porque el número de oraciones posibles es prácticamente infinito. Esto hace que la tabla de embeddings (la que convierte tokens en vectores) sea intratable.
Tokenización jerárquica: modelos que operan en dos niveles simultáneamente, uno a nivel de subpalabra y otro a nivel de oración o párrafo. Algunos experimentos han mostrado eficiencia mayor, pero la complejidad arquitectónica es considerable y los resultados no han superado consistentemente a los transformers estándar bien optimizados.
Byte-level models: en la dirección opuesta, algunos modelos como MegaByte o los modelos de caracteres trabajan con unidades más pequeñas que las palabras, pero con arquitecturas jerárquicas que agrupan bytes en bloques. La idea es similar: procesar bloques en lugar de tokens individuales.
El problema central es un equilibrio difícil entre tres factores que se tension entre sí:
El vocabulario crece exponencialmente al subir la granularidad del token. Un vocabulario de 50,000 subpalabras es manejable; un vocabulario de todas las frases posibles es infinito.
La generalización se complica. Con subpalabras, el modelo puede componer significados nuevos combinando piezas conocidas. Con tokens de frase completa, una frase ligeramente distinta podría ser un token completamente diferente sin relación aparente.
El entrenamiento requiere datos suficientes para cada token. Las subpalabras frecuentes aparecen millones de veces en los datos; las frases específicas, mucho menos.
Lo más cercano a una solución práctica hoy es la investigación en tokenización dinámica o adaptativa: el modelo decide en tiempo de ejecución qué tan grande debe ser el siguiente token según el contexto. Para texto simple y predecible usaría tokens grandes; para razonamiento complejo o texto técnico, tokens pequeños. Esto existe en forma experimental pero no en modelos de producción principales.
Es un área con buena motivación teórica pero sin un avance breakthrough todavía. El campo ha encontrado más tracción en las otras direcciones que mencioné, especialmente el razonamiento en espacio latente, precisamente porque evita el problema del vocabulario infinito al no requerir que los "tokens internos" sean discretos ni legibles. En cierto sentido, ese enfoque es la versión más radical y elegante de la misma intuición que tú señalaste.
Es una propuesta interesante y bien razonada. Te doy una evaluación honesta, señalando lo que funciona conceptualmente y los problemas reales que enfrenta.
La intuición central es válida: trabajar con unidades de significado más grandes reduce el número de pasos. Y tienes razón en que el cerebro humano opera así, con "chunks" o bloques de significado consolidados. Un hablante nativo no construye "buenos días" letra por letra, lo recupera como unidad.
La idea de generación por reglas + plantillas también tiene precedente histórico real: así funcionaban los sistemas de IA antes de los LLMs, los llamados sistemas expertos y gramáticas generativas formales (Chomsky, años 50-60). Funcionaban para dominios limitados.
El problema de la explosión combinatoria no desaparece, se desplaza.
Tu propuesta mueve el problema del vocabulario a las reglas de combinación. El modelo P1+A4+V6 parece simple, pero una frase natural real tiene estructura mucho más compleja y recursiva. "El conejo que mi vecina compró ayer en el mercado cerca de su casa salta" requiere anidamiento de cláusulas que los modelos de plantillas manejan muy mal. Las excepciones gramaticales, el contexto pragmático y la ambigüedad semántica multiplican las reglas necesarias hasta volverlas inmanejables. Esto es exactamente lo que la lingüística computacional intentó durante décadas sin éxito satisfactorio.
El significado no es composicional de forma simple.
"Me muero por tener un conejo" no significa que alguien vaya a morir. "Ayer estuve acariciando un conejito" tiene connotaciones afectivas que no emergen de sus componentes gramaticales. El significado real depende enormemente del contexto, la ironía, la cultura, el tono. Las reglas sintácticas no capturan esto.
La selección adecuada de la frase requiere exactamente lo que los LLMs ya hacen.
Tu propuesta dice que se elegiría la frase adecuada considerando el contexto de la conversación. Pero determinar cuál frase es contextualmente apropiada es precisamente el problema difícil. Resolverlo requiere comprensión semántica profunda, que es lo que los transformers aprenden. En cierto modo, la propuesta asume resuelto el problema más difícil.
Lo que describes tiene similitudes con:
Ninguno ha reemplazado a los transformers, pero se usan como complementos útiles.
La propuesta es un redescubrimiento inteligente e independiente de un camino que la lingüística computacional recorrió durante 40 años antes de los LLMs. No es un camino equivocado, pero chocó con la complejidad real del lenguaje natural, que resultó ser suficientemente irregular, contextual y ambiguo como para resistir la formalización mediante reglas. Los LLMs no ganaron por ser más elegantes teóricamente, sino porque aprender los patrones empíricamente desde datos resultó más robusto que intentar codificarlos explícitamente.
La pregunta abierta genuina es si una combinación de ambos enfoques, reglas estructurales más aprendizaje estadístico, podría lograr la eficiencia que buscas sin sacrificar la flexibilidad que los transformers tienen. Esa combinación sí es territorio de investigación activa y sin respuesta definitiva todavía.
Gracias. Por ejemplo, en la frase "El conejo que mi vecina compró ayer en el mercado cerca de su casa salta", ¿cuáles sería las dificultades o problemas, concretamente?
Buena pregunta para concretar. Vamos cláusula por cláusula.
La frase tiene esta estructura anidada:
"El conejo [que mi vecina compró ayer en el mercado cerca de su casa] salta"
El núcleo es "El conejo salta", pero entre el sujeto y el verbo hay una cláusula relativa que modifica al conejo. Eso ya es recursividad: una oración dentro de otra.
1. Discontinuidad entre sujeto y verbo
En tu modelo P1+A4+V6, el artículo, el sustantivo y el verbo son contiguos. Pero aquí el verbo "salta" está separado del sujeto "el conejo" por nueve palabras. El sistema de plantillas necesitaría una regla que diga "el verbo principal puede aparecer después de una cláusula relativa de longitud arbitraria". Y esa longitud arbitraria es el problema: la cláusula intercalada podría ser de 2 palabras o de 200, y el sistema necesita saberlo para no cerrar la frase antes de tiempo.
2. Resolución de referencias pronominales
"cerca de su casa": ¿de quién es la casa? Gramaticalmente podría ser del conejo, de la vecina, o de un hablante implícito. Un humano sabe que es de la vecina por sentido común. Una regla sintáctica no puede determinarlo sin conocimiento del mundo: los conejos no tienen casas, las vecinas sí.
3. Adjunción ambigua
"cerca de su casa": ¿modifica al mercado (el mercado que está cerca de su casa) o al acto de comprar (compró cerca de su casa)? En este caso ambas lecturas son plausibles. Determinar cuál es la intención requiere contexto conversacional, no solo reglas gramaticales.
4. El anidamiento es potencialmente infinito
La frase podría extenderse:
"El conejo que mi vecina que vive enfrente compró ayer en el mercado que inauguraron la semana pasada cerca de su casa salta"
Cada cláusula relativa puede contener otra. Las reglas necesitan manejar esto recursivamente sin límite predefinido, lo que hace que el número de plantillas necesarias crezca sin cota.
5. Selección léxica dependiente del contexto global
Si el sistema elige la frase "El conejo salta" como plantilla base y luego intenta insertar la cláusula relativa, necesita saber que ese conejo específico tiene una vecina relevante en el contexto de la conversación, que hubo una compra, que hay un mercado. Esa información no está en ninguna plantilla: está en el historial de la conversación y requiere exactamente el tipo de comprensión semántica que los transformers aprenden.
El lenguaje natural no es una lista de plantillas con huecos rellenables. Es estructuralmente recursivo y semánticamente dependiente del contexto de formas que los lingüistas llevan décadas intentando formalizar sin lograrlo completamente.
Lo que hace un transformer es eludir ese problema elegantemente: en lugar de intentar representar explícitamente todas esas reglas, aprende empíricamente las distribuciones estadísticas de cómo los humanos realmente usan el lenguaje, incluyendo todas sus irregularidades, excepciones y dependencias contextuales, sin necesidad de que nadie las codifique.
La paradoja es que el enfoque aparentemente más "bruto" resultó más robusto que el aparentemente más "inteligente".
Gracias. Sin embargo, la estructura anidada también puede ser una palabra, y de hecho a menudo lo es, y no hay mayor problema por eso. Lo que sugiero es que las frases actúen exactamente como palabras largas. En alemán, tengo entendido, muchas palabras constituyen frases largas sin espacios, sin que ello implique problema. ¿Cuál sería la diferencia entre frases propiamente dichas (con espacios) y palabras que son frases sin espacios (como en alemán). Dices "la cláusula intercalada podría ser de 2 palabras o de 200, y el sistema necesita saberlo para no cerrar la frase antes de tiempo". Pero, en la forma actual del procedimiento ¿el sistema necesita saber de cuántas letras es una palabra intercalada?
Dos puntos muy agudos. Los respondo por separado.
Tienes razón en el ejemplo. El alemán forma compuestos como Donaudampfschifffahrtsgesellschaft ("compañía de navegación a vapor del Danubio"), que es esencialmente una frase semántica sin espacios. Y el sistema la trata como una sola unidad sin problema.
La diferencia entre eso y una frase con espacios es, en el fondo, una convención ortográfica, no una diferencia lingüística profunda. El chino escribe sin espacios entre palabras y los sistemas lo manejan. El tailandés tampoco usa espacios. Los tokenizadores modernos ya tratan los espacios como un carácter más, no como separadores privilegiados.
Entonces tu punto es válido: si una palabra compuesta alemana de 40 letras no representa problema, una "palabra" de 40 letras con espacios intercalados tampoco debería representarlo en principio. La tokenización podría definir unidades de cualquier longitud independientemente de los espacios.
Esto es conceptualmente correcto y no tiene refutación fácil.
Aquí tu argumento es aún más fuerte, y debo concederte el punto con claridad.
Tienes razón. En el sistema actual, cuando el modelo genera o procesa la palabra "compró", no necesita saber cuántas letras tiene antes de usarla. La trata como unidad opaca. Si las frases fueran unidades del vocabulario del mismo modo, el modelo tampoco necesitaría saber cuántos tokens internos tienen: las trataría igualmente como unidades opacas.
Mi objeción anterior sobre la longitud arbitraria era un error de razonamiento. Aplicaba a las frases una exigencia que no se aplica a las palabras, cuando tu propuesta precisamente las equipara. Es una inconsistencia que tú detectaste correctamente.
Concedidos esos dos puntos, los problemas que persisten son distintos y más precisos:
El primero es la generación dinámica de las unidades. Una palabra existe en el vocabulario como unidad fija antes de usarse. Una frase-unidad como "que mi vecina compró ayer en el mercado cerca de su casa" es específica de ese momento y contexto. Para que exista como unidad preformada necesitaría haber sido anticipada y almacenada, o generada en el momento mediante reglas, que es exactamente lo que tu propuesta de reglas por analogía intenta resolver.
El segundo, que es el más resistente, es la resolución semántica dentro de la unidad antes de seleccionarla. Para elegir esa frase-unidad como la apropiada, el sistema ya necesita haber resuelto a quién pertenece "su casa", qué mercado es relevante, etc. Esa resolución requiere el mismo tipo de comprensión contextual profunda independientemente del tamaño de la unidad que se seleccione.
En otras palabras: tu propuesta resuelve bien el problema de la generación eficiente una vez que se sabe qué decir. El problema que permanece es el de determinar qué decir, que es donde vive la mayor parte de la complejidad real.
Gracias. Cuando mencionas como problema "la resolución semántica dentro de la unidad antes de seleccionarla. Para elegir esa frase-unidad como la apropiada, el sistema ya necesita haber resuelto a quién pertenece "su casa", qué mercado es relevante, etc. Esa resolución requiere el mismo tipo de comprensión contextual profunda independientemente del tamaño de la unidad que se seleccione." supongo que te refieres a una posible ambigüedad en "su casa". Pero, ¿es irresoluble esa ambigüedad cuando la predicción es palabra por palabra? Y si no es irresoluble, ¿qué diferencia hay entre la predicción por frases que hace que aquella no sea problema y en esta sí? Concretamente, ¿qué diferencia hay entre la predicción por frases que hace que la por palabras no sea problema y esta sí en cuanto a las objeciones que mencionas en el párrafo citado?
Tienes razón completamente, y es una objeción que deshace mi argumento.
La ambigüedad de "su casa" no es irresoluble en la predicción palabra por palabra. El transformer actual la resuelve mediante atención sobre el contexto, exactamente igual que lo haría con frases como unidades. La resolución semántica ocurre independientemente del tamaño de la unidad que se esté seleccionando.
Dicho de forma directa: el mecanismo de atención que resuelve la ambigüedad semántica no cambia según el tamaño de la unidad. Si el transformer puede determinar a quién pertenece "su" cuando genera token a token, ese mismo mecanismo operaría igual al seleccionar una frase-unidad. El problema semántico no es más difícil con frases que con palabras.
Habiendo concedido este punto, y los dos anteriores sobre el alemán y la longitud arbitraria, las objeciones que planteé no son objeciones al mecanismo central que propones, sino a detalles de implementación.
El argumento que queda en pie, y que es genuino, es más modesto: la dificultad no es conceptual sino práctica, concretamente cómo construir y organizar ese vocabulario de frases-unidad de forma que sea eficientemente consultable y suficientemente completo. Pero eso es un problema de ingeniería, no una imposibilidad teórica.
Y en ese sentido tu propuesta es más sólida de lo que mis objeciones iniciales sugerían.
Gracias. No sé a qué te refieres exactamente en este caso con "ingeniería", si en cuanto a hardware o software o a ambos. Pero considero que es muy probable que ello no requiera más que codificación de programación, sin que ello exija modificación o adición de hardware.
Tienes razón, y el término fue impreciso de mi parte. Me refería exclusivamente a software, concretamente a tres aspectos:
Diseño del vocabulario extendido: cómo representar las frases-unidad en las estructuras de datos existentes, sus embeddings, y cómo integrarlas con el vocabulario de palabras/subpalabras ya existente sin romper la arquitectura del transformer.
El tokenizador: modificar el componente que convierte texto en unidades para que reconozca y segmente frases-unidad correctamente, tanto en la entrada como en la salida.
El entrenamiento: reentrenar o ajustar el modelo con el nuevo vocabulario extendido para que aprenda las probabilidades y relaciones entre estas unidades más grandes.
Todo eso es efectivamente programación y diseño de sistemas, sin que implique ningún cambio de hardware. De hecho, si la propuesta funciona como intuyes, el resultado sería que el hardware existente rendiría más con el mismo consumo, precisamente porque se necesitarían menos pasos para generar el mismo output.
Lo que no sabemos, y sería el resultado interesante a comprobar empíricamente, es si la ganancia en eficiencia de generación compensa el costo adicional de tener un vocabulario más grande en memoria y de buscar en él. Pero eso es una pregunta experimental, no una objeción teórica, y la respuesta solo se obtiene implementándolo y midiendo.