Efison Lisan Teknologi https://efisonlt.com/ Computation for Everybody Thu, 28 May 2026 10:38:46 +0000 en-US hourly 1 https://wordpress.org/?v=7.0 https://efisonlt.com/wp-content/uploads/2020/03/cropped-efison_logo_orange-skuer-32x32.png Efison Lisan Teknologi https://efisonlt.com/ 32 32 Our Experience with MSI EdgeXpert – Nvidia DGX Spark GB10 https://efisonlt.com/our-experience-with-msi-edgexpert-nvidia-dgx-spark-gb10/?utm_source=rss&utm_medium=rss&utm_campaign=our-experience-with-msi-edgexpert-nvidia-dgx-spark-gb10 Thu, 28 May 2026 07:48:40 +0000 https://efisonlt.com/?p=1974 “Agentic AI”. That’s the key phrase. Everybody is talking about how we should utilise AI on our life. Invest on the skill, buy your own hardware, they said. And this one is probably the best gateway hardware out there. Behold! A mini AI supercomputer (Nvidia’s words, not mine) Such a big statement, I thought. But… Read More »Our Experience with MSI EdgeXpert – Nvidia DGX Spark GB10

The post Our Experience with MSI EdgeXpert – Nvidia DGX Spark GB10 appeared first on Efison Lisan Teknologi.

]]> “Agentic AI”. That’s the key phrase.

Everybody is talking about how we should utilise AI on our life. Invest on the skill, buy your own hardware, they said.

And this one is probably the best gateway hardware out there.

Behold! A mini AI supercomputer (Nvidia’s words, not mine)

Such a big statement, I thought. But after a short exploration, this thing is really a minified supercomputer in many different aspects. It has this enterprise-level of software support, clustering, network interface, and also the emphasis on being an AI server, not just a mere mini PC.

I won’t rewrite the full specification table here. You can see it yourself on MSI EdgeXpert page or Nvidia DGX Spark page.

But let me tell you all the interesting parts.

At a Glance

Ignore the scratches. Not mine to blame. It has almost a half of its height dedicated for an intake grill.
Back view. On top is the exhaust grill. All the physical interfaces are on the backside. Yes, including the power button.
USB ports
4*USB type-C, no USB type-A in sight.
The ConnectX-7 200 Gbps ports for a better clustering support compared to any mini PC I’ve ever seen.

The omission of power LED or any power-on indicator is kinda heartbreaking, tho.

Hardware Overview

This system is using a custom multi-chip package SoC called Nvidia GB10. The GB10 is consisted of (should be) Grace Arm CPU and Blackwell GPU. Nvidia didn’t really mention the specific name of both the CPU and GPU so I’ll put the specification below to represent the number of the compute unit count instead.

ComponentSpecification
CPU10-core Arm Cortex-X925, 10-core Arm Cortex-A725
GPU48-SM Blackwell
Storage1 TB NVMe
Memory128 GB 256-bit LPDDR5x unified
Memory Bandwidth273 GB/s
Ethernet10 GbE RJ-45
High-Speed NetworkConnectX-7 NIC @ 200 Gbps
Wireless ConnectionWifi 7, Bluetooth 5.4
Power Supply240 W AC-to-DC power brick via USB type-C
BMC/IPMINone

As it stands, my main complaint is the lack of baseboard management controller (BMC) to remotely monitor the state of the hardware, connect to a virtual KVM to the server, and to control the power state, exclusive from the OS. This way, you can only get the monitoring of the unit after you boot into the OS. Well, unfortunately Nvidia decided it is not supercomputer enough to bear the right of having a BMC.

Software Overview

This one is a more interesting one. The OS is called DGX OS officially, but it’s actually an Ubuntu 24.04 with some “custom sauce” from Nvidia.

neofetch of DGX Spark.

The “custom sauce” lies on the repository being used for delivering packages optimised for the GB10 which are maintained and deployed by Nvidia.

Nvidia repo for DGX Spark.

It comes with GNOME Desktop Environment if you fancy using it as a normal desktop PC. You can install various software through command line or Software Center in a typical Ubuntu desktop fashion.

Webcam works, too, if you feel like wanting to plug a webcam.

As it is a mini server, it has this cute quirk, which is you’ll find no sleep (or hibernate) option. You can only set the power saving to blank the screen after being left idle for some time. Well you don’t want your server to suddenly sleep in the middle of serving, no?

No sleep. Sleep is for the weak. Excuse my keyboard (Bridge75) for the photobomb.

Being an AI Server: Default Software

After first boot and setup, you’ll get yourself a default dashboard called DGX Dashboard which can be accessed by a browser. The default address is http://localhost:11000 which can only be accessed locally from the machine itself. But you can easily redirect it with a proxy or tunneling just fine.

DGX Dashboard

As can be seen above you can easily see simple statuses of the hardware and launch a JupyterLab which would then can be used as PyTorch or TensorFlow development environment just as easy. From there you can use the underlying hardware both CPU and GPU to develop or test your various Jupyter workflow.

From the same dashboard we can click on the Updates menu to… update. Nvidia recommends updating from this dashboard instead of using CLI, and you will also get your firmware or UEFI update from this same interface.

DGX Dashboard: Updates

Continuing right there is a Settings menu which can be used to change the hostname and enable/disable telemetry.

DGX Dashboard: Settings

The next three buttons on the right are external links in which you can interact with:

Docs: Product Documentation and User Manual

Here you can look for everything you need to know about DGX Spark down from its hardware, software, configuration, release notes, system update guide, how to get support, to legal information. This is as complete as you want it to be. Personally I found that this is the most complete manual ever written for a mini PC. Oh wait it’s a mini supercomputer, not just a mini PC.

Docs button will bring you to DGX Spark User Guide site.

Forums: Discussion Boards

Do you ever feel like missing a bulletin boards? Or interacting with a bunch of geniuses around the world who have the same systems? Afraid not! This forum is as lively as it can, with Nvidia moderators also actively participates in the discussions. Maybe someone has a crazy idea, maybe someone has a solution for a particular problem, you name it. Lovely.

Lively forum.
Maybe a little bit too lively. But what is life without genius madlads around?

Resources: Guides for Deploying AI Softwares

For me this is one of the killer features. This is the guide for building, running, and deploying any popular AI software, some with prebuilt container images or models built by Nvidia themselves. Again, personally this has been the best resources provided by first-party for users to have the least possible headache of running any AI software they want to use.

They encourage you to build any AI software in the easiest way possible.
Example: vLLM serving guide.
They have their ready-to-run models, if you prefer.
You can also use Nvidia’s prebuilt container image from the NGC.

CPU (and Memory) Performance Benchmarks

Here I tested some benchmarks to portray how fast it is in general tasks.

Geekbench 6

It slightly beat my desktop PC which has a bigger cooler and consumes more power.

Geekbench 6 result against an 8P core i7-12700K.

Phoronix Linux Kernel 7.0 Compilation

Unfortunately it fell short in compilation performance. Personally, I also found this machine to be quite slow during Nunchaku wheel compilation which I will explain later on.

Compilation time of Linux Kernel 7.0.

It is slower than an aging 8-core 8-thread i7-9700. Ouch.

Linux kernel 7.0 compilation time comparison on various different CPUs.

Phoronix SVT-AV1 4.0

Similar picture painted when tested against SVT AV1 encoding using CPU.

AV1 encoding speed using SVT library.

It’s only marginally faster than an aging 4-core 8-thread mobile CPU i7-8550U.

SVT-AV1 performance comparison on various different CPUs.

Phoronix 7-zip 26.01 Compression and Decompression

This one yielded a better outcome. My theory would be the large memory bandwidth helps with the compression/decompression performance by much and feeds the cores with the necessary data nicely.

7-zip 26.01 file compression speed.

Only slightly lower than another mini AI machine (Ryzen AI Max+ 395) and faster than the current gen mainstream-class Intel desktop CPU (Core Ultra 5 250K Plus).

7-zip 26.01 file compression performance on various different CPUs.

The decompression performance also painted a good number.

7-zip 26.01 file decompression speed.

Albeit a much bigger gap against the Ryzen AI Max+ 395. Still respectable nonetheless.

7-zip 26.01 file decompression performance on various different CPUs.

Comparison against A Similar Mini AI Machine

It’s been a year or so that AMD released the Strix Halo (Ryzen AI Max+ 395 with integrated Radeon 8060S). I actually tested one but haven’t written any article about it (sorry 😥). Now when you see the raw specification, they’re kinda similar in stature.

DGX SparkStrix Halo
Memory128 GB 256-bit LPDDR5x unified128 GB 256-bit LPDDR5x shared
Memory Bandwidth273 GB/s256 GB/s
Smallest Floating Point SupportNVFP4, MXFP4BF16, FP16
Smallest Integer SupportINT4INT4

But it has this glaring difference: DGX Spark supports a smaller floating point data type.

Aside from the data type support, you can also look at the memory. DGX Spark uses unified memory while Strix Halo uses shared memory. This is different in nature.

With unified memory, you get a transparent memory addressing in which the CPU and GPU can access the same memory address, making it possible for the CPU or GPU-bound application to get more memory available on the pool on-demand. They can access the same 128 GB available memory in whole.

Strix Halo, uses shared memory in which you need to set a fixed amount of shared UMA (unified memory address) size available for the GPU. While the GPU can dynamically allocate the GPU memory to the available memory address, the fixed amount of shared UMA is locked for GPU and the CPU can only use the remaining memory pool. For example you can set the UMA size of 1 GB statically set to the GPU, then the

We’ll see the difference in performance later on.

LLM Performance

First, I need to talk about sidelining llama.cpp for vLLM. The reason is llama.cpp wouldn’t be representative for this machine LLM capability measurement. As I already presented above, it has a large unified memory capacity of 128 GB. With this much of a memory, you are not on the mercy of GGUF models with llama.cpp and you can just run the non-GGUF quantized model with an inference engine good enough to serve more requests.

Wait that explanation isn’t really helpful, right?

Let me just show you this model size comparison.

Here are unsloth/Qwen3.6-35B-A3B-GGUF models’ size.

With GGUF model, you can grab a lower quantization easily to scale with your memory capacity.

And this is unsloth/Qwen3.6-35B-A3B-NVFP4 model size.

This non-GGUF model only has one variant, which is 23 GB in size.

llama.cpp will allocate certain parts of the memory to be used as KV cache. This number is fixed based on the data type being used and the context length set up in the llama-server directive. It can’t grow or shrink to fit the available memory, nor set up on-the-fly when the inference server is running.

In this example, I used context length of 262144 tokens, K cache data type of q4_0, and V cache data type of q4_0. It used 1440 MB of the available memory for the context alone, independent from the memory needed to run the model.

Unlike llama.cpp, when you use an enterprise focused inference engine like vLLM, you can use the remaining available memory for more concurrency.

In this example, the remaining 67.5 GB after loading the data would be allocated as KV cache memory, which then translate to 13.3 of maximum concurrencies estimation.

Now when we put the comparison side-by-side, you can see that vLLM can serve more concurrent requests easily compared to llama.cpp, even with a similarly sized GGUF model. All the benchmarks were done with llama-benchy for easy benchmarking tool and consistency.

llama.cpp serve command line, model: unsloth/Qwen3.6-35B-A3B-GGUF, UD-Q4_K_XL quantization
Bash
llama-serve \
  --model unsloth/Qwen3.6-35B-A3B-GGUF/Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf \
  --mmproj unsloth/Qwen3.6-35B-A3B-GGUF/mmproj-BF16.gguf --image-min-tokens 1024 \
  -ctk q8_0 -ctv q8_0 -c 262144 -ub 4096 -b 4096 \
  -fa 1 \
  --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.0 \
  --presence-penalty 0.0 --repeat-penalty 1.0 \
  --parallel 1 --threads 16 \
  --host 0.0.0.0 --port 8000 \
  --jinja
vLLM serve command line, model: unsloth/Qwen3.6-35B-A3B-NVFP4
Bash
podman run \
  -p 8000:8000 \
  --device nvidia.com/gpu=all \
  -v ~/.cache/huggingface:/root/.cache/huggingface:Z \
  docker.io/vllm/vllm-openai:cu130-nightly unsloth/Qwen3.6-35B-A3B-NVFP4 \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder --reasoning-parser qwen3 \
  --trust-remote-code \
  --dtype float16 \
  --max-model-len -1 \
  --gpu-memory-utilization 0.8
llama-benchy benchmarking line for the llama.cpp server, model: unsloth/Qwen3.6-35B-A3B-GGUF, UD-Q4_K_XL quantization
Bash
llama-benchy \
  --base-url http://${HOST}:8000/v1 \
  --model Qwen3.6-35B-A3B-UD-Q4_K_XL.gguf \
  --depth 0 8192 \
  --pp 2048 --tg 256 \
  --concurrency 1 2 4 \
  --no-results-on-fail
llama-benchy benchmarking line for the vLLM server, model: unsloth/Qwen3.6-35B-A3B-NVFP4
Bash
llama-benchy \
  --base-url http://${HOST}:8000/v1 \
  --model unsloth/Qwen3.6-35B-A3B-NVFP4 \
  --depth 0 8192 \
  --pp 2048 --tg 256 \
  --concurrency 1 2 4 \
  --no-results-on-fail
The llama.cpp fell through in prompt processing performance when faced with more than 1 concurrent request.
Similar story with the token generation performance. Although not as dramatic as the prompt processing one.

Now that I’ve already put out my reasons, let’s continue to the vLLM benchmarks.

But wait, there’s more. I also put Radeon AI Pro R9700 as another data for comparison.

DGX SparkRadeon AI Pro R9700Strix Halo
Memory128 GB 256-bit LPDDR5x unified32 GB 256-bit GDDR6 dedicated128 GB 256-bit LPDDR5x shared
Memory Bandwidth273 GB/s644.6 GB/s256 GB/s
Smallest Floating Point SupportNVFP4, MXFP4FP8BF16, FP16
Smallest Integer SupportINT4INT4INT4

vLLM Container Image Version

For the vLLM deployment, I used these container images running on Podman for each machine, as I found them to be the most performant at the time of testing (18 May 2026).

Machine/GPUContainer Image
DGX Sparkdocker.io/vllm/vllm-openai:cu130-nightly
Radeon AI Pro R9700docker.io/rocm/vllm-dev:nightly
Strix Halodocker.io/kyuz0/vllm-therock-gfx1151:latest

Also here are the vLLM inference engine serving lines for each GPU:

vLLM serve command line for DGX Spark
Bash
podman run \
  -p 8000:8000 \
  --device nvidia.com/gpu=all \
  -v ~/.cache/huggingface:/root/.cache/huggingface:Z \
  docker.io/vllm/vllm-openai:cu130-nightly ${MODEL} \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder --reasoning-parser qwen3 \
  --trust-remote-code \
  --dtype float16 \
  --max-model-len -1 \
  --gpu-memory-utilization 0.8
vLLM serve command line for Radeon AI Pro R9700
Bash
# Create distrobox
distrobox create vllm \
  --image docker.io/rocm/vllm-dev:nightly \
  -- \
  --device /dev/dri --device /dev/kfd \
  --group-add keep-groups --security-opt seccomp=unconfined

# Enter distrobox
distrobox enter vllm

# Run vllm serve inside the distrobox
vllm serve \
  ${MODEL} \
  --host 0.0.0.0 --port 8000 \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder --reasoning-parser qwen3 \
  --trust-remote-code \
  --dtype float16 \
  --max-model-len -1 \
  --gpu-memory-utilization 0.9 \
  --enforce-eager
vLLM serve command line for Strix Halo
Bash
# Create distrobox
distrobox create vllm-gfx1151 \
  --image docker.io/kyuz0/vllm-therock-gfx1151:latest \
  -- \
  --device /dev/dri --device /dev/kfd \
  --group-add keep-groups --security-opt seccomp=unconfined

# Enter distrobox
distrobox enter vllm-gfx1151

# Run vllm serve inside the distrobox
VLLM_ROCM_USE_AITER=1 vllm serve \
  ${MODEL} \
  --host 0.0.0.0 --port 8000 \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder --reasoning-parser qwen3 \
  --trust-remote-code \
  --dtype float16 \
  --max-model-len -1 \
  --gpu-memory-utilization 0.8
llama-benchy benchmarking for the vLLM servers
Bash
llama-benchy \
  --base-url http://${HOST}:8000/v1 \
  --model ${MODEL} \
  --depth 0 8192 16384 32768 \
  --pp 2048 --tg 256 \
  --concurrency 1 2 4 8 \
  --no-results-on-fail

vLLM Performance, Qwen/Qwen3.5-35B-A3B-GPTQ-Int4

First, I used an exact same model, Qwen/Qwen3.5-35B-A3B-GPTQ-Int4, which is Qwen3.5-35B-A3B model that has been quantized to int4 (4-bit integer). This way we can measure the performance without resorting to any hardware data type support advantage.

vLLM prompt processing performance using Qwen/Qwen3.5-35B-A3B-GPTQ-Int4 from DGX Spark, R9700, and Strix Halo.

As we can see above, the Radeon AI Pro R9700 was able to beat the DGX Spark when the prompt has no meaningful context length. But, the DGX Spark was able to gain advantage, even so slightly, on deeper contexts. Unfortunately, the Strix Halo fumbled big with the performance was nowhere around those two.

vLLM token generation performance using Qwen/Qwen3.5-35B-A3B-GPTQ-Int4 from DGX Spark, R9700, and Strix Halo.

Funnily enough, even with lower memory bandwidth (273 GB/s vs 644.6 GB/s), the DGX Spark was able to blow the Radeon AI Pro R9700 out of the water. Don’t even mention the Strix Halo, it failed to perform to even half of the DGX Spark performance, and even worse on deeper contexts.

vLLM Performance, Qwen/Qwen3.6-35B-A3B, Different Quantization

For this one I used same models with different quantization on the DGX Spark against both set of Radeons.

The GB10 in the DGX Spark is based on Nvidia Blackwell architecture which supports NVFP4. This support is shared with other Blackwell-based GPU such as RTX 50 Series, RTX PRO Blackwell Series, B100, B200, B300, etc. For that reason, I used unsloth/Qwen3.6-35B-A3B-NVFP4 to represent the lowest possible hardware quantization support.

As the Radeon AI Pro R9700 and Strix Halo only support 4-bit on the integer unit and not on the floating point unit, I used cyankiwi/Qwen3.6-35B-A3B-AWQ-4bit. It uses activation-aware weight quantization technique from the MIT HAN Lab and mainly utilises int4 (4-bit integer).

vLLM prompt processing performance using Qwen/Qwen3.6-35B-A3B from DGX Spark, R9700, and Strix Halo.

This one brought a more interesting comparison between the DGX Spark and the Radeon AI Pro R9700. Somehow the DGX Spark was able to gain foothold on no context depth with 4 concurrent requests. Also the deeper contexts on the DGX Spark shined this time against the R9700. And yes, the Strix Halo performance was far behind those two.

vLLM token generation performance using Qwen/Qwen3.6-35B-A3B from DGX Spark, R9700, and Strix Halo.

The data portrays similar story. But this time, the DGX Spark was slightly faster and the R9700 was slightly slower, giving more performance delta between those two. Poor Strix Halo still struggled hard.

LLM Performance Conclusion

At the time of writing, DGX Spark can be found for around IDR170Mio (assuming the currency rate of IDR18k/USD), give or take, with bigger storage size would warrant higher price.

Now compare that to R9700 which can be found for around IDR30Mio. When you factor the total system cost of around IDR80Mio for a high-end system, yet yields LLM performance not far short of the DGX Spark, you would have to answer at least these 4 questions:

  1. Do you need a smaller footprint?
  2. Do you need lower heat and power envelope?
  3. Do you need a better software/model/documentation/support?
  4. Do you intend to setup a cluster?

If most of your answers are yes, I think the IDR170Mio of DGX Spark would worth the money compared to R9700 or Strix Halo.

I’m sorry Strix Halo. But with your current expected price for 128 GB variant of around IDR75Mio, I would rather choose between R9700 or DGX Spark.

Image Generation Performance

Things get more interesting here on image generation test. As I already wrote above regarding the NVFP4 support, you can expect that this mini machine would be able to run Nunchaku SVDQuant FP4 model like the RTX 5070 Ti we tested on this article. But there’s a big trouble challenge. Big big challenge.

The Nunchaku wheel binaries provided on Nunchaku Github release are only available for x86_64. Meanwhile this DGX Spark uses Arm processor inside.

Oof.

Oh wait. Turns out there is someone from Japan who was able to build and compile from source, so that Nunchaku wheel would run for aarch64 (Arm64)!

Yep. After following the direction in which I required to use Google Translate to decipher that article (shout out to tori29umai) and waited for several minutes of compilation process (trust me it was goddamn long lol, I’m used to faster CPUs), voila!

Those who do not know pain (of self-compiling) will never understand true peace (of simply installing).

I used the same model (Qwen Image Edit 2509), same workflow, and same input images for the comparison as the one used in this article.

TypeModel
GGUFBase: QuantStack/Qwen-Image-Edit-2509-Q4_K_M
LoRA: lightx2v/Qwen-Image-Edit-2509-Lightning-4steps-V1.0-bf16
Nunchaku SVDQuant NVFP4nunchaku-ai/nunchaku-qwen-image-edit-2509/svdq-fp4_r32-qwen-image-edit-2509-lightningv2.0-4steps

First, I would like to show you how the DGX Spark stands against the R9700 and the Strix Halo, using GGUF model which can be run across those three.

DGX Spark – Qwen Image Edit 2509 GGUF run screenshot

Radeon AI Pro R9700 – Qwen Image Edit 2509 GGUF run screenshot
Strix Halo – Qwen Image Edit 2509 GGUF run screenshot

Qwen Image Edit 2509 GGUF performance comparison.

One interesting thing is, the Radeon AI Pro R9700 is now much faster than the last time I tested.

52.17s then to 36.87s now translates to around 30% time shaving! Kudos to AMD!

The Strix Halo is around 4x slower than the other two. Also faster than the last time I tried which requires around 188s to complete the task.

This was the last time I ran Qwen Image Edit 2509 GGUF on the Strix Halo.

Now, let’s get to the staple of Nunchaku SVDQuant FP4 variant.

DGX Spark – Qwen Image Edit 2509 SVDQuant FP4 run screenshot

Qwen Image Edit 2509 complete performance comparison.

The DGX Spark finished the task and shaved around 38% of required time to complete using SVDQuant FP4 model variant. Turns out having a 4-bit floating point unit still helps even with a smaller chip and lower power.

Desktop PC Experience

If you want to switch the experience from being a mini supercomputer to a mere mini PC, it handles the job well. Well enough that you can do browsing, but nothing special from the performance standpoint.

Reasonable.
Comparison to other systems, courtesy of NotebookCheck.net. Apparently faster than Strix Halo represented by the Asus ProArt PX13 there.

For multimedia purposes, it supports a wide range of codec on its encoder and decoder.

Encoder codec support: YES YES YES YES YES YES…
…YES YES YES YES YES
Decoder codec support: ALSO GIVE ME AS MANY YES…
…AS POSSIBLE

And my test showed that it is possible to use the NVENC (Nvidia encoder) to do some video rendering with the state of the art AV1 codec.

NVENC AV1 is available!
AV1 video encoding demonstration using Kdenlive.
AV1 video encoding demonstration using Handbrake.

Gaming

Funnily enough, you can also game on DGX Spark. Despite of having a full-fledged Nvidia GPU with shader core, raytrace core, and tensor core, you won’t be expected to game on this as well as a normal gaming PC. The reason is most of the game available there are developed for:

  1. Windows (or DirectX API, to be precise)
  2. x86 CPU

Well, this system is running on:

  1. Linux (Vulkan API)
  2. Arm CPU

Now think about it. In order for your ordinary game to work, it needs to translate/emulate both the graphics API and the CPU ISA, before it hits the underlying low level instructions on the GPU and the CPU. The translation layers require certain computational cost in order for it to run.

For example, certain games require you to have an x86 CPU with AVX2 instruction extension. But there’s no such thing on Arm, and no such thing on GB10 CPU as well.

GB10 CPU flags. Do you see any AVX/AVX2/AVX512 anywhere?

Thanks to the people from the Box86/Box64 project, we actually have an x86 to Arm emulator. Kudos to them, they’re also managed to emulate AVX(2)! Therefore, this Steam for Arm64 on Ubuntu was born.

Steam snap for Arm64

And yes, with the magic of Box64 and Proton and VKD3D and many many more open source projects, I managed to play Clair Obscur: Expedition 33!

Expedition 33 in all of its glory.

Unfortunately I wasn’t able to make MangoHud or Steam overlay to work, so there’s no framerate reading available. It was playable, not as smooth as my own PC, but respectable nonetheless for a machine which is not intended for gaming.

Power Consumption

DGX Spark only exposes the power draw data from the GPU side. I tried probing the available sensors exposed to the OS to find a way to read the CPU or the SoC power draw using various tools like lm-sensors, siomon, and Prometheus node_exporter, to no avail. In the end, I only had limited time doing the power draw test. Regardless I can show you some interesting data, using both the GPU power draw sensor and wall outlet watt meter.

Video encoding GPU power draw of around 15-17W.
Image generation GPU power draw of around 85W, with idle GPU power draw of around 10-11W.
Image generation wall outlet power draw of around 160W.
Expedition 33 gaming GPU power draw of around 45W.
Expedition 33 gaming wall outlet power draw of around 126-130W.

Noise

Every implementation of the DGX Spark platform from various Nvidia partners brings their own cooling solution. As for this test, it is specific to MSI EdgeXpert and not representative to all DGX Spark solutions available.

I would describe the noise as a typical gaming laptop whisper which can get louder under load. Even at the loudest it’s still pretty reasonable and you can have this system on your desk no problem.

Idle noise.
Under load noise.

Verdict

What can we grab from all those tests?

The fact that this has no AI moniker in its name yet excels in pretty much all of my AI tests, impressed me by very much.

If you’re looking for an edge device, with excellent support, software, and matured CUDA platform, maybe this device is for you. The problem would be the price. My estimation of IDR170Mio as per 28th May 2026 is based on the uncertainty of the currency exchange rate, the memory/storage chip shortage, and the freight cargo price hike caused by the Middle East conflict. It can probably get more expensive in the future, with no option of waiting until the price drops.

If you’re looking for alternatives, I don’t feel there’s any non-enterprise system or GPU that can give 128 GB of total available memory with this level of performance, especially around vLLM concurrent requests and deep context which are required for agentic AI of today. Not to mention the possibility of stacking multiple DGX Spark and setting up tensor parallelism to run a bigger model or to get more performance.

Also pls don’t buy it for a gaming PC. Save your money and buy any typical desktop or laptop instead.

The post Our Experience with MSI EdgeXpert – Nvidia DGX Spark GB10 appeared first on Efison Lisan Teknologi.

]]> Our Experience with Asus AMD Radeon AI Pro R9700 Turbo https://efisonlt.com/our-experience-with-asus-amd-radeon-ai-pro-r9700-turbo/?utm_source=rss&utm_medium=rss&utm_campaign=our-experience-with-asus-amd-radeon-ai-pro-r9700-turbo Sat, 11 Oct 2025 13:13:19 +0000 https://efisonlt.com/?p=1880 2025, and AI. What’s not to love? Again, if somebody were to sell a rendang and they state that it was created using AI, I bet venture capitals would clap and circle like vultures. Okay enough yapping. Now we are talking about a damn GPU. A tool to run real AI. Introducing, AMD Radeon AI… Read More »Our Experience with Asus AMD Radeon AI Pro R9700 Turbo

The post Our Experience with Asus AMD Radeon AI Pro R9700 Turbo appeared first on Efison Lisan Teknologi.

]]> 2025, and AI.

What’s not to love?

Again, if somebody were to sell a rendang and they state that it was created using AI, I bet venture capitals would clap and circle like vultures.

Okay enough yapping. Now we are talking about a damn GPU. A tool to run real AI.

Introducing, AMD Radeon AI Pro R9700

In their wisdom, calling a prosumer/workstation GPU with a “pro” moniker doesn’t quite cut it anymore. It now has AI in its name. Why, do you ask?

Because apparently it has 32GB worth of VRAM and it supports another numerical precision (FP8). The VRAM is quite big, we reckon. Still not as big as the last gen Pro (no AI) W7900, but with all its new-ness, AI-ness, and goodness, it’s still pretty nice.

Radeon AI Pro R9700Radeon Pro W7900
ArchitectureAMD RDNA 4AMD RDNA 3
Memory size32 GB48 GB
Memory bandwidth644.6 GB/s864 GB/s
Memory ECC supportYes (Linux only)*Yes
Peak FP32 (vector) performance47.8 TFLOPS61.3 TFLOPS
Peak FP16 (vector) performance95.7 TFLOPS123 TFLOPS
Peak FP16 (matrix) performance191 TFLOPS123 TFLOPS
Peak FP8 (matrix) performance383 TFLOPSN/A
Peak INT8 (matrix) performance383 TOPS123 TOPS

Personally we’re pretty confused about why the memory ECC support on R9700 is stated as Linux only but as we’re mostly using Linux as our test platform, no complaint there.

Even with smaller memory size, it is pretty beefy in terms of performance. Especially in theoretical matrix performance. Hence the AI namesake. Unfortunately we have no W7900 or any RX 7900 XTX for real-world comparison purpose, but we do have an RTX 5070 Ti which apparently has a similar profile.

Radeon AI Pro R9700Geforce RTX 5070 Ti
Process technologyTSMC N4PTSMC 4N
Die size357 mm²378 mm²
Memory size32 GB GDDR616 GB GDDR7
Memory interface256-bit256-bit
Memory bandwidth644.6 GB/s896 GB/s
Total board power300 W300 W

The Test Setup

ComponentSpecification
CPUIntel Core i7-12700K
@5.0 GHz
MotherboardASRock Z690 PG Velocita
Memory4*24 GB Klevv Cras V RGB
@DDR5-5600
Storage2TB MSI Spatium M480
PSU1000W 1stPlayer NGDP Gold

For the benchmark, we tested LLM using llama.cpp and image generation using Qwen Image Edit 2509.

llama.cpp Benchmark Setup

We used llama.cpp build d2ee056e1 (6713) and compiled the CPU backend using Intel oneAPI compiler 2025.2.1 against external BLAS library which is Intel oneAPI MKL 2025.2. Why, do you ask? Because it yields faster performance compared to mere GNU compiler 15.2.1 with no BLAS.

We tested using unsloth/gpt-oss-120b-Q4_K_M model and .(7|8|9|[0-9][0-9]|[0-9][0-9][0-9]).ffn_(up|down|gate)_exps. MoE layers which are then being put to system RAM for CPU offload processing.

(In token/s. Higher is better)GNU compiler 15.2.1
no BLAS		oneAPI compiler 2025.2.1
BLAS=oneAPI MKL 2025.2
Prompt processing (512 tokens)180.65 ± 1.74182.39 ± 1.60
Text generation (256 tokens)21.85 ± 0.8232.19 ± 0.04
Compilation steps for GNU compiler 15.2.1, no BLAS
Bash
mkdir build_no-blas-gcc_vulkan && cd build_no-blas-gcc_vulkan
cmake .. -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DGGML_NATIVE=ON -DGGML_VULKAN=1
cmake --build . --config Release -j
Compilation steps for oneAPI compiler 2025.2.1, BLAS=oneAPI MKL 2025.2
Bash
mkdir build_mkl-ilp64-icx_vulkan && build_mkl-ilp64-icx_vulkan
cmake -DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icpx -DGGML_BLAS=ON -DGGML_BLAS_VENDOR=Intel10_64ilp -DGGML_NATIVE=ON -DGGML_VULKAN=1
cmake --build . --config Release -j
Run output
Bash
GGML_VULKAN_DEVICE=0 ./build_no-blas-gcc_vulkan/bin/llama-bench --model ../MoE/unsloth/gpt-oss-120b-Q4_K_M.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -ot "\.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096

GGML_VULKAN_DEVICE=0 ./build_mkl-ilp64-icx_vulkan/bin/llama-bench --model ../MoE/unsloth/gpt-oss-120b-Q4_K_M.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -ot "\.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096
WARNING: radv is not a conformant Vulkan implementation, testing use only.
ggml_vulkan: Found 2 Vulkan devices:
ggml_vulkan: 0 = AMD Radeon Graphics (RADV GFX1201) (radv) | uma: 0 | fp16: 1 | bf16: 0 | warp size: 64 | shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat
ggml_vulkan: 1 = Intel(R) UHD Graphics 770 (ADL-S GT1) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 32 | shared memory: 65536 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | ngl | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | --: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan     |  99 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU |           pp512 |        180.65 ± 1.74 |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan     |  99 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU |           tg256 |         21.85 ± 0.82 |

build: d2ee056e1 (6713)
WARNING: radv is not a conformant Vulkan implementation, testing use only.
ggml_vulkan: Found 2 Vulkan devices:
ggml_vulkan: 0 = AMD Radeon Graphics (RADV GFX1201) (radv) | uma: 0 | fp16: 1 | bf16: 0 | warp size: 64 | shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat
ggml_vulkan: 1 = Intel(R) UHD Graphics 770 (ADL-S GT1) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 32 | shared memory: 65536 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU |           pp512 |        182.39 ± 1.60 |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU |           tg256 |         32.19 ± 0.04 |

build: d2ee056e1 (6713)

For the GPU backend, we used both Vulkan and HIP (ROCm 7) which we won’t discuss much here to prevent spoilers.

We refrained on using ROCm 6.4.x as ROCm 7.0.x is now performing much better on this GPU (or probably all AMD RDNA4 GPUs in general). If you haven’t heard already, AMD have just released their newest ROCm 7 on September 16, 2025. We did a quick comparison in terms of llama.cpp performance against ROCm 6.4.3 which can be seen on this guy’s Facebook post.

As for the RTX 5070 Ti, we compiled llama.cpp GPU backend against CUDA without GGML_CUDA_FORCE_CUBLAS.

So for references, here are the compilation lines used for various configurations stated above:

Compilation line for llama.cpp ROCm
Bash
cmake .. -DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icpx -DGGML_BLAS=ON -DGGML_BLAS_VENDOR=Intel10_64ilp -DGGML_NATIVE=ON -DGGML_HIP=ON -DGPU_TARGETS=gfx1201
Compilation line for llama.cpp Vulkan
Bash
cmake .. -DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icpx -DGGML_BLAS=ON -DGGML_BLAS_VENDOR=Intel10_64ilp -DGGML_NATIVE=ON -DGGML_VULKAN=1
Compilation line for llama.cpp CUDA
Bash
cmake .. -DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icpx -DGGML_BLAS=ON -DGGML_BLAS_VENDOR=Intel10_64ilp -DGGML_NATIVE=ON -DGGML_CUDA=ON

We chose 2 models to be used for testing:

Qwen Image Edit 2509 Benchmark Setup (and rambling about PyTorch for ROCm on Windows situation)

This one is a bit different because it has PyTorch dependencies and it’s not that simple. Historically, AMD has been neglecting (or unable to make?) Windows PyTorch package for their GPUs. With the Windows Preview Edition 25.20.01.14 driver, they finally support PyTorch on Windows for Radeons. Yay!

Albeit the limited roster of supported GPUs…

Funnily enough, they only listed Windows 11 as the compatible OS. Lo and behold, we managed to use it on Windows 10.

Enough with the rambling, now let’s get onto the setup.

We did the tests on 2 different OSes:

  • Aurora Linux 42 based on Fedora Kinoite
  • Windows 10 Pro

For the PyTorch, we tested different combinations:

PyTorch 2.x for ROCm 6.4.xPyTorch 2.x for ROCm 7.0.x
Aurora Linux 42✘✔
Windows 10 Pro✔✔

The Qwen Image Edit 2509 models used here were QuantStack/Qwen-Image-Edit-2509-Q4_K_M. We also used lightx2v/Qwen-Image-Edit-2509-Lightning-4steps-V1.0-bf16 LoRA for performance reason. As for the UI and additional package, we used ComfyUI v0.3.64. Not to forgot to mention city96/ComfyUI-GGUF for GGUF models compatibility.

Additional notes about Qwen Image Edit 2509 test setup and deployment

As for the inputs, we used these images:

And these sentences for the prompt:

Test Results: llama.cpp

We talked a bit about llama.cpp LLM MoE layer offload to CPU above. But in short, CPU offloading is done to make sure you can run a big model without the big performance hit caused by memory spill from VRAM to system RAM.

So, if you run a big model on GPU, and the VRAM is smaller than the model, it will still run. But it will run terribly because now the GPU needs to access the data from RAM in which the available VRAM can’t contain, while the CPU is doing nothing to help the processing.

unsloth/gpt-oss-120b-Q4_K_M has the size of 58.45 GB, while the available VRAM is only around 32 GB before substracting other necessary services for the operating system, which is now spilling around 26-27 GB to system RAM.

Now see the difference with CPU offloading.

With .(4|5|6|7|8|9|[0-9][0-9]|[0-9][0-9][0-9]).ffn_(up|down)_exps. layers being offloaded to CPU and put to the system RAM, now the CPU can help with the processing while preventing the layers loaded to VRAM to spill over.

Probably this article is not the best at explaining how the MoE layers work or the way they’re offloaded. You can read a little bit more technical stuffs starting from reading this guide, or maybe a little bit of Google-fu. Sorry.

Now, let’s see the performance difference:

(In token/s. Higher is better)Without CPU offloadingWith CPU offloading
Prompt processing (512 tokens)120.48 ± 4.06215.93 ± 1.42
Text generation (256 tokens)11.21 ± 0.0234.97 ± 0.15
Run output
Bash
GGML_VULKAN_DEVICE=0 ./build_mkl-ilp64-icx_vulkan/bin/llama-bench --model ../MoE/unsloth/gpt-oss-120b-Q4_K_M.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -p 512 -n 256 -fa 1 -ub 4096 -b 4096

GGML_VULKAN_DEVICE=0 ./build_mkl-ilp64-icx_vulkan/bin/llama-bench --model ../MoE/unsloth/gpt-oss-120b-Q4_K_M.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -ot "\.(4|5|6|7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096
WARNING: radv is not a conformant Vulkan implementation, testing use only.
ggml_vulkan: Found 2 Vulkan devices:
ggml_vulkan: 0 = AMD Radeon Graphics (RADV GFX1201) (radv) | uma: 0 | fp16: 1 | bf16: 0 | warp size: 64 | shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat
ggml_vulkan: 1 = Intel(R) UHD Graphics 770 (ADL-S GT1) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 32 | shared memory: 65536 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------: | -------------------: |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 |           pp512 |        120.48 ± 4.06 |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 |           tg256 |         11.21 ± 0.02 |

build: d2ee056e1 (6713)
WARNING: radv is not a conformant Vulkan implementation, testing use only.
ggml_vulkan: Found 2 Vulkan devices:
ggml_vulkan: 0 = AMD Radeon Graphics (RADV GFX1201) (radv) | uma: 0 | fp16: 1 | bf16: 0 | warp size: 64 | shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat
ggml_vulkan: 1 = Intel(R) UHD Graphics 770 (ADL-S GT1) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 32 | shared memory: 65536 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(4|5|6|7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU |           pp512 |        215.93 ± 1.42 |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(4|5|6|7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU |           tg256 |         34.97 ± 0.15 |

build: d2ee056e1 (6713)

Let’s continue with the test results.

Here we have different configs of layers for CPU offloading. One is to keep the VRAM usage to under 16 GB, and then maximize the possible 32 GB. The configuration details can be seen below:

  • RTX 5070 Ti with just under 16 GB VRAM load, CUDA backend
  • RTX 5070 Ti with just under 16 GB VRAM load, Vulkan backend
  • R9700 with just under 16 GB VRAM load, ROCm 7 backend
  • R9700 with just under 16 GB VRAM load, Vulkan backend
  • R9700 with just under 32 GB VRAM load, ROCm 7 backend
  • R9700 with just under 32 GB VRAM load, Vulkan backend

Here are the results using unsloth/Qwen3-Coder-30B-A3B-Instruct-1M-IQ4_XS:

(In token/s. Higher is better)5070 Ti, 16G
CUDA		5070 Ti, 16G
Vulkan		R9700, 16G
ROCm 7		R9700, 16G
Vulkan		R9700, 32G
ROCm 7		R9700, 32G
Vulkan
Prompt processing (512 tokens)3723.33 ± 50.092739.83 ± 30.37746.77 ± 3.451236.97 ± 9.19797.92 ± 3.611665.47 ± 5.95
Text generation (256 tokens)137.34 ± 0.69138.41 ± 0.7988.98 ± 0.16105.35 ± 0.75100.05 ± 0.08122.63 ± 0.52

Here are the results using unsloth/gpt-oss-120b-Q4_K_M:

(In token/s. Higher is better)5070 Ti, 16G
CUDA		5070 Ti, 16G
Vulkan		R9700, 16G
ROCm 7		R9700, 16G
Vulkan		R9700, 32G
ROCm 7		R9700, 32G
Vulkan
Prompt processing (512 tokens)370.32 ± 4.22206.81 ± 3.52188.32 ± 4.82169.56 ± 2.60251.93 ± 6.61230.01 ± 2.78
Text generation (256 tokens)40.24 ± 0.1337.90 ± 0.4232.59 ± 0.0131.49 ± 0.0438.73 ± 0.0836.22 ± 0.03
RTX 5070 Ti 16G run output
Bash
./build_mkl-ilp64-icx_cuda/bin/llama-bench --model ../MoE/unsloth/Qwen3-Coder-30B-A3B-Instruct-1M-IQ4_XS.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -ot "\.(39|[4-9][0-9]|[1-9][0-9][0-9])\.ffn_(gate)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096

GGML_VULKAN_DEVICE=0 ./build_mkl-ilp64-icx_vulkan/bin/llama-bench --model ../MoE/unsloth/Qwen3-Coder-30B-A3B-Instruct-1M-IQ4_XS.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -ot "\.(39|[4-9][0-9]|[1-9][0-9][0-9])\.ffn_(gate)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096

./build_mkl-ilp64-icx_cuda/bin/llama-bench --model ../MoE/unsloth/gpt-oss-120b-Q4_K_M.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -ot "\.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096

GGML_VULKAN_DEVICE=0 ./build_mkl-ilp64-icx_vulkan/bin/llama-bench --model ../MoE/unsloth/gpt-oss-120b-Q4_K_M.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -ot "\.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096
ggml_cuda_init: GGML_CUDA_FORCE_MMQ:    no
ggml_cuda_init: GGML_CUDA_FORCE_CUBLAS: no
ggml_cuda_init: found 1 CUDA devices:
  Device 0: NVIDIA GeForce RTX 5070 Ti, compute capability 12.0, VMM: yes
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | CUDA,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(39|[4-9][0-9]|[1-9][0-9][0-9])\.ffn_(gate)_exps.=CPU |           pp512 |      3723.33 ± 50.09 |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | CUDA,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(39|[4-9][0-9]|[1-9][0-9][0-9])\.ffn_(gate)_exps.=CPU |           tg256 |        137.34 ± 0.69 |

build: d2ee056e1 (6713)
ggml_vulkan: Found 2 Vulkan devices:
ggml_vulkan: 0 = NVIDIA GeForce RTX 5070 Ti (NVIDIA) | uma: 0 | fp16: 1 | bf16: 1 | warp size: 32 | shared memory: 49152 | int dot: 1 | matrix cores: NV_coopmat2
ggml_vulkan: 1 = Intel(R) UHD Graphics 770 (ADL-S GT1) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 32 | shared memory: 65536 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(39|[4-9][0-9]|[1-9][0-9][0-9])\.ffn_(gate)_exps.=CPU |           pp512 |      2739.83 ± 30.37 |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(39|[4-9][0-9]|[1-9][0-9][0-9])\.ffn_(gate)_exps.=CPU |           tg256 |        138.41 ± 0.79 |

build: d2ee056e1 (6713)
ggml_cuda_init: GGML_CUDA_FORCE_MMQ:    no
ggml_cuda_init: GGML_CUDA_FORCE_CUBLAS: no
ggml_cuda_init: found 1 CUDA devices:
  Device 0: NVIDIA GeForce RTX 5070 Ti, compute capability 12.0, VMM: yes
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | CUDA,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU |           pp512 |        370.32 ± 4.22 |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | CUDA,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU |           tg256 |         40.24 ± 0.13 |

build: d2ee056e1 (6713)
ggml_vulkan: Found 2 Vulkan devices:
ggml_vulkan: 0 = NVIDIA GeForce RTX 5070 Ti (NVIDIA) | uma: 0 | fp16: 1 | bf16: 1 | warp size: 32 | shared memory: 49152 | int dot: 1 | matrix cores: NV_coopmat2
ggml_vulkan: 1 = Intel(R) UHD Graphics 770 (ADL-S GT1) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 32 | shared memory: 65536 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU |           pp512 |        206.81 ± 3.52 |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU |           tg256 |         37.90 ± 0.42 |

build: d2ee056e1 (6713)
R9700 16G run output
Bash
./build_mkl-ilp64-icx_rocm/bin/llama-bench --model ../MoE/unsloth/Qwen3-Coder-30B-A3B-Instruct-1M-IQ4_XS.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -ot "\.(39|[4-9][0-9]|[1-9][0-9][0-9])\.ffn_(gate)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096

GGML_VULKAN_DEVICE=0 ./build_mkl-ilp64-icx_vulkan/bin/llama-bench --model ../MoE/unsloth/Qwen3-Coder-30B-A3B-Instruct-1M-IQ4_XS.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -ot "\.(39|[4-9][0-9]|[1-9][0-9][0-9])\.ffn_(gate)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096

./build_mkl-ilp64-icx_rocm/bin/llama-bench --model ../MoE/unsloth/gpt-oss-120b-Q4_K_M.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -ot "\.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096

GGML_VULKAN_DEVICE=0 ./build_mkl-ilp64-icx_vulkan/bin/llama-bench --model ../MoE/unsloth/gpt-oss-120b-Q4_K_M.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -ot "\.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096
ggml_cuda_init: GGML_CUDA_FORCE_MMQ:    no
ggml_cuda_init: GGML_CUDA_FORCE_CUBLAS: no
ggml_cuda_init: found 1 ROCm devices:
  Device 0: AMD Radeon AI PRO R9700, gfx1201 (0x1201), VMM: no, Wave Size: 32
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | ROCm,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(39|[4-9][0-9]|[1-9][0-9][0-9])\.ffn_(gate)_exps.=CPU |           pp512 |        746.77 ± 3.45 |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | ROCm,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(39|[4-9][0-9]|[1-9][0-9][0-9])\.ffn_(gate)_exps.=CPU |           tg256 |         88.98 ± 0.16 |

build: d2ee056e1 (6713)
WARNING: radv is not a conformant Vulkan implementation, testing use only.
ggml_vulkan: Found 2 Vulkan devices:
ggml_vulkan: 0 = AMD Radeon AI PRO R9700 (RADV GFX1201) (radv) | uma: 0 | fp16: 1 | bf16: 1 | warp size: 64 | shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat
ggml_vulkan: 1 = Intel(R) UHD Graphics 770 (ADL-S GT1) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 32 | shared memory: 65536 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(39|[4-9][0-9]|[1-9][0-9][0-9])\.ffn_(gate)_exps.=CPU |           pp512 |       1236.97 ± 9.19 |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(39|[4-9][0-9]|[1-9][0-9][0-9])\.ffn_(gate)_exps.=CPU |           tg256 |        105.35 ± 0.75 |

build: d2ee056e1 (6713)
ggml_cuda_init: GGML_CUDA_FORCE_MMQ:    no
ggml_cuda_init: GGML_CUDA_FORCE_CUBLAS: no
ggml_cuda_init: found 1 ROCm devices:
  Device 0: AMD Radeon AI PRO R9700, gfx1201 (0x1201), VMM: no, Wave Size: 32
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | ROCm,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU |           pp512 |        188.32 ± 4.82 |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | ROCm,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU |           tg256 |         32.59 ± 0.01 |

build: d2ee056e1 (6713)
WARNING: radv is not a conformant Vulkan implementation, testing use only.
ggml_vulkan: Found 2 Vulkan devices:
ggml_vulkan: 0 = AMD Radeon AI PRO R9700 (RADV GFX1201) (radv) | uma: 0 | fp16: 1 | bf16: 1 | warp size: 64 | shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat
ggml_vulkan: 1 = Intel(R) UHD Graphics 770 (ADL-S GT1) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 32 | shared memory: 65536 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU |           pp512 |        169.56 ± 2.60 |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down|gate)_exps.=CPU |           tg256 |         31.49 ± 0.04 |

build: d2ee056e1 (6713)
R9700 32G run output
Bash
./build_mkl-ilp64-icx_rocm/bin/llama-bench --model ../MoE/unsloth/Qwen3-Coder-30B-A3B-Instruct-1M-IQ4_XS.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -p 512 -n 256 -fa 1 -ub 4096 -b 4096

GGML_VULKAN_DEVICE=0 ./build_mkl-ilp64-icx_vulkan/bin/llama-bench --model ../MoE/unsloth/Qwen3-Coder-30B-A3B-Instruct-1M-IQ4_XS.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -p 512 -n 256 -fa 1 -ub 4096 -b 4096

./build_mkl-ilp64-icx_rocm/bin/llama-bench --model ../MoE/unsloth/gpt-oss-120b-Q4_K_M.gguf -ctk q8_0 -ctv q8_0 --threads 8 -ngl 99 -ot "\.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096

GGML_VULKAN_DEVICE=0 ./build_mkl-ilp64-icx_vulkan/bin/llama-bench --model ../MoE/unsloth/gpt-oss-120b-Q4_K_M.gguf -ctk q8_0 -ctv q8_0 --threads 8 -ngl 99 -ot "\.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096
ggml_cuda_init: GGML_CUDA_FORCE_MMQ:    no
ggml_cuda_init: GGML_CUDA_FORCE_CUBLAS: no
ggml_cuda_init: found 1 ROCm devices:
  Device 0: AMD Radeon AI PRO R9700, gfx1201 (0x1201), VMM: no, Wave Size: 32
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------: | -------------------: |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | ROCm,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 |           pp512 |        797.92 ± 3.61 |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | ROCm,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 |           tg256 |        100.05 ± 0.08 |

build: d2ee056e1 (6713)
WARNING: radv is not a conformant Vulkan implementation, testing use only.
ggml_vulkan: Found 2 Vulkan devices:
ggml_vulkan: 0 = AMD Radeon AI PRO R9700 (RADV GFX1201) (radv) | uma: 0 | fp16: 1 | bf16: 1 | warp size: 64 | shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat
ggml_vulkan: 1 = Intel(R) UHD Graphics 770 (ADL-S GT1) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 32 | shared memory: 65536 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------: | -------------------: |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 |           pp512 |       1665.47 ± 5.95 |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 |           tg256 |        122.63 ± 0.52 |

build: d2ee056e1 (6713)
ggml_cuda_init: GGML_CUDA_FORCE_MMQ:    no
ggml_cuda_init: GGML_CUDA_FORCE_CUBLAS: no
ggml_cuda_init: found 1 ROCm devices:
  Device 0: AMD Radeon AI PRO R9700, gfx1201 (0x1201), VMM: no, Wave Size: 32
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | ROCm,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU |           pp512 |        251.93 ± 6.61 |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | ROCm,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU |           tg256 |         38.73 ± 0.08 |

build: d2ee056e1 (6713)
WARNING: radv is not a conformant Vulkan implementation, testing use only.
ggml_vulkan: Found 2 Vulkan devices:
ggml_vulkan: 0 = AMD Radeon AI PRO R9700 (RADV GFX1201) (radv) | uma: 0 | fp16: 1 | bf16: 1 | warp size: 64 | shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat
ggml_vulkan: 1 = Intel(R) UHD Graphics 770 (ADL-S GT1) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 32 | shared memory: 65536 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU |           pp512 |        230.01 ± 2.78 |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU |           tg256 |         36.22 ± 0.03 |

build: d2ee056e1 (6713)

Even though it has twice the VRAM, with the MoE layers CPU offloading strategy, turns out it still can’t quite compete with the RTX 5070 Ti. This might be caused by the large memory bandwidth gap between both (644.6 GB/s vs 896 GB/s, 39% difference).

Now, when you see on unsloth/Qwen3-Coder-30B-A3B-Instruct-1M-IQ4_XS, it has this big performance delta between ROCm 7 backend and Vulkan backend. I wonder why a bunch of open-source developers from Vulkan/SPIR-V/Kompute project can outperform engineers who are paid to make their stuffs performant… Although, it did better on unsloth/gpt-oss-120b-Q4_K_M by a tiny margin.

Also, turns out having a bigger VRAM still can’t quite defeat the smaller VRAM, if your bandwidth is too slow, and your software isn’t up to par.

It’s not about the size. It’s about how you use it.

Test Results: Qwen Image Edit 2509

Sometimes we question ourselves why do we like to suffer.

And this test is no different.

We (or me, personally), wonder if being a goose farmer is a better choice for living a happy life.

First, let us tell you that running this test for the first run, is not a happy feat. It takes quite a while for the text encoder and VAE to load and process our prompt and image inputs.

On a bad day, it can take more than 7 mins of time to generate this for the first run.

UPDATE: IT DOESN’T HAVE TO BE 7 MINUTES

PyTorch for ROCm apparently has a bug in which the VAE stage is extremely slow.

The solution? ComfyUI recently pushed a workaround. Which is to disable cuDNN back-end (?).

Now the first generation isn’t that painful anymore.

Original article continues below.

Here, we only put the generation time after text encoder and VAE had been loaded and then run it in a batch of 5. Then we averaged the time needed to generate the same prompt with the same inputs.

Now, let’s get onto the results:

(In seconds, Lower is better)RTX 5070 Ti
CUDA 12.9
Linux		R9700
ROCm 7.0.x
Linux		R9700
ROCm 6.4.x
Windows		R9700
ROCm 7.0.x
Windows
Results29.38452.1769.26262.59
RTX 5070 Ti CUDA 12.9 Linux test screenshot

https://efisonlt.com/wp-content/uploads/2025/10/5070-Ti-GGUF.png

R9700 ROCm 7.0.x Linux test screenshot

https://efisonlt.com/wp-content/uploads/2025/10/R9700-GGUF.png

R9700 ROCm 6.4.x Windows test screenshot

https://efisonlt.com/wp-content/uploads/2025/10/Windows-R9700-GGUF.png

R9700 ROCm 7.0.x Windows test screenshot

https://efisonlt.com/wp-content/uploads/2025/10/Windows-R9700-GGUF-gfx120x-nightly.png

Oops.

Almost twice faster.

Also you can make a case that PyTorch for ROCm on Windows is slower. Almost 20% slower than on Linux. Although this is only on one use case that we tested and we didn’t confirm with different various use cases.

And to make it worse, RTX 5070 Ti does have a trick up its sleeve.

Introducing Nunchaku SVDQuant. An inference engine so fast it cut the inference time of Qwen Image Edit 2509 almost in half even versus already quantized Q4_K_M model.

(In seconds, Lower is better)RTX 5070 Ti
CUDA 12.9
Linux
Nunchaku FP4 r32		RTX 5070 Ti
CUDA 12.9
Linux
Q4_K_M GGUF
Results15.19829.384
RTX 5070 Ti CUDA 12.9 Linux, Nunchaku FP4 r32 model test screenshot

https://efisonlt.com/wp-content/uploads/2025/10/5070-Ti-Nunchaku-r32-CPU-offload.png

Overclocking

Real men do OC.

Or men with too much times in hands.

We managed to overclock this card using LACT. No, we didn’t test overclocking on Windows. Penguins FTW!

We found out that 2800 MHz was the ideal maximum VRAM clock to keep it from crashing doing various workloads. Still a healthy 282 MHz increase from the default 2518 MHz. Which translates to 11.2% more memory bandwidth.

The maximum power usage limit also increased to 330 W from 300 W (10% increase). And maybe you wonder what does GPU voltage offset about? Why is it being lowered, right?

Some of you might have heard that overclocking the GPU clock on RDNA4 is done by shifting the voltage/frequency curve by setting the voltage offset to a lower value, so the GPU would be tricked and boosts to higher frequency.

Too difficult to understand? Let us show you a video from our friend Alva Jonathan who did an excellent job explaining overclocking on another RDNA4 GPU which is a Radeon RX 9070.

Here are the performance results to show you the gain from the overclocking attempt:

llama.cpp unsloth/Qwen3-Coder-30B-A3B-Instruct-1M-IQ4_XS (Overclocked)

(In token/s. Higher is better)5070 Ti, 16G
CUDA		R9700, 32G
Vulkan
Overclocked		R9700, 32G
Vulkan
Stock default
Prompt processing (512 tokens)3723.33 ± 50.091810.00 ± 11.361665.47 ± 5.95
Text generation (256 tokens)137.34 ± 0.69131.09 ± 0.37122.63 ± 0.52

llama.cpp unsloth/gpt-oss-120b-Q4_K_M (Overclocked)

(In token/s. Higher is better)5070 Ti, 16G
CUDA		R9700, 32G
ROCm 7
Overclocked		R9700, 32G
ROCm 7
Stock default
Prompt processing (512 tokens)370.32 ± 4.22254.46 ± 4.62251.93 ± 6.61
Text generation (256 tokens)40.24 ± 0.1339.72 ± 0.0438.73 ± 0.08
Overclocked R9700 llama.cpp run output
Bash
./build_mkl-ilp64-icx_rocm/bin/llama-bench --model ../MoE/unsloth/Qwen3-Coder-30B-A3B-Instruct-1M-IQ4_XS.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -p 512 -n 256 -fa 1 -ub 4096 -b 4096

GGML_VULKAN_DEVICE=0 ./build_mkl-ilp64-icx_vulkan/bin/llama-bench --model ../MoE/unsloth/Qwen3-Coder-30B-A3B-Instruct-1M-IQ4_XS.gguf -ctk q8_0 -ctv q8_0  --threads 8 -ngl 99 -p 512 -n 256 -fa 1 -ub 4096 -b 4096

./build_mkl-ilp64-icx_rocm/bin/llama-bench --model ../MoE/unsloth/gpt-oss-120b-Q4_K_M.gguf -ctk q8_0 -ctv q8_0 --threads 8 -ngl 99 -ot "\.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096

GGML_VULKAN_DEVICE=0 ./build_mkl-ilp64-icx_vulkan/bin/llama-bench --model ../MoE/unsloth/gpt-oss-120b-Q4_K_M.gguf -ctk q8_0 -ctv q8_0 --threads 8 -ngl 99 -ot "\.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU" -p 512 -n 256 -fa 1 -ub 4096 -b 4096
ggml_cuda_init: GGML_CUDA_FORCE_MMQ:    no
ggml_cuda_init: GGML_CUDA_FORCE_CUBLAS: no
ggml_cuda_init: found 1 ROCm devices:
  Device 0: AMD Radeon AI PRO R9700, gfx1201 (0x1201), VMM: no, Wave Size: 32
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------: | -------------------: |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | ROCm,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 |           pp512 |        834.27 ± 3.99 |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | ROCm,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 |           tg256 |        105.42 ± 0.12 |

build: d2ee056e1 (6713)
WARNING: radv is not a conformant Vulkan implementation, testing use only.
ggml_vulkan: Found 2 Vulkan devices:
ggml_vulkan: 0 = AMD Radeon AI PRO R9700 (RADV GFX1201) (radv) | uma: 0 | fp16: 1 | bf16: 1 | warp size: 64 | shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat
ggml_vulkan: 1 = Intel(R) UHD Graphics 770 (ADL-S GT1) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 32 | shared memory: 65536 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------: | -------------------: |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 |           pp512 |      1810.00 ± 11.36 |
| qwen3moe 30B.A3B IQ4_XS - 4.25 bpw |  15.25 GiB |    30.53 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 |           tg256 |        131.09 ± 0.37 |

build: d2ee056e1 (6713)
ggml_cuda_init: GGML_CUDA_FORCE_MMQ:    no
ggml_cuda_init: GGML_CUDA_FORCE_CUBLAS: no
ggml_cuda_init: found 1 ROCm devices:
  Device 0: AMD Radeon AI PRO R9700, gfx1201 (0x1201), VMM: no, Wave Size: 32
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | ROCm,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU |           pp512 |        254.46 ± 4.62 |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | ROCm,BLAS  |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU |           tg256 |         39.72 ± 0.04 |

build: d2ee056e1 (6713)
WARNING: radv is not a conformant Vulkan implementation, testing use only.
ggml_vulkan: Found 2 Vulkan devices:
ggml_vulkan: 0 = AMD Radeon AI PRO R9700 (RADV GFX1201) (radv) | uma: 0 | fp16: 1 | bf16: 1 | warp size: 64 | shared memory: 65536 | int dot: 1 | matrix cores: KHR_coopmat
ggml_vulkan: 1 = Intel(R) UHD Graphics 770 (ADL-S GT1) (Intel open-source Mesa driver) | uma: 1 | fp16: 1 | bf16: 0 | warp size: 32 | shared memory: 65536 | int dot: 1 | matrix cores: none
| model                          |       size |     params | backend    | threads | n_batch | n_ubatch | type_k | type_v | fa | ot                    |            test |                  t/s |
| ------------------------------ | ---------: | ---------: | ---------- | ------: | ------: | -------: | -----: | -----: | -: | --------------------- | --------------: | -------------------: |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU |           pp512 |        236.58 ± 2.89 |
| gpt-oss 120B Q4_K - Medium     |  58.45 GiB |   116.83 B | Vulkan,BLAS |       8 |    4096 |     4096 |   q8_0 |   q8_0 |  1 | \.(7|8|9|[0-9][0-9]|[0-9][0-9][0-9])\.ffn_(up|down)_exps.=CPU |           tg256 |         37.41 ± 0.04 |

build: d2ee056e1 (6713)

As we can see, the increase is bigger when the model is smaller, as bigger portion of layers fit on the VRAM hence the performance gain from VRAM overclocking. Still a tad slower than RTX 5070 Ti, but we’ll grab what we can.

Qwen Image Edit 2509 Q4_K_M GGUF (Overclocked)

(In seconds, Lower is better)RTX 5070 Ti
CUDA 12.9
Linux		R9700
ROCm 7.0.x
Linux
Overclocked		R9700
ROCm 7.0.x
Linux
Stock default
Results29.38448.62852.17
Overclocked R9700 run screenshot

https://efisonlt.com/wp-content/uploads/2025/10/R9700-GGUF-OC.png

7.28% faster. Not bad for a free performance gain.

Verdict

So, what do we think?

Bigger VRAM doesn’t always translate to a bigger performance. Especially in our tests which are very inference heavy. This doesn’t mean this card is DoA or something (pls don’t be, we need alternatives to the leather jacketed overlord).

There are many good takeaways. Such as AMD GPU software team are now finally getting their stuffs together. PyTorch for ROCm on Windows was one of the biggest to-do list. ROCm 7 is being faster than ROCm 6 (at least on RDNA4).

They also managed to lower the size of ROCm Docker image and PyTorch package.

Unfortunately, turns out it was due to they chose to drop RDNA2 from their supported GPUs. Sad.

AMD Radeon ROCm 7 supported GPUs

We still think there would be a better value for a bigger VRAM for different use cases. Probably in LLM finetuning, in 3D modelling/rendering, which we presume wouldn’t be easier to work around with CPU offload the way we tested MoE LLM inference above.

The post Our Experience with Asus AMD Radeon AI Pro R9700 Turbo appeared first on Efison Lisan Teknologi.

]]> Menggunakan ALELEON Supercomputer, Dr. Fajar Inggit Pambudi, M.Sc. Menyelesaikan Penelitiannya Tentang Kerangka Logam-Organik Berbasis Zirkonium! https://efisonlt.com/menggunakan-aleleon-supercomputer-dr-fajar-inggit-pambudi-m-sc-menyelesaikan-penelitiannya-tentang-kerangka-logam-organik-berbasis-zirkonium/?utm_source=rss&utm_medium=rss&utm_campaign=menggunakan-aleleon-supercomputer-dr-fajar-inggit-pambudi-m-sc-menyelesaikan-penelitiannya-tentang-kerangka-logam-organik-berbasis-zirkonium Mon, 03 Jul 2023 08:50:28 +0000 https://efisonlt.com/?p=1851 Pada Juni 2023 lalu, Dr. Fajar Inggit Pambudi, M.Sc. berhasil mempublikasikan penelitiannya ke jurnal Materials Today Communications sebagai pemenang EUREKA! periode 2. Bekerjasama dengan 2 peneliti lainnya yaitu Nadiyah Sekar Pratiwi dan Ukhti Chusnawati, mereka mempublikasikan paper penelitian yang berjudul “First-principle study on the lattice-directed missing linker defect in zirconium based metal-organic framework (MOF-801): Electronic… Read More »Menggunakan ALELEON Supercomputer, Dr. Fajar Inggit Pambudi, M.Sc. Menyelesaikan Penelitiannya Tentang Kerangka Logam-Organik Berbasis Zirkonium!

The post Menggunakan ALELEON Supercomputer, Dr. Fajar Inggit Pambudi, M.Sc. Menyelesaikan Penelitiannya Tentang Kerangka Logam-Organik Berbasis Zirkonium! appeared first on Efison Lisan Teknologi.

]]> Pada Juni 2023 lalu, Dr. Fajar Inggit Pambudi, M.Sc. berhasil mempublikasikan penelitiannya ke jurnal Materials Today Communications sebagai pemenang EUREKA! periode 2.

Bekerjasama dengan 2 peneliti lainnya yaitu Nadiyah Sekar Pratiwi dan Ukhti Chusnawati, mereka mempublikasikan paper penelitian yang berjudul “First-principle study on the lattice-directed missing linker defect in zirconium based metal-organic framework (MOF-801): Electronic properties and interaction with hydrogen”.

Penelitian ini bertujuan untuk mengetahui efek dari cacat yang diakibatkan oleh sambungan yang terputus serta prospek ke depan dari MOF-801 (kerangka logam-organik berbasis Zirkonium) untuk penyimpanan gas hidrogen.

Lattice-directed missing linker defect in MOF-801

Selamat kepada Dr. Fajar Inggit Pambudi, M.Sc. dan tim. Semoga perkembangan ilmu pengetahuan dan teknologi di Indonesia semakin berkembang bersama EFISON dan ALELEON Supercomputer!

Tautan paper:
www.sciencedirect.com/science/article/abs/pii/S235249282300658X

The post Menggunakan ALELEON Supercomputer, Dr. Fajar Inggit Pambudi, M.Sc. Menyelesaikan Penelitiannya Tentang Kerangka Logam-Organik Berbasis Zirkonium! appeared first on Efison Lisan Teknologi.

]]> Berkat ALELEON Supercomputer, Dr. Sc. Sholihun, S.Si., M.Sc. Berhasil Menemukan Kandidat Nanomaterial untuk Mengubah Panas Menjadi Listrik! https://efisonlt.com/aleleon-supercomputerberhasil-menemukan-kandidat-nanomaterial/?utm_source=rss&utm_medium=rss&utm_campaign=aleleon-supercomputerberhasil-menemukan-kandidat-nanomaterial Tue, 05 Jul 2022 11:51:25 +0000 https://efisonlt.com/?p=1805 Dr. Sc. Sholihun, S.Si., M.Sc. sebagai pemenang EUREKA! periode 1 berhasil mempublikasikan hasil penelitiannya ke jurnal internasional IOP Science! Dibantu dengan 3 peneliti lainnya yaitu P. Lubis, N. Amalia, dan S. A. Wella, penelitian yang berjudul “Thermoelectric properties of monolayer and bilayer buckled XTe (X = Ge, Sn, and Pb)” ini bertujuan untuk mencari kandidat… Read More »Berkat ALELEON Supercomputer, Dr. Sc. Sholihun, S.Si., M.Sc. Berhasil Menemukan Kandidat Nanomaterial untuk Mengubah Panas Menjadi Listrik!

The post Berkat ALELEON Supercomputer, Dr. Sc. Sholihun, S.Si., M.Sc. Berhasil Menemukan Kandidat Nanomaterial untuk Mengubah Panas Menjadi Listrik! appeared first on Efison Lisan Teknologi.

]]> Dr. Sc. Sholihun, S.Si., M.Sc. sebagai pemenang EUREKA! periode 1 berhasil mempublikasikan hasil penelitiannya ke jurnal internasional IOP Science!

Dibantu dengan 3 peneliti lainnya yaitu P. Lubis, N. Amalia, dan S. A. Wella, penelitian yang berjudul “Thermoelectric properties of monolayer and bilayer buckled XTe (X = Ge, Sn, and Pb)” ini bertujuan untuk mencari kandidat nanomaterial yang dapat mengubah energi panas menjadi energi listrik secara langsung. Seluruh pengujian ini dilakukan dengan komputasi canggih yang dibantu oleh ALELEON Supercomputer bertenaga AMD EPYC!

Selamat atas publikasi paper penelitiannya. Semoga ilmu pengetahuan dan teknologi di Indonesia semakin berkembang dengan hadirnya EFISON dan ALELEON Supercomputer!

Tautan paper
iopscience.iop.org/article/10.1088/2043-6262/ac7322









The post Berkat ALELEON Supercomputer, Dr. Sc. Sholihun, S.Si., M.Sc. Berhasil Menemukan Kandidat Nanomaterial untuk Mengubah Panas Menjadi Listrik! appeared first on Efison Lisan Teknologi.

]]> EFISON EUREKA! Hadir Kembali di 2022 untuk Peneliti Indonesia! https://efisonlt.com/efison-eureka-periode-2/?utm_source=rss&utm_medium=rss&utm_campaign=efison-eureka-periode-2 Fri, 04 Mar 2022 09:28:42 +0000 https://efisonlt.com/?p=1665 Salam sehat dan sejahtera. Semoga kita semua selalu diberi keselamatan, kesehatan, dan kebahagiaan. Melanjutkan program EFISON EUREKA! yang sebelumnya pernah diluncurkan di Agustus 2021 lalu, kali ini EFISON dan AMD kembali bersama-sama menghadirkan EFISON EUREKA! periode 2. Program sponsor penggunaan HPC ini akan melanjutkan mimpi besar kita untuk memajukan ilmu pengetahuan dan riset di Indonesia.… Read More »EFISON EUREKA! Hadir Kembali di 2022 untuk Peneliti Indonesia!

The post EFISON EUREKA! Hadir Kembali di 2022 untuk Peneliti Indonesia! appeared first on Efison Lisan Teknologi.

]]> Salam sehat dan sejahtera. Semoga kita semua selalu diberi keselamatan, kesehatan, dan kebahagiaan.

Melanjutkan program EFISON EUREKA! yang sebelumnya pernah diluncurkan di Agustus 2021 lalu, kali ini EFISON dan AMD kembali bersama-sama menghadirkan EFISON EUREKA! periode 2. Program sponsor penggunaan HPC ini akan melanjutkan mimpi besar kita untuk memajukan ilmu pengetahuan dan riset di Indonesia.

Pemenang sponsor nantinya berkesempatan menggunakan ALELEON Supercomputer bertenaga AMD EPYC yang kencang dan andal. Harapannya, dengan menggunakan ALELEON Supercomputer peneliti bisa menghasilkan keluaran hasil penelitian yang berkualitas dan bertaraf internasional. Perlu diketahui pula bahwa peserta dan pemenang sponsor EFISON EUREKA! tidak dipungut biaya.

Rekan-rekan peneliti yang sudah mempersiapkan penelitian yang akan ataupun sedang dilakukan bisa langsung mencoba mendaftar melalui formulir Pendaftaran Program Sponsor HPC EFISON EUREKA!. Pendaftaran dibuka mulai dari 4 Maret 2022 hingga 25 Maret 2022.

Informasi lebih lanjut bisa dibaca di wiki EUREKA! Periode 2. Berbagai pertanyaan mengenai program sponsor ini bisa langsung ditanyakan di kontak resmi sponsorship@efisonlt.com.

Mari kita bersama-sama maju dengan teknologi superkomputer dan memperluas jangkauan komputasi HPC di Indonesia.

Salam,

Wilson Lisan
CEO Efison Lisan Teknologi

The post EFISON EUREKA! Hadir Kembali di 2022 untuk Peneliti Indonesia! appeared first on Efison Lisan Teknologi.

]]> Program Sponsor EFISON EUREKA! demi Kemajuan Ilmu Pengetahuan dan Teknologi Indonesia https://efisonlt.com/pengumuman-program-sponsor-efison-eureka/?utm_source=rss&utm_medium=rss&utm_campaign=pengumuman-program-sponsor-efison-eureka Mon, 16 Aug 2021 08:11:43 +0000 https://efisonlt.com/?p=1242 Salam sejahtera bagi teman-teman semua. Semoga kita selalu diberi keselamatan dan kesehatan terutama di masa pandemi sekarang ini. Menyambut hari kemerdekaan Republik Indonesia yang ke-76, EFISON dengan gembira mengumumkan program sponsor EFISON EUREKA!. Program ini memungkinkan warga negara Indonesia yang sedang melakukan riset dan penelitian untuk memperoleh layanan akses superkomputer gratis tanpa dipungut biaya. Pemenang… Read More »Program Sponsor EFISON EUREKA! demi Kemajuan Ilmu Pengetahuan dan Teknologi Indonesia

The post Program Sponsor EFISON EUREKA! demi Kemajuan Ilmu Pengetahuan dan Teknologi Indonesia appeared first on Efison Lisan Teknologi.

]]> Salam sejahtera bagi teman-teman semua. Semoga kita selalu diberi keselamatan dan kesehatan terutama di masa pandemi sekarang ini.

Menyambut hari kemerdekaan Republik Indonesia yang ke-76, EFISON dengan gembira mengumumkan program sponsor EFISON EUREKA!. Program ini memungkinkan warga negara Indonesia yang sedang melakukan riset dan penelitian untuk memperoleh layanan akses superkomputer gratis tanpa dipungut biaya.

Pemenang sponsor akan memperoleh akses terhadap superkomputer ALELEON Mk. II yang dapat dipelajari lebih lanjut di Wiki HPC ALELEON Mk .II. Pemenang sponsor juga memiliki tanggung jawab menghasilkan produk riset dan penelitian berupa jurnal maupun berbagai bentuk pencapaian lain yang dapat dipertanggungjawabkan.

Bagi Anda yang tertarik untuk menyelesaikan penelitian dengan superkomputer ALELEON Mk. II dalam program EFISON EUREKA! dapat mengisi formulir Pendaftaran Program Sponsor HPC EFISON EUREKA!. Pendaftaran dibuka mulai dari 16 Agustus 2021 sampai 13 September 2021. Untuk pertanyaan lebih lanjut dapat langsung melalui surel resmi EFISON EUREKA! di sponsorship@efisonlt.com.

Semoga dengan hadirnya EFISON EUREKA!, kita dapat membantu perkembangan riset dan teknologi serta dapat memperkenalkan komputasi HPC ke masyarakat luas di Indonesia.

Salam,

Wilson Lisan
CEO Efison Lisan Teknologi

The post Program Sponsor EFISON EUREKA! demi Kemajuan Ilmu Pengetahuan dan Teknologi Indonesia appeared first on Efison Lisan Teknologi.

]]> Pengumuman Peluncuran Superkomputer ALELEON untuk Umum https://efisonlt.com/peluncuran-superkomputer-aleleon-untuk-umum/?utm_source=rss&utm_medium=rss&utm_campaign=peluncuran-superkomputer-aleleon-untuk-umum Wed, 07 Apr 2021 07:16:25 +0000 https://efisonlt.com/?p=1090 Salam sehat dan sejahtera bagi kita semua, Kami dari EFISON dengan bangga dan berbahagia mengumumkan peluncuran superkomputer ALELEON yang sebelumnya telah dilaksanakan beta-testing selama 6 bulan. ALELEON yang terkini adalah versi Mark II (ALELEON Mk. II) yang dibangun dari purwarupa ALELEON sebelumnya. ALELEON Mk. II merupakan superkomputer yang ditenagai oleh CPU AMD EPYC Rome Zen… Read More »Pengumuman Peluncuran Superkomputer ALELEON untuk Umum

The post Pengumuman Peluncuran Superkomputer ALELEON untuk Umum appeared first on Efison Lisan Teknologi.

]]> Salam sehat dan sejahtera bagi kita semua,

Kami dari EFISON dengan bangga dan berbahagia mengumumkan peluncuran superkomputer ALELEON yang sebelumnya telah dilaksanakan beta-testing selama 6 bulan.

ALELEON yang terkini adalah versi Mark II (ALELEON Mk. II) yang dibangun dari purwarupa ALELEON sebelumnya. ALELEON Mk. II merupakan superkomputer yang ditenagai oleh CPU AMD EPYC Rome Zen 2, GPU Nvidia Ampere, dan interkoneksi antar node menggunakan Mellanox 100Gbps. Spesifikasi mutakhir ini memungkinkan ALELEON Mk. II menyelesaikan komputasi dengan kecepatan lebih kencang dari ALELEON versi purwarupa. Superkomputer terbaru dari EFISON ini siap digunakan untuk berbagai komputasi saintifik seperti kimia molekuler, statistika, deep-learning, big data, dan masih banyak lagi.

Bagi Anda yang ingin mengetahui lebih lanjut mengenai bagaimana ALELEON bekerja dapat mengunjungi laman wiki EFISON. Pertanyaan seputar ALELEON dan layanan komputasi EFISON dapat langsung melalui surel dukungan pelanggan di support@efisonlt.com.

Hormat kami,

Wilson Lisan
CEO Efison Lisan Teknologi

The post Pengumuman Peluncuran Superkomputer ALELEON untuk Umum appeared first on Efison Lisan Teknologi.

]]> Solusi Permasalahan Work From Home dari Synology https://efisonlt.com/solusi-akses-data-saat-work-from-home/?utm_source=rss&utm_medium=rss&utm_campaign=solusi-akses-data-saat-work-from-home Tue, 09 Mar 2021 02:20:21 +0000 https://efisonlt.com/?p=1060 Semenjak pandemi COVID-19, banyak pemilik usaha perkantoran terpaksa mengharuskan pegawainya untuk bekerja dari rumah. Hal ini menimbulkan polemik di kalangan pemilik usaha untuk tetap dapat menjaga produktivitas dan kerjasama yang baik antar pegawainya dalam kondisi work from home (WFH). Bekerja dari rumah atau yang biasa disebut work from home tidak semudah yang dibayangkan. Kebutuhan untuk… Read More »Solusi Permasalahan Work From Home dari Synology

The post Solusi Permasalahan Work From Home dari Synology appeared first on Efison Lisan Teknologi.

]]> Semenjak pandemi COVID-19, banyak pemilik usaha perkantoran terpaksa mengharuskan pegawainya untuk bekerja dari rumah. Hal ini menimbulkan polemik di kalangan pemilik usaha untuk tetap dapat menjaga produktivitas dan kerjasama yang baik antar pegawainya dalam kondisi work from home (WFH). Bekerja dari rumah atau yang biasa disebut work from home tidak semudah yang dibayangkan. Kebutuhan untuk platform komunikasi atau diskusi jarak jauh dan sistem untuk akses sentral data yang aman dan dan terstruktur sangat penting demi berlangsungnya WFH.

Untuk mengatasi masalah-masalah yang terjadi dalam pembangunan ekosistem “Work From Home” (WFH) diatas, pebisnis umumnya menggunakan solusi penyimpanan data berbasis jaringan. Dalam hal ini secara spesifik terdapat dua jenis solusi untuk penyimpanan data berbasis jaringan. Yang pertama adalah Cloud Storage seperti google drive dan Network Attached Strorage.

Jadi mana yang lebih baik, Cloud Storage atau NAS?

Untuk menjawab pertanyaan diatas, berikut kami sertakan tabel perbandingan antara kedua solusi tersebut.

Network Attached Storage (NAS) Cloud Storage
Biaya dikeluarkan untuk hanya pembelian perangkat. Biaya dikeluarkan hanya untuk pembayaran jasa.
Data tersimpan didalam perangkat NAS. Data tersimpan di server penyedia jasa.
Data pengguna dikelola secara pribadi. Terdapat kemungkinan penggunaan data secara terbatas oleh penyedia jasa.
Tetap dapat diakses melalui jaringan lokal tanpa adanya internet. Hanya dapat diakses via internet.
Lebih murah pada penggunaan skala besar atau jangka panjang. Lebih murah pada penggunaan skala kecil atau jangka pendek.


Dari sini bisa kita lihat bahwa penggunaan cloud pada jangka pendek atau skala kecil cenderung lebih murah karena biaya yang dikeluarkan selalu sama atau linear seiring berjalannya waktu. Sedangkan untuk jangka panjang, terlebih pada skala bisnis dimana data tersimpan dalam jumlah besar, NAS menawarkan biaya yang signifikan lebih murah. Selain itu, NAS juga menawarkan fleksibilitas untuk tetap dapat digunakan tanpa jaringan internet, meskipun hanya terbatas pada jaringan lokal saja. Dalam beberapa situasi spesifik dimana data yang disimpan merupakan data yang sangat sensitif, umumnya penggunaan cloud dihindari untuk menghindari akses tidak diinginkan terhadap data sensitif tersebut.

Tapi, Apa itu Network Attached Storage?

Network Attached Storage atau biasa disingkat dengan NAS, adalah perangkat penyimpanan file yang terkoneksi dan diakses melalui jaringan. Perangkat NAS secara fisik adalah sebuah komputer yang memiliki sejumlah slot untuk media penyimpanan data (Drive Bay) dan juga konektor ke jaringan ethernet, baik dengan kabel atau tanpa kabel (nirkabel) melalui wifi. NAS sendiri secara general berfungsi untuk mendistribusikan dan mengelola data dari banyak pengguna yang terkoneksi melalui jaringan ethernet.

Menyambung artikel sebelumnya mengenai salah satu NAS 4-Bay dari seri DiskStation keluaran brand Synology yaitu DS920+. DS920+ ini menurut kami merupakan alternatif yang “pas”. Seri ini diposisikan di segmen Small to Medium Business (SMB). Didukung dengan 4-Bay yang mampu ditingkatkan kapasitasnya hingga 9-Bay, Penggunaan CPU berbasis arsitektur x86, dan tentunya sebagai NAS entry level pastinya harganya cukup terjangkau sehingga sangat pas digunakan sebagai pilihan awal untuk pengguna yang belum memiliki NAS sebelumnya.

Tidak hanya mumpuni dari segi hardware dan skalabilitasnya, DS920+ juga dibekali dengan software yang mumpuni dari Synology, yaitu DiskStation Manager (DSM). DiskStation Manager merupakan salah satu sistem operasi untuk NAS terbaik yang ada hingga saat ini. Dilengkapi dengan segudang fitur seperti Global Deduplikasi dan Incremental Backup yang dapat membuat NAS bekerja dengan sangat efisien yaitu dengan mencegah NAS untuk melakukan pencadangan terhadap file-file yang identik secara berulang sehingga dapat menghemat ruang, selain itu fitur ini juga akan mencegah pencadangan untuk file yang sudah dicadangkan sebelumnya sehingga pencadangan hanya dilakukan terhadap file yang mengalami perubahan dan penambahan saja.

Jadi apa yang membuat solusi yang ditawarkan oleh Synology menarik?

Berdasarkan pengalaman kami, terdapat 4 fitur penting yang dapat digunakan untuk memaksimalkan dan mempermudah WFH.

1. Synology QuickConnect

QuickConnect berfungsi membuat NAS dapat diakses melalui jaringan internet. Pengguna hanya perlu mendaftarkan sebuah alamat atau ID kedalam sistem QuickConnect dan NAS secara otomatis dapat diakses dari manapun selama pengguna terkoneksi dengan internet. menurut kami QuickConnect ini sangat cocok digunakan oleh pengguna awam karena sistem QuickConnect akan secara otomatis melakukan konfigurasinya sendiri.

2. Synology DDNS

DDNS (Dynamic Domain Name Service) berfungsi untuk membuat NAS dapat diakses melalui sebuah domain. Untuk menggunakan DDNS pengguna wajib terlebih dahulu memiliki alamat IP publik sendiri. DDNS memberikan keleluasaan bagi pengguna untuk memanfaatkan domain dan alamat IP yang sudah dimiliki. Meskipun begitu, Synology juga memberikan opsi domain gratis untuk pengguna yang belum memiliki domain. Pengguna juga dapat melakukan kustomisasi terhadap alamat IP hingga port dan menggunakan SSL certificate untuk meningkatkan keamanan. Berbeda dengan QuickConnect, menurut kami DDNS memberikan keleluasaan dalam kustomisasi dan lebih diperuntukkan kepada pengguna yang memiliki pengetahuan mengenai jaringan komputer.

3. Synology MailPlus

Synology MailPlus merupakan layanan private webmail dari Synology. Sebagai private webmail, secara tidak langsung MailPlus memiliki proteksi ekstra dibanding layanan webmail publik karena penggunaan server pribadi yang tidak terekspos ke publik. MailPlus juga disertai dengan fitur migrasi untuk mempermudah pengguna untuk tetap dapat menggunakan layanan webmail lain seperti Gmail atau Yahoo Mail. Selain itu MailPlus juga disertai dengan filter untuk menyaring ancaman seperti spam dan virus. Tapi, apa yang sesungguhnya membedakan MailPlus dibanding layanan webmail lain? Menurut kami terdapat dua fitur unik yang terintegrasi didalam MailPlus yang membuatnya sangat nyaman digunakan. Pertama ada Synology Chat, fitur ini memungkinkan pengguna untuk melakukan chat kepada seluruh pengguna MailPlus untuk berkoordinasi mengenai email yang akan dikirimkan. Hal ini tentunya memudahkan pengirim email untuk memberikan informasi yang tepat guna dan efisien. Last but not least, MailPlus juga disertai dengan Synology Calendar dimana pengguna dapat melihat dan mencocokkan pekerjaan dengan to-do list yang terintegrasi langsung didalam fitur ini.

4. Synology Drive

Synology Drive dapat dianalogikan sebagai jantung atau komponen utama dalam penggunaan NAS. Synology Drive memfasilitasi pengguna untuk mengakses file yang ada didalam NAS. Apabila dikombinasikan dengan QuickConnect atau DDNS, memungkinkan pengguna untuk memiliki sebuah Cloud Storage pribadi yang 100% bebas biaya berlangganan. Selain itu Synology Drive juga disertai dengan fitur Intelliversioning, Intelliversioning ada sistem version control terhadap file yang berada didalam NAS. Fitur ini memungkinkan pengguna untuk mengakses sebuah file didalam keadaan yang lampau. Tidak hanya itu, Intelliversioning juga dibekali dengan kemampuan khusus untuk memilih versi apa dari file tersebut yang sekiranya akan dibutuhkan oleh pengguna. Fitur terakhir yang menurut kami membuat Synology Drive sangat kompetitif dibanding solusi sejenis adalah Synology Office. Synology Office merupakan sebuah sistem penyuntingan dokumen berbasis jaringan yang terintegrasi secara langsung didalam Synology Drive. Sebagai gambaran, Synology Office bisa dibilang adalah versi lebih advance dari solusi sejenis yang ditawarkan oleh Google yaitu Docs, Sheets dan Slides. Tidak hanya memungkinkan pengguna untuk melakukan penyuntingan yang akan tersimpan dan tersinkronisasi secara realtime. Fitur ini juga memungkinkan file yang sama diakses secara bersamaan. Tentunya Synology juga tidak lupa menambahkan Synology Chat sebagai pelengkap yang sempurna yang membuat kami merasa fitur ini sangat cocok digunakan di untuk mempermudah WFH.

Menurut kami, solusi dan pendekatan yang dilakukan oleh Synology ini bisa dibilang adalah sebuah paket komplit. Masalah terhadap akses data melalui internet? Ada QuickConnect dan DDNS. Mengakses dan menyunting file secara bersamaan dan reatime? Ada Synology Office. Bingung mengenai penyuntingan dokumen atau email? Synology Chat terintegrasi di kedua fitur untuk memastikan anda dan tim selalu terkoneksi tanpa hambatan. Apakah fitur yang diberikan hanya itu saja? Tentu tidak, Disamping layanan atau fitur yang sudah disediakan oleh Synology, mereka juga memberikan keleluasaan kepada penggunanya untuk dapat memasang aplikasi atau layanan tambahan melalui repository pihak ketiga.

Mau tau lebih lanjut soal Synology Drive? KLIK DISINI!

The post Solusi Permasalahan Work From Home dari Synology appeared first on Efison Lisan Teknologi.

]]> WFH Lebih Efisien Bersama Synology NAS https://efisonlt.com/wfh-lebih-efisien-bersama-synology-nas/?utm_source=rss&utm_medium=rss&utm_campaign=wfh-lebih-efisien-bersama-synology-nas Wed, 06 Jan 2021 08:16:20 +0000 https://efisonlt.com/?p=993 Melanjutkan artikel sebelumnya yang membahas mengenai Synology DS920+, kali ini kita akan membahas mengenai cara memaksimalkan penggunaan NAS dari Synology untuk menunjang kegiatan Work From Home (WFH). Jadi Pertanyaan besarnya adalah, Kenapa memilih NAS dari Synology untuk menunjang kegiatan WFH? Untuk menjawab pertanyaan diatas, kita perlu membandingkan NAS dari Synology dengan solusi penyimpanan data yang… Read More »WFH Lebih Efisien Bersama Synology NAS

The post WFH Lebih Efisien Bersama Synology NAS appeared first on Efison Lisan Teknologi.

]]> Melanjutkan artikel sebelumnya yang membahas mengenai Synology DS920+, kali ini kita akan membahas mengenai cara memaksimalkan penggunaan NAS dari Synology untuk menunjang kegiatan Work From Home (WFH).

Jadi Pertanyaan besarnya adalah, Kenapa memilih NAS dari Synology untuk menunjang kegiatan WFH?

Untuk menjawab pertanyaan diatas, kita perlu membandingkan NAS dari Synology dengan solusi penyimpanan data yang lain.

Traditional File Sharing

NAS

Cloud
Tanpa opsi untuk kolaborasi Dengan opsi untuk kolaborasi Dengan opsi untuk kolaborasi
Pembayaran di awal Pembayaran di awal

Pembayaran berlangganan
Data disimpan di server pribadi Data disimpan di server pribadi Data disimpan di server penyedia jasa
TCO untuk jangka panjang tidak meningkat signifikan TCO untuk jangka panjang tidak meningkat signifikan TCO untuk jangka panjang meningkat signifikan
Meningkatkan kapasitas penyimpanan tidak meningkatkan biaya secara signifikan Meningkatkan kapasitas penyimpanan tidak meningkatkan biaya secara signifikan Meningkatkan kapasitas penyimpanan biaya secara signifikan
Dapat diakses secara lokal dan via internet Dapat diakses secara lokal dan via internet Hanya dapat diakses via internet

Poin penting pertama adalah “kolaborasi”. NAS dari brand Synology selain mampu bekerja layaknya server file sharing tradisional, juga dapat diakses layaknya editor dokumen online seperti Google Docs dan Spreadsheet melalui aplikasi Synology Office. Hal ini memungkinkan akses ke file dokumen yang sama secara bersamaan tanpa adanya kemungkinan untuk saling menimpa satu sama lain. Hal ini sangat berguna dalam kondisi WFH dimana kita tidak dimungkinkan untuk melakukan diskusi atau pertemuan tatap muka secara langsung.

Concern selanjutnya adalah mengenai Total Cost of Ownership (TCO). TCO untuk Server File Sharing Tradisional atau NAS kurang lebih sama, yaitu biaya untuk pembelian hardware berupa server dan media penyimpanannya. Sedangkan pada layanan penyimpanan data cloud biaya yang dikeluarkan adalah biaya berlangganan bulanan. Kelemahan dari layanan cloud adalah TCO yang meningkat secara signifikan untuk kapasitas skala besar maupun untuk solusi penyimpanan jangka panjang. Selain itu untuk relevansi penggunaan jangka panjang di kondisi yang sudah tidak lagi menerapkan WFH, kemampuan untuk akses dalam jaringan lokal juga merupakan poin penting dalam kegiatan bisnis agar produktifitas tetap terjaga meskipun terjadi gangguan pada jaringan internet.

Pertimbangan terakhir yang tidak kalah penting adalah keamanan data. Kerahasiaan data sensitif perusahaan menjadi concern dalam penggunaan layanan penyimpanan cloud. Penyimpanan data sensitif di lokasi fisik yang tidak dapat dipantau secara langsung masih menjadi pertimbangan yang penting di kalangan pebisnis hingga saat ini.

Berdasarkan pertimbangan-pertimbangan diatas dapat kita simpulkan bahwa NAS dari Synology merupakan solusi yang paling efektif untuk menunjang kegiatan bisnis, baik dalam kondisi WFH ataupun tidak. NAS dari Synology mampu menggabungkan fleksibilitas akses dari layanan cloud dengan biaya yang lebih terjangkau dan keamanan yang lebih baik dari solusi penyimpanan data tradisional.

The post WFH Lebih Efisien Bersama Synology NAS appeared first on Efison Lisan Teknologi.

]]> Synology DS920+, NAS 4-Bay Terbaik? https://efisonlt.com/synology-ds920-nas-4-bay-terbaik/?utm_source=rss&utm_medium=rss&utm_campaign=synology-ds920-nas-4-bay-terbaik Tue, 05 Jan 2021 13:27:13 +0000 https://efisonlt.com/?p=891 Synology DS920+ diperkenalkan pada pertengahan tahun 2020 untuk menggantikan Synology DS918+ yang sudah rilis sebelumnya. Seperti apa kemampuan dan fitur yang disematkan ke NAS entry-level 4-bay ini? Berikut poin poin penting yang perlu anda ketahui sebelum membeli Synology DS920+. 1. Drivebay yang aman, mudah, dan expandable Synology DS920+ meskipun berdimensi cukup kecil, mampu memuat 4-drivebay… Read More »Synology DS920+, NAS 4-Bay Terbaik?

The post Synology DS920+, NAS 4-Bay Terbaik? appeared first on Efison Lisan Teknologi.

]]> Synology DS920+ diperkenalkan pada pertengahan tahun 2020 untuk menggantikan Synology DS918+ yang sudah rilis sebelumnya. Seperti apa kemampuan dan fitur yang disematkan ke NAS entry-level 4-bay ini? Berikut poin poin penting yang perlu anda ketahui sebelum membeli Synology DS920+.

1. Drivebay yang aman, mudah, dan expandable

Synology DS920+ meskipun berdimensi cukup kecil, mampu memuat 4-drivebay untuk HDD berukuran 3,5 Inch. Selain itu untuk menunjang kemampuan upgrade yang lebih baik, Synology DS920+ juga mampu ditambahkan sebuah expansion unit sehingga dapat menjadi satu kesatuan NAS dengan 9-drivebay. Jumlah drivebay yang  lebih banyak juga dapat membantu memberikan opsi RAID tambahan baik untuk meningkatkan kecepatan maupun meningkatkan keamanan. Fitur menarik lain yang perlu digarisbawahi adalah drivebay dari DS920+ mampu dipasang dengan HDD dengan form factor 3,5mm tanpa menggunakan bantuan peralatan tambahan atau disebut tool-less drivebay, sayang sekali fitur ini tidak berlaku untuk pemasangan HDD/SSD dengan form factor 2,5mm. Meskipun begitu, sekrup untuk pemasangan HDD/SSD dengan form factor 2,5mm sudah disertakan dalam paket penjualan. Sebagai tambahan fitur keamanan, drivebay pada Synology DS920+ juga dapat dikunci sehingga dapat menghindarkan akses yang tidak diinginkan seperti jangkauan dari anak-anak.

2. Dapur pacu yang mumpuni untuk transfer data hingga transcoding 4K Video

Synology DS920+ dibekali prosesor quad core Intel Celeron J4125 dengan clock maksimal hingga 2,7 GHz. Dibanding dengan pendahulunya yaitu DS918+ yang disertai dengan prosesor quad core Intel Celeron J3455 dengan clock maksimal yang hanya 2,3 GHz, DS920+ memberikan peningkatan kecepatan yang cukup baik. Sangat disayangkan Synology masih belum menyertakan prosesor Intel Core Series ke seri DS920+ ini. Meskipun hanya menggunakan prosesor Intel Celeron J4125, penggunaan prosesor dengan arsitektur x86 memungkinkan penambahan banyak fitur seperti dukungan untuk file system BTRFS, kemampuan hosting Virtual Machine, dan bahkan kemampuan untuk transcoding video di Plex Media Server hingga resolusi 1080p FullHD dan 4K UltraHD!

3. Upgradeable performance

Tidak hanya mampu meningkatkan kapasitas drivebay dengan expansion unit, Synology DS920+ juga dibekali beberapa fitur tambahan untuk meningkatkan performanya lebih jauh lagi. Yang pertama adalah slot RAM, Selain 4GB yang sudah terpasang Synology juga memberikan tambahan berupa 1 slot yang dapat digunakan untuk meningkatkan kapasitas RAM dari DS920+. Akan tetapi meskipun memiliki slot RAM tambahan, kapasitas maksimal yang mampu diakomodasi oleh prosesor dari DS920+ terbatas di kapasitas 8GB saja.

DS920+ juga dibekali dengan 2 slot NVMe M.2 SSD untuk membantu meningkatkan kecepatan pembacaan data dengan teknologi data cache. Sayangnya, kedua slot tersebut memang hanya terbatas untuk data cache dan tidak dapat diakses secara langsung. Untuk melakukan upgrade baik ke slot memory RAM maupun ke slot NVMe M.2 SSD dapat dilakukan dengan mudah tanpa menggunakan peralatan tambahan (tool-less) seperti pada pemasangan HDD 3,5mm yang sudah disebutkan sebelumnya.

4. Hanya memiliki 2 port Gigabit Ethernet

Salah satu hal yang kami sayangkan dari Synology DS920+ adalah kedua port ethernet yang tersedia hanya memiliki kecepatan maksimal 1 gigabit. Infrastruktur jaringan dengan kecepatan 2,5 gigabit memang masih belum banyak ditemui di Indonesia. Akan tetapi ketersediaan fitur ini menurut kami cukup penting untuk menunjang performa DS920+ dalam penggunaan jangka panjang. Mengingat perangkat perangkat elektronik keluaran tahun 2020 sudah mulai mengadopsi 2,5 gigabit ethernet. Synology memang memberikan solusi berupa protokol link aggregation yang dapat menggabungkan kedua port menjadi satu untuk mencapai kecepatan 2 gigabit. Akan tetapi fitur ini hanya dapat diakses dengan apabila terdapat perangkat manageable network switch saja.

5. Ringkas dan Senyap

Dengan dimensi 166 mm x 199 mm x 223 mm, Synology DS920+ memiliki ukuran yang cukup ringkas untuk NAS dengan kapasitas 4-bay. Hal ini memang harus dibayar dengan penggunaan komponen penyuplai daya yang terpisah dari fisik DS920+. Tetapi, disisi lain desain seperti ini memungkinkan NAS beroperasi dengan lebih dingin dan senyap karena salah satu sumber panas utama adalah komponen penyuplai daya. Komponen penyuplai daya terpisah juga memungkinkan penggantian yang lebih mudah apabila terjadi kerusakan pada komponen penyuplai daya.

 

The post Synology DS920+, NAS 4-Bay Terbaik? appeared first on Efison Lisan Teknologi.

]]>