JoseMSL's picture
Upload Dockerfile
3401387 verified
Raw
History Blame Contribute Delete
1.94 kB
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"]