Ingeniero de ML Sénior | Kimchi (Optimización de Stack de Inferencia)

• Has construido sistemas de ML reales durante más de 5 años, y tu portfolio muestra profundidad en infraestructura de inferencia o entrenamiento, no solo cuadernos (notebooks) de entrenamiento de modelos.
• Tu Python es de nivel de producción: servicios, no scripts.
• Has ejecutado vLLM, SGLang o TensorRT-LLM de verdad, y tienes un modelo mental funcional de por qué un motor rinde como lo hace en una GPU determinada.
• Has medido regresiones de cuantización, no solo ratios de compresión.
• Las configuraciones multi-GPU y multi-nodo no te asustan: paralelismo de tensores y de expertos, comunicación colectiva y sus modos de fallo prácticos.
• Sabes dónde residen los bytes (page caches, O_DIRECT, sistemas de archivos de red bajo lecturas a escala de terabytes) y con qué rapidez se mueven.
• Instrumentas antes de optimizar, y sabes distinguir una victoria real de un artefacto de benchmark.
• Un mandato amplio te entusiasma más de lo que te inquieta.

• Has trabajado específicamente en enrutamiento de LLM: evaluaciones de clase RouterBench, frentes de Pareto de coste/calidad/latencia.
• Métodos de calibración, abstención o conformes en sistemas de decisión en producción.
• Has ejecutado bucles A/B online con monitorización de deriva (drift) en un modelo que gestiona dinero real.

• Salario competitivo (dependiendo del nivel de experiencia).
• Disfruta de un entorno global flexible y "remote-first".
• Colaborar con un equipo global de expertos e innovadores en la nube, apasionados por ampliar los límites de la tecnología Kubernetes
• Opciones de acciones (equity).
• Recibe feedback rápido con un flujo de trabajo ágil. La mayoría de los proyectos de funcionalidades se completan en un plazo de 1 a 4 semanas.
• Dedica el 10% de tu tiempo de trabajo a proyectos personales o a la superación personal.
• Presupuesto de aprendizaje para el desarrollo profesional y personal, incluyendo el acceso a conferencias internacionales y cursos que eleven tus habilidades.
• Hackathon anual para generar nuevas ideas y fortalecer los vínculos del equipo.
• Presupuesto para team-building y eventos de empresa para conectar con tus compañeros.
• Presupuesto para equipamiento para asegurar que tienes todo lo que necesitas.
• Días libres adicionales para ayudar a mantener un equilibrio saludable entre la vida laboral y personal.

Los grandes modelos son ingredientes en bruto. El Kimchi es lo que ocurre cuando los fermentas con una buena ingeniería. Empezamos dentro de CAST AI ayudando a las empresas a ejecutar LLMs en sus propios clústeres de Kubernetes; hoy ejecutamos nuestro propio entorno de codificación en cualquier modelo que elijas, y nosotros mismos ejecutamos los modelos que hay debajo.

Kimchi Inference

Una sola línea de API y el cliente existente del usuario simplemente funciona: DeepSeek, GLM, Kimi, MiniMax, Nemotron servidos sin servidor (serverless) desde nuestra propia flota de GPU (compatibles con OpenAI y Anthropic, pago por token, gasto visible por usuario, equipo y clave). Cuando el control es importante, los mismos modelos se ejecutan en el propio clúster del cliente. Detrás de esa única línea se encuentra la maquinaria que poseerás: motores SGLang y vLLM, nodos B300, un sistema de archivos de clúster compartido que contiene cada checkpoint exactamente una vez, cachés KV acompañando al tráfico de codificación con una fuerte reutilización de prefijos, y el entorno de benchmarks que controla cada cambio que lanzamos.

Throughput. Latencia. Arranques en frío. Coste por token.

Mueve esos cuatro números en la dirección correcta y ocurren dos cosas: los clientes obtienen una inferencia más rápida y barata, y nuestros márgenes mejoran. Esa es la tesis completa de este puesto. Cada cargador que optimices, cada decisión de planificación que tomes, cada kernel que analices se refleja en el p99 de un cliente y en nuestra cuenta de resultados (P&L). Tu mandato es la optimización del stack de inferencia, cueste lo que cueste, y la dirección técnica de cómo lo optimizamos es tuya para debatirla con datos.

El problema: los checkpoints ocupan entre 0,3 y 1,5 TB, y la configuración de servicio "correcta" depende de la forma del tráfico, la distribución de la longitud de la secuencia, la dinámica de lotes (batch), el SKU de la GPU, el ancho de banda de la memoria y la tolerancia a la cuantización; todas ellas variables que cambian semana tras semana. La mayoría de los equipos eligen una configuración una vez, sobredimensionan las GPU y absorben el coste. Nosotros no: logramos que Kimi-K3 (1,5 TB) pasara de tardar más de una hora en el arranque en frío a estar listo para el servicio en menos de doce minutos mediante un sistema de archivos compartido, cargadores de pesos O_DIRECT y cachés JIT locales en el nodo, y aún no hemos terminado. La desagregación de prefill/decode y las cachés KV por niveles son lo siguiente.

Stack: Python; SGLang; vLLM; TensorRT-LLM; PyTorch; fastsafetensors; herramientas adyacentes a CUDA; Kubernetes; sistemas de archivos compartidos virtiofs; ClickHouse; OpenTelemetry; Prometheus; Grafana; GitLab CI.

• Impulsar el throughput. Continuous batching, chunked prefill, speculative decoding con modelos de borrador, captura de CUDA-graph y ajuste del scheduler en toda la flota de motores.
  Encuentra el límite de cada SKU de GPU y luego elévalo.
• Reducir la latencia. Ataca el TTFT y la latencia inter-token por separado; realiza perfiles para encontrar el cuello de botella real (cómputo, ancho de banda de memoria, planificación, almacenamiento o
  red) y arréglalo, no el que suponías que era.
• Sacar más provecho de la caché KV. Atención jerárquica y paginada (paged attention), caché de prefijos en tráfico de codificación de alta reutilización, políticas de desalojo, KV cuantizado. Gran parte del
  throughput no aprovechado reside aquí, y tú te encargarás de ello.
• Eliminar los arranques en frío. Cargadores de pesos (O_DIRECT, clase fastsafetensors), cachés JIT y de compilación, rutas de lectura de sistemas de archivos compartidos. Un checkpoint de 1,5 TB no tiene por qué
  tardar una hora en estar listo para el servicio.
• Cuantizar sin perder calidad. INT8/INT4, FP8/FP4 en pesos, activaciones y KV, medido en cargas de trabajo reales, no solo en benchmarks de perplejidad.
• Escalar entre nodos. Topologías de inferencia distribuida, ubicación consciente de la red, desagregación de prefill/decode, estrategias de checkpointing que no generen cuellos de botella
  en el almacenamiento o la interconexión.
• Establecer la dirección técnica. Decide qué evaluamos con benchmarks, qué adoptamos y qué construimos nosotros mismos. Guía al equipo con informes sólidos y experimentos
  reproducibles.