Bolmo: transforma Olmo 3 a modelos byte-level | Keryc
Bolmo llega como una apuesta clara: tomar la potencia de Olmo 3 y convertirla en modelos que operan directamente sobre bytes UTF-8. ¿Por qué importa esto? Porque trabajar a nivel de byte puede resolver problemas reales —ortografía, palabras raras, manejo de múltiples idiomas y casos límite— sin renunciar al rendimiento que han ganado los mejores modelos subword.
¿Qué es Bolmo y por qué importa?
Bolmo es una familia de modelos byte-level (Bolmo 7B y Bolmo 1B) que no nace desde cero. En lugar de eso, byteifica checkpoints abiertos de Olmo 3, reutilizando su backbone y capacidades, y los adapta a una arquitectura que procesa bytes con parches de longitud variable. El resultado: modelos abiertos que, según Ai2, empatan y a veces superan a modelos subword en muchas tareas, y sobresalen donde los bytes son más relevantes.
¿Por qué preferir bytes a subwords? Los modelos subword dependen de un vocabulario fijo: bien funcionan, pero fallan en límites claros. Los modelos byte-level evitan ese vocabulario manual y manejan mejor errores de ortografía, rarezas tipográficas y texto multilingüe.
Cómo funciona Bolmo (arquitectura técnica)
Bolmo es un latent tokenizer language model. En alto nivel opera en tres etapas:
Cada byte UTF-8 se embebe y pasa por un encoder local ligero (una pila de mLSTM) que produce representaciones contextuales a nivel de byte.
Un boundary predictor no causal decide límites de parche usando un poco de contexto futuro, y agrupa bytes en parches de longitud variable que se pool-ean.
Los parches alimentan al transformador global (el propio Olmo 3), luego se depoolean de vuelta a bytes y un decoder local refina la predicción del siguiente byte y del siguiente límite.
Esta estrategia combina lo mejor de dos mundos: sensibilidad a la estructura fina del texto (bytes) y la fuerza de un transformador grande ya entrenado. Técnicamente, Bolmo comparte familia con modelos como DTP, BLT y H-Net, pero con modificaciones para reutilizar backbones subword fuertes.
Byteifying Olmo 3: entrenamiento en dos etapas
Entrenar byte-levels desde cero es caro. Bolmo evita ese gasto con un plan en dos etapas:
Congelar el transformador Olmo 3 y entrenar solo el encoder local, decoder local, boundary predictor y la cabeza de lenguaje. Esta etapa usa 9.8B tokens (aprox. 43B bytes) y es relativamente barata.
Descongelar todo el modelo y continuar el entrenamiento por 39.3B tokens adicionales (aprox. 173B bytes) para que Bolmo explote la información a nivel de byte.
La idea clave: no se desperdicia la inversión en curación de datos, arquitectura o entrenamiento de contexto largo. Se extiende ese trabajo al espacio de bytes con un costo adicional moderado.
Rendimiento: dónde destaca Bolmo
Ai2 evaluó Bolmo en una suite amplia (matemática, razonamiento STEM, QA, código, conocimiento general) y en pruebas centradas en caracteres como CUTE y EXECUTE. Resultados destacados:
Bolmo 7B se aproxima al Olmo 3 7B en la mayoría de tareas generales, y lo supera ampliamente en benchmarks centrados en caracteres. En el agregado de carácter, mejora cerca de 20 puntos sobre Olmo 3.
Frente a otros byte-levels similares (BLT 7B, TFree-Hat 7B, EvaByte 6.5B), Bolmo 7B es el más sólido en código, matemáticas, QA multiple-choice y comprensión a nivel de caracteres, con una pequeña excepción en GenQA.
Bolmo 1B, byteificado desde Olmo 2 1B, compite bien con byte-models previos en esa escala y mejora la comprensión de caracteres respecto a su base subword.
Esto confirma la hipótesis: se puede tener lo mejor de los bytes (detalle fino) sin pagar un peaje grande en rendimiento general.
Inferencia y eficiencia práctica
Un miedo común es la latencia: más tokens puede significar más tiempo. Bolmo afronta esto con mLSTM locales y pooling dinámico. Mediciones indicativas:
Decodado en pared: ~125 bytes por segundo, frente a ~150 bytes por segundo del modelo subword correspondiente al mismo nivel de compresión.
Se puede acelerar aumentando la ratio bytes-por-parche.
Una ventaja importante: la compresión es un control ajustable. Los modelos subword se topan con el cuello de botella del softmax cuando agrandan su vocabulario. Bolmo puede elevar la media de bytes por parche sin chocar con ese límite, lo que extiende la frontera de Pareto entre rendimiento y costo computacional.
Ventaja práctica: actualizaciones sin costo (zero-cost upgrades)
Una función poderosa de byteificar es la compatibilidad con el ecosistema de post-entrenamientos. Ai2 demuestra que, después de byteificar, puedes importar mejoras de checkpoints post-entrenados mediante weight merging sin volver a entrenar en byte-space.
Ejemplo concreto: un Olmo 3 post-entrenado para seguir instrucciones, al ser convertido vía arithmetic de pesos, mejora enormemente a Bolmo en IFEval. Números clave:
Bolmo base en IFEval: 31.1% versus 35.4% del subword original.
Tras aplicar la mezcla de pesos, Bolmo sube a 67.4%, igualando aproximadamente al Olmo 3 post-entrenado en 66.9%.
Eso sugiere un flujo de trabajo eficiente: byteifica tu modelo fuerte y reusa RL, fine-tunes y adaptadores mediante fusiones ligeras de pesos, en lugar de rehacer todo en bytes.
Importante: esta compatibilidad no está garantizada para todas las familias de modelos. Funciona bien aquí porque las embeddings de Olmo 3 se pueden "resetear" sin perder rendimiento, un comportamiento que merece investigación adicional.
Qué sigue y cómo probar Bolmo
Ai2 propone varias direcciones: experimentar con predictoras de límites más ricas, escalar el proceso a modelos más grandes, crear variantes multilingües y permitir que las mejoras del ecosistema subword sigan fluyendo hacia el espacio byte.
Si quieres probarlo ya, Ai2 publica checkpoints, código, datos y el informe técnico para reproducir y extender el proceso de byteifying. Eso facilita que investigadores y desarrolladores examinen internals, reproduzcan resultados y construyan sistemas byte-level sobre Olmo.
Piensa en aplicaciones prácticas: asistentes científicos que corrigen notación, herramientas de edición de código que no se rompen con nombres extraños, o modelos multilingües que no dependen de vocabularios sesgados. ¿No suena eso útil para muchas aplicaciones reales?
