Idea: Strix Halo community evidence + vendor collaboration #25
Replies: 7 comments 7 replies
|
One extra note from my side: I do think everyone here can benefit from this, not just me. If a vendor ever sends a Beelink, Framework, Corsair, GMKtec, Minisforum, Nimo, or other Strix Halo system for testing, the value is much higher when multiple people can help shape the benchmark questions, compare against their own systems, and sanity-check the results. Even if there is one maintainer/contact point for a first vendor conversation, I would love this to turn into something where contributors also get visibility, credit, useful hardware access where possible, and a stronger shared evidence base. Honestly, seeing someone else here get a unit or access to test would make me just as happy as getting one myself. The fun part is proving what these systems can do together. |
|
I think this is a fantastic idea. I've been away for the last 2 weeks, and will get caught up with the repo developments this week. If there are any immediate thoughts on how my gmktec and I can be helpful at this point please lmk.
…________________________________
From: hogeheer499-commits ***@***.***>
Sent: Monday, 22 June 2026 09:57:39
To: hogeheer499-commits/strix-halo-guide ***@***.***>
Cc: mottledMantis ***@***.***>; Mention ***@***.***>
Subject: Re: [hogeheer499-commits/strix-halo-guide] Idea: Strix Halo community evidence + vendor collaboration (Discussion #25)
One extra note from my side: I do think everyone here can benefit from this, not just me.
If a vendor ever sends a Beelink, Framework, Corsair, GMKtec, Minisforum, Nimo, or other Strix Halo system for testing, the value is much higher when multiple people can help shape the benchmark questions, compare against their own systems, and sanity-check the results.
Even if there is one maintainer/contact point for a first vendor conversation, I would love this to turn into something where contributors also get visibility, credit, useful hardware access where possible, and a stronger shared evidence base.
Honestly, seeing someone else here get a unit or access to test would make me just as happy as getting one myself. The fun part is proving what these systems can do together.
—
Reply to this email directly, view it on GitHub<#25?email_source=notifications&email_token=AJTQARGJKHTAFXTYYS2LITL5BE3NHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZTHEZTKMRXUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17393527>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJTQARHBUODNPWPBMMF6KBD5BE3NHAVCNFSNUABJKJSXA33TNF2G64TZHMYTCNZZGMYDGNJQHE5UI2LTMN2XG43JN5XDWMJQGI4TKOBZHGQXMAQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
im also gonna be on vacation from 23-30 June. so no hurries. but it would be so cool if we can turn this around and have benefits/rewards for everybody!!! |
|
Sorry for the slow reply, I was in Hungary for a week and I am catching up now. This is exactly the kind of help that would be useful. For the GMKtec, I think the best next step is to keep it simple and make one small apples-to-apples pack first, then expand from there:
That gives us a clean GMKtec baseline that vendors/reviewers can understand, instead of a huge benchmark dump that is hard to compare. Also, if you have thoughts on the vendor angle, I would love them. My current instinct is: GitHub stays the clean source of truth, Discord is better for coordination, and vendor asks should be concrete: loaner/review units, BIOS/firmware notes, driver/setup feedback, and maybe affiliate/support later only if it is clearly disclosed. No rush at all. Glad you are in. |
|
That’s wild, I was next door in Slovenia for 10 days. Beautiful place.
I’m getting caught up this week and will look more carefully at your list in the next few days.
From: hogeheer499-commits ***@***.***>
Sent: Tuesday, June 30, 2026 6:10 PM
To: hogeheer499-commits/strix-halo-guide ***@***.***>
Cc: mottledMantis ***@***.***>; Mention ***@***.***>
Subject: Re: [hogeheer499-commits/strix-halo-guide] Idea: Strix Halo community evidence + vendor collaboration (Discussion #25)
Sorry for the slow reply, I was in Hungary for a week and I am catching up now.
This is exactly the kind of help that would be useful. For the GMKtec, I think the best next step is to keep it simple and make one small apples-to-apples pack first, then expand from there:
* exact system / OS / BIOS / UMA / IOMMU / power profile
* llama.cpp or Ollama version, plus Vulkan/RADV or ROCm path
* one row that matches a guide headline as closely as possible
* one row you personally think is the most useful or representative
* any weird setup notes, surprises, or things that did not work
That gives us a clean GMKtec baseline that vendors/reviewers can understand, instead of a huge benchmark dump that is hard to compare.
Also, if you have thoughts on the vendor angle, I would love them. My current instinct is: GitHub stays the clean source of truth, Discord is better for coordination, and vendor asks should be concrete: loaner/review units, BIOS/firmware notes, driver/setup feedback, and maybe affiliate/support later only if it is clearly disclosed.
No rush at all. Glad you are in.
—
Reply to this email directly, view it on GitHub <#25?email_source=notifications&email_token=AJTQARB5GDYQACLP3MPBBS35CQ3CPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZUHA4TSNZYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17489978> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJTQARBVIR2VZRKU7GY7QVD5CQ3CPAVCNFSNUABJKJSXA33TNF2G64TZHMYTCNZZGMYDGNJQHE5UI2LTMN2XG43JN5XDWMJQGI4TKOBZHGQXMAQ> .
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Sounds neat! I think you covered a lot there and it's a good place to start if there are interested vendors. Sometime soon I plan to release OSS the agent software I've been working on; has an extension architecture and should be easy enough to write an extension that'll spit out some nice metrics for real-world sessions and/or automate some testing routines if that would be helpful. |
|
Late reply from me, I was on vacation and only now catching up with the useful stuff I missed. @devoidfury that would be very useful. Synthetic benchmark rows are good for comparisons, but real-world session metrics are the missing layer: what happens during actual agent/coding/local-API use. If your extension can export something simple like model, backend, prompt tokens, decode tokens, TTFT, tok/s, memory, workload label, and maybe temp/power when available, that could become a really nice community evidence format. No rush, but if you open-source it I’d love to link it and maybe add a “session metrics / automation” lane to the guide. That would fit the vendor/reviewer angle too, because it turns “this box is fast” into “this is what real local workflows look like.” |
|
I open-sourced the agent today! https://github.com/devoidfury/hotdog Haven't written the metrics extension yet but it's on my TODO list. |
|
Small update from my side: this still feels like the right direction. I am going to spend the next few days thinking through a simple plan for how to do this without making it messy: what stays in GitHub, what belongs in Discord, what we ask vendors for first, and how contributors stay properly credited and involved. I would really like everyone who helped here to be part of that. The guide is already way stronger because people brought different systems, weird edge cases, failures, NPU ideas, power numbers, and better routes than I would ever find alone. Also, honestly, it would be awesome if this eventually helps some of you get access to AI PCs / loaners / test hardware too. You have all put real value into this, and I think you deserve to benefit from it as well, not just have your data disappear into a random repo. No big proposal yet. I just wanted to say I am still very interested in this, and I will come back with a clearer plan soon. |
|
definitely down to test hardware. I've sort of lost track of where we are at with benchmarks. There's a few new models sized well for strix i need to check out for sure |
|
Try my new step3.7 rocmfpx quant, super stable and fast for its size |
|
Yeah this is exactly where it starts getting messy lol. I cleaned up the split a bit now: CURRENT_MODELS.md is the current model map/test queue, while BEST_KNOWN_PROFILES.md stays only for routes we have actually reproduced and can recommend. I checked the Step 3.7 Q3 build properly. It is definitely worth a Beelink run: 198B total / about 11B active, 81.77 GiB target shards, separate Q8 MTP draft, and much more memory headroom than the older ~95-98 GiB Step builds. The card also has useful 4k/16k speed, 64k agent-memory, quality, and 256k load evidence. We already have the older Nimo Step 3.7 rows, so this would be a real second-system comparison instead of just another random benchmark. I added the exact runner pin and repro plan here: I am keeping it out of the best-known profiles until I reproduce it. And boxwrench, just drop those new model names when you have them; I will keep them in the same queue so we do not lose track or duplicate work. Also, I have not forgotten the Discord/coordination part. I have just been buried in the guide cleanup, benchmarks, and the first vendor outreach, so I have not decided yet whether a small dedicated Discord or the existing Lemonade/AMD dev servers makes more sense. It is clearly getting hard to follow here, so I will come back with a simple plan for where chat, the test queue, and final evidence should live. |
|
Small concrete update: I stopped just talking about vendor outreach and sent the first two messages today.
Nothing has been accepted and there is no partnership yet. These are just the first two proper outreach messages. I kept both evidence-first, independent, and disclosed instead of making it a generic hardware request. The community evidence is what made these messages credible in the first place. If either conversation turns into something real, I will bring the useful technical questions back here before promising a benchmark scope. I will also share any actual progress or feedback here. |
|
Quick update. I could use your help with one thing: getting this guide in front of the right people. I emailed AMD and Beelink on July 14, but have not heard back yet. I do not think the guide or evidence is the problem. I probably just have not reached the right person through those generic inboxes. I have now registered strixhaloguide.com and will use it as a clear public home for the project. GitHub will remain the source of truth for all benchmarks, raw evidence, failures, and contributor credit. The value for vendors is simple: people are interested in Strix Halo hardware, but many hesitate because the setup is confusing and reliable information is scattered everywhere. This guide turns that confusion into a tested path from buying the hardware to actually running local AI. That reduces buyer friction. Buyers can make a more confident decision and get the system working faster. Vendors get independent proof of what their hardware can do, plus useful feedback about BIOS, firmware, drivers, cooling, and setup problems. @ciru-ai @boxwrench @Fail-Safe @mottledMantis: do any of you know someone at AMD, Beelink, another OEM, DevRel, engineering, or a reviewer who would be worth showing this to? I think the work can speak for itself once it reaches the right person. I mainly need help finding the right door. Even a name, introduction, Discord channel, or "talk to this team" would help. If this leads to test hardware, engineering access, review projects, or vendor opportunities, I want you, the contributors, involved. That means clear credit, a say in what we test, and where practical, shared access to systems or opportunities to run comparisons yourselves. I cannot promise what a vendor might offer, but I do not want the benefits to flow in only one direction. The community evidence is what makes this project valuable in the first place. The guide stays independent and failed results stay public. I am also finally joining the AMD and Lemonade Discords. If there is a channel where you guys are already active, let me know where to find you. |
Uh oh!
There was an error while loading. Please reload this page.
Tagging the people who helped build this into more than one Beelink benchmark page: @ciru-ai @Fail-Safe @mottledMantis @boxwrench @devoidfury @bennos1911, and anyone else contributing systems, corrections, data, failures, or ideas.
I want to float one bigger idea and get feedback before doing anything too formal.
This guide is starting to look less like a single setup guide and more like a small Strix Halo community evidence project: Beelink, Corsair, GMKtec, Nimo, MS-S1-Max, NixOS, CachyOS, Windows/LM Studio, NPU notes, ROCmFP4, MTP, RPC, power, failures, and actual raw evidence.
The goal is still simple: reduce buyer friction. Help people understand what these Strix Halo systems can actually run, which setup paths work, where the blockers are, and what is worth buying/testing/supporting.
I think there may be a real vendor/reviewer collaboration angle here. Not paid-positive coverage, not marketing claims, and not hiding failures. More like:
For a first pilot, I would probably keep one clear maintainer/contact point because that is easier for vendors. But I do not want this to become me taking credit for other people's work. If this grows, I want contributors credited clearly, source-of-truth links preserved, and any broader opportunity handled transparently.
So the question is: does this direction make sense?
What would be most useful to ask vendors for first?
Also: should coordination just happen in the Lemonade / AMD dev Discords, or should we make a small Strix Halo evidence/benchmark Discord too? GitHub should stay the clean source of truth for final numbers, but Discord might be better for avoiding duplicate work and figuring out who is testing what.
No pressure on anyone. The guide stays independent either way. I just think a small team with real systems and real evidence is much stronger than one person trying to get vendors to care.
All reactions