Ripple-65B vs. Qwen3.8-27B für lokales Programmieren: Welches Modell passt zu deinem Rechner?

Wählen Sie zunächst Qwen3.8-27B, wenn das Speicherbudget Ihres lokalen Programmierrechners knapp ist. Ripple-65B Preview kommt infrage, wenn Ihre Laufzeitumgebung ein Ollama-Paket von etwa 39–46 GB laden kann und noch genug Platz für Cache, Betriebssystem und Programmierumgebung bleibt. Vergleichen Sie die beiden anhand abgeschlossener Repository-Aufgaben und der Speicherauslastung. Ein größerer Checkpoint sorgt nicht automatisch für einen schnelleren oder nützlicheren lokalen Arbeitsablauf.

Dies ist ein Hardware- und Arbeitslastvergleich mit einem wiederholbaren Verfahren. Die Modellmerkmale stammen aus den jeweiligen Entwicklerkarten. Die Speicherklassen sind Einschätzungen zur Planung. Hier wird kein Vergleichssieger anhand von Messungen ermittelt. Wenn Sie eine Zielmaschine haben, treffen Sie die endgültige Wahl anhand ihrer eigenen Daten zu Modellplatzierung, Laufzeit und Aufgabenabschluss.

Wie unterscheiden sich die beiden Modelle?

Ricursive beschreibt Ripple als dichtes 65B-Modell mit 80 Layern, herunterladbaren BF16- und NVFP4-Versionen sowie einem unterstützten Kontext von bis zu etwa einer Million Tokens. Qwen3.8-27B ist ein kleineres dichtes Modell des Qwen-Teams. Der Unterschied bei der Parameteranzahl führt bei gleicher Präzision zu einem erheblichen Unterschied beim unkomprimierten Speicherbedarf der Gewichte. Architektur, Tokenizer, Bildunterstützung, Laufzeitumgebung und Präzision können die Kosten einer Arbeitslast zusätzlich beeinflussen.

Diese BF16-Schätzungen berücksichtigen keinen Overhead. Planen Sie den Speicherplatz anhand der tatsächlich installierten Dateien. Weitere Informationen zu unterstützten Ausführungswegen und Artefaktdetails finden Sie auf der Ripple-Entwicklerkarte, der Qwen-Entwicklerkarte und in der Ollama-Modellübersicht zu Ripple.

Was passt auf eine Grafikkarte mit 24 GB oder 48 GB?

Ein etwa 39–46 GB großes Ripple-Ollama-Paket passt nicht vollständig auf eine dedizierte GPU mit 24 GB. Das Auslagern auf den Host könnte das Laden des Modells ermöglichen, sofern Laufzeitsystem und Host-Arbeitsspeicher es zulassen. Dadurch ändern sich Bandbreite und Latenz, also teste diesen Weg ausdrücklich. Ein geeignetes Qwen-Artefakt mit geringerer Präzision könnte auf derselben GPU genug Platz für den Cache und die Laufzeit lassen, abhängig von deinem Zielkontext. Prüfe die tatsächliche Quantisierung und lies die Bereitstellungsanleitung für Qwen3.8-27B, um mehr zu erfahren.

Eine 48-GB-Karte bietet Ripple bei einer kompakten, unterstützten Präzision einen realistischeren Ausgangspunkt, aber ein Paket am oberen Ende lässt nur wenig Spielraum. Miss den vom Laufzeitsystem verwendeten Speicher und prüfe, ob ein Teil des Modells unbemerkt in den Arbeitsspeicher des Hosts verschoben wurde. Große Prompts und parallele Worker konkurrieren ebenfalls um Speicher. Eine Speicherbelegung, die für einen kurzen Chat ausreicht, ist keine verlässliche Grundlage für den Kauf einer Workstation.

Was ändert sich bei einem Mac mit gemeinsamem Speicher?

Der gemeinsame Speicher wird vom Betriebssystem, der GPU und anderen Anwendungen genutzt. Beginne mit einem kleinen Kontext auf einer unterstützten Laufzeit und miss dann die Speicherauslastung und den Swap. Ein System mit 64 GB könnte sich für einen kompakten Ripple-Artefakt als Testplattform eignen. Ein Rechner mit 96 GB oder mehr bietet mehr Spielraum, um lange Prompts und größere Tool-Ausgaben zu testen. Ein kleineres Modell kann mehr Ressourcen verfügbar halten, wenn derselbe Rechner Code erstellt oder Hintergrundaufgaben ausführt.

Verwende eine unterstützte Version von Ollama und MLX und notiere das genaue heruntergeladene Tag. Vergleiche sie mit der Anleitung zur lokalen Einrichtung von Ripple und der separaten Anleitung zum lokalen Speicherbedarf von Flash Next. Das Beispiel zu Flash Next zeigt, warum sich Laufzeitoptimierungen nicht allein anhand der Parameterzahl ableiten lassen.

Wie vergleicht man die Codequalität, ohne die Testbedingungen zu vermischen?

Verwende einen festen Repository-Commit und einen einzigen Harness mit denselben Leseberechtigungen, Testbefehlen, demselben Kontextbudget und derselben maximalen Anzahl an Versuchen. Gleiche die Präzisionsklassen ab, sofern dies unterstützt wird, und halte die Unterschiede fest, wenn eine exakte Übereinstimmung nicht möglich ist. Führe beide bei einem kleinen Bugfix mit bekanntem Test, einer Review-Aufgabe, bei der keine Änderungen vorgenommen werden sollten, und einem Fall aus, in dem die richtige Reaktion darin besteht, nach fehlenden Informationen zu fragen.

1. Speichere den Aufgaben-Prompt, den Basis-Commit und die exakten Runner-Optionen.
2. Messen Sie die Zeit bis zum ersten Token, den Spitzen-Speicherverbrauch und die Gesamtzeit einschließlich der Testbefehle.
3. Prüfen Sie die Tests und sehen Sie sich die resultierenden Änderungen an. Ein bestandener Test ist ein Kriterium, ebenso wie Umfang und Überprüfbarkeit.
4. Zählen Sie Zeitüberschreitungen, ungültige Tool-Argumente, unnötige Dateiänderungen und unvollständige Versuche.
5. Wiederholen Sie die Tests oft genug, um Schwankungen zu erkennen, und behalten Sie die Rohdaten.

Führen Sie getrennte Kalt- und Warmläufe durch. Wenn ein Modell von spekulativem Decoding profitiert, halten Sie das als Teil der Konfiguration fest. Rechnen Sie die Testzeit des Test-Frameworks nicht dem Modell zu und vergleichen Sie separate veröffentlichte Ranglistenergebnisse nicht so, als stammten sie aus Ihrem eigenen Testlauf.

Wann sollten Sie Speicher und Inferenz trennen?

Ein gemeinsamer Speicher kann unveränderliche Repository-Snapshots, freigegebene Datensätze und abgeschlossene Berichte enthalten. Lassen Sie den Rechner für die Berechnungen die Inferenz ausführen und temporäre Checkouts verwalten, wenn Speicher- und Backup-Dienste Kapazität zuverlässig verfügbar haben müssen. Messen Sie das Laden von Modellen von einer lokalen SSD, bevor Sie sich auf eine Netzwerklaufwerk-Einbindung verlassen. Halten Sie beschreibbare Ausgaben von Quelldateien getrennt.

Beginnen Sie mit dem kleineren Modell, wenn es Routineaufgaben bereits zuverlässig erledigt. Testen Sie Ripple als zweite Stufe für Aufgaben, bei denen es gebraucht wird, und halten Sie fest, ob es Arbeiten erledigt, an denen die Basis scheitert. Dieser Vergleich ist hilfreicher, als Speicher für einen theoretischen maximalen Kontextumfang zu kaufen.

FAQ

Mit welchem Modell sollte ich bei 24 GB VRAM beginnen?

Prüfen Sie zunächst eine geeignete Quantisierung von Qwen3.8-27B und den Kontextumfang. Für Ripple benötigen Sie eine unterstützte Aufteilung oder ein deutlich kleineres Modell als das hier besprochene Ollama-Paket.

Bedeutet 65B automatisch bessere Programmierfähigkeiten?

Die Parameteranzahl erklärt einen Teil des Hardwarebedarfs. Training, Quantisierung, Tools und Aufgabe beeinflussen ebenfalls die Qualität beim Programmieren.

Sollte ich mit dem größten unterstützten Kontext testen?

Verwenden Sie den Kontextumfang, den Ihre Aufgaben erfordern. Erfassen Sie die Prompt-Verarbeitung und den Spitzen-Speicherverbrauch, bevor Sie ihn erhöhen.

Kann ich die Ergebnisse der Modellkarten vergleichen?

Lesen Sie die Evaluierungsbedingungen für jedes Modell. Verwenden Sie dasselbe Test-Framework, dieselben Eingaben und dieselbe Bewertungsmethode, um einen direkten lokalen Vergleich zu erstellen.

Kann ein NAS die Modelle für beide Rechner speichern?

Es lässt sich als Speicher nutzen, wenn Ihr Workflow das unterstützt. Die Leistung bei aktiver Inferenz hängt weiterhin davon ab, wo die Modelle liegen, wie sie geladen werden und welcher Rechner die Berechnungen ausführt.

Fazit

Nutzen Sie Qwen3.8-27B als speicherschonende Basis und testen Sie Ripple auf einem Rechner, der zusätzlich zu den Modellgewichten noch Speicherreserven hat. Führen Sie dieselben Aufgaben aus und bewerten Sie Speicherverbrauch, Latenz und erledigte Arbeit gemeinsam. Das passende lokale Modell ist dasjenige, das sowohl zu Ihrem Workflow als auch zu Ihrer Hardware passt.