Dockerfile

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

ENV PORT=7860
EXPOSE 7860

# PYTHONUNBUFFERED=1 fuerza el flush inmediato de stdout/stderr en Python.
# Sin esto, los print() del bert_api.py (carga del modelo, warmup, etc.) quedan
# en buffer y NO aparecen en los Container logs de HF Spaces antes de SIGKILL.
# Documentado en doc 40 §11.10 y en HF forum (foros.huggingface.co).
ENV PYTHONUNBUFFERED=1

# NOTA v8-intent (joint model): difiere del v6/v7-part6 en 3 flags críticos.
# Causa raíz documentada en doc 40 §11.10 — bug conocido fork+OpenMP+PyTorch.
#
#   ❌ NO usar --preload con modelos PyTorch custom (JointIntentSlotModel).
#      Bug pytorch/pytorch#49555 + gunicorn#2478: PyTorch inicializa su thread
#      pool intra-op (OpenMP/MKL) en master. Tras fork(), los workers heredan
#      el estado del runtime OpenMP pero NO los threads → deadlock infinito en
#      el primer model.forward(). Síntoma: WORKER TIMEOUT exactamente al
#      --timeout configurado.
#      Solución (Opción A doc 40 §11.10): cargar el modelo en cada worker
#      post-fork. Sin master pre-fork, sin OpenMP heredado, sin deadlock.
#
#   --workers 1: el joint model bloquea ~1 vCPU por GIL en cada inferencia.
#      CPU Basic free tiene 2 vCPU. Con workers=1 hay margen y el modelo se
#      carga UNA vez (sin --preload se cargaría por cada worker → +RAM si
#      escaláramos workers).
#
#   --timeout 120: vuelta al default del v6/v7-part6. Sin el deadlock OpenMP,
#      las inferencias son ~600-800ms warm. No hace falta el --timeout 300
#      excepcional.
#
# Trade-off conocido: arranque del worker tarda ~30-60s (carga el modelo en
# worker en lugar de heredarlo de master). Inferencias warm sin cambio.
CMD ["gunicorn", "--bind", "0.0.0.0:7860", "--workers", "1", "--timeout", "120", "bert_api:app"]