Recursos de un servidor Palworld según tus necesidades
Par Benjamin D. · PDG
· Mis à jour le 29 de agosto de 2026 · Lecture 9 min
Índice
Los recursos servidor Palworld no escalan de forma lineal con el número de jugadores: una partida de 8 personas puede consumir más CPU que una de 20 si cada guild mantiene cuatro bases llenas de Pals trabajando. En esta guía desglosamos qué consume RAM, qué consume núcleos, qué consume ancho de banda y qué líneas de PalWorldSettings.ini disparan la factura de rendimiento.
Qué consume realmente una partida dedicada de Palworld
El servidor dedicado de Palworld corre sobre Unreal Engine 5 y arrastra las particularidades de ese motor. Entender dónde se va cada recurso evita sobredimensionar la memoria mientras el cuello de botella real está en un solo núcleo saturado.
RAM: el recurso que más crece con el tiempo
La memoria es el punto más sensible. Al arrancar, el proceso PalServer-Linux-Shipping se queda en torno a 4-6 GB con el mundo recién generado. A partir de ahí, la ocupación sube con tres factores:
- Estructuras construidas: cada muro, cofre y máquina de producción vive en memoria y se serializa en el guardado.
- Pals asignados a bases: cada trabajador es una entidad con IA activa, inventario y estado de hambre/salud.
- Chunks del mundo cargados: cuantos más jugadores dispersos por el mapa, más zonas simuladas simultáneamente.
Además, Palworld arrastra desde su lanzamiento un crecimiento progresivo de memoria durante partidas largas. No es un fallo que puedas corregir desde la configuración: la solución operativa es un reinicio programado cada 6-12 horas, algo trivial de automatizar desde las tareas del panel Pterodactyl.
CPU: frecuencia por encima de número de núcleos
El bucle de simulación principal de Palworld está fuertemente ligado a un hilo. Puedes tener 16 núcleos y ver cómo uno solo va al 100 % mientras el resto duerme. Por eso, en la práctica, un procesador Ryzen de alta frecuencia rinde mejor que un chip con muchos núcleos lentos. Los hilos secundarios se encargan de red, guardado en disco y carga asíncrona de assets, tareas importantes pero que rara vez saturan.
Los argumentos de arranque ayudan a repartir algo mejor esa carga:
./PalServer.sh -useperfthreads -NoAsyncLoadingThread -UseMultithreadForDS -port=8211 -players=16En un panel tipo Pterodactyl esos flags se añaden en la variable de arranque del egg. No multiplican el rendimiento, pero reducen los microcortes durante el guardado y la carga de zonas.
Disco y guardado
El archivo Level.sav es el corazón del mundo y crece sin parar. En una partida madura con varias guilds activas puede superar holgadamente los 100 MB. Cada autoguardado implica serializar todo eso y escribirlo: sobre un disco mecánico se traduce en congelaciones visibles de uno o dos segundos; sobre SSD NVMe la operación es prácticamente imperceptible. Si administras varias comunidades a la vez, esa diferencia de latencia de escritura es lo que separa un guardado limpio de un rubberbanding constante.
Ancho de banda
Palworld es sorprendentemente contenido en red comparado con juegos de supervivencia con mundos persistentes densos. Como orden de magnitud práctico, cuenta con varias decenas de KB/s por jugador conectado en estado estable, con picos claros al entrar a una base ajena llena de estructuras o al iniciar sesión (sincronización inicial del mundo). Con 16 jugadores activos hablamos de un tráfico muy asumible; lo que realmente importa aquí no es el caudal sino la estabilidad de la ruta y la protección anti-DDoS, porque una saturación del enlace se nota inmediatamente en forma de teletransportes y desincronización de Pals.
Si estás evaluando dónde ejecutar tu partida con estas cifras en la mano, la página de alojamiento servidor Palworld detalla las configuraciones disponibles con CPU Ryzen, NVMe y anti-DDoS incluido.
Recursos servidor Palworld según el número de jugadores
Estas referencias asumen una partida con ajustes por defecto y jugadores que construyen bases de forma normal. Súbelas si tu comunidad es constructora compulsiva o si vas a activar mods.
| Jugadores simultáneos | RAM útil recomendada | Núcleos | Observaciones |
|---|---|---|---|
| 2 a 4 | 6 a 8 GB | 2 núcleos de alta frecuencia | Suficiente para una partida cooperativa entre amigos con 1-2 bases por guild. |
| 5 a 8 | 10 a 12 GB | 3 a 4 núcleos | Empieza a notarse el peso de los Pals trabajadores en el hilo principal. |
| 9 a 16 | 16 GB | 4 núcleos | Reinicios programados obligatorios si la partida dura semanas. |
| 17 a 32 | 24 a 32 GB | 4 a 6 núcleos rápidos | Requiere limitar bases por guild y trabajadores por base para mantener 30 FPS de servidor. |
Por qué el número de jugadores engaña
Un jugador desconectado no deja de consumir. Sus estructuras siguen ocupando memoria, sus Pals de base siguen apareciendo en el guardado y su guild sigue existiendo en el estado del mundo. Diez jugadores que entran una vez por semana y que dejaron cuatro bases cada uno pesan más que diez jugadores activos con una base compartida.
La métrica que debes vigilar no es el contador de conectados sino el FPS de servidor. Palworld apunta a 30 FPS de simulación. Por debajo de 20 el juego se siente elástico: los Pals se quedan clavados, la recolección tarda en registrarse y el combate pierde precisión.
Lectura de métricas en tiempo real
Desde la versión con REST API integrada puedes consultar el estado del proceso sin depender de RCON. Actívala en el .ini y consulta:
curl -s -u admin:TU_PASSWORD_ADMIN \
http://127.0.0.1:8212/v1/api/metricsLa respuesta devuelve algo similar a:
{
"serverfps": 29,
"currentplayernum": 11,
"serverframetime": 34.2,
"maxplayernum": 16,
"uptime": 41207
}Con serverframetime por encima de 50 ms de forma sostenida ya tienes un problema de CPU, no de RAM. Añadir memoria en ese escenario no cambia nada.
Ajustes de PalWorldSettings.ini que disparan el consumo
El archivo vive en Pal/Saved/Config/LinuxServer/PalWorldSettings.ini y todos los parámetros van dentro de una única línea gigante OptionSettings=(...). Edítalo siempre con el servidor apagado desde el gestor de archivos del panel, o se sobrescribirá al apagar.
Los cuatro parámetros de mayor impacto
BaseCampMaxNumInGuild— bases por guild (por defecto 4). Bajarlo a 2 o 3 es la palanca más directa sobre la carga de CPU en partidas pobladas.BaseCampWorkerMaxNum— Pals trabajadores por base (por defecto 15). Cada uno es una IA con pathfinding activo. Reducirlo a 10-12 alivia el hilo principal sin arruinar la experiencia.ServerPlayerMaxNum— reserva estructuras en memoria en función del máximo declarado. No pongas 32 si tu comunidad son 10 personas.PalSpawnNumRate— densidad de Pals salvajes en el mundo. Bajarlo a 0.8 reduce entidades simuladas de forma transversal.
Higiene del mundo: limpieza automática de guilds
El mayor generador de basura persistente son las guilds abandonadas. Estas dos claves eliminan automáticamente las que llevan tiempo sin actividad:
bAutoResetGuildNoOnlinePlayers=True,
AutoResetGuildTimeNoOnlinePlayers=72.000000Con 72 horas, una guild sin ningún miembro conectado durante tres días desaparece junto con sus bases. En una partida pública es la diferencia entre un Level.sav de 80 MB y uno de 400 MB seis meses después. Anúncialo claramente en tu Discord antes de activarlo.
Parámetros que no afectan al rendimiento
Mucha gente toca a ciegas creyendo que optimiza. Estos son puramente de balance y no cambian el consumo: ExpRate, PalCaptureRate, PalEggDefaultHatchingTime, DeathPenalty, CollectionDropRate. Modifícalos por gameplay, no por rendimiento. Los detalles completos de cada clave están en la documentación técnica oficial de Palworld.
Sobre los mods
Los mods de servidor (frameworks tipo UE4SS y sus scripts) añaden su propia sobrecarga al hilo principal y aumentan el tiempo de arranque. Como regla práctica, suma un 15-25 % de RAM sobre la referencia de la tabla anterior si vas a cargar varios, y prueba siempre la combinación en una instancia aparte antes de tocar la partida principal.
Rutina de administración para mantener el consumo bajo control
Dimensionar bien es la mitad del trabajo; la otra mitad es operativa. Esta rutina evita el 90 % de los tickets de "el servidor va a tirones".
Reinicios programados
Desde las tareas de Pterodactyl, define un reinicio diario en horario de baja actividad con aviso previo por RCON:
/Broadcast Reinicio_programado_en_5_minutos
/Save
/Shutdown 300 Mantenimiento_diarioTen en cuenta que /Broadcast no admite espacios: usa guiones bajos. Y ejecuta siempre /Save antes de cualquier parada manual, porque el autoguardado no es instantáneo.
Copias de seguridad y verificación
Las copias automáticas del panel te cubren ante corrupción del Level.sav, un escenario nada exótico en Palworld cuando el proceso se corta durante una escritura. Mantén al menos tres puntos de restauración escalonados y, una vez al mes, comprueba que una copia restaura de verdad. Un respaldo que nunca se ha probado no es un respaldo.
Seguridad básica
- Contraseña RCON larga y distinta de la de administración del juego.
AdminPasswordnunca compartida en el Discord público; usa subusuarios del panel para tus moderadores.- Si activas la REST API, mantenla escuchando en local o restringida, no expuesta abiertamente.
- La mitigación DDoS volumétrica ya está cubierta en Fly-Serv a nivel de infraestructura, así que tu trabajo se limita al control de accesos.
Comparado con otros juegos de supervivencia
Palworld se sitúa en la franja alta de consumo de memoria entre los títulos de supervivencia, por delante de Valheim y en un terreno parecido al de ARK Survival Ascended en partidas muy construidas. Si administras varias comunidades, encontrarás las referencias equivalentes de cada título en Todos nuestros servidores de juegos y más guías de administración en el Blog de Fly-Serv.
Conclusión
Dimensionar Palworld consiste en mirar dos números: la memoria ocupada tras varios días de partida y el serverframetime en hora punta. El primero se corrige con reinicios programados y limpieza de guilds inactivas; el segundo, limitando bases y trabajadores por guild. Con esas dos palancas y una frecuencia de CPU decente, una partida de 16 personas se mantiene estable durante meses.
FAQ
¿Cuánta RAM necesita una partida de Palworld para 10 jugadores?Cuenta con 16 GB útiles para trabajar cómodo. Con 12 GB funciona al principio, pero tras algunas semanas de bases construidas y con el crecimiento progresivo de memoria del proceso, empezarás a ver reinicios por falta de RAM. Programa además un reinicio diario para liberar memoria acumulada.
¿Por qué mi servidor Palworld va a tirones aunque la RAM no esté llena?Casi siempre es saturación del hilo principal de simulación. Consulta serverfps vía REST API: si está por debajo de 20, reduce BaseCampMaxNumInGuild y BaseCampWorkerMaxNum, y baja PalSpawnNumRate a 0.8. Añadir memoria en ese caso no soluciona nada.
Activa bAutoResetGuildNoOnlinePlayers=True con AutoResetGuildTimeNoOnlinePlayers entre 72 y 168 horas para eliminar guilds abandonadas y sus bases. Complementa con una limpieza manual periódica de estructuras huérfanas y verifica el tamaño del archivo cada mes desde el gestor de archivos del panel.