Large Language Modelle lokal mit R nutzen

Wenn es um Large Language Models (LLMs) geht, gibt es Momente, in denen ich mich frage: Muss ich meine Daten wirklich einmal um den halben Globus zu OpenAI schicken, nur um eine Zusammenfassung zu bekommen? Mit Ollama gibt es mittlerweile einen Standard, um Modelle wie Llama 3 oder Mistral lokal laufen zu lassen. Diese Modelle können direkt aus R gesteuert werden. Das spart nicht nur Geld, sondern löst auch das Datenschutz-Problem ziemlich elegant. In diesem Artikel geht es darum, wie man das in R am besten umsetzt. Spoiler: Es gibt nicht den einen Weg, sondern (mindestens) zwei sehr gute Pakete mit völlig unterschiedlichen Philosophien.

Ollama fungiert als Backend-Server, der die Komplexität des Ladens von Modellgewichten, der Tokenisierung und der Hardwarebeschleunigung abstrahiert. Es basiert auf llama.cpp, einer Bibliothek, die es ermöglicht, LLMs effizient auf Standard-Hardware (insbesondere Apple Silicon und Consumer-GPUs) auszuführen. Ein Schlüsselelement hierbei ist das GGUF-Format (GPT-Generated Unified Format). GGUF ist ein binäres Dateiformat, das für schnelles Laden und Mapping in den Arbeitsspeicher optimiert ist. Anders als PyTorch-Modelle, die oft gigantische VRAM-Ressourcen benötigen, unterstützen GGUF-Modelle Quantisierung. Quantisierung reduziert die Präzision der Gewichte von 16-Bit-Gleitkommazahlen (FP16) auf 4-Bit-Ganzzahlen (Int4) oder noch weniger. Dies reduziert den Speicherbedarf drastisch bei oft vernachlässigbarem Qualitätsverlust. Standardmäßig bindet sich Ollama an localhost (127.0.0.1) auf Port 11434. Das bedeutet, dass der R-Client und der Ollama-Server auf derselben Maschine laufen. 

Ein kurzer Seitenblick auf die Hardware, weil ich oft gefragt werde, worauf das läuft: Macs mit Apple Silicon (M1/M2/M3/M4) sind besser als erwartet für lokale LLMs. Der Grund ist die Unified Memory Architecture. Auf einem klassischen PC ist der Speicher getrennt: Die CPU hat ihren RAM, die Grafikkarte ihren VRAM. Ein großes Modell wie Llama 3 70B braucht etwa 40 GB Speicher. Eine Nvidia RTX 4090 – das Flaggschiff für Gamer – hat aber „nur“ 24 GB VRAM. Das Modell passt schlicht nicht rein. Beim Mac teilen sich CPU und GPU denselben Speicher. Mit meinem M4 Max und 128 GB RAM habe ich effektiv fast 100 GB Video-Speicher zur Verfügung. Damit kann ich riesige Modelle lokal laufen lassen, für die man im PC-Bereich teure Enterprise-Hardware bräuchte. Wenn ihr also einen Mac mit viel Arbeitsspeicher habt: Ihr sitzt auf einer KI-Workstation.

Der Pragmatiker: ollamar

Wenn man einfach nur schnell Ergebnisse will, ist ollamar das Werkzeug der Wahl. Das Paket fühlt sich „natürlich“ an, wie jedes andere gute R-Package auch. Es versucht nicht, das Rad neu zu erfinden, sondern bildet die API von Ollama fast 1:1 ab. Zudem ist es extrem flexibel beim Output. Du kannst dir das Ergebnis als simplen Text, als Liste oder – mein Favorit – direkt als Dataframe (Tibble) ausgeben lassen. Das macht es unglaublich einfach, die Ergebnisse direkt in einer dplyr-Pipeline weiterzuverarbeiten.

library(ollamar)

df <- generate("llama3.1:70b", "Warum ist R besser als Excel?", output = "df")
df$response


[1] "Eine Frage, die viele Datenanalysten und Wissenschaftler interessiert!\n\nR und Excel sind beide beliebte Werkzeuge für Datenanalyse und -visualisierung, aber sie haben unterschiedliche Stärken und Schwächen. Hier sind einige Gründe, warum R in bestimmten Aspekten besser als Excel sein kann:\n\n1. **Flexibilität und Erweiterbarkeit**: R ist eine programmierbare Umgebung, die es ermöglicht, benutzerdefinierte Funktionen und Pakete zu erstellen. Dies macht es möglich, komplexe Analysen und Modelle zu implementieren, die in Excel nicht möglich wären.\n2. **Statistische Analyse**: R bietet eine umfangreiche Sammlung von statistischen Methoden und Algorithmen, einschließlich Hypothesentests, Regressionsanalysen und Zeitreihenanalyse. Diese Funktionen sind in Excel nicht so umfassend verfügbar.\n3. **Datenvisualisierung**: R bietet eine Vielzahl von Bibliotheken für Datenvisualisierung, wie z.B. ggplot2, die es ermöglichen, ansprechende und informative Grafiken zu erstellen. In Excel sind die Visualisierungsmöglichkeiten begrenzter.\n4. **Reproduzierbarkeit**: R-Code kann einfach reproduziert werden, indem man den Code teilt oder in einem Repository speichert. Dies ist besonders wichtig in der wissenschaftlichen Forschung, wo die Reproduzierbarkeit von Ergebnissen essentiell ist.\n5. **Kollaboration**: R ermöglicht die Zusammenarbeit an Projekten durch die Verwendung von Versionierungssystemen wie Git und die Erstellung von gemeinsamen Code-Basen.\n6. **Skalierbarkeit**: R kann mit großen Datensätzen umgehen und ist daher gut geeignet für Big-Data-Analysen.\n7. **Kostenlosigkeit**: R ist kostenlos und Open-Source, was es zu einer attraktiven Alternative zu kommerziellen Softwareprodukten macht.\n\nEs ist jedoch wichtig zu beachten, dass Excel auch seine eigenen Stärken hat, wie z.B.:\n\n* Eine einfache Bedienung für Anwender ohne Programmierkenntnisse\n* Eine Vielzahl von Vorlagen und Add-ins für spezifische Aufgaben\n* Eine enge Integration mit anderen Microsoft-Pro ... <truncated>

Die Ergebnisse sind nicht unbedingt so gut wie die von den OpenAI- oder Gemini-Apps, auch fehlt (noch) die Websuche, die man selbst konfigurieren müsste. Aber für einige Aufgaben sind diese Modelle auf jeden Fall gut genug.

Der Wissenschaftler: rollama

Dann gibt es da noch rollama. Dieses Paket kommt aus der Forschung. Johannes Gruber hat es entwickelt, und man merkt sofort, dass hier Reproduzierbarkeit im Vordergrund steht.

LLMs sind bekanntlich „stochastische Papageien“ – sie plappern jedes Mal etwas anderes. Für wissenschaftliche Arbeiten (oder wenn wir eine verlässliche Datenpipeline benötigen) ist das ein Albtraum. rollama macht es einem sehr leicht, den „Seed“ zu setzen und Parameter wie die „Temperature“ streng zu kontrollieren. Für Textklassifikation oder Annotationen ist das der bessere Weg. rollama hat außerdem eine geniale Helper-Funktion namens make_query, die hilft, komplexe Prompts mit System-Instruktionen sauber zusammenzubauen.

Für die Puristen: httr2

Natürlich kannst du auch alles selbst bauen. Da Ollama eine simple REST-API bereitstellt, reicht eigentlich das großartige httr2 Paket völlig aus. Das ist dann sinnvoll, wenn du wirklich jedes Detail des Requests kontrollieren willst oder Streaming-Antworten (Wort für Wort) in eine eigene Shiny-App bauen möchtest.

library(httr2)

req <- request("http://localhost:11434/api/generate") |>
  req_method("POST") |>
  req_body_json(list(
    model = "llama3.1:70b", 
    prompt = "Erzähl mir einen Statistik-Witz!",
    stream = FALSE  
  ))

resp <- req_perform(req)

result_json <- resp |> resp_body_json()

cat(result_json$response)

Warum ging die Statistikerin zur Disco?

Weil sie gehört hat, dass da 100% Chance besteht, jemanden zu treffen. Als sie dort ankommt, ist sie jedoch alleine. 

Die Antwort: Sie war der Mittelwert und jeder andere war die Standardabweichung!

So richtig witzig sind die meisten Witze allerdings nicht 🙂

Mall

Das Paket mall verfolgt einen völlig anderen Ansatz. Es integriert LLMs direkt in dplyr-Pipelines als Verben zur Datenmanipulation. Anstatt „mit dem Modell zu chatten“, wendet man NLP-Operationen auf Spalten eines Dataframes an.

Kernkonzepte:

• Row-wise Processing: Funktionen wie llm_sentiment(), llm_summarize() oder llm_translate() operieren zeilenweise über eine Textspalte.
• Caching: Ein massives Problem bei der Arbeit mit LLMs ist die Rechenzeit. mall implementiert ein automatisches Caching. Wird derselbe Text mit denselben Einstellungen erneut verarbeitet, kommt das Ergebnis aus dem Cache, nicht vom Modell. Das spart Stunden an Rechenzeit bei iterativen Analysen.
• Backend-Agnostisch: mall nutzt intern Pakete wie ollamar oder ellmer, ist aber abstrahiert. Man kann das Backend wechseln (z.B. zu OpenAI), ohne den Analyse-Code zu ändern.

Tidyverse Workflow: Dies ist der eleganteste Weg, LLMs in bestehende ETL-Prozesse (Extract, Transform, Load) einzubinden.

library(tibble)
library(dplyr)
library(mall)

llm_use("ollama", model = "llama3.1")

reviews <- tribble(
  ~id, ~kommentar,
  1,   "Die Installation war super einfach und es läuft stabil.",
  2,   "Völlige Katastrophe, nichts funktioniert wie versprochen.",
  3,   "Ganz okay für den Preis, aber die Doku könnte besser sein."
)


results <- reviews |> 
  llm_sentiment(
    col = kommentar, 
    options = c("positiv", "neutral", "negativ") 
  )

glimpse(results)

> results
# A tibble: 3 × 3
     id kommentar                                                  .sentiment
  <dbl> <chr>                                                      <chr>     
1     1 Die Installation war super einfach und es läuft stabil.    positiv   
2     2 Völlige Katastrophe, nichts funktioniert wie versprochen.  negativ   
3     3 Ganz okay für den Preis, aber die Doku könnte besser sein. neutral   
> 

• Webseite: mlverse.github.io/mall

chattr und ellmer: Interaktive Assistenten

Während die oben genannten Pakete für die Programmierung gedacht sind, zielen chattr und ellmer auf die Unterstützung des Programmierers ab.

chattr bietet ein Shiny-basiertes Interface (Gadget) direkt in RStudio (Viewer Pane). Es kennt den Kontext der R-Session (geladene Dataframes) und kann so kontextsensitiven Code generieren. Seit Version 0.3 nutzt chattr das Backend-Paket ellmer (entwickelt von Posit), um Verbindungen zu LLMs herzustellen. ellmer bietet eine robuste Klasse Chat, die Konversationshistorie und Token-Zählung verwaltet. Die Verbindung zu Ollama ist trivial. Dieses Setup eignet sich hervorragend, um einen eigenen „Copilot“ zu bauen, der lokal läuft und keine sensiblen Code-Schnipsel in die Cloud sendet.

Fazit: Deine Daten bleiben bei dir, und dein Laptop wird im Winter angenehm warm – win-win.