Me di cuenta de algo mientras leía la documentación de PIPE de OpenGradient que no he podido sacarme de la cabeza. Cuando un contrato inteligente llama a un modelo, el secuenciador saca la solicitud de inferencia antes de que comience la construcción del bloque: la ejecuta en un mempool paralelo, distribuye el trabajo entre los operadores de GPU y luego entrelaza el resultado de nuevo. El bloque nunca espera al modelo. A primera vista, suena elegante. Pero seguía con una pregunta: ¿qué pasa realmente cuando dos nodos de GPU compiten y devuelven diferentes resultados para el mismo prompt?
La documentación dice que el primer paquete válido gana y los duplicados se descartan. Eso está bien para modelos deterministas, pero los LLMs no son deterministas. La temperatura, la variabilidad de muestreo e incluso las diferencias en punto flotante entre hardware pueden producir salidas legítimamente diferentes del mismo input. Así que la mecánica de "carrera" no es realmente una carrera hacia la corrección, es más bien una carrera hacia la primera presentación. No estoy completamente seguro de que el diseño actual tenga una respuesta clara para eso, o si asume en silencio que la variación no importará lo suficiente como para disputarla.
Me hace pensar en lo que significa "válido" aquí en la práctica. Si la validez es solo prueba de ejecución en lugar de prueba de un resultado específico, entonces el sistema tolera la no determinación por diseño. Eso podría ser intencionado. Pero para cualquier aplicación en cadena donde la salida del modelo alimenta una decisión financiera o una acción de gobernanza, tolerar la variación en la salida se siente como una verdadera brecha en lugar de un compromiso aceptable.
La pregunta que me viene a la mente es cómo se sostiene esto cuando los desarrolladores comienzan a incrustar llamadas a modelos de alto riesgo directamente en contratos inteligentes a gran escala, no solo experimentando en testnet; de todos modos, el tiempo lo dirá👍
#opg $OPG
La documentación dice que el primer paquete válido gana y los duplicados se descartan. Eso está bien para modelos deterministas, pero los LLMs no son deterministas. La temperatura, la variabilidad de muestreo e incluso las diferencias en punto flotante entre hardware pueden producir salidas legítimamente diferentes del mismo input. Así que la mecánica de "carrera" no es realmente una carrera hacia la corrección, es más bien una carrera hacia la primera presentación. No estoy completamente seguro de que el diseño actual tenga una respuesta clara para eso, o si asume en silencio que la variación no importará lo suficiente como para disputarla.
Me hace pensar en lo que significa "válido" aquí en la práctica. Si la validez es solo prueba de ejecución en lugar de prueba de un resultado específico, entonces el sistema tolera la no determinación por diseño. Eso podría ser intencionado. Pero para cualquier aplicación en cadena donde la salida del modelo alimenta una decisión financiera o una acción de gobernanza, tolerar la variación en la salida se siente como una verdadera brecha en lugar de un compromiso aceptable.
La pregunta que me viene a la mente es cómo se sostiene esto cuando los desarrolladores comienzan a incrustar llamadas a modelos de alto riesgo directamente en contratos inteligentes a gran escala, no solo experimentando en testnet; de todos modos, el tiempo lo dirá👍
#opg $OPG
