Escalabilidad en sistemas de optimización: cuándo y cómo complementar Python con Rust.
07 de mayo de 2026
Cómo aplicar una arquitectura híbrida para eliminar cuellos de botella en optimización sin sacrificar calidad de solución.
El reto
Imaginemos un algoritmo de planificación logística con resultados sólidos, validado técnicamente y con un potencial claro para generar ventaja competitiva. El modelo funciona y, lo más importante, las decisiones que propone son mejores: reduce kilómetros, mejora ocupaciones, equilibra cargas, cumple ventanas y responde a restricciones reales. En un entorno controlado, el resultado es incuestionable.
El problema aparece cuando el tiempo de cálculo empieza a ser incompatible con la realidad operativa. En la práctica, la logística no espera: cambian las prioridades, se cancela una entrega, aparece un pico de demanda, se avería un vehículo o se amplía el alcance del problema con nuevas rutas, más puntos o más reglas. En ese contexto, un tiempo de cálculo que en fase experimental puede parecer asumible empieza a convertirse en una deuda operativa. Si recalcular un escenario tarda una hora, la realidad sobre la que se calculó ya no existe cuando llega la respuesta.
Ahí es donde la pregunta estratégica cambia por completo. Deja de ser “¿es bueno el algoritmo?” para convertirse en “¿llega a tiempo para ser útil?”. Porque en optimización aplicada, la calidad de solución solo genera valor si puede convertirse en decisión dentro de la ventana operativa y con la rapidez que exige el negocio.
Solución tecnológica
El enfoque adoptado fue deliberadamente pragmático. No se rediseñó el algoritmo, no se introdujeron heurísticas adicionales para “forzar” mejoras artificiales y no se recortó el espacio de búsqueda para ganar velocidad sacrificando calidad. Se mantuvo exactamente la misma lógica de la metaheurística utilizada para resolver el problema de optimización combinatoria, concretamente un Problema de Ruteo de Vehículos Capacitados con Múltiples Viajes (MTCVRP). La pregunta no era cómo cambiar el método, sino cómo hacer que el método existente pudiera ejecutarse a la velocidad necesaria.
La primera decisión fue medir con precisión. A través de profiling se identificó el componente crítico responsable de millones de operaciones dentro del bucle principal: ese tramo de ejecución donde se concentra el coste real y donde, en Python, cada micro-operación tiene un peaje acumulativo. En lugar de reescribir todo el sistema, se migró selectivamente ese “hot path” a Rust, manteniendo Python como capa de orquestación, modelado y control del flujo.
El resultado fue una arquitectura híbrida diseñada para maximizar retorno con mínimo riesgo: Python se quedó donde aporta más valor —rapidez de iteración, expresividad para la lógica de alto nivel, instrumentación y experimentación— y Rust se convirtió en el motor de ejecución del núcleo intensivo en CPU. Este diseño permitió aislar el efecto del cambio tecnológico y medirlo con precisión, sin introducir ruido por cambios metodológicos.
Impacto
El salto no es incremental: es un cambio de categoría operativa. En problemas medios, el tiempo de ejecución pasa de más de dos minutos a apenas segundos; en problemas grandes, el cálculo pasa de más de una hora a poco más de dos minutos. Estas cifras no son solo “rendimiento”: son ventana de decisión. Marcan la diferencia entre tener un optimizador que entrega resultados cuando todavía son accionables y otro que llega tarde, por muy buenas que sean sus soluciones.
Y lo más relevante es lo que no cambió. No se modifica el modelo. No se sacrifica calidad de solución. No se simplifica el problema. La misma metaheurística, con la misma lógica, produce soluciones comparables, pero ahora lo hace a una velocidad compatible con la realidad de la operación.
Ese cambio habilita comportamientos que para el cliente final son cualitativamente distintos. Permite recalcular varias veces dentro de una misma ventana operativa, no como excepción sino como parte del proceso normal de toma de decisiones. Permite trabajar con instancias de mayor tamaño —más pedidos, más rutas, más restricciones— sin que el tiempo de cómputo se dispare de forma no lineal hasta volverse impracticable. Permite explorar escenarios de forma real, comparando alternativas con criterio operativo (coste, nivel de servicio, robustez ante incertidumbre) sin quedar limitados a “un único plan” porque ejecutar un segundo intento sería inviable.
Además, reduce riesgo de escalabilidad en el despliegue. Muchas iniciativas de optimización fracasan no por falta de inteligencia matemática, sino por falta de encaje operacional: el modelo funciona, pero no entra en la cadencia del negocio. Al eliminar el cuello de botella del motor de ejecución, se reduce la presión sobre infraestructura, se minimiza la necesidad de sobredimensionar cómputo para cumplir tiempos, y se abre la puerta a evolucionar modelos experimentales hacia entornos de casi tiempo real.
Por eso, no se trata de “acelerar un algoritmo”. Se trata de eliminar una barrera que impide que una buena solución pueda desplegarse con ambición.
Equipo
El proyecto fue desarrollado por un Data Scientist especializado en optimización e inteligencia artificial, acompañado por líderes técnicos en IA e Investigación Operativa, y con el apoyo del equipo de AIOR (Data y Optimization Scientists). El trabajo combinó dos disciplinas que, en sistemas de optimización en producción, son inseparables: la solidez del enfoque matemático y la ingeniería necesaria para convertirlo en un sistema fiable, escalable y mantenible.
La revisión estratégica de perfiles senior de tecnología aseguró que la solución no solo resolviera el problema inmediato de rendimiento, sino que encajara en una visión de producto sostenible: conservar la agilidad de Python para iterar y evolucionar modelos, mientras se refuerza con un núcleo de ejecución en Rust para garantizar tiempos de respuesta consistentes y operables.
En conjunto, el proyecto refleja una colaboración transversal y la cultura de I+D de OGA orientada a mejorar continuamente la transferencia de soluciones avanzadas desde el prototipo hasta la operación real.
Links de referencia:
- Autor: Priya Senthil (2025) – Título: Python or Rust: Performance Comparison in Optimization Model Environment – Link: https://www.osiopt.com/blogs/python-or-rust-performance-comparison-in-optimization-model-environment
#PassionForData
Categorías
Pablo Téllez López
Optimization Scientist especializado en el diseño de sistemas de optimización eficientes y creación de modelos predictivos en entornos industriales. Graduado en Matemáticas Aplicadas, con un máster en Inteligencia Artificial.
En lo personal, apasionado del deporte, los libros y convencido de que la tecnología puede tener un impacto real en la sociedad.