Disco y almacenamiento
Elegir un tamaño al desplegar
La página Desplegar tiene un control deslizante de disco. Comienza en 50 GB y avanza en pasos de 10 GB, desde un mínimo de 10 GB hasta el máximo que puede darle la máquina que eligió. El texto de ayuda debajo del control indica ese máximo. Distintas máquinas tienen distintos topes, así que cambiar la oferta cambia el límite superior del control.
Desde la API el campo es disk_gb en POST /v1/instances, y acepta de 10 a 20,000. Un valor por encima de la capacidad de la máquina elegida se rechaza con 422 DISK_TOO_LARGE, y el error indica el máximo que esa máquina puede darle.
{
"offer_id": "…",
"template_id": "…",
"disk_gb": 200,
"label": "llama-finetune"
}
Dimensiónelo para todo el trabajo: la imagen, su conjunto de datos, las cachés de paquetes y todos los checkpoints que piense conservar a la vez. Los checkpoints suelen ser lo que se desborda: una ejecución que escribe uno por época y no borra nada llenará un disco que parecía generoso.
No se puede redimensionar después
No hay ningún control de redimensionamiento en la consola ni ningún campo en ningún endpoint que cambie disk_gb después del despliegue. Un disco es fijo durante toda la vida de la instancia.
Si lo dimensionó demasiado pequeño, la única vía hacia uno más grande es una instancia nueva: copie sus datos fuera, destruya la instancia anterior y despliegue de nuevo con un disco mayor. Consulte Mover datos hacia dentro y hacia fuera.
La tarifa de almacenamiento se cobra por GB por hora, así que 50 GB adicionales son un costo pequeño y predecible. Quedarse sin disco a mitad de una ejecución de entrenamiento no lo es.
Qué vive dónde
El disco respalda el sistema de archivos del contenedor. No hay montajes del host ni volúmenes adjuntos: todo lo que el contenedor escribe cae en el disco que usted pagó.
| Ruta | Qué contiene |
|---|---|
/workspace | sus datos y su código por convención, y la raíz por omisión de JupyterLab |
/root/.ssh/authorized_keys | la clave pública que adjuntó al desplegar, escrita en cada arranque |
/var/log/superheat/jupyter.log | la salida del servidor de notebooks |
/var/log/superheat/onstart.log | la salida del script onstart de la plantilla |
Todo el sistema de archivos sobrevive a una detención y vuelve intacto al iniciar. Todo el sistema de archivos se elimina al destruir, incluido /workspace. Nada de esto tiene copia de seguridad.
Qué paga y cuándo
| Estado de la instancia | Cargo |
|---|---|
running | la tarifa de GPU del bloque, medida por segundo |
stopped | la tarifa de almacenamiento, por GB por hora, por el disco que aprovisionó |
creating, starting, stopping, destroying | nada |
destroyed | nada |
El cargo de almacenamiento es el que la gente olvida. Una instancia detenida cuesta dinero cada hora que permanece detenida, y un disco grande detenido durante un mes es una factura real por trabajo que no se está ejecutando. Los cargos se liquidan aproximadamente una vez por minuto, así que el saldo de la página de facturación se mantiene casi en tiempo real.
El almacenamiento deja de cobrarse en el momento en que la instancia se destruye, porque el disco ya no existe. Ese es el intercambio: Detener frente a destruir explica cuál de los dos quiere.