JoyBuilder AI Development Service Platform
JD Explore Academy · JDCloud Yunhai · Fully Reproducible
System Purpose
Question asked
Please describe the purpose and general usage of the submitted system. This would include the types of typical applications it supports (e.g., defense applications, molecular dynamics, benchmarking, system test, systems research), and the general use and purpose of the data generated by the applications running on it.
| The submitted system is a high-performance AI computing platform deployed at the JD Explore Academy HPC Data Center, serving as the core infrastructure for the JoyBuilder Model Development Platform. It delivers comprehensive, end-to-end support for large-scale AI model development workflows, including training, fine-tuning, and inference for advanced generative AI applications. Key Supported Workloads Large Language Model (LLM) Development Enables distributed training and optimization of large language models on the JoyBuilder platform, facilitating scalable and efficient model development. AI Model Fine-Tuning Provides platform-accelerated adaptation of foundation models, allowing rapid customization and enhancement for specific tasks and datasets. Generative AI Deployment Supports seamless transition from model development to production inference, ensuring robust deployment of generative AI solutions. |
Availability
Question asked
Please provide the deployment timeframe of the submitted system, or for on-demand cloud systems, the general period over which it is deployed and destroyed.
Please describe the availability of the system to users and who are its set of most regular users.
| The system was deployed in September 2025 and continues to operate reliably. Its primary users are AI model developers; however, it is also accessible to clients from diverse industries seeking solutions for AI scenario development. |
Storage System Software
Question asked
How is this storage software available? (e.g., commercially, open-source, not publicly available) Note that if the storage software is not open-source or commercially available, then a general description would be requested, but this would limit the submission’s reproducibility score.
Can anyone download/purchase this software?
List either product webpage or open-source repo of the exact software used in IO500.
Give any and all additional details of this specific storage deployment: (e.g., type of storage server product such IBM ESS or DDN SFA400X2, use of Ext4 or some other file system on each storage node, dual connected storage media to storage servers).
| The storage software utilized is JPFS, a commercially available parallel file system optimized for NVMe storage and high-performance computing (HPC) environments. JPFS is designed for the following use cases: AI training and inference High-performance computing (HPC) Large-scale data analytics Media processing and rendering Emerging technologies JPFS is vendor-agnostic and can be deployed on any supported commodity hardware equipped with NVMe drives and Mellanox-compatible networking. For more information, please visit: https://www.jdcloud.com/products/jpfs A public cloud version is also available at: https://www.jdcloud.com/products/cloud-file-service |
Runtime Environment
Question asked
State here that you provided all scripts/documentation that would allow someone else to reproduce your environment and attempt to achieve a similar IO500 score as the submitted system.
NOTE: provide all files/documentation/scripts that would enable a user to build your environment and deploy the custom scripts, software, or config files once they have obtained the appropriate storage system hardware and software. These may be included into the io500.tgz or into the extraCodes upload on the submission form.
Several examples include:
- Commands used to set striping information (either for the entire system or for particular directories)
- File system config and tuning information (or a reason why this is not available due to lack of root access, etc) on each node type (e.g., non-default config parameters on all three types of Lustre nodes: MDS, OSS, and client)
- Any additional scripts utilized that impact IO500 execution beyond the io500 config file. For example, with IBM Spectrum Scale, the output of mmlsconfig, mmlscluster, mmlsfs, and mmlsfileset commands (and possibly even a dump of the configuration if possible). Each file system probably has similar type of config/tuning information that would need to be shared for a user to fully reproduce the environment.
| The IO500 environment is fully reproducible. We utilize general-purpose servers with no customization. The IO500 benchmark was compiled and executed using a locally built OpenMPI version 5.0.7 without any modifications. A total of 10 compute nodes were used, each running 98 MPI processes and our filesystem client, ufs-client. Additionally, 20 data nodes were deployed, each running a mix of our data service (uds), metadata service (ums), and data storage service (ofs-data-server). Relevant tuning scripts and configuration files (e.g., io500.sh, MPI hostfile, mount options) can be provided upon request or included in the submission package. |
Fault Tolerance Mechanisms
Question asked
Does your system have a single point of failure as defined by “Definition 7” of a Production System? Please describe all mechanisms that provide fault tolerance for the submitted storage system. Be specific to your submission, not general storage system capabilities.
- Power (For example, can power failure of a node or rack bring down the storage system?)
- Networking (For example, can failure of a single NIC bring down the storage system? Remember that any networking failure that brings down multiple nodes is acceptable)
- Inter storage data and metadata server (For example, what type of data protection mechanism does the storage system use to keep operating during node failures, e.g., active-active servers, client-directed RAID, declustered RAID, erasure-coding, 3-way replication)
- Intra storage data and metadata server storage media (For example, how does the storage eysstem protect against fiailure of a single storage device within a node, e.g., raid5)
Please list any additional information needed to determine whether this system has a single point of failure.
| As a production system used for commercial purposes, our platform is designed with no single point of failure. Power: The storage infrastructure features redundant power feeds from both commercial and UPS sources, enabling continuous operation in the event of a failure of either power supply. Each storage server is equipped with dual power supplies (1+1 redundancy), ensuring uninterrupted service during a single power supply failure or rack PDU outage. Networking: Our management network employs a dual network card bonding strategy to ensure failover capability. While our data network utilizes a single InfiniBand (IB) network card, services are typically organized into in-memory, stateless shard groups based on load balancing strategies. If a network card failure is detected, a failover process is automatically triggered: a new node is selected to take over the shard group from the failed node, ensuring uninterrupted service. The same disaster recovery strategy applies in the event of node failures. Inter-storage data and metadata servers: Our storage system employs a three-replica strategy for metadata and a two-replica strategy for data. Replicas are distributed across different racks, providing tolerance to both server-level and rack-level failures. Intra-storage data and metadata server storage media: The system disk is protected by RAID 1. Each data disk is managed by a separate ofs-data-server process. In the event of a disk failure, a data repair program is triggered. During the repair process, data may be migrated to a new disk or node, and the system will automatically rebalance data to maintain redundancy and load balancing. |
Execution
Question asked
Please provide a description of how the IO500 benchmark was executed, e.g., via system scheduler (e.g., SLURM) to run a job on the compute cluster, which initially ran a setup process to configure the client and file system, and then started the full benchmark.
During the IO500 benchmark execution was the system entirely dedicated to running the benchmark or were there other jobs running in the same cluster and storage system?
| First, eight instances of ufs-client are started to mount the backend filesystem locally. Next, eight containers are launched, each mapping the corresponding local mount point into the container environment. Finally, the full benchmark is executed inside the containers using io500.sh. The mpirun arguments used: io500_mpiargs="--allow-run-as-root -np 960 --hostfile io500.hosts --mca btl_tcp_if_include eth0" The storage system was in a pre-production state during these tests and was dedicated exclusively to benchmarking. |
Caching
Question asked
Please describe all caching mechanisms in client/server that were utilized during the IO500 run. This could include caching in any storage medium (e.g., SSD, RAM).
A few examples would include:
- Client data/metadata caching (in Linux page cache or in other memory cache)
- Client side NVMe read-only data cache
- Storage server metadata/data caching in RAM
- Storage controller caching
- RAID card caching
| Our client kernel module, jdufs, is developed based on FUSE. It utilizes the Linux page cache for both data and metadata while maintaining full POSIX compliance. Our userspace client, ufs-client, employs a read-only metadata cache for recently accessed files and directories. Similarly, our metadata server, ums, uses a read-only metadata cache for recently accessed files and directories. All write operations to our metadata server (ums) and data server (uds) are written directly to the underlying NVMe storage as write-ahead logs (WAL). |
Data Source
Question asked
Is the submitted system a stand-alone storage system or an acceleration layer in front of another storage system that is the source of truth for all application data? This question relates to whether the submitted system is a burst buffer layered on primary storage or primary storage itself.
| The submitted system is a high-performance, stand-alone storage solution designed to serve as primary storage. It was developed entirely in-house and is fully compliant with POSIX standards. The system offers exceptional data security and scalability, providing stable and reliable storage support for enterprise-level applications. |
Trust
Question asked
Please describe any steps taken to ensure that the results are trustworthy.
- Did you run the benchmark multiple times and get similar scores?
- Did you validate the score is below the physical capabilities of the deployed hardware?
- How did you validate that the storage system follows the IO500 rules regarding persistence, which states, "All data must be written to persistent storage within the measured time for the individual benchmark, e.g. if a file system caches data, it must ensure that data is persistently stored before acknowledging the close"?
| To submit the final test result, I conducted multiple tests and obtained consistent scores, with variation within 5%. Through calculations and system monitoring, I have confirmed that the benchmark scores are below the physical capabilities of the deployed hardware. Our filesystem is fully compliant with the POSIX standard, strictly adhering to close-to-open semantics. This ensures that all data is persistently stored before acknowledging the close operation. |