El domingo abrí mis marcadores y vi una tabla de competidores para rutas de IA on-chain que copié hace medio año. La cantidad de modelos que colgó cada empresa varía desde cifras de dos dígitos hasta de tres. De paso, abrí el panel on-chain de @OpenGradient . El Model Hub ya alojaba más de 4.500 modelos: era varias veces la suma de todos los proyectos de aquella tabla. No me apresuré a asombrarme; quería confirmar si ese volumen realmente tenía capacidad para soportar carga, o si solo estaban colgados un montón de archivos vacíos que nunca se habían llamado.
Elegí una semana laboral de cinco días y saqué, desde el Model Hub, los modelos que habían sido invocados ese día en cuatro dimensiones: el hash del peso, la distribución de nodos de alojamiento, los registros de planificación del middleware de enrutamiento de capacidades y los acuses de recibo de la Verification Layer. Cada día tomé doce muestras; así, con sesenta conjuntos de datos, en cada caso verifiqué una por una en la tabla el tiempo de subida, la latencia de la primera invocación y la firma del acuse. El resultado fue bastante limpio: dentro de esos más de 4.500 modelos, una parte considerable tuvo tráfico real en la semana previa; incluso la cola larga pudo levantarse con un arranque en frío.
Las discusiones populares sobre el número de modelos alojados se enfocan casi por completo en la comparación de cantidades. La diferencia que de verdad puede verificarse en OpenGradient es más fría: el volumen no está hecho solo de un contador de cargas. Cada juego de pesos se divide en rebanadas y se guarda en Walrus; al invocarlo, el middleware de enrutamiento de capacidades lo recompone según la disponibilidad, y la Verification Layer lo sella. Para colgarlo hay que vincular capacidad de almacenamiento; para invocarlo, tiene que dejar huella en el acuse. El costo de “actualizar datos” es incluso mayor que el de “hacer trabajo”. Cuatro mil quinientos es un conjunto de carga real, no una frase en una tabla.
También hay que cambiar el indicador de observación. No me fijo en cuántos modelos acumula OpenGradient colgados; miro un dato contrario al consenso: la proporción de modelos que, al menos una vez por semana, se activan con una invocación real y de pago, y que además dejan un acuse en la Verification Layer. El primero mide el ingreso al repositorio; el segundo mide si esta capa de alojamiento realmente está siendo usada por desarrolladores.
Si $OPG solo está como comisión de emparejamiento por una invocación de modelo, entonces se parece más a un token de cobro por llamadas; pero si en el futuro la capacidad alojada se pignora, hay incentivos por arranque en frío, se emiten acuses, se reparte la cola larga, y hasta el desalojo y las multas por modelos zombis giran alrededor de ese mecanismo, entonces ya no cumple la función de token de cobro, sino la de un activo de crédito de capacidad en esta red de alojamiento de modelos.
No saco conclusiones apuradas. La ventaja de volumen solo cuenta si se valida repetidamente en la cola larga; estoy dispuesto a seguir observando las muestras que OpenGradient en su red principal y las partes posteriores entreguen al conectarse.
#opg
Elegí una semana laboral de cinco días y saqué, desde el Model Hub, los modelos que habían sido invocados ese día en cuatro dimensiones: el hash del peso, la distribución de nodos de alojamiento, los registros de planificación del middleware de enrutamiento de capacidades y los acuses de recibo de la Verification Layer. Cada día tomé doce muestras; así, con sesenta conjuntos de datos, en cada caso verifiqué una por una en la tabla el tiempo de subida, la latencia de la primera invocación y la firma del acuse. El resultado fue bastante limpio: dentro de esos más de 4.500 modelos, una parte considerable tuvo tráfico real en la semana previa; incluso la cola larga pudo levantarse con un arranque en frío.
Las discusiones populares sobre el número de modelos alojados se enfocan casi por completo en la comparación de cantidades. La diferencia que de verdad puede verificarse en OpenGradient es más fría: el volumen no está hecho solo de un contador de cargas. Cada juego de pesos se divide en rebanadas y se guarda en Walrus; al invocarlo, el middleware de enrutamiento de capacidades lo recompone según la disponibilidad, y la Verification Layer lo sella. Para colgarlo hay que vincular capacidad de almacenamiento; para invocarlo, tiene que dejar huella en el acuse. El costo de “actualizar datos” es incluso mayor que el de “hacer trabajo”. Cuatro mil quinientos es un conjunto de carga real, no una frase en una tabla.
También hay que cambiar el indicador de observación. No me fijo en cuántos modelos acumula OpenGradient colgados; miro un dato contrario al consenso: la proporción de modelos que, al menos una vez por semana, se activan con una invocación real y de pago, y que además dejan un acuse en la Verification Layer. El primero mide el ingreso al repositorio; el segundo mide si esta capa de alojamiento realmente está siendo usada por desarrolladores.
Si $OPG solo está como comisión de emparejamiento por una invocación de modelo, entonces se parece más a un token de cobro por llamadas; pero si en el futuro la capacidad alojada se pignora, hay incentivos por arranque en frío, se emiten acuses, se reparte la cola larga, y hasta el desalojo y las multas por modelos zombis giran alrededor de ese mecanismo, entonces ya no cumple la función de token de cobro, sino la de un activo de crédito de capacidad en esta red de alojamiento de modelos.
No saco conclusiones apuradas. La ventaja de volumen solo cuenta si se valida repetidamente en la cola larga; estoy dispuesto a seguir observando las muestras que OpenGradient en su red principal y las partes posteriores entreguen al conectarse.
#opg
4500+ 模型,还说啥呢冲!
100%
调用是不是真实付费的?
0%
1 Votos • Votación cerrada