<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Local AI Hardware &#8211; Derek.net.au</title>
	<atom:link href="https://www.derek.net.au/lab-section/local-ai-hardware/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.derek.net.au</link>
	<description></description>
	<lastBuildDate>Mon, 17 Aug 2026 05:53:14 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	
	<item>
		<title>Hilbert And The Open-Source AI Workstation</title>
		<link>https://www.derek.net.au/lab/hilbert-and-the-open-source-ai-workstation/</link>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Mon, 17 Aug 2026 05:53:14 +0000</pubDate>
				<guid isPermaLink="false">https://www.derek.net.au/lab/hilbert-and-the-open-source-ai-workstation/</guid>

					<description><![CDATA[Hilbert is important to the Lab because it reframes local AI around capacity. The system is based on an AMD Ryzen AI Max+ 395 class machine with 128GB unified memory and ROCm-oriented local inference. That makes it different from a conventional desktop GPU box: it can attempt models and contexts that are awkward or impossible...  <a class="excerpt-read-more" href="https://www.derek.net.au/lab/hilbert-and-the-open-source-ai-workstation/" title="Read Hilbert And The Open-Source AI Workstation">Read more &#187;</a>]]></description>
										<content:encoded><![CDATA[<p>Hilbert is important to the Lab because it reframes local AI around capacity.</p>
<p>The system is based on an AMD Ryzen AI Max+ 395 class machine with 128GB unified memory and ROCm-oriented local inference. That makes it different from a conventional desktop GPU box: it can attempt models and contexts that are awkward or impossible on smaller discrete cards, even when those cards are faster.</p>
<h2>01 &#8211; The Workstation Stack</h2>
<p>The v2 archive recovers a July 2026 layer of the open-source workstation stack:</p>
<ul>
<li>local inference and chat;</li>
<li>coding agents;</li>
<li>generative media;</li>
<li>voice.</li>
</ul>
<p>The point was not to install one impressive demo. It was to assemble a workstation where local models, coding tools, ComfyUI-style media workflows and voice systems could coexist.</p>
<h2>02 &#8211; Hilbert Unofficial Suite</h2>
<p>The Hilbert Unofficial Suite combined several layers:</p>
<ul>
<li>Hilbert Studio, a ComfyUI workflow platform;</li>
<li>Genesis Runtime, an assistant/agent runtime;</li>
<li>an AI code-build pipeline;</li>
<li>ai-switch, a switcher intended to keep GPU-heavy stacks from trampling each other.</li>
</ul>
<p>The suite&#039;s workflow layer was manifest-driven: declared inputs and outputs, model requirements, hardware requirements, tags, presets, registry discovery, schema validation, batch processing and quality-control scoring.</p>
<p>At one point the public registry was recorded as 12 categories and 89 workflows. Adult and community-model checkpoint categories were intentionally excluded from the public registry.</p>
<h2>03 &#8211; ROCm As A Constraint</h2>
<p>The ROCm focus is not incidental.</p>
<p>Most generative-AI tooling assumes NVIDIA/CUDA by default. Hilbert made ROCm and unified memory first-class constraints, which is exactly the kind of constraint the Lab should document: the engineering work required to make AI practical on the hardware actually available.</p>
<h2>04 &#8211; Failures Count</h2>
<p>The Hilbert archive includes operational failures:</p>
<ul>
<li>ROCm/unified-memory messages involving Qwen3 Coder Next and SVM allocation;</li>
<li>sleep/resume instability after moving to Pop!_OS;</li>
<li>a disk-capacity incident where Code state and the AI suite consumed enormous storage.</li>
</ul>
<p>Those are not footnotes. They are part of the research output.</p>
<h2>05 &#8211; Relationship To The GPU Farm</h2>
<p>Hilbert and the older GPU farm solve different problems:</p>
<ul>
<li>Hilbert provides capacity through unified memory;</li>
<li>discrete GPUs provide speed and throughput for narrower specialised tasks.</li>
</ul>
<p>That distinction feeds directly into Omega&#039;s cognitive-cluster direction.</p>
<hr>
<p><strong>Source note:</strong> assembled from v2 sections on Hilbert, the recovered July 2026 workstation layer and the Hilbert Unofficial Suite.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Heterogeneous Compute As A Research Material</title>
		<link>https://www.derek.net.au/lab/heterogeneous-compute-as-a-research-material/</link>
		
		<dc:creator><![CDATA[]]></dc:creator>
		<pubDate>Mon, 17 Aug 2026 05:53:14 +0000</pubDate>
				<guid isPermaLink="false">https://www.derek.net.au/lab/heterogeneous-compute-as-a-research-material/</guid>

					<description><![CDATA[The Lab keeps returning to a hardware idea that is easy to miss: useful AI research does not require one clean, modern, homogeneous machine. Sometimes the right platform is a strange pile of old cards, cheap boards, risers, unified memory and careful workload assignment. 01 &#8211; The Hardware Pattern The archive records experiments or plans...  <a class="excerpt-read-more" href="https://www.derek.net.au/lab/heterogeneous-compute-as-a-research-material/" title="Read Heterogeneous Compute As A Research Material">Read more &#187;</a>]]></description>
										<content:encoded><![CDATA[<p>The Lab keeps returning to a hardware idea that is easy to miss: useful AI research does not require one clean, modern, homogeneous machine.</p>
<p>Sometimes the right platform is a strange pile of old cards, cheap boards, risers, unified memory and careful workload assignment.</p>
<h2>01 &#8211; The Hardware Pattern</h2>
<p>The archive records experiments or plans around:</p>
<ul>
<li>Tesla P40;</li>
<li>Tesla P4;</li>
<li>planned P100s;</li>
<li>Radeon RX 580;</li>
<li>Radeon RX 7970 6GB;</li>
<li>RX 5700 XT;</li>
<li>RTX 4060;</li>
<li>RTX 4070;</li>
<li>Hilbert unified memory;</li>
<li>ASRock mining boards;</li>
<li>Supermicro dual-Opteron server hardware.</li>
</ul>
<p>The recurring question is not &quot;what is the fastest single GPU?&quot; It is &quot;what useful cognitive or generative role can this hardware perform?&quot;</p>
<h2>02 &#8211; P40 Logic</h2>
<p>The Tesla P40 is interesting because 24GB of VRAM can matter more than modern gaming performance for some local LLM experiments.</p>
<p>The trade-off is explicit:</p>
<ul>
<li>older card;</li>
<li>more memory per dollar;</li>
<li>lower modern feature support;</li>
<li>awkward cooling and power;</li>
<li>useful capacity for certain inference roles.</li>
</ul>
<p>That is not nostalgia. It is budget-aware systems design.</p>
<h2>03 &#8211; Dedicated Function Nodes</h2>
<p>The mature direction is not necessarily one model spread across every card.</p>
<p>Instead, cards can be assigned to roles:</p>
<ul>
<li>one GPU for video generation;</li>
<li>one for image generation;</li>
<li>one for an LLM;</li>
<li>smaller cards for lightweight specialist processors;</li>
<li>Hilbert for large capacity-bound models;</li>
<li>CPU services for routing and state.</li>
</ul>
<p>This maps cleanly onto Omega&#039;s specialist cognitive-cluster idea.</p>
<h2>04 &#8211; PCIe x1 Is Not Automatically Disqualifying</h2>
<p>Mining boards and risers are poor for workloads requiring heavy inter-GPU transfer. But for dedicated-function nodes, PCIe x1 can still be acceptable if the model loads and does substantial local work on the card.</p>
<p>That distinction is important. The Lab should not pretend cheap mining-era hardware is secretly ideal. It should document where it is bad, and where it is still useful.</p>
<h2>05 &#8211; Relic And Scrap LLM</h2>
<p>The r/RelicAndScrapLLM idea belongs here because it names the philosophy directly: old hardware can still be part of serious AI experimentation if the workload is chosen honestly.</p>
<p>The point is not to beat flagship GPUs. The point is to expand what can be learned with the machines already within reach.</p>
<hr>
<p><strong>Source note:</strong> assembled from v2 hardware sections and the recovered research philosophy around capacity, throughput and reuse.</p>
]]></content:encoded>
					
		
		
			</item>
	</channel>
</rss>
