Última revisión: 25 de septiembre de 2026 con Palworld v1.0.5 y la documentación del servidor de Pocketpair en la versión v1.0.4. Las mediciones de la época del Acceso Anticipado no son trasladables 1:1: la 1.0 (10/07/2026) trajo optimizaciones del servidor dedicado con muchos jugadores, y después llegaron la 1.0.2 a la 1.0.5.
Leer bien los requisitos oficiales
Para un servidor dedicado de Palworld, Pocketpair indica 16 GB de RAM, al menos cuatro núcleos de CPU recomendados y un SSD rápido. Estos datos son una recomendación del fabricante, pero no una tabla de jugadores por GB. No dicen que una cantidad determinada de RAM garantice automáticamente un número determinado de jugadores.
Encontrarás la fuente actual del fabricante en los requisitos oficiales del servidor de Palworld. Pocketpair advierte allí además de que un almacenamiento lento puede dañar los datos de guardado. Por eso, planifica juntos la RAM, la CPU y el almacenamiento.
Lo que hemos medido en nuestros servidores
En nuestros servidores de clientes en funcionamiento con hasta 4 jugadores activos al mismo tiempo, el uso de RAM se mantuvo por debajo de 6 GB con un reinicio diario, sin cierres por falta de memoria (medición de 14 días, octubre de 2026). Los picos estuvieron entre 3,4 y 5,3 GB, independientemente del plan contratado. En cambio, la CPU fue el cuello de botella: con cada jugador adicional, la carga de CPU aumentaba notablemente, y un servidor con 4 jugadores llegó por momentos al límite de CPU. Para grupos más grandes no tenemos valores de medición propios.
Si quieres que jueguen más jugadores al mismo tiempo, elige un plan con un límite de CPU más alto o contrata un núcleo adicional: +1 vCPU por 2,99 € al mes, con un máximo de 2 núcleos adicionales.
| Componente | Clasificación oficial | Consecuencia para tu planificación |
|---|---|---|
| RAM | 16 GB de requisito de funcionamiento | Dato del fabricante; en nuestros servidores de clientes con hasta 4 jugadores, la necesidad se mantuvo por debajo de 6 GB |
| CPU | se recomiendan al menos cuatro núcleos | determina cuántos jugadores pueden jugar con fluidez; más jugadores requieren un límite de CPU más alto |
| Almacenamiento | Se recomienda un SSD rápido | No descuidar los datos de guardado ni la E/S |
Por qué el número de jugadores por sí solo no da una fórmula de RAM
Dos mundos con el mismo número de jugadores conectados pueden generar una carga totalmente distinta. Un mundo nuevo en el que un grupo viaja junto se comporta de forma diferente a un mundo que lleva mucho tiempo en marcha, con bases repartidas, muchos Pals trabajadores, grandes complejos de construcciones y una tasa de aparición elevada. También las zonas del mundo activas al mismo tiempo, la automatización y los ajustes modificados del servidor influyen en el trabajo que debe realizar el servidor dedicado.
Por eso, el número máximo de participantes es un límite de acceso y no un medidor directo de recursos. Una afirmación general como una cantidad fija de RAM por jugador ignora el estado del mundo, la carga de CPU y los accesos a memoria. Usa el número de jugadores como valor de contexto, pero decide una mejora de plan solo junto con datos de medición reproducibles.
Construir una línea base de medición útil
Primero define una ventana de carga típica. Puede ser una noche de comunidad, un evento de jefe o una fase en la que varios grupos trabajan al mismo tiempo en distintas bases. Durante esa ventana, registra como mínimo los jugadores conectados al mismo tiempo, el uso de RAM y CPU, los FPS del servidor, el frame time, el número de bases y los eventos llamativos de los registros. Los FPS del servidor y el frame time los obtienes a través de la API REST del servidor (RESTAPIEnabled=True en PalWorldSettings.ini, después GET /v1/api/metrics): devuelve serverfps, serverframetime, currentplayernum y uptime. Anota además qué tasas de aparición y ajustes relevantes para el rendimiento estaban activos.
Un solo pico no basta como prueba. Repite la observación en momentos comparables y documenta si la saturación es continua o solo aparece brevemente. Anota también la versión del parche: desde la versión 1.0, Palworld comprueba la versión de forma estricta, y un servidor sin actualizar rechaza como incompatibles a los clientes con una versión más reciente. Además, una actualización del juego o una nueva fase del mundo puede cambiar la carga sin que aumente el número de jugadores. Esta línea base hace posibles las comparaciones posteriores de antes y después.
Separar los cuellos de botella de RAM de otras causas
Antes de ampliar la RAM, revisa el tiempo de ejecución del proceso: el servidor de Palworld ocupa más memoria con cada hora de funcionamiento, también después de la versión 1.0. Si el consumo de RAM crece de forma constante con el mismo número de jugadores y vuelve al valor inicial tras un reinicio, la medida adecuada es un reinicio programado (con guardado previo, en la franja horaria tranquila), no una ampliación.
Una ampliación de RAM es plausible si el proceso alcanza repetidamente el límite disponible, aparecen eventos OOM o el servidor funciona de forma reproducible más estable con más memoria bajo una carga comparable. Un valor alto de uso, por sí solo, no demuestra una carencia: el sistema operativo y la aplicación pueden usar memoria libre como caché. Lo decisivo son la saturación, el cuadro de errores y el comportamiento repetible.
Comprueba la CPU en paralelo. En nuestros servidores de clientes fue con más frecuencia el cuello de botella que la RAM. Si algunos núcleos están al máximo de forma continua mientras aún queda reserva de RAM, más memoria no resuelve el verdadero cuello de botella. La caída de los FPS del servidor o el aumento del frame time pueden estar relacionados tanto con el trabajo de la CPU como con estados complejos del mundo. Por eso, no cambies a la vez la RAM, la asignación de CPU y la tasa de aparición; de lo contrario ya no se podrá determinar qué medida fue la eficaz.
Incluir el almacenamiento y la seguridad de las partidas guardadas
Pocketpair recomienda almacenamiento SSD rápido y advierte de un riesgo para los datos de guardado con un almacenamiento poco potente; la página de requisitos desaconseja expresamente Docker Desktop, porque aumenta el riesgo de partidas dañadas. bIsUseBackupSaveData (activado por defecto) crea copias de seguridad rotativas en la carpeta de partidas guardadas y, a cambio, cuesta carga de disco adicional. Por eso, vigila los errores de E/S, los procesos de guardado inusualmente largos y el espacio libre. Antes de cada prueba con mods, cambios de configuración mayores o actualizaciones del servidor, crea una copia de seguridad verificable. La guía Guardar y restaurar el mundo de Palworld describe el procedimiento adecuado.
Una copia de seguridad solo es fiable cuando sabes dónde está, qué estado del mundo contiene y cómo funciona la restauración. No realices pruebas de carga arriesgadas sobre la única copia de tu mundo de producción. Así evitas que una investigación de rendimiento acabe ella misma en pérdida de datos.
Probar los cambios de forma controlada
Antes del cambio, crea un breve plan de comprobación: ¿qué síntoma debe desaparecer, qué valor de medición debe mejorar y en qué ventana de carga comparable se comprobará? Después haz una copia de seguridad del mundo y cambia exactamente una variable. Ante un posible cuello de botella de RAM, es la capacidad de memoria; ante un cuello de botella de CPU, un límite de CPU más alto, por ejemplo mediante un núcleo adicional, o un ajuste relevante para el rendimiento.
Reinicia el servidor limpiamente tras el cambio y repite la ventana de carga documentada. Compara no solo un valor pico, sino la estabilidad, los eventos OOM, la RAM, la CPU, los FPS del servidor y el frame time. Si el problema sigue igual, revierte el cambio o investiga el siguiente cuello de botella fundamentado. Si el comportamiento mejora de forma reproducible, documenta la nueva línea base y el desencadenante.
Para los cambios de configuración, usa la guía Configurar los ajustes del servidor de Palworld. La lista oficial de argumentos de Pocketpair explica, entre otras cosas, el puerto de escucha, el número máximo de participantes y las indicaciones actuales sobre los argumentos de rendimiento. No copies parámetros de inicio a ciegas de publicaciones antiguas de la comunidad, porque para la versión 1.0 y posteriores el fabricante señala expresamente, en ciertos parámetros de multithreading anteriores, un posible mejor comportamiento sin ellos.
Revisión de capacidad tras actualizaciones y crecimiento del mundo
Desde la v1.0.3, bAllowEnemyCampSpawnNearBaseCamp=False limita las apariciones de raids cerca de las bases de los jugadores, y desde la v1.0.4 MaxBuildingLimitNum fija un tope a las piezas de construcción por jugador; ambos son interruptores relevantes para el rendimiento. El clustering de servidores, anunciado en junio de 2026, no se ha entregado hasta la v1.0.5, así que el reparto de carga entre varias instancias sigue sin ser una opción.
Un valor medido una vez no sigue siendo correcto de forma permanente. Repite la comprobación después de actualizaciones importantes de Palworld, de un fuerte crecimiento de las bases, de cambios en las tasas de aparición y de una comunidad claramente más grande. Compara siempre con la última línea base estable. Así sabrás si realmente ha cambiado la necesidad de recursos o si ha surgido un nuevo error independiente de la RAM y la CPU.
Usa el mismo orden para cada decisión: comprobar la base mínima oficial, hacer una copia de seguridad del mundo, registrar valores de medición, clasificar el cuello de botella, probar exactamente un cambio y documentar el resultado. Así evitas tanto instancias demasiado pequeñas como mejoras de plan caras que no resuelven un error de CPU, almacenamiento o configuración.
FAQ
¿Bastan 6 GB de RAM para un servidor de Palworld?
En nuestros servidores de clientes en funcionamiento con hasta 4 jugadores activos al mismo tiempo, el uso de RAM se mantuvo por debajo de 6 GB con un reinicio diario, sin cierres por falta de memoria (medición de 14 días, octubre de 2026). Pocketpair indica 16 GB de RAM como requisito de funcionamiento. Para grupos más grandes no tenemos valores de medición propios.
¿Cuánta RAM necesito por jugador?
No existe una fórmula fija fiable para ello. El número de jugadores, las bases, los Pals trabajadores, las construcciones, la tasa de aparición, los ajustes y las zonas del mundo activas al mismo tiempo influyen conjuntamente en la carga. En nuestros servidores, con cada jugador aumentaba sobre todo la carga de CPU, y apenas la RAM. Decide la capacidad adicional según valores de medición repetibles.
¿Cuándo necesito más RAM o un límite de CPU más alto?
Más RAM ayuda cuando la saturación de RAM o los eventos OOM aparecen de forma reproducible bajo una carga comparable. Si la CPU está de forma continua en el límite mientras hay RAM libre, necesitas un límite de CPU más alto, por ejemplo mediante un núcleo adicional.
¿Ayuda más RAM contra cualquier tipo de lag?
No. La saturación de CPU, el almacenamiento lento, la complejidad del mundo, los problemas de red y los ajustes inadecuados pueden generar síntomas similares. Comprueba juntos la RAM, la CPU, los FPS del servidor, el frame time, los registros y el almacenamiento antes de determinar una causa.
¿Qué debo guardar antes de una prueba de rendimiento?
Crea una copia de seguridad verificable del mundo y documenta la versión del parche y los ajustes. Después cambia solo una variable y repite una ventana de carga comparable. Así el resultado sigue siendo trazable y el mundo en producción se puede restaurar.