Disclaimer
Since A5p is still in the new-product internal testing stage, the test results only represent performance during internal testing and are for reference only. Final performance is subject to the product after its official release.
This article does not constitute purchase advice. Please place your order rationally.
Introduction
This time I received two fully configured A5p test machines: one standard model and one storage model with a large-capacity disk. Compared with the previous A5m from the same provider (review: 「只测不评」VPS.Town A5m 新品大内存机内测), the main improvements in the newly released A5p are its better CPU and support for large-capacity disks, which is very welcome.
This test used the top-end 12C48G configuration, with a 120G SSD system disk, a 1T data disk on the storage model, 3Gbps bandwidth, and 8T monthly traffic. (This configuration is for reference only and does not represent the final retail configuration.)
NL Aggregated Script Tests
Standard Model
Original test result: NodeLoc VPS Benchmark Results
[The benchmark output is preserved unchanged.]
Storage Model
Original test result: NodeLoc VPS Benchmark Results
[The benchmark output is preserved unchanged.]
Fusion Monster Script Tests
Standard Model
Original test result: PasteBin - VPS测评平台
[The benchmark output is preserved unchanged.]
Storage Model
Original test result: PasteBin - VPS测评平台
[The benchmark output is preserved unchanged.]
Sysbench and Sustained Load
To reduce single-run errors, the same version and parameters were used for three runs each with one thread and 12 threads, taking the median.
| Item | A | B |
|---|---|---|
| One thread, median of three runs | 461.13 events/s | 458.80 events/s |
| 12 threads, median of three runs | 5521.69 events/s | 5512.34 events/s |
| 12 threads, 180-second continuous average | 5518.98 events/s | 5512.49 events/s |
Under this workload, the two test machines performed very similarly, with multithreaded throughput approaching 12 times single-threaded throughput. The 30-second segments during sustained load were also fairly stable, with no obvious stepwise slowdown during the three-minute test.
An additional AES-256-GCM test using OpenSSL 3.5.1 was performed: with 16KiB blocks, a single process achieved approximately 3.79GB/s, while 12 processes combined achieved approximately 45.2–45.4GB/s. This is algorithm throughput, not HTTPS service throughput or actual network throughput.
STREAM Large Working-Set Bandwidth
STREAM was compiled and run with three arrays totaling 1.5GiB, using 20 iterations per run. Both one-thread and 12-thread tests were run three times. The following are the medians, in decimal GB/s.
| STREAM Triad | A | B |
|---|---|---|
| 1 thread | 9.28GB/s | 12.57GB/s |
| 12 threads | 38.99GB/s | 22.62GB/s |
| Numerical validation | All passed | All passed |
The capacity results were fairly consistent, but bandwidth varied between samples and runs. B’s three 12-thread Triad runs were approximately 32.59, 22.62, and 20.72GB/s. A larger amount of memory should not be equated with consistent memory bandwidth on every machine. For workloads highly dependent on memory throughput, retesting on the machine actually allocated to you is recommended.
1MiB Sequential Read/Write, QD1
| Test disk | Read | Write |
|---|---|---|
| 480GiB system disk | 1500.0MiB/s | 1152.9MiB/s |
| 120GiB system disk | 1499.9MiB/s | 1189.0MiB/s |
| 1000GiB data disk | 1452.8MiB/s | 1191.3MiB/s |
All three disks delivered impressive sequential read/write performance. For scenarios such as moving large files, archiving, and reading model files, the data disk was not noticeably slower simply because of its larger capacity.
4KiB Random Read/Write
| Test disk | QD1 random read | QD1 random write | QD32 random read | QD32 random write |
|---|---|---|---|---|
| 480GiB system disk | 24124 IOPS | 15611 IOPS | 49995 IOPS | 39375 IOPS |
| 120GiB system disk | 22152 IOPS | 17157 IOPS | 49995 IOPS | 39451 IOPS |
| 1000GiB data disk | 5000 IOPS | 3987 IOPS | 4999 IOPS | 3970 IOPS |
There is a very clear difference here: the 1T data disk’s random I/O was significantly lower than that of the system disks, and increasing queue depth did not bring its throughput close to that of the system disks.
At QD1, the system disks’ average completion latency for 4K reads was approximately 0.036–0.039ms, compared with approximately 0.195ms for the data disk. For 4K writes, the figures were approximately 0.051–0.056ms and 0.244ms, respectively. The data disk’s QD1 P99 completion latency was approximately 1.09ms for reads and 1.12ms for writes.
Single-Threaded Writes with fsync on Every Operation
Ordinary random writes do not mean that every operation completes with a synchronous commit, so an additional set of 4K write + fsync=1 tests was performed, with each disk tested for 20 seconds.
| Test disk | Write IOPS | Average fsync latency | fsync P99 latency |
|---|---|---|---|
| 480GiB system disk | 2292 | 0.369ms | 0.489ms |
| 120GiB system disk | 2657 | 0.312ms | 0.481ms |
| 1000GiB data disk | 2100 | 0.357ms | 1.368ms |
The fsync latency in the table is the latency of the synchronous operation itself, not the total latency of a complete write plus synchronization. Write IOPS reflects the actual throughput of this single-threaded serial process. It is a more relevant reference for synchronously committed workloads than purely asynchronous write IOPS, but it is still not a database transaction test and does not guarantee safety in the event of physical power loss.
1T Data Disk: 64GiB Sequential Write and Readback
To avoid looking only at the short-run result of a small file, an additional 64GiB sequential write and readback test was performed on the data disk. It used 1MiB blocks, QD8, and direct I/O, with fsync executed after writing finished.
| Item | fio result |
|---|---|
| Sequential write, 64GiB | 963.8MiB/s, approximately 68.0 seconds |
| Sequential read, 64GiB | 1535.0MiB/s, approximately 42.7 seconds |
| Separate 4GiB CRC32C write/readback verification | Passed, 0 errors |
Network
It is still the same traditional internationally optimized route. There is not much to say; in any case, it is not specifically optimized for routes toward mainland China.
Large Language Models
Since there is so much memory, it is only natural to try running a large language model.
On the A5p, Ollama 0.35.0 was used to run deepseek-r1:14b (the 14B Qwen-distilled version of DeepSeek-R1, not the full 671B version). The context was set to 4096, the thread count to 12, and num_gpu=0 was explicitly configured. VRAM usage was 0 in the runtime status.
| Run | Output tokens | Decoding throughput |
|---|---|---|
| Run 1, including initial loading | 128 | 3.92 token/s |
| Run 2, warm load | 128 | 4.22 token/s |
| Run 3, warm load | 128 | 4.98 token/s |
The initial model load took approximately 16.4 seconds, while the runtime status reported model usage of approximately 9.92GB. This confirms that a quantized 14B model can be loaded in practice and produce short outputs on the CPU, but approximately 4 tokens per second is not a substitute for GPU inference.
Three different short prompts were used, and all runs reached the 128-token output limit. Throughput includes the model’s reasoning tokens and is not a measure of complete response speed, response quality, or long-context performance. Cold-start loading time was also excluded from the decoding token/s calculation.
Recommendations
Services that are relatively suitable:
- Development environments or lightweight service consolidation using multiple containers and services: there is ample memory, and 12 vCPUs provide room for parallel workloads.
- Java services, larger caches, or memory-intensive applications: capacity is an advantage, but room must still be reserved for the system, persistence, and memory peaks.
- Data where large files, model weights, archives, and capacity are priorities: the data disk offers good sequential throughput.
- Services primarily serving users in Hong Kong or internationally: latency within Hong Kong was low in this test, although actual user routes still need to be verified separately.
Services that are less recommended:
- Low-latency services for mainland China: latency to the three major networks was not an advantage in this test.
- Databases with high requirements for high-concurrency random I/O on the data disk: approximately 5,000 random-read and 4,000 random-write IOPS are in a different class from the system disks.
- Long-term, exclusively fully loaded computation: long-term CPU policies and performance over extremely long periods were not verified.
- Uses that depend on permanent access to a specific platform: the results differed between the two IP addresses.
- Data warehouses containing the only copy of data: a large disk is not a backup, nor does it mean that underlying data redundancy and disaster recovery have been verified.
Conclusion
The combination of abundant memory and a large disk does significantly improve the A5p’s versatility. Whether it is truly outstanding or merely ordinary, however, is for you to judge based on your own usage scenarios 
As for the price, I hope the provider will continue not to disappoint us 