Buenas, esto es BIMPRAXIS, el podcast donde el
BIM se encuentra con la inteligencia artificial.
Exploramos la ciencia, la tecnología y el futuro
desde el enfoque de la arquitectura, ingeniería y
construcción.
¡Empezamos!
Muy buenas, bienvenidas, bienvenidos a un nuevo episodio
de BIMPRAXIS.
Hoy os traemos el revolucionario coste de IA
por kilovatio.
¿Estáis listos?
Pues entramos en materia.
Bueno, a ver, imaginemos por un momento una
situación.
Te escucho.
Le pedimos a un modelo de inteligencia artificial
que reescriba por completo una base de código
inmensa.
Que eso ya de por sí es un
reto importante.
Exacto.
Le exigimos que la lea una y otra
vez, analizando la arquitectura, proponiendo cambios y procesando
casi 20 millones de palabras de ida y
vuelta.
Una barbaridad de datos, o sea, un volumen
industrial.
Pues fíjate, la locura es que, al terminar,
la factura final que llega es literalmente lo
que cuesta un café solo.
¡Madre mía!
Sí, sí, unos 2 dólares con 70 centavos.
Y, a ver, esto no es un escenario
de ciencia ficción para la próxima década.
No que va.
Principalmente porque rompe con todo lo que asumíamos
sobre la economía de la computación.
O sea, con las reglas básicas.
Totalmente.
Normalmente, en este sector, pues, debatimos sobre teorías
abstractas o proyecciones a 5 años vista.
Pero lo que tenemos sobre la mesa hoy
son facturas reales.
Dinero de verdad.
Exacto.
Desarrolladores independientes que están operando con márgenes de
coste que, a primera vista, parecen un fallo
flagrante en el sistema de facturación del proveedor.
O sea que parece que se han equivocado
al cobrarles.
Eso es.
Y claro, para comprender el terremoto que esto
supone, necesitamos destripar cómo interactúan, pues, la física
del hardware, la eficiencia del software y un
modelo comercial que, fíjate, desafía directamente a los
gigantes de Silicon Valley.
Pues vamos a empezar por el origen del
revuelo, porque el contexto aquí lo es todo.
¿Qué es lo que se está haciendo?
Es un proyecto de Reddit, concretamente en la
comunidad OpenCodeKlee.
Un desarrollador que utiliza el seudónimo Purplenipis compartió
una captura de pantalla de su uso diario
que dejó a todo el mundo boquiabierto.
No es para menos, claro.
Es que este usuario estaba trabajando con el
modelo GLM 5 .2 utilizando una herramienta que
se llama OpenCodeCode y el objetivo era sumamente
intensivo.
Sí, querían refactorizar un proyecto personal de tamaño
medio, ¿verdad?
Exacto.
Usando una habilidad técnica muy especializada.
Una habilidad específica llamada Improved Codebase Architecture que
fue diseñada originalmente por Matt Pocock.
Claro, y eso es importante recalcarlo.
Sí, porque no le estaba pidiendo a la
IA que escribiera un simple bloque de texto,
¿no?
¿Qué va, qué va?
Le estaba exigiendo que iterara sobre una arquitectura
de código compleja, evaluando dependencias, reestructurando toda la
lógica profunda de la aplicación.
Y ese tipo de tareas, a ver, tradicionalmente
es un pozo sin fondo por el consumo
de tokens.
Claro.
Si pides a un modelo que mejore una
arquitectura completa, no puedes simplemente mirar el archivo
suelto en el que estás trabajando.
Tiene que ver la foto grande.
Exactamente.
Tiene que cargar en su memoria el contexto
entero del proyecto.
Y cada vez que hace un pequeño ajuste,
necesita releer y revaluar cómo ese cambio afecta
al resto del ecosistema de tu código.
O sea, un proceso iterativo masivo.
Sí, sí.
Y los números que reporta este usuario en
Reddit reflejan exactamente esa carga de trabajo.
Hablamos de 19 ,2 millones de tokens consumidos,
en un solo día de desarrollo.
Yo me quedé impactada.
Quiero que nos detengamos un momento en ese
número para dimensionarlo correctamente.
Consumir 19 millones de tokens por menos de
tres dólares es, a ver, es una escala
de asimilación de datos casi absurda.
Sí.
Sería el equivalente a entrar en la biblioteca
central de una gran universidad, pedirle a un
asistente que devore absolutamente todos los libros de
la sección de ingeniería informática en segundos.
Madre mía, la imagen es buena.
Es de toda esa información para reescribir tu
propia tesis doctoral desde cero.
Y al salir, pues dejarle unas monedas de
propina.
Es que es tal cual.
Es un volumen que rompe nuestros esquemas actuales.
De hecho, el propio usuario hizo la comparativa
usando los precios estándar del mercado a través
de Open Router para ese mismo modelo, el
GLM 5 .2.
¿Y cuánto salía ahí?
Pues en un escenario tradicional, esa misma refactorización
habría costado unos ocho dólares con tres centavos.
Guau.
Y eso asumiendo que los precios de Open
Router ya son competitivos, claro.
Claro, claro.
Además, un aspecto crucial que menciona este desarrollador
es la percepción de la calidad y la
velocidad.
Ajá, porque si es barato pero lento, no
sirve de mucho.
Exacto.
Pero empíricamente, este usuario compara la experiencia de
usar este modelo en esta plataforma con correr
Opus 4 .6 en alto.
O sea, niveles máximos de rendimiento.
Eso es.
No estamos ante un servicio de bajo coste
que tarda minutos en hacer o que te
devuelve un código inservible.
Y fíjate, cuando el coste de la inferencia
de alta calidad se desploma de esta manera,
la viabilidad matemática de cómo construimos software cambia
radicalmente.
O sea, ya no tienes miedo a equivocarte.
Exacto.
El desarrollo asistido por IA deja de ser
una consulta quirúrgica y súper cuidadosa para no
gastar presupuesto.
Claro, que antes lo pensabas dos veces antes
de darle al intro.
Totalmente.
Se convierte en un motor contimo de prueba
y error.
Puedes pedirle al modelo que genere 20 versiones
diferentes de un mismo módulo, descartar 19 y
no sentir que estás quemando billetes.
Pero claro, semejante descuento monumental nos surge por
arte de magia.
A ver, las empresas no regalan capacidad de
computo.
No, desde luego.
Tiene que haber una mecánica técnica muy afinada
que sostenga esto financieramente.
Y si miramos el desglose exacto de esos
19 millones de tokens en la factura de
nuestro protagonista, encontramos la primera revelación.
A ver.
Resulta que 17 millones de esos tokens fueron
etiquetados como tokens de entrada en caché.
Ajá, ahí está la clave.
Solo 1 ,9 millones fueron de entrada regular
y apenas 192 .900 fueron de salida.
Un contraste brutal.
Es que otros usuarios en el mismo hilo,
como uno llamado Luke, reportaban tasas de acierto
de la caché de entre el 89 y
el 94 por ciento.
Confieso que esas cifras me parecen magia negra.
Es normal que te lo parezca.
¿Qué es exactamente esta caché a nivel técnico
y cómo logran un porcentaje de acierto tan
salvaje?
Bueno, la explicación reside en cómo funciona la
memoria a corto plazo de estos modelos, lo
que conocemos como la caché KV o Key
Value Catch.
¿Vale?
Usemos una analogía del mundo de la alta
cocina para que se entienda mejor.
Me gusta.
A ver.
Imagina que un chef con estrella tiene que
preparar un plato extremadamente complejo.
Si cada vez que le piden el plato
tiene que ir a la huerta a recoger
las verduras, lavarlas, cortarlas y preparar las salsas
base desde cero, el tiempo y el esfuerzo
son enormes.
Inviables para un restaurante, claro.
Eso sería procesar tokens regulares.
Pero ¿qué pasa si tiene un equipo de
ayudantes que ya ha preprocesado, pesado y ordenado
todos los ingredientes en la mesa de trabajo?
Pues que el chef solo tiene que ejecutar
la receta final.
Exacto.
La caché KV hace exactamente eso con el
contexto matemático del código.
Entiendo.
Entonces, como la base de código del proyecto,
digamos, no cambia en su gran mayoría entre
una petición y la siguiente.
El sistema no la vuelve a leer.
Exactamente.
Al refactorizar, el contexto principal, o sea, los
cientos de archivos de tu proyecto, pues permanece
estático.
Lo único que cambia es el pequeño prompt,
¿no?
La instrucción específica de ese momento.
Eso es.
NeuralWatt, que es la plataforma detrás de esto,
es un sistema avanzado que guarda esa representación
matemática ya precomputada de los archivos en la
memoria de las tarjetas gráficas.
Ya veo.
Cuando tú envías la siguiente petición, el sistema
reconoce que el 90 por ciento del contexto
es idéntico al de hace dos segundos y
recupera ese plato preparado instantáneamente y sólo invierte
esfuerzo computacional real en calcular la respuesta nueva.
Por eso facturan esos 17 millones de tokens
a una fracción ridícula del precio normal.
El servidor apenas sudó para procesarlos.
Vale.
El caché justifica una enorme reducción del esfuerzo.
Sí, pero al indagar en la documentación técnica
de NeuralWatt Cloud hay otra pieza fundamental de
la que presumen para bajar los costes y
es la cuantización FP8.
Así eso es vital.
Dicen que reducen la precisión de los cálculos
de coma flotante de 16 bits a 8
bits para literalmente cortar por la mitad el
ancho de banda de memoria necesario.
Correcto.
Y aquí tengo que hacer un poco de
abogada del diablo.
Adelante, adelante.
En el foro de Reddit, usuarios como Longjumpingpush351
defienden que en tareas de programación la caída
de calidad por usar FP8 es apenas perceptible.
Y a ver, me cuesta creer que recortar
la precisión a la mitad no afecte al
resultado.
Es una duda muy lógica.
¿Es esto un hecho técnico real o los
desarrolladores simplemente se están conformando con un código
mediocre porque es tan barato que pueden pedirle
a la IA que lo arregle luego?
Pues mira, es una pregunta buenísima.
Y toca el corazón de cómo las redes
neuronales procesan diferentes tipos de información.
A ver, ilumínanos.
Para entender la cuantización FP8, pensemos en la
diferencia entre una fotografía en formato RAW de
altísima resolución y una imagen JPG ligeramente comprimida.
Vale.
Si estás fotografiando una puesta de sol con
miles de degradados de color supersutiles, la compresión
JPG destruye esa belleza.
¿Ves cómo va?
Tienes bandas de color abruptas, ¿verdad?
Sí, claro, se pixela todo.
Eso equivaldría a pedirle a la IA que
escriba poesía compleja o literatura muy emocional.
Ahí sí necesitas la máxima precisión, los 16
bits, para captar los matices del lenguaje humano.
Ya, pero el código informático no es un
atardecer.
Exacto.
El código es más bien como un plano
arquitectónico.
Es verdad, es pura lógica.
Es como un mapa de carreteras o un
plano en blanco y negro.
Si tú comprimes un plano arquitectónico JPG, las
líneas siguen estando claras.
Una puerta sigue siendo una puerta y un
muro es un muro.
Increíblemente rígida y estructurada.
Una llave de cierre o un bucle condicional
no requieren de sutilezas poéticas.
Por tanto, reducir la precisión matemática de los
pesos neuronales de 16 a 8 bits ahorra
una cantidad colosal de memoria y energía en
los servidores.
¿Y el modelo sigue siendo perfectamente capaz de
seguir la lógica de la programación?
Eso es.
Además, sacrificar esa precisión permite mantener mucha más
cantidad de código en esa caché ultra rápida
de la que hablábamos.
Es un intercambio técnico brillante para este caso
de uso en concreto.
Viéndola así, la verdad es que tiene una
lógica aplastante.
Optimización matemática por un lado, más una gestión
de memoria inteligente por otro.
Así es.
Pero, a ver, por mucha tecnología que haya
detrás, el verdadero terremoto, lo que hace que
estemos analizando todo esto hoy, es su modelo
de negocio.
Totalmente.
Ahí está la disrupción real.
Y aquí es donde la propuesta de NeuralWatt
Cloud se vuelve verdaderamente rompedora.
Se presentan como la primera API de inferencia
de IA con precios basados en energía.
¡Qué locura!
Están cobrando 5 dólares por kilowatt y hora
consumido por sus servidores.
Ni rastro de los clásicos precios por millón
de tokens.
Y yo me pregunto, ¿por qué la industria
adoptó el precio por token en primer lugar,
si ahora resulta que facturar por energía es
más justo?
Bueno, la historia del precio por token nace
de una necesidad de abstracción, básicamente.
De hacerlo más fácil para el cliente.
Claro.
Cuando OpenAI y otros pioneros lanzaron sus primeras
APIs, necesitaban una métrica que el usuario final
pudiera entender y predecir de forma sencilla.
Un token, que equivale más o menos a
tres cuartas partes de una palabra, pues era
una unidad fácil de calcular.
Era como un puente psicológico entre el texto
humano y el cálculo de la máquina.
Exactamente.
Pero claro, el token siempre fue un parche,
un representante muy imperfecto del verdadero coste real.
Porque entiendo que no todos los tokens exigen
el mismo esfuerzo físico a la máquina, ¿no?
Efectivamente.
Generar un token para la palabra hola en
un saludo básico casi no consume ciclos de
procesador.
Es pan comido.
Pero generar un token que resuelve un problema
matemático complejo o que requiere conectar conceptos a
lo largo de 100 páginas de contexto.
Claro, ahí la cosa cambia.
Hace que las tarjetas gráficas de los servidores
trabajen al máximo, consumiendo picos masivos de electricidad.
Y al unificarlo todo bajo un precio por
token, los proveedores de la nube estaban promediando
los costes.
O sea que unos subsidiaban a otros.
Eso es.
NeuralWatt elimina esa abstracción por completo.
Prometen una transparencia energética del 100 por ciento.
Si tu petición es fácil, el servidor consume
poca electricidad y pagas poquísimo.
Y si tu petición es compleja, ¿pagas más?
Claro.
Pero siempre pagas por el estrés físico real
del servidor, no por un margen de beneficio
arbitrario que esté escondido detrás de una palabra.
Fíjate, para visualizar bien este cambio de paradigma
comercial, imaginemos una panadería tradicional.
Me gustan tus analogías.
A ver.
El estándar de la industria hasta ahora ha
sido entrar a la panadería y pagar un
precio fijo por cada rebanada de pan que
te llevas.
Ajá.
Al panadero le da exactamente igual.
Si para hacer esa rebanada ha usado una
amasadora industrial gigante durante horas o si lo
ha hecho a mano en dos minutos, te
cobra la rebanada a precio fijo.
Tal cual.
Pues el modelo de Neural Watt es como
decirle al panadero oye, no te voy a
pagar por la cantidad de pan que salga.
Te voy a conectar un medidor eléctrico al
horno y a la amasadora y te pagaré
exclusivamente por la electricidad que consuman tus máquinas
mientras trabajas para mí.
Espectacular.
Si resulta que con muy poca electricidad puedes
sacar 50 barras de pan porque eres super
eficiente, el beneficio de ese ahorro me lo
llevo yo como cliente.
Es una analogía perfecta, la verdad.
Y la razón por la que Neural Watt
se atreve a conectar ese medidor eléctrico de
cara al público es porque saben de sobra
que tienen unas máquinas increíblemente eficientes.
Están muy seguros de sí mismos.
Es que afirman ser un 40 por ciento
más eficientes energéticamente que la media del sector.
Tela.
Y ojo, no sólo en coste, sino también
en velocidad.
Su documentación oficial, que es la de la
tienda, es la de la tienda.
Su documentación oficial refleja una mediana de tiempo
hasta el primer token, lo que en la
industria se llama TTFT, inferior a los 50
milisegundos.
O sea, medio segundo.
Es prácticamente instantáneo desde que pulsas la tecla
de intro.
Exacto.
Pero claro, al revisar cómo logran esa velocidad
extrema, la documentación te lanza una pared de
jerga técnica brutal.
Hablan de VLMM, de procesamiento por lotes continuo
o continuos batching y de paralelismo tensorial.
Suena súper intimidante, sí.
Impresionante, pero necesitamos aterrizar todo esto.
¿Qué significan realmente estas arquitecturas en las tripas
de un centro de datos?
Pues bajémoslo al mundo físico.
Empecemos por el procesamiento por lotes tradicional.
Imagina que los servidores son como autobuses urbanos.
Vale.
En los sistemas antiguos, el autobús esperaba en
la parada hasta que se llenaba de pasajeros,
es decir, de peticiones de los usuarios.
Cerraba las puertas y hacía el trayecto entero
antes de volver a abrir.
O sea, que si era ser el primer
pasajero en subir, tenías que esperar ahí sentado
a que se llenara el autobús.
Exactamente.
Una pérdida de tiempo, pues el procesamiento por
lotes continuo, el continuous batching, cambia ese autobús
por un remonte de esquí continuo.
Ah, qué buena imagen mental.
Las peticiones de los usuarios se suben y
bajan de la tarjeta gráfica constantemente, en tiempo
real, sin esperar a que otros terminen.
Nadie espera.
Por eso el tiempo de respuesta baja a
esos segundos.
Clarísimo.
¿Y qué hay de lo del paralelismo tensorial?
Porque la palabra tensor, a ver, siempre impone
un poco de respeto.
Sí, sí impone.
A ver, el paralelismo tensorial soluciona un problema
puramente de tamaño.
Cuéntame.
Imagina que tienes que transportar un bloque de
piedra de 100 toneladas, pero tus camiones sólo
aguantan 20 toneladas cada uno.
Evidentemente no puedes meter la piedra en un
solo camión.
Eso es.
El paralelismo tensorial es la capacidad de transportar
ese bloque matemático en pedazos perfectos, poner cada
pedazo en un camión distinto, que en este
caso serían múltiples tarjetas gráficas, y hacer que
todos esos camiones conduzcan a la misma velocidad
milimétrica para que el sistema funcione como un
solo motor gigante.
Porque cuando tienes modelos de IA enormes, claro,
no caben en un solo chip.
Imposible.
Tienes que dividirlos y hacerlos sin perder velocidad.
Es un prodigio absoluto de la ingeniería.
Totalmente.
Pero claro, todo esto suena a una infraestructura
colosal, y esto me hace pensar que, a
ver, no montas un sistema de remonte continuo
y transporte de 100 toneladas simplemente para que
desarrolladores independientes se ahorren unos dólares en sus
proyectillos de fin de semana, ¿no?
Desde luego que no.
Tiene que haber una estrategia corporativa a gran
escala detrás de esto.
Sí la hay.
Y revisando la documentación, la verdad es que
se ve claramente.
NeuralWatt no es solo una API suelta.
Han desplegado todo un ecosistema con tres pilares.
Exacto.
Han diseñado una arquitectura pensada para colorizar el
mundo empresarial.
Cuéntanos.
El primer pilar es NeuralWatt Cloud, que es
el servicio alojado en la nube que utilizó
nuestro usuario de Reddit, ¿no?
La solución rápida y accesible para cualquiera.
Vale.
Pero el segundo pilar es donde la cosa
se pone seria de verdad.
NeuralWatt Deploy.
Ajá, para empresas.
Esto permite a las grandes corporaciones llevarse toda
esta magia de optimización de energía e instalarla
directamente en sus propios centros de datos.
En sus servidores privados.
Garantizando la seguridad y el control absoluto de
sus datos corporativos.
Exacto.
Lo que se conoce como infraestructura on -premise,
que es vital para sectores como la banca
o la sanidad.
Lógico.
¿Y cuál es el tercer pilar?
El tercer pilar es el cerebro subyacente de
todo.
NeuralWatt Optimize.
Ah, el software de control.
Eso es.
Es el motor de software que regula el
consumo de electricidad en tiempo real de esas
tarjetas gráficas.
Hace como malabarismos constantes entre el rendimiento que
exige el modelo de IA y el voltaje
que se le inyecta al procesador.
Buscando siempre el punto de máxima eficiencia, supongo.
Exactamente.
Y aseguran que logran ahorrar enormes cantidades de
energía con una penalización en el rendimiento, fíjate,
inferior al cero con un por ciento.
O sea que el ahorro no sacrifica ni
la velocidad ni la calidad para nada.
Nada.
Es imperceptible.
Y creo que esa mínima penalización va a
ser crucial para lo que viene.
Porque está claro que no estamos estancados en
los modelos actuales.
Esto avanza muy rápido.
La propia NeuralWatt anuncia en su web una
lista de futuros modelos soportados que la verdad
da bastante vértigo.
Sí, sí.
Hablan del inminente Devstral 2 de 123 .000
millones de parámetros de Mistral, el Yema 4
de 31 .000 millones o el gigantesco GPTOS
de 120 .000 millones.
Monstruos.
Son auténticos monstruos.
Y a medida que escalamos a estos titanes,
la pura fuerza bruta eléctrica se mete en
el problema central de todos.
Ya no se trata sólo de quién tiene
el modelo más listo, sino de quién puede
mantener los servidores encendidos sin ir a la
bancarrota.
Has dado en el clavo.
Ese es el verdadero campo de batalla de
la próxima década.
Históricamente, el cuello de botella era el acceso
al conocimiento, el conseguir los pesos matemáticos del
modelo.
Claro.
Hoy, la tendencia hacia el código abierto está
democratizando el acceso a modelos excepcionales.
Cualquiera puede tenerlos.
La barrera de entrada ya no es el
software.
Ahora es puramente el hardware y la factura
de la luz.
Madre mía.
Las empresas que puedan ofrecer la inferencia más
eficiente por vatio consumido van a ser las
que dominen la infraestructura del futuro.
Y ojo, porque están empujando esta adopción de
forma súper agresiva desde las trincheras.
Ya te digo.
Volviendo al hilo de Reddit que originó todo
esto, se veía claramente cómo fomentan el boca
a boca entre los usuarios.
Sí, con los programas de referidos.
Exacto.
Por ejemplo, un usuario llamado Aotrex le decía
al autor original que si hubiera usado su
código de referidos, ambos habrían ganado saldo.
Concretamente, ofrecen un sistema donde si gastas 10
dólares, te regalan otros 10 y el que
te invitó se lleva 20.
Es un incentivo brutal.
Sumado a un crédito inicial de 5 dólares
solo por crear la cuenta de prueba.
Están inyectando capital real directamente en los bolsillos
de los desarrolladores para obligarlos, las compañías, a
probar el sistema.
Y está funcionando, claro.
Vaya que sí.
En ese mismo foro, usuarios como Milquipidia expresaban
su angustia existencial.
Y lo digo en serio, porque con su
plan de suscripción actual, el Zeta .ai Lite,
estaban quemando 340 millones de tokens a la
semana.
Qué barbaridad.
Una necesidad absoluta de supervivencia financiera.
Totalmente.
Y esto nos plantea una disyuntiva fascinante para
los gigantes tecnológicos internacionales.
A ver.
Porque las grandes empresas de IA han construido
imperios enteros basados en modelos de suscripción mensual
o facturación por volumen de tokens, ¿verdad?
Sí.
Estos modelos, que son típicos del software como
servicio, están diseñados para generar ingresos recurrentes, altamente
predecibles.
Lo cual, claro, encanta a los inversores de
Wall Street.
Todo cuadra a final de mes.
Pero a menudo ocultan el hecho de que
los usuarios que apenas usan el servicio están
de alguna manera subsidiando los inmensos costes de
computación de los superusuarios.
La facturación por energía expone la cruda realidad
del coste del hardware.
Obliga a una transparencia total en el mercado.
Exacto.
Lo cual me lleva a la gran pregunta
de la industria que quería hacerte.
Si esta migración hacia el pago por kilovatio
gana tracción masiva entre los desarrolladores pesados, ¿crees
que los titanes de la industria se verán
obligados a abandonar sus opacos multiplicadores por token
y adoptar métricas estrictas de consumo eléctrico?
Porque de ser así, sus márgenes de beneficio
podrían sufrir un impacto monumental.
Pues mira, van a resistirse todo lo que
puedan.
De eso no hay duda.
Yo también lo creo.
Desmontar un modelo de precios opaco pero inmensamente
rentable es algo que ninguna corporación va a
hacer voluntariamente.
Obvio.
Pero, claro, si competidores como NeuralWatt logran demostrar
que escalar modelos de 120 .000 millones de
parámetros es viable pagando solo el coste de
la electricidad más un pequeño margen, el mercado
corporativo forzará el cambio.
Las propias empresas lo van a exigir.
Exacto.
Las direcciones financieras de las grandes empresas que
compran estos servicios van a exigir auditorías del
coste real por vatio y no estarán dispuestas
a seguir pagando ese impuesto del token si
pueden evitarlo de alguna manera.
Es que es asombroso observar el clásico efecto
mariposa de la tecnología desplegándose justo ante nuestros
ojos.
Comenzamos analizando un simple pantallazo en un foro
donde alguien celebraba haberse gastado menos de lo
que cuesta un café.
Ya.
Y al tirar del hilo nos encontramos con
que una optimización de memoria mediante cuantización FP8,
sumada a la eficiencia del procesamiento por lotes
continuo, ha dado a luz a un modelo
de negocio que amenaza con reestructurar literalmente cómo
se comercializa el intelecto sintético a nivel mundial.
Es una pasada, sí.
Para quienes construyen software hoy en día, esto
significa acceder a un nivel de experimentación e
iteración que era financieramente prohibitivo hace solo unos
meses y eso, fíjate, nos empuja hacia una
reflexión ineludible que quiero dejar hoy en el
aire para que le demos una vuelta.
A ver, cuéntanos si la capacidad computacional necesaria
para analizar, reescribir y optimizar arquitecturas enteras de
software pasa a costar meros céntimos gracias al
uso inteligente de cachés y a la facturación
energética.
Sí, cabe preguntarnos dónde residirá el verdadero valor
del profesional de la tecnología en el próximo
lustro.
Wow, buena pregunta.
Todo apunta a que vamos a asistir a
una evolución muy profunda.
El trabajo diario dejará de centrarse en ser
un escritor de código meticuloso.
Claro, porque eso ya lo hará la máquina
casi gratis.
Exacto.
La labor fundamental será la de actuar como
un gestor de flujos de energía y un
orquestador de contexto masivo.
Qué potente.
Es un horizonte apasionante, la verdad, y desafía
las bases mismas de lo que consideramos trabajo
intelectual de alto valor hoy en día.
Pues con esa reflexión final nos vamos a
quedar hoy.
Antes de despedirnos hasta el próximo programa, os
informamos de que las voces que oyes han
sido generadas por la IA de Notebook LM
y que dirigiendo el podcast se encuentra Julio
Pablo Vázquez, un humano que te envía saludos.
En caso de error, probablemente sean errores humanos.
Nos escuchamos.
Y hasta aquí el episodio de hoy.
Muchas gracias por tu atención.
Esto es BIMPRAXIS.
Nos escuchamos en el próximo episodio.