Heterogene GPU-Lastverteilung für Ollama: RTX 5090+3090 schneller als 5090 allein
Der Entwickler modifizierte den `main`-Branch von Ollama, der laut Beitrag aktuell auf Windows nicht kompilierbar ist, und ersetzte die Standard-Gewichtungslogik für heterogene Multi-GPU-Setups. Das Kernproblem: Ollamas `findBestFit()` verteilt Layer rein nach freiem VRAM, wodurch eine RTX 3090 (24 GB) und eine RTX 5090 (32 GB) fast gleichbehandelt werden und der Greedy-Algorithmus die schwächere GPU zuerst befüllt – die stärkere wartet dann im Leerlauf. Die vier zentralen Änderungen: (1) Compute-Power-Gewichtung via `SMCount * ClockMHz`, die VRAM-Kapazitäten vor der Zuteilung skaliert; (2) Umkehr der Iterationsrichtung in `greedyFit()`, sodass Layer zuerst auf die stärkste GPU geladen werden; (3) `protectOutputLayer()`, das den teuersten Layer zwingend auf die stärkste GPU pinnt; (4) `redistributeHeavyLayers()`, das FFN-schwere Layer bei `computeBoost > 1.0` von der schwächsten zur stärksten GPU verschiebt. Der Code liegt in `ml/device.go`. Windows-Nutzer müssen Vision- und MLX-Support manuell entfernen, um zu kompilieren.
- findBestFit() berechnet rawPower[i] = SMCount × ClockMHz und skaliert FreeMemory entsprechend vor greedyFit()
- greedyFit() startet jetzt bei device=0 (stärkste GPU) statt device=len(gpus)-1 (schwächste) — laut Autor die wirkungsvollste Einzeländerung
- protectOutputLayer() pinnt den Output-Layer per ComputeMajor/Minor-Tier auf die stärkste GPU, was im Upstream-Ollama fehlt
- redistributeHeavyLayers() greift nur bei computeBoost > 1.0 und berechnet Ziel-Imbalance als strongestRawPower / (weakestRawPower + 1)
- Ollama main-Branch kompiliert derzeit standardmäßig nur für Darwin; Windows-Build erfordert manuelle Entfernung von Vision- und MLX-Support
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.
Heterogene GPU-Lastverteilung für Ollama: RTX 5090+3090 schneller als 5090 allein
Der Entwickler modifizierte den `main`-Branch von Ollama, der laut Beitrag aktuell auf Windows nicht kompilierbar ist, und ersetzte die Standard-Gewichtungslogik für heterogene Multi-GPU-Setups. Das Kernproblem: Ollamas `findBestFit()` verteilt Layer rein nach freiem VRAM, wodurch eine RTX 3090 (24 GB) und eine RTX 5090 (32 GB) fast gleichbehandelt werden und der Greedy-Algorithmus die schwächere GPU zuerst befüllt – die stärkere wartet dann im Leerlauf. Die vier zentralen Änderungen: (1) Compute-Power-Gewichtung via `SMCount * ClockMHz`, die VRAM-Kapazitäten vor der Zuteilung skaliert; (2) Umkehr der Iterationsrichtung in `greedyFit()`, sodass Layer zuerst auf die stärkste GPU geladen werden; (3) `protectOutputLayer()`, das den teuersten Layer zwingend auf die stärkste GPU pinnt; (4) `redistributeHeavyLayers()`, das FFN-schwere Layer bei `computeBoost > 1.0` von der schwächsten zur stärksten GPU verschiebt. Der Code liegt in `ml/device.go`. Windows-Nutzer müssen Vision- und MLX-Support manuell entfernen, um zu kompilieren.
- findBestFit() berechnet rawPower[i] = SMCount × ClockMHz und skaliert FreeMemory entsprechend vor greedyFit()
- greedyFit() startet jetzt bei device=0 (stärkste GPU) statt device=len(gpus)-1 (schwächste) — laut Autor die wirkungsvollste Einzeländerung
- protectOutputLayer() pinnt den Output-Layer per ComputeMajor/Minor-Tier auf die stärkste GPU, was im Upstream-Ollama fehlt
- redistributeHeavyLayers() greift nur bei computeBoost > 1.0 und berechnet Ziel-Imbalance als strongestRawPower / (weakestRawPower + 1)
- Ollama main-Branch kompiliert derzeit standardmäßig nur für Darwin; Windows-Build erfordert manuelle Entfernung von Vision- und MLX-Support
Frag die KI zum Artikel
Folgefragen zu Headline, Quelle und Volltext — Antwort streamt in wenigen Sekunden.