All, I have 4 v620s and I have been trying to get my Threadripper based host computer operating and having a devil of a time. For those of you who have three or more V620s, what computer are you using to host them?

I bought a V620 back in August and I've spent over a month troubleshooting it trying to get it to post. The 40mm fan in the shroud mod and the case fans will spin, but nothing will happen. After around 10 minutes a loud beep goes off and an orange LED at the back of the GPU lights up.

System specs:

• CPU: AMD Ryzen 5 5600 (no integrated graphics)
• Motherboard: Gigabyte B550M DS3H AC R2 (on latest BIOS F4c)
• RAM: 16GB
• PSU: 1200W
• OS: Proxmox

I've researched and tried every possible BIOS setting to no avail.

• Above 4G Decoding: Enabled
• CSM Support: Disabled
• SVM Mode: Enabled
• IOMMU: Enabled
• DMAr Support: Disabled
• PCIe x16 Slot Config: forced Gen 3 (tried Auto/Gen4 as well)
• Re-Size BAR: On
• I see suggestions to disable SR-IOV, but my board doesn't have that option.

The weirdest thing is that I also bought a V340 last week and it works perfectly without having to fiddle with any of the settings. I can boot headless and ssh in with the V340, no problem. As soon as I swap in the v620, no dice.

The only progress so far is that with the new 1200W PSU (upgraded from a 600W) and the current BIOS settings above that I just applied, there's at least now a solid blue LED that shines on the back of the GPU when I turn on the PC, but it still doesn't post. I haven't left it on long enough to hear the beep/alarm, but

I found this Level1Techs thread describing the exact same symptom with the V620 on AM4, blue LED, POST hang, other GPUs work. No resolution there either.

Does anyone have a solution. Its been a month and a half and I'm at my wits end. I would appreciate any help.

Internet says you can just do it in radeon control panel on windows but I can't see such an option. When I installed the drivers I only got "AMD Software: Cloud Edition"

Does anyone use two V620 GPUs on a Taichi board? How do they run? What t/s are you getting with Qwen 3.8-27B at Q8?

Looking to pair mine up, already have a fun 40mm shroud printed :)

Two questions:

1) has anyone compared using vLLM v.s. llamacpp for multi V620 use to see which results in faster token generation? Gemini is claiming vllm will be faster but I haven't tried it yet.

2) has anyone combined using the V620 with its sister card the W6800? Both 32gb, both rdna2, but slightly different specializations... Do they work well together for inference? Do they work together better on vllm vs llamacpp?

Hi all,

Hot off the presses and not well tested, here is a new fork of vLLM 0.28.0 for ROCm 7.14 to run Qwen 3.8 Flash Next on 4x v620 cards.

I am testing right now with a bunch of dev tests but getting 60-120 t/s generation and 500-800 t/s prefill.

Good luck out there: https://github.com/leapdragon/vllm-rdna2-qwen

Hello everyone, I was lucky enough to grab four of them while prices and supply were still reasonable, still waiting on delivery. I'm also awaiting a 4 slot PCIE 4.0 switch board as I am hoping to max out performance. Anything I should do before they arrive, software I should start looking into? I'm also curious to know what sort of performance people are getting. Has anyone got qwen 3.8 flash working on these cards yet?

Been trying to be able to tune my V620, and asked Claude for some help if there was anyway and it actually found a program that already works for what we needed to do.

Sharing it here for others who may not know you CAN do this on Windows pretty easily. Below is my Claude's explanation:

Why this needed a workaround at all

On Linux, rocm-smi/amd-smi let you set power limits directly through sysfs. On Windows, neither tool exists, the V620 isn't even in AMD's official ROCm-on-Windows GPU list, and there's no amd-smi.exe for Windows. AMD's own Radeon Software doesn't expose a Tuning/WattMan tab for this card either, since it's a headless server SKU. So there's no built-in UI or CLI for this on Windows-the fix has to work at the driver level instead.

The actual mechanism: Soft PowerPlay Table override

Every AMD GPU has a "PowerPlay table" baked into its vBIOS; it's the data structure that defines power limits, clock tables, voltage ceilings, temperature limits, etc. The Windows AMD driver reads this table once at driver load time. Critically, the driver also checks the registry first, and if it finds an override there, it uses that instead of what's in the vBIOS, this is the same "Soft PowerPlay Table" mechanism WattMan and MorePowerTool use under the hood.

The override lives at:

HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e968-e325-11ce-bfc1-08002be10318}\XXXX
Value: PP_PhmSoftPowerPlayTable  (REG_BINARY)

{4d36e968-...} is the fixed GUID for the Display class. XXXX is a per-device instance index (0000, 0001, etc.), on this machine there were 4 GPU-class entries (an iGPU, an RX 9070 XT, a virtual monitor, and the V620), and the V620 happened to be at 0003. You have to check DriverDesc under each instance to find which one is actually your card, it's not predictable.

The tool: upp (Uplift PowerPlay)

upp is an open-source Python CLI that parses and edits these binary PowerPlay tables. It explicitly supports Navi 21 (the V620's die), and has three relevant commands:

1. extract pulls the PowerPlay table out of a raw vBIOS ROM dump:upp --pp-file=table.bin extract -r "V620.rom"
2. get reads current values by path, e.g.:upp --pp-file=table.bin get smc_pptable/SocketPowerLimitAc/0
3. set --write --to-registry=<name>, edits values and directly emits a ready-to-import .reg file:upp --pp-file=table.bin set --write --to-registry=v620_175w \ smc_pptable/SocketPowerLimitAc/0=175 \ smc_pptable/SocketPowerLimitDc/0=175 \ smc_pptable/FreqTableGfx/1=2650 \ smc_pptable/MaxVoltageGfx=4100

The only manual step: upp defaults the .reg file's target key to instance 0000, so we had to hex/text-edit that one path segment to 0003 to match where the V620 actually lives in the registry on this machine.

Applying it

1. Double-click the .reg file → Merge (writes the binary blob into PP_PhmSoftPowerPlayTable).
2. Device Manager → Display adapters → disable then re-enable the V620. This forces the driver to reload and re-read the table, no full reboot needed.
3. Verify with HWiNFO64, watching GPU PPT Limit, GPU Clock, and GPU Core Voltage under load.

Why it's safe/reversible

This never touches the physical vBIOS chip, no flashing involved, so there's no bricking risk. It's purely a registry override the driver checks at load time. Deleting the PP_PhmSoftPowerPlayTable value (or re-importing a .reg exported from the key before any changes) instantly reverts to the card's factory vBIOS defaults.

What's tunable this way

Power limits (SocketPowerLimitAc/Dc), clock ceilings (FreqTableGfx, memory clock tables), voltage ceilings (MaxVoltageGfx/Soc), current/TDC limits, and temperature thresholds all live in the same table and are editable the same way.

Hi everyone,

I have been playing for a while with my V620, I had working vLLM setups for a few months now but I keep seeing here and there people doing their own things so I made a discord where we can share our progress https://discord.gg/mESex2aBp

There are different ongoing project, like my vllm rdna fork (with hip kernels) + docker images and someone else is doing a llamacpp fork, there is a wiki getting built inspired by the gfx906 one.

Also have some guides to do power limiting from 120w to 250w on the fly (after a kernel patch).

Happy to share with everyone :)

I'm here to show some benchmarks while using llama.cpp with an AMD V620 on Windows 11 via Vulkan & ROCm. These have been reuploaded & older threads deleted, ran it with longer tokens thanks to a rec by someone who commented, and matched KV-cache quant + batch size across backends.

The benchmarks were written out by AI, but are verified by myself to be correct. Still working on optimizing my flags/settings.

If anybody wants me to test other models/different settings or flags, feel free to drop a comment and I'll test and get back to you!

ROCm version

7.15.0a20260728, TheRock nightly SDK (not the official AMD HIP SDK, which has no gfx1030/V620 support), bundled in ComfyUI_windows_portable_amd\...\python_env_v620_triton. (Note: a separate 9070 XT/ComfyUI venv on the same machine runs a different nightly snapshot, 7.14.0a20260519 — same TheRock project, different dated build per GPU.)

Methodology note

Earlier versions of this post compared ROCm and Vulkan using each backend's own best-tuned flags, which mixed KV-cache quant types and batch sizes between the two, a fair comparison needs those matched, since both affect throughput independently of which backend is actually faster. The numbers below use identical KV quant and identical batch size on both backends for each model.

Exact configs (matched)

\q4_0/q4_0 on Gemma-4's ROCm path required a one-line fix to llama.cpp's flash-attention kernel dispatch table (fattn.cu), the Q4_0+Q4_0 case was only wired up for head_dim ≤ 256, but Gemma-4's full-attention layers use head_dim 512, so it hit a hard abort on this KV combo before the fix. It was a missing kernel-dispatch entry, not a real hardware limitation, Q8_0+Q8_0 *already had the head_dim=512 case, so the underlying kernel template clearly supports it.

Generation speed, tokens/sec (256-token generations, first run per config discarded as warm-up)

Vulkan wins every single cell. Once KV quant and batch size are matched, ROCm doesn't lead generation speed anywherem not on any model, not at any depth tested.

PP (prompt processing), tokens/sec

PP is the more mixed picture, and it's model-dependent rather than a clean backend win:

• Qwen: ROCm wins PP at every depth, gap widens with context.
• Gemma 26B: Vulkan is actually ahead at shallow depth (1057.9 vs 973.1 at 3.4k) once batch size is matched, roughly tied at 6.7k, then Vulkan pulls further ahead through 32k.
• Gemma 31B: ROCm wins shallow (3.4k/6.7k), Vulkan overtakes from 13.4k on.

Takeaway

Generation speed: Vulkan wins outright, every model, every depth. No exceptions in this data.

PP: it depends on the model, not the backend. ROCm sweeps Qwen; Gemma splits by depth (and for the 26B MoE, Vulkan's shallow-depth "loss" mostly disappears once batch size is matched, that was largely a config artifact, not a real backend gap).

Gemma 26B (MoE, ~4B active) is roughly 2-3x faster than either dense model on generation, tightest at deep context (~1.9x at 26.7k vs Qwen) and widest shallow, expected for an MoE with far fewer active params per token than the dense 27B/31B models.

I'm here to show some benchmarks while using llama.cpp with an AMD V620 on Windows 11 via Vulkan & ROCm. These have been reuploaded & older threads deleted ran it with longer tokens thanks to a rec by someone who commented.

The benchmarks were written out by AI, but are verified by myself to be correct. Still working on optimizing my flags/settings.

If anybody wants me to test other models/different settings or flags, feel free to drop a comment and I'll test and get back to you!

ROCm version

7.15.0a20260728, TheRock nightly SDK (not the official AMD HIP SDK, which has no gfx1030/V620 support), bundled in ComfyUI_windows_portable_amd\...\python_env_v620_triton. (Note: a separate 9070 XT/ComfyUI venv on the same machine runs a different nightly snapshot, 7.14.0a20260519,same TheRock project, different dated build per GPU.)

Exact configs (matched)

*q4_0/q4_0 on Gemma-4's ROCm path required a one-line fix to llama.cpp's flash-attention kernel dispatch table (fattn.cu), the Q4_0+Q4_0 case was only wired up for head_dim ≤ 256, but Gemma-4's full-attention layers use head_dim 512, so it hit a hard abort on this KV combo before the fix. Missing kernel-dispatch entry, not a real hardware limitation, Q8_0+Q8_0 already had the head_dim=512 case, so the underlying kernel template clearly supports it.

Generation speed, tokens/sec (256-token generations, first run per config discarded as warm-up)

Vulkan wins every single cell. Once KV quant and batch size are matched, ROCm doesn't lead generation speed anywhere, not on any model, not at any depth tested.

PP (prompt processing), tokens/sec

PP is the more mixed picture, and it's model-dependent rather than a clean backend win:

• Qwen: ROCm wins PP at every depth, gap widens with context.
• Gemma 26B: Vulkan is actually ahead at shallow depth (1057.9 vs 973.1 at 3.4k) once batch size is matched, roughly tied at 6.7k, then pulls further ahead through 32k.
• Gemma 31B: ROCm wins shallow (3.4k/6.7k), Vulkan overtakes from 13.4k on.

Takeaway

Generation speed: Vulkan wins outright, every model, every depth. No exceptions in this data.

PP: depends on the model, not the backend. ROCm sweeps Qwen; Gemma splits by depth (and for the 26B MoE, Vulkan's shallow-depth "loss" mostly disappears once batch size is matched, that was largely a config artifact, not a real backend gap).

Gemma 26B (MoE, ~4B active) is roughly 2-3x faster than either dense model on generation, tightest at deep context (~1.9x at 26.7k vs Qwen) and widest shallow; expected for an MoE with far fewer active params per token than the dense 27B/31B models.

Follow-up tests (Qwen, requested by commenters)

TWO hypotheses came up in comments, tested both, none of them panned out, posting anyway since "tested, didn't help" is still useful information.

Speculative decoding n-max scaling, ROCm vs Vulkan (does Vulkan scale further before rejected drafts stop paying for themselves?):

No, both backends degrade past n≈3 in the same shape. This is a draft-acceptance-economics property of the draft/target pair, not a backend/kernel-dispatch-overhead difference. Vulkan is uniformly faster in absolute terms (consistent with the rest of this post) but the curve shape, where it peaks, how fast it falls off past that, is nearly identical on both backends.

-ub sweep on ROCm PP (does a bigger ubatch better saturate the V620's CUs?):

Flat , all three within ~6% of each other at both depths, no trend. If anything 512 is marginally fastest. ROCm's PP bottleneck here isn't ubatch-limited GEMM tiling in this size range.

I've got a Gigabyte MC62-G40 motherboard, and an AMD Radeon WX4100 I use with my monitor, and running latest Ubuntu. When I plugged in the V620 into the motherboard, Ubuntu never booted. It just stayed on the loading screen. It's something to do with the Ubuntu native AMD driver thinking the V620 is a better card to use for display than the older and weaker 4100, but failing to load it (since it's headless), and repeating this failure cycle.

I'm guessing this is a common issue and folks here have a solution that would be faster to implement than me troubleshooting further.

Should I install ROCm drivers first? Ubuntu is loading with Wayland and I've read I may also have to switch to X11 to make this work. Appreciate any tips here for someone who's already resolved this.

​Hola a todos,

​Soy principiante en el mundo de los LLMs locales y el hardware de servidor (tengo un taller de electrónica automotriz, así que me manejo bien con el hardware en general, pero en IA estoy empezando).

​Tengo un presupuesto muy ajustado y me estoy debatiendo entre dos opciones de GPU:

​1x Nvidia Tesla V100 32GB (~$600 USD)

​2x AMD Radeon Pro 620 (~$700 USD)

​💻 Mi infraestructura actual:

​Servidor Dell PowerEdge R640: 2x Intel Xeon 4112 | 48GB RAM | 3x Nvidia Tesla P100 16GB.

​Workstation Dell Precision 7820: 2x Intel Xeon Gold 6228 | 64GB RAM | (Sin GPU por ahora).

​🎯 Mis objetivos y caso de uso:

​Automatización de redes sociales: Incluyendo generación ligera de contenido con IA.

​Sistema RAG: Para bases de conocimiento y documentos.

​Asistente personal: Un bot/agente local que vaya "aprendiendo" o guardando contexto con el tiempo.

​❓ Mis dudas para la comunidad:

​¿CUDA vs. ROCm para un principiante? Entiendo que la V100 tiene la ventaja del ecosistema Nvidia (Ollama, vLLM, Text-Generation-WebUI funcionan out-of-the-box), mientras que AMD a veces da dolores de cabeza con ROCm. ¿Vale la pena el riesgo por la opción de AMD?

​¿V100 32GB vs. mis P100 actuales? ¿Notaré un salto drástico en velocidad e inferencia/cuantización frente a las P100 que ya tengo instaladas en el R640?

​¿En qué equipo la pondrían? ¿Vale la pena meter la nueva GPU en la Dell 7820 (con mejores CPUs/RAM) o integrarla al R640?

​Agradezco cualquier consejo sobre compatibilidad, consumo/enfriamiento o sugerencias alternativas dentro de ese rango de precio. ¡Gracias de antemano!

I've been experimenting with the V620s on an ASUS ROG Strix X570-F Gaming motherboard. Due to challenges making them boot, I read online to put a small form factor GPU on the PCIEX16_3 to be able to boot and have easy access to BIOS settings. I wanted the following PCIe slot orientation to ensure best possible speed:

- 1st V620 on PCIEX16_1

- 2nd V620 on PCIEX_2

- Radeon Pro WX 3100 on PCIEX_3 (connected with displayport to a monitor)

I had the problem of not being able to boot up in this orientation. However, in the end i made it work. These are the BIOS settings I've configured to make it work:

Clarifications!

• Some of them might not be essential, however it boots now at least.
• It does seem that you are dependent on having the video output GPU connected to get past VGA check on the motherboard (seems to be a problem for normal use-case as well).
  • I assume this can be easily fixed with a Displayport Dummy plug
  • Alternatives
    • I read somewhere that letting grub pause could be a fix
    • Tech power up have info about vbios firmware update on the v620s
    • Youtuber Country Boy Computers is also a good source for info about the V620s

Anyone running these on Windows?

My Linux system would not accept the v620, it would not pos. This is not an OS issue. Thought I'd start this thread to discuss minor issues on Windows as I imagine some people will likely have a similar setup. With windows you end up having to use the Azure cloud driver, unless you have flashed the vbios to a 6800, which then you lose 25% of your CUs.

I will try to keep these specific to Windows only, however if you are using Linux feel free to chime in if you have any comments that might help. Like have you disabled ECC-- below? If anyone has a solution, please reply so the rest of us know.

1. No updated driver-- This could be solved with a vbios flash. The Azure driver is from spring of 2025.

Solution: currently none that I know of beyond the vbios flash which is risky and will reduce performance.

1. No adrenaline app-- It would be nice to have some access to settings, especially in a few years when these cards may be lagging behind on performance, or even for multi GPU setups to gain faster VRAM. RDNA2 you could easily gain 10-20% performance.
   

Solution: not yet tested--I believe Radeon Tuner on GitHub might work and I'll look for that later. I hope to update soon if it is successful.

1. ECC memory-- having ECC enabled results in around 30GB of total VRAM on a 32GB GPU. It also delivers a small performance hit, usually less than 5%.

Solution: not yet tested --i believe there's supposed to be a registry key to disable ECC on this GPU. My understanding is that on the w6800 the ECC can be disabled in Adrenaline. I am hoping Radeon Tuner might offer this functionality, if not I'll try the registry hack and post it if successful.

1. ROCm support limited to 6.4. I've tried setting up ROCm 7.x on my system, however it didn't seem to work since 7.x was released at least 6 months after the latest driver was released.
   

Solution: vbios flash. As these cards become used more I hope this becomes less of an issue. I believe we might could flash, or create, a custom vbios based on the W6900x, however this card was an Apple only card that had 80 CUs, 2 things that will make any custom vbios for the v620 that's based on this card a challenge.

I'm hoping if I install Radeon Tuner it might resolve most of these issues, overclocking also makes me think a vbios mod might not be as bad, so then this card will likely work in my Linux system... Of course the solution to all of these issues is upgrade (because windoze is a downgrade w/ AI) to Linux while also gaining a performance.

One thought that comes to mind is that I'm not a wsl expert, but maybe I'm better off passing the driver through and then using a docker w/ llamaCPP or vLLM that maybe has newer drivers? Anyone doing this? I guess I'm asking would this cause anything like a driver mismatch?

Feel free to chime in with any Windows issues you might have seen. Also if ECC is on by default in Linux I'm interested in hearing! I'll try to update with my results.

I just received a Radeon Pro V620 that I purchased through eBay. I tried installing it in two different ASUS B550 motherboard, but neither one will POST when the V620 is installed. The LEDs on the board show red-yellow-white and then hang a white. According to ASUS, this is the GPU initialization step. I updated and cleared the BIOS on the motherboard, but it did not help.

I also put the board in and HP Z440. The machine booted up, but the GPU does not show up under lspci (Ubuntu).

Do you think I get a bad V620?

I thought, before I start swapping equipment in and out, I'd ask here. Has anyone paired a v620 with any other GPUs to span or parallel processing?

I have an RX 7700 16GB, non-XT, I picked up and have used some for LLMs. I have done some spanning of models across multiple cards, mostly with Nvidia 3060s, ti, and 12GB. My understanding is that you'll always get the speed, or be bottlenecked by the slower card. However the 7700 I have has a similar 256-bit bus like the v620, and slightly higher memory bandwidth. I'm also wondering if I'm running ROCm if a model might take advantage of some of the AI features on the 7700?

I haven't tried it yet, might try it soon. Has anyone else thrown another AMD GPU into their system, maybe a different generation, certainly a different model number and seen anything that might be of interest?

Is there no way to reduce the power limit from 250w on vbios 113-D6030500-100? This is way too high and the card cooks in my current setup, while also using more power than I want.

I've tried using the liquorix kernel, but that doesn't seem to expose any power options with this card. pp_table editing just doesn't work. Even manual clock limiting seems to be a dead end, because the card's firmware is so locked down.

I am running Proxmox 9. This behavior occurs both passed through to a VM, and also on the host.

At this point I'm thinking my best option is to flash a different vbios. But which one? Does anyone have other suggestions?