Second fiddle time - how to get your crappy AMD Ryzen APU proxmox machine (t640/740/t55) to also be a lousy to tolerable LLM inferencing box

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

WANg

Well-Known Member
Jun 10, 2018
1,564
1,194
113
48
New York, NY
Technique 1 (the easy way) - Getting Lemonade-AI to run on Proxmox 9

Note: This pre-suppose that you are running proxmox 9.x (i.e. based on Debian Trixie) and you left some extra room on /dev/mapper/pve-root to fit a few GGUFs.

Hey kids, looks like you inherited a bunch of t740s (basically e-waste adjacent at this point), and you would like to put those useless Ryzen Vega iGPUs to work on Proxmox 9. It can't be offloaded (SR-IOV) cleanly, and blacklisting the device for docker just felt...odd.
How about tossing lemonade.ai onto it so you too can add a low parameter inferencing capability to the box?

Oh, you can't because of dependencies?

Here's how to fix it.

a) Add the missing repos


Code:
SSH in as root

Go to
/etc/apt/sources.list.d/debian.source
and change the 2 repos to include non-free

Add the new file

/etc/apt/sources.list.d/debian-backports.sources

with the following:

Types: deb deb-src
URIs: http://deb.debian.org/debian
Suites: trixie-backports
Components: main
Enabled: yes
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

(do a save, and apt-get update - if you can't figure it out rename the 2 txt files attached here (by gettng rid of the .txt in the name, and then moving them to /etc/apt/sources.list.d/)
b) Add the dependency packages

Code:
apt-get -y install libvulkan1 mesa-vulkan-drivers vulkan-tools
c) Grab the debian packages for lemonade-ai server, autoresolve the issues and enable the lemonade server

Code:
wget https://github.com/lemonade-sdk/lemonade/releases/latest/download/lemonade-server_11.5.2-debian13_amd64.deb
apt-get install ./lemonade-server_11.5.2-debian13_amd64.deb
apt --fix-broken install
systemctl enable --now lemond
d) Download and download amdgpu_top

Code:
wget https://github.com/Umio-Yasuno/amdgpu_top/releases/download/v0.11.5/amdgpu-top_0.11.5-1_amd64.deb
dpkg -i amdgpu-top_0.11.5-1_amd64.deb
e) Setup Lemonade to allow connections from outside localhost, and restart lemond

Code:
lemonade config set host=0.0.0.0
service lemond restart
Now connect to it using lemonade-server and download/run some tests.

The HP t740 thin client

Is it useful in the context of a t740 (features a Ryzen embedded V1756B, which is the same as a Ryzen 5 2600H)?
Eeeeeh, marginally.

For example, if we download a small model (gemma-4-E2B-it) on a t740 (running proxmox 9.2) and run it with a context window of 32k, and by using the lemonade benchmark over 5 runs using this syntax:

Code:
root@pve2:~# LLM="Gemma-4-E2B-it-GGUF"
root@pve2:~# lemonade bench $LLM --backend vulkan --ctx-size 32768 --runs 5
We have:

TTFT = Time to FIrst Token (in milliseconds, lower number is better)
TPS = Tokens per second (higher number is better)

Screenshot 2026-08-11 at 10.12.58 PM.png

16 is slower than realtime (usually 25) but it's somewhat tolerable.

Does context window size matter on this machine? Kinda. Here's lowering the ctx to 8k to compensate for less compute firepower...very slight improvement in TTFT time and slightly higher tokenization rate.

Screenshot 2026-08-11 at 10.30.59 PM.png

Are we sure it's working off the Radeon Vega 8 Embedded iGPU?

Screenshot 2026-08-11 at 10.42.41 PM.png

Yeah it is. What about a more frontier model like Qwen 3.8 with 4 billion parameters, q=8?

Screenshot 2026-08-11 at 10.57.11 PM.png


Eeeeeh, it's working but 7 tokens/sec isn't my idea of functional.

The HP t755 Elite thin client

What about the t755 (its successor), which has a Ryzen embedded V2546 (same as a Ryzen 5 4600H)? Can anything fun be done with it when it goes onto the secondary market one day?
Okay, well, it just so happens that I have a t755 as my production hypervisor, so I can do some quick testing.

Note that if you compare the numbers it's about 20% faster (from 16 to 20 tps) despite the fact that the Radeon Graphics 384SP iGPU on the t755 is roughly the same in terms of texture/FP performance as the Vega 8 Embedded iGPU on the t740 (the pixel rate is higher on the 384SP but not by much, roughly 15-20% higher)

Screenshot 2026-08-12 at 11.01.02 AM.png

So, eh, how do we know it's working?

Screenshot 2026-08-12 at 10.43.12 AM.png

What about the same trick with lowering ctx? Slight improvement but not by much.

Screenshot 2026-08-12 at 11.19.21 AM.png

What about Qwen 3.8? TTFT is significantly better but token-walking still suck.

Screenshot 2026-08-12 at 11.11.01 AM.png

20tps on Gemma-4 is almost about useful. Although I would be extremely cautious/skeptical about its factuality.

1786551553020.png

Screenshot 2026-08-12 at 12.14.23 PM.png

(at least 4 of those stations exist on another route coming out northwest of Tokyo, the train route is generally a south/southwest route, Kobe is west of Osaka on a completely different line, and both Atami and Odawara (major beachside resorts in the Kanto region) are both misreported as not being stops on the Tokaido Shinkansen. Hoooh boy...)

OFF-TOPIC
Comparison / e-Peen measurement with the Minisforum N5 Air, with or without AMD Radeon Pro V620 acceleration


In contrast, here's the Minisforum N5 Air (Ryzen 7 255H, same as a Ryzen 8845HS but with its useless XDNA NPU disabled) using its Radeon 780M iGPU on Debian 14 (should work on Debian 13). ROCm support for the 780M was added in Lemonade 11.6.

Note the much lower TTFT numbers due to the 780M having stronger compute overall (RDNA3.5 instead of Vega 2 GPU architecture).
If you have a strix Halo, the 780M is about 1/2 to 1/3 the computing firepower of your Radeon 8060S and with double 1/2 the RAM bandwidth, and based on benchmarks from Strix halo machines versus the 780M the numbers do jive with that difference.

Here's Gemma-4 E2B on the 780M, with Vulkan and ROCm respectivelyy...

Screenshot 2026-08-11 at 10.08.48 PM.png
1788143178247.png

And here's Qwen 3.8 with 4 billion parameters, condensed on quantization level 8, Vulkan and ROCm.

Screenshot 2026-08-11 at 10.56.34 PM.png
1788143201467.png

And here with its Radeon Pro V620 off an Oculink eGPU dock on Vulkan mode.

Gemma-4-E2B...Vulkan and ROCm

Screenshot 2026-08-11 at 10.13.06 PM.png
Screenshot 2026-08-11 at 10.16.12 PM.png

Qwen 3.8, Vulkan and ROCm

Screenshot 2026-08-11 at 10.43.45 PM.png
Screenshot 2026-08-11 at 10.47.25 PM.png

Yeah, TTFT is faster here but token walking is slower on ROCm.

Note that TTFT isn't much lower overall on the V620 versus the 780M, but the token walk rate is much better.
That hints to the RDNA3.5 compute units on the 780M being faster on a per-CU basis (but with less CUs than the V620 so it loses overall), but the higher token walk rate on the V620 is a direct correlation of its higher in-device memory bandwidth.

So, what does the V620 look like with its VRAM (32GB) maxed out and spilling over?
Here's Vulkan and ROCm on an 80B parameter, A3B model, which uses up ~30GB of VRAM out of the 48 needed (the rest will go to GTT/DDR5 system RAM).

Screenshot 2026-08-11 at 10.39.09 PM.png
Screenshot 2026-08-11 at 10.29.08 PM.png

And what about inferencing off the 780M using DDR5 system memory? Is the numbers that much worse?

Screenshot 2026-08-30 at 10.38.30 PM.png

Screenshot 2026-08-11 at 11.28.34 PM.png
1788144324750.png
Eh, I would say that paradoxically for certain tasks the 780M is not that far off from the V620...maybe about 1/3 slower...and for the code explain/debug tasks the 780M is actually almost-as-fast as the V620 and on Vulkan, even slightly faster on first token/prompt processing rate.
We'll need to see if the benchmark numbers jive with actual experiences.
 

Attachments

Last edited:

Greg_E

Active Member
Oct 10, 2024
563
176
43
Thanks, I'm currently not getting anything that fast on my t740, I need to look into vulkan settings, it's running CPU mode right now, even though I have the vulkan docker container for localAI running. Need to get back to this and fiddle a little more, but at this point it seems just an exercise in frustration to see if I can actually finish the project.

I did check for vulkan, it's all installed in openSUSE Leap 16, and shows both igpu and egpu so I should be getting something better. Just haven't felt like beating my head against the wall trying to figure it out.
 

WANg

Well-Known Member
Jun 10, 2018
1,564
1,194
113
48
New York, NY
Technique 2 (the silly way) - Getting LocalAI to run on Proxmox 9.1 and above

Okay, so the second and admittedly sillier method of running an LLM is to run it inside a docker container, and joy of joys, you can now run docker containers as LXC images on Proxmox 9.1 and above...so we will take advantage of that. And yes, it's very silly and I don't recommend doing so (containers are not really my cup of tea), but if you want to run an LLM with not much effort, well, this is how.

Step 1: Prep your victim

Actually, you don't really have to do too much - maybe make sure that your proxmox hypervisor knows about your GPU (in my case, the Radeon Vega should at least be showing up on the kernel module...for amdgpu).

Screenshot 2026-08-20 at 7.36.07 PM.png

Step 2: Prep the CT template

Open up the main storage container in Proxmox (local) and go to CT Templates.

Screenshot 2026-08-20 at 7.33.25 PM.png

You want to pick the option to pull from OCI registry - and under reference, you want to type in localai/localai and then click on "query tags". Give it a few seconds and the drag-down should auto-populate. Select "latest-aio-gpu-vulkan" for the Radeon Vega iGPU...and then click on Download...

Screenshot 2026-08-20 at 7.34.18 PM.png

And wait until it finishes...
Screenshot 2026-08-20 at 8.06.34 PM.png

Step 3: Create the LXC container (and be prepared to shut it down and tweak if needed)

Well, make the LXC container, point back to the template that you referenced, but make sure you'll be ready to shut it off soon...(I gave it 16GB of RAM and a 64GB vdisk)...then fire it up. Note that on this demo I set up localai to use a static IP address of 192.168.1.183/23.

Screenshot 2026-08-20 at 8.19.16 PM.png

Step 4: ssh into the proxmox server and use pct enter <id> to get into it, then install some tools that can help...

Code:
apt-get update; apt-get install kmod lsof nano vulkan-tools
Screenshot 2026-08-20 at 9.15.44 PM.png
and then wget/install amdgpu_top, and run it once (if you are using the Vega 8 iGPU within). You'll need the error message...

Code:
wget https://github.com/Umio-Yasuno/amdgpu_top/releases/download/v0.11.5/amdgpu-top_0.11.5-1_amd64.deb; dpkg -i amdgpu-top_0.11.5-1_amd64.deb
Screenshot 2026-08-20 at 9.18.09 PM.png

Code:
amdgpu_top
Yeah, it'll fail. The driver will fail to grab the device from devfs and it'll puke an error message identifying which devfs device you'll need to pass in from the proxmox host

Screenshot 2026-08-20 at 9.20.18 PM.png

Note the error explicitly references 2 out of 3 locations (it might be different), which is /dev/dri/card0 and /dev/dri/renderD128 here, and /dev/kfd in the host machine) that is mapped by the amdgpu driver...note that this is different for nVidia devices.

Step 5: Go back to the proxmox server, shut down the LXCcontainer and add the 3 location as device passthroughs (its under "resources")

Screenshot 2026-08-20 at 9.24.23 PM.png

Then start it back up using the proxmox UI OR via the command line (pct start 200, then pct enter 200 in our case). Then run amdgpu_top again.
If amdgpu_top fires up successfully and shows the compute units, then it's ready.

Screenshot 2026-08-20 at 9.29.24 PM.png

Step 6: go to the http://<IP address>:8080 (192.168.1.183 in this demo) on your web browser and see if localAI shows up there...and you might want to have amdgpu_top running on that container just in case to see the compute units being put to work while working on questions. Note that while 12 tokens/sec is not something to brag about it's still putting idle resources to work for free...

Screenshot 2026-08-20 at 9.39.43 PM.png
 
Last edited: