Ich würde nicht zum M3 Ultra 60 GPU raten. Der scheint langsamer zu sein als der M2 Ultra 76 GPU:
https://github.com/ggml-org/llama.cpp/discussions/4167
@Wuchtbrumme:
Ich habe mich gegen meinen eigenen Rat entschieden und mir den M3 Ultra 96 GB 60-core GPU gegönnt.
Zwar scheint es zu stimmen, dass der M2 Ultra 76-core GPU etwas schneller ist, aber mit 128 GB Ram ist er zudem selten und die Angebote, die bei den üblichen Anzeigen geschaltet sind, sind nicht günstiger als der kleine M3. Die meisten second-hand M2 Ultras sind das kleinste Modell oder dann wieder welche, die auch große SSDs haben und somit unbezahlbar teuer sind. Daher habe ich meinen EDU-Rabatt genutzt und letztes Wochenende den kleinen Racker aus dem Apple Store abgeholt.
Ich war auch auf der Suche nach etwas, dass mir komfortabel 70B-Modelle bereitstellen kann und gerne auch noch etwas mehr. Als 4-bit quants sind die ca. 43 GB und als 8-bit quant 75 GB groß. Somit reichen die 96 GB des kleinen M3 Ultra für mich. Von größeren Modellen wie Mistral Large (123B) oder Command-a (111B) habe ich nicht erwartet, dass sie noch schnell genug sind, um sinnvoll genutzt werden können. Aber auch hier ist noch was möglich, Mistral Large als 4-bit quant ist 73 GB groß!
Geradem Subreddit locallama ätzen viele rum, dass das Prompt Processing, zurückzuführen auf die vergleichsweise schwache Rechenleistung des M3 Ultra, zu langsam sei um überhaupt noch als benutzbar zu gelten. Ich glaube, dass dort auch ein gewisser Glaubenskrieg dahintersteht und einige auch ihre Racks mit 4 x 3090 Karten und mehr verteidigen wollen (die ohne jede Frage auch schneller sind).
Für LLMs ist das Gerät für mich genau meinen Vorstellungen nach zu nutzen. Nach dem Laden lässt sich mit Modellen bis einschliesslich 70B sehr schnell chatten, aber das machen ja auch viele YouTuber vor. Ich habe dann einfach mal einen längeren Text eingegeben und geschaut, wie lange das dauert und was für Auswirkungen das hat.
Hinweis: ich habe den VRAM auf 88 GB festgelegt, so bleiben 8 GB für das System. Getestet habe ich gguf quants mit koboldcpp und mlx quants mit LM Studio, jeweils mit 32768 Token context.
Als Text habe ich den englischen Wikipedia-Artikel zu Napoleon gewählt. Das sind 21k Token oder 30 Seiten DIN-A4 Schriftgröße 12.
Geladen habe ich Llama 3.3 70B 4Q_K_M als gguf:
Ein erstes "Hi" wird spontan beantwortet mit ca. 14 T/s.
Dann habe ich den Text eingegeben, mit der Aufforderung ihn in einem Absatz zusammenzufassen. Das Prozessieren benötigt: 229 s.
Danach kann ich wieder ganz normal Fragen stellen, und die Antworten kommen mit 8 T/s.
Llama 3.3 70B 4Q als mlx:
Ein erstes "Hi" wird spontan beantwortet mit ca. 17 T/s.
Dann habe ich den Text eingegeben, mit der Aufforderung ihn in einem Absatz zusammenzufassen. Das Prozessieren benötigt: 203 s.
Danach kann ich wieder ganz normal Fragen stellen, und die Antworten kommen mit 12 T/s.
Was die Zahlen angeht, bin ich ersteinmal voll zufrieden. Ich weiß nicht, ob in meinem Alltag jemals das Zusammenfassen von 30 Seiten Schreibmaschinentext anstehen wird. Und falls doch, warte ich da gerne 200 Sekunden drauf. Auch für einen Chatverlauf, der sich so langsam dieser Größenordnung annähert, ist passabel und die Ausgabe ist für mich immer noch schnell genug, um als benutzbar zu gelten.
Was die Vergleichbarkeit zwischen gguf und mlx angeht, bin ich noch vorsichtig. Zum einen soll ein 4-bit mlx wohl weniger Daten enthalten als das gguf als Q4_K_M (das ist auch etwas größer) und zum anderen erinnere ich mich an Unstimmigkeiten bei den Angaben aus LM Studio. Vor einiger Zeit wurde das Context Shifting bei koboldcpp sehr gelobt (auch bei gut gefülltem Kontext wird dann nicht immer alles neu prozessiert, sondern es werden nur neue Eingaben berücksichtigt), sodass ich erstmal dabei bleibe.
Um zu testen, wo die Grenze ist, habe ich noch ein Mistral Large Finetune geladen (123B, Q4_K_M). Das geht immer noch mit 32768 context, da ich ja 88 GB für den VRAM reserviert habe. Interessanterweise verweigert LM Studio das Laden, obwohl mir auch da die 88 GB als frei angezeigt werden und das Modell 73 GB groß ist. In koboldcpp geht es aber. Ein erstes "Hi" wird noch mit 8 T/s beantwortet. Der 30-Seiten-Text benötigt 493 s und die Antworten kommen danach mit 5 T/s. Etwas zäh, aber je nach Anwendungszweck durchaus noch benutzbar.