¿Cuánta RAM necesita un servidor de Palworld? (Guía de dimensionamiento)

La documentación oficial de Pocketpair recomienda 16 GB de RAM para un servidor dedicado de Palworld. 8 GB arrancarán el servidor, pero conllevan un riesgo real de fallos por falta de memoria (OOM), y Pocketpair indica "más de 32 GB" para configuraciones más grandes. Entonces: ¿cuánta RAM necesita un servidor de Palworld? La respuesta completa que muchas guías de dimensionamiento omiten es que Palworld escala según el estado del mundo y el tiempo de actividad, no solo según el número de jugadores. Un servidor que nunca se reinicia necesita más RAM que el mismo número de jugadores en un servidor con reinicios programados.

Esta guía utiliza la página de requisitos oficiales de Pocketpair como punto de partida, y luego añade lo práctico: una tabla de dimensionamiento con rangos honestos, el problema del crecimiento de la memoria y el diagnóstico de reinicio frente a actualización que te ahorra dinero.

Requisitos oficiales del servidor de Palworld (v1.0)

Según la Guía del Servidor oficial de Pocketpair, vigente para la v1.0:

Notarás que muchas páginas de alojamiento citan 8 GB como "el requisito". Los documentos indican que 8 GB es solo para el arranque, con un mayor riesgo de fallos por falta de memoria. Esa es una afirmación diferente, y la diferencia importa cuando tu servidor lleva tres semanas con un guardado de comunidad.

Dos advertencias sobre las cifras oficiales. En primer lugar, la frase "más de 32 GB para servidores más grandes" es ambigua. No es una promesa para ningún número específico de jugadores, y Pocketpair no publica una tabla de jugadores por GB. En segundo lugar, la versión 1.0 incluyó optimizaciones para servidores dedicados, por lo que las mediciones de las guías de Acceso Anticipado no se transfieren 1:1. Si estás leyendo un artículo de dimensionamiento anterior a la v1.0, desconfía de sus cifras.

Tabla de dimensionamiento de RAM para servidores de Palworld por número de jugadores

Que tengas veinte personas en tu Discord que entren una vez a la semana no convierte tu servidor en uno de 20 jugadores. Lo que importa es el número máximo de jugadores conectados al mismo tiempo, porque Palworld asigna memoria para mantener el estado persistente del mundo (bases, Pals trabajadores, objetos del Pal Box y cajas abandonadas) en lugar de hacerlo estrictamente por jugador conectado, como explica fly-serv's analysis. Dimensiona tu servidor según tus noches más movidas, no según la lista de miembros.

Ninguna fuente coincide perfectamente en las cifras, así que estos son rangos, no dogmas:

Basado en la tabla HostMyGame 1.0, el dimensionamiento conservador de gamehosting.app y los niveles de Nodecraft. Fíjate dónde discrepan: gamehosting.app dice que 6 GB están bien para 2–4 jugadores casuales con reinicios diarios, mientras que otras no bajan de 8 GB. Nuestra recomendación para un mundo pequeño de amigos y familia: mínimo 8 GB, 12 GB si puedes permitirte el lujo, porque tener margen es barato comparado con un servidor colapsado en horas punta.

Independientemente del nivel que elijas, añade 2–4 GB de margen (aproximadamente un 30%) para el comportamiento de crecimiento de la memoria que cubriremos a continuación.

Por qué el estado del mundo importa tanto como el número de jugadores

¿Qué impulsa el extremo superior de la tabla? Principalmente la densidad del mundo. Una base con 15 Pals trabajadores ejecuta decisiones de IA continuas, comprobaciones de idoneidad laboral y cálculo de rutas. Esta es la principal fuente de carga en un mundo maduro, según fly-serv, y la versión 1.0 aproximadamente duplicó el tamaño del mapa, lo que se suma a todo ello.

Algunas configuraciones en PalWorldSettings.ini reducen esa carga:

• BaseCampMaxNumInGuild (por defecto 3) y BaseCampWorkerMaxNum (por defecto 15): menos bases y Pals trabajadores por gremio significa menos simulación
• DropItemMaxNum (por defecto 3000): limita el botín disperso por tu mundo
• ServerReplicatePawnCullDistance (por defecto 15000): redúcelo y los clientes rastrean menos Pals lejanos

Por qué la memoria de Palworld aumenta con el tiempo (y por qué más RAM solo lo retrasa)

El patrón documentado: la RAM de un servidor de Palworld sube constantemente incluso con un número de jugadores constante, y baja después de un reinicio. Este comportamiento de crecimiento de la memoria (la mayoría lo llama fuga de memoria) es el problema operativo definitorio de los servidores de Palworld, y según game-serverhosting.com, el proceso sigue ocupando más memoria cada hora de funcionamiento incluso después de la v1.0.

Una cronología típica, basada en los informes de ConnectHosting: los días 2–3 traen aumento gradual de RAM y efectos de rebote, los días 4–6 traen picos de lag, y sin memoria libre alcanzas un fallo por falta de memoria en aproximadamente una semana. Trátalos como ilustrativos más que precisos; esa fuente no publicó mediciones.

Pocketpair ha estado parcheando este tema. Las correcciones de fugas para servidores dedicados llegaron en v0.3.10 (octubre de 2024) y v0.5.3 (abril de 2025), la optimización de sesiones largas llegó en v0.6.2 (julio de 2025), y las notas de la versión 1.0 incluían más correcciones. El crecimiento ha mejorado, pero sigue siendo un problema operativo activo.

La conclusión clave: más RAM empuja el techo más lejos. No corrige el crecimiento. Si tu servidor gana 500 MB al día, un plan de 16 GB simplemente fallará más tarde que un plan de 8 GB.

Reinicia, no actualices: el diagnóstico que te ahorra dinero

Esta es la regla de decisión que usaríamos: si la RAM sube constantemente con un número de jugadores fijo y baja después de un reinicio, la solución es un horario, no un plan más grande. Un reinicio borra la memoria acumulada y vuelves a una línea base limpia. Esta es la solución consensuada en todas las guías que valen la pena leer.

Una actualización solo está justificada cuando:

• La RAM se satura repetidamente incluso con reinicios programados
• Estás teniendo fallos OOM justo después de reiniciar
• Puedes medir una mejora real en la estabilidad gracias al margen adicional

Una comprobación contraintuitiva antes de gastar dinero: si los núcleos de la CPU están al máximo mientras queda margen de RAM, tienes un cuello de botella de CPU, no un problema de RAM. El lag concentrado cerca de las bases grandes suele ser carga de simulación y densidad, no de memoria. Actualizar la RAM para ese síntoma no sirve de nada.

Cuando reinicies, hazlo de forma ordenada. La secuencia documentada en los documentos de configuración de Pocketpair:

1. /Save para volcar el mundo al disco
2. /Broadcast un mensaje de aviso, e.g. /Broadcast Restarting in 60 seconds!
3. /Shutdown 60, lo que da a los jugadores un minuto para terminar

Cómo programar reinicios y copias de seguridad que mantengan estable un servidor de Palworld

Cadencia de reinicios: lo que recomiendan las fuentes y por qué no hay un número universal

No hay una cifra definitiva y las fuentes discrepan: XGamingServer recomienda 4–6 horas para servidores pequeños hasta cada hora para los grandes, mientras que WebsNP recomienda 6–12 horas durante ventanas de bajo tráfico. Nuestra lectura práctica: cada 6–12 horas para mundos activos, a diario para los tranquilos, programado en tu ventana de menor población (las 5:00 AM es la opción clásica).

Copias de seguridad seguras

Haz una copia de seguridad de Pal/Saved/SaveGames/ inmediatamente después de un apagado limpio, nunca durante una escritura, según WebsNP. Mantén bIsUseBackupSaveData=True también en tu configuración. Según la documentación oficial, este ajuste mantiene un directorio de copias de seguridad rotativas junto con tu partida (5 guardados por cada 30 segundos, 6 por cada 10 minutos, 12 por hora, 7 por día), al costo de mayor carga en el disco. Es un seguro barato para una partida donde puedes tener meses de trabajo.

Vigila el archivo de guardado

Level.sav contiene todo el mundo (bases, Pals, contenedores, gremios) y es el archivo que crece. Comienza en unos pocos megabytes y alcanza entre 40 y 150 MB con una docena de jugadores activos, según fly-serv. Partidas más grandes significan congelamientos más largos al guardar, porque cada autoguardado serializa todo el archivo. Puedes revisar el tuyo con ls -lh */Level.sav en ~/Pal/Saved/SaveGames/0/. Un crecimiento superior a 10 MB por semana indica que la densidad de tu mundo está aumentando.

Frecuencia de guardado

AutoSaveSpan en PalWorldSettings.ini controla el intervalo de autoguardado, pero las fuentes discrepan sobre el valor predeterminado (uno dice 30 s, otro 15 s, la documentación oficial no lista uno). La prueba concreta: establece el valor que estás considerando, observa los timestamps de Level.sav durante un día para ver con qué frecuencia escribe realmente, y luego sopesa la recuperación ante caídas contra los congelamientos al guardar. Algunos administradores en mundos grandes lo amplían a 600 s para reducir esos congelamientos. Solo recuerda que un intervalo más largo significa más progreso perdido ante una caída.

En Hostwolf, los horarios integrados gestionan el reinicio nocturno, y las copias de seguridad diarias con restauración en un clic cubren la red de seguridad, así que no necesitas configurar cron tú mismo.

RAM vs CPU: por qué tu servidor puede ir lento incluso con memoria libre

La simulación de Palworld depende principalmente de un solo hilo, lo que significa que la velocidad de reloj por núcleo importa más que el número de núcleos, según el análisis de fly-serv. Cuatro o más núcleos son un punto de partida, no una garantía de juego fluido. La única forma de saberlo es probar bajo carga real con jugadores reales.

Un mapa rápido de síntomas:

• Alto uso de RAM más lentitud: crecimiento de memoria; corrige primero el horario de reinicio
• Bajo uso de RAM más lentitud: problema de CPU/densidad; la RAM no ayudará
• Lentitud solo cerca de bases grandes: carga del estado del mundo por Pals y búsqueda de caminos

El almacenamiento también importa. Una partida de 150 MB serializada en un disco lento causa congelamientos de 1–2 segundos en cada autoguardado. Por eso la documentación oficial recomienda un SSD rápido y advierte que el almacenamiento lento puede corromper los datos guardados. No es un lujo.

Elegir el plan adecuado

Ajusta la tabla de tamaños a un plan: comienza en la categoría de 16 GB para un servidor comunitario real, y sube hacia 32 GB para mundos llenos y de larga duración que no se reinician con frecuencia. Debido a que la simulación es sensible a hilos únicos, las opciones de CPU dedicada valen la pena. Estás pagando por rendimiento consistente por núcleo, que es exactamente lo que Palworld necesita.

El lado operativo importa tanto como las especificaciones brutas. Con alojamiento de servidores de Palworld de Hostwolf, obtienes tu propia máquina en la nube, reinicios programados, respaldos diarios con restauración en un clic, una consola en vivo y editores de configuración por juego para cosas como BaseCampWorkerMaxNum. Consulta precios de Hostwolf por tamaño de RAM para planes y regiones actuales.

Conclusión

La respuesta honesta a "¿cuánta RAM necesita un servidor de Palworld?" es un punto de partida más un hábito. El punto de partida: 16 GB para cualquier cosa más allá de un mundo casual solo para amigos, escalando hacia 32 GB para servidores llenos. El hábito: reinicios programados, porque el crecimiento de memoria con el tiempo de actividad es un comportamiento documentado y más RAM solo lo retrasa, nunca lo soluciona.

Dimensiona para el mundo que tendrás en dos meses, con más bases, más Pals y un Level.sav más grande, no para el que tienes el primer día.