Metas Open-Source-Agent-Modell für Endgeräte

Am 10. August 2026 veröffentlichte Metas Superintelligence Lab Muse Glimmer – ein Open-Source-Agent-Modell mit 30 Milliarden Parametern. Dies ist kein weiterer Wettbewerber um die größte Parameterzahl, sondern ein speziell für lokale Agenten-Szenarien optimiertes „kleines Kraftpaket".

Die Kernbotschaft ist klar: Eine einzige Consumer-GPU mit 24 GB VRAM reicht für den Betrieb, keine Internetverbindung nötig, kann Bildschirme lesen, Tools aufrufen und bei Fehlern automatisch neu versuchen. Apache-2.0-Lizenz, sorgenfrei für kommerzielle Nutzung.

In einer Zeit, in der Cloud-Agenten dominieren, warum setzt Meta auf lokale Ausführung? Weil ein echter persönlicher Assistent tiefen Zugriff auf Ihren privaten Kontext braucht – Kalender, Dateien, Code, Nachrichten. Nur wenn diese Daten lokal bleiben, ist der Datenschutz wirklich gelöst.

Der grundlegende Unterschied zu Cloud-Agenten

Cloud-Agenten sind netzwerkabhängig – Daten müssen auf Server hochgeladen werden. Lokale Agenten laufen auf Ihrem Gerät, Daten verlassen nie die Maschine. Das ist nicht nur ein Unterschied im Deployment-Standort, sondern eine grundlegend andere Architektur-Philosophie.

Einschränkungen von Cloud-Agenten: - Netzwerklatenz: Jeder Tool-Aufruf erfordert einen Roundtrip zum Server, bei mehreren Gesprächsrunden summiert sich die Verzögerung - Datenschutzrisiko: Screenshots, Dateiinhalte, Code-Snippets durchlaufen alle die Cloud - Offline unbrauchbar: Im Flugzeug, in der U-Bahn, bei instabilem Netz einfach lahmgelegt - Laufende Kosten: API-Aufrufe werden pro Token abgerechnet, bei häufiger Nutzung werden die Kosten enorm

Vorteile lokaler Agenten: - Millisekundenschnelle Antwort: Inferenz läuft auf der lokalen GPU, kein Netzwerk-Roundtrip - Null Datenleck:_sensitive Informationen verlassen niemals Ihr Gerät - Immer verfügbar: Funktioniert auch ohne Internet, echtes Always-on - Einmalige Investition: Nach dem Hardware-Kauf gehen die Grenzkosten gegen null

Muse Glimmer wurde genau dafür entwickelt, diese Lücke bei lokalen Agenten zu schließen. Es ist kein einfach komprimiertes Cloud-Modell, das auf Consumer-Hardware gezwängt wird, sondern wurde auf Architekturebene für Endgeräte-Szenarien neu konzipiert.

Kerntechnologie: 30B-Parameter-Destillation und multimodale Wahrnehmung

Muse Glimmer ist kein von Grund auf trainiertes Modell, sondern wurde durch Destillation aus Metas größerem Muse-Spark-Modell gewonnen. Destillation ist die Technik, die Fähigkeiten eines großen Modells in ein kleineres zu „komprimieren" – ähnlich wie ein erfahrener Meister einen Lehrling ausbildet: Der Lehrling hat zwar weniger Erfahrung, hat aber die Kernfertigkeiten des Meisters übernommen.

Dreiphasiger Trainingsprozess:

  1. Pre-Training: Logit-Destillation mit den Ausgaben von Muse Spark, Datenmischungsverhältnis ähnlich dem des Lehrermodells. In diesem Schritt erlernt das kleine Modell die grundlegenden Inferenzfähigkeiten des großen Modells.

  2. Mid-Training: Weiteres Training auf Daten mit längerem Kontext und stärkeren Agenten-Szenarien, ergänzt durch reichhaltigere Reasoning Traces. Dieser Schritt stärkt die mehrstufige Schlussfolgerung und Tool-Aufruf-Fähigkeiten.

  3. Post-Training: Kombination aus Supervised Fine-Tuning (SFT) und On-Policy-Destillation, mit Reinforcement Learning in vier Bereichen – Allgemein, Reasoning, Coding und Agenten. Dieser Schritt optimiert die Leistung im praktischen Einsatz.

Multimodaler Wahrnehmungs-Encoder:

Muse Glimmer enthält einen speziellen Perception Encoder mit rund 1,8 Milliarden Parametern für die Bildverarbeitung. Das bedeutet, es kann nicht nur Text verstehen, sondern auch Screenshots, Diagramme und Dokumente „sehen". Für Agenten-Szenarien ist das eine Schlüsselfähigkeit – es kann GUI-Oberflächen direkt betrachten, Button-Positionen, Eingabefelder und Fehlermeldungen verstehen.

ATEM-Tool-Aufrufprotokoll:

Muse Glimmer verwendet das selbstentwickelte ATEM-Protokoll (Agent Tool Execution Model) für Tool-Aufrufe. Anders als traditionelles JSON-Function-Calling nutzt ATEM eine XML-artige Tag-Struktur:

XML 
<atem:function_calls>
<atem:invoke name="search_web">
<atem:parameter name="query">Muse Glimmer benchmark</atem:parameter>
<atem:parameter name="max_results">5</atem:parameter>
</atem:invoke>
</atem:function_calls>

Dieses Design ermöglicht dem Modell, Tools in langen Workflows stabiler aufzurufen und reduziert Formatfehler.

Fehlerwiederherstellungsmechanismus:

Wenn ein Tool-Aufruf fehlschlägt oder unerwartete Ergebnisse liefert, stoppt Muse Glimmer nicht einfach oder wiederholt den Fehler wie traditionelle Modelle, sondern diagnostiziert die Fehlerursache und versucht es erneut. Das ist entscheidend für die Zuverlässigkeit von Agenten – echte Tool-Aufrufe sind voller Unsicherheiten, und nur mit Selbstheilung kann kontinuierlich gearbeitet werden.

Hardwareanforderungen: Consumer-GPU mit 24 GB VRAM reicht

Ein 30B-Parameter-Modell benötigt in BF16-Vollpräzision etwa 55-60 GB VRAM, weit mehr als jede Consumer-GPU bietet. Meta hat dieses Problem durch Quantisierung gelöst.

Vergleich der drei Quantisierungsversionen:

Version VRAM-Bedarf Qualitätsverlust Einsatzszenario
BF16 Vollpräzision 55-64 GB Baseline Evaluierungsserver, Fine-Tuning
K-Quant-Dynamic 32 GB durchschnittlich 0,2 % Beste Wahl für lokales Deployment
K-Quant-17GB 24 GB durchschnittlich 1,0 % Einzelarbeitsplatz

Wichtige Zahl: Das quantisierte Sprachmodell selbst ist unter 20 GB, der verbleibende Speicher steht für KV-Cache (Arbeitsspeicher), Perception Encoder (Bildverarbeitung) und den DFlash-Speculative-Decoder zur Verfügung.

Empfohlene Hardware-Konfiguration:

  • Mindestkonfiguration: GPU mit 24 GB VRAM (RTX 4090/3090 oder Apple M4 Max und höher)
  • Empfohlene Konfiguration: GPU mit 32 GB VRAM (RTX 5090 oder Apple M5 Max)
  • Arbeitsspeicher: Mindestens 32 GB System-RAM
  • Speicher: SSD, Modelldateien ca. 17-20 GB

Gemessene Geschwindigkeitsdaten (Meta offiziell):

Hardware Ohne Speculative Decoding Mit DFlash Speculative Decoding
RTX 5090 74,9 Tokens/s 233,4 Tokens/s
MacBook M4 Max 23,7 Tokens/s 37,8 Tokens/s
MacBook M5 Max 26,6 Tokens/s 50,2 Tokens/s

Der DFlash-Speculative-Decoder ist ein leichtgewichtiges Begleitmodell, das ganze Token-Blöcke auf einmal vorschlägt, die das Hauptmodell parallel verifiziert. Das ist 3-4× schneller als die tokenweise Generierung bei identischer Ausgabequalität.

Benchmark-Vergleich: Gegen Gemma4-31B und Qwen3.6-27B

Meta hat Muse Glimmer mit den gleichklassigen Google Gemma4-31B und Alibaba Qwen3.6-27B verglichen. Hier die offiziell veröffentlichten Benchmark-Ergebnisse:

Benchmark Muse Glimmer 30B Gemma4-31B Qwen3.6-27B Testinhalt
MCP-Atlas 75,5 54,2 62,5 Multi-Turn 20+ MCP-Server-Aufrufe
DeepSearch QA 74,6 61,7 71,1 Autonome Webrecherche
SWE-Bench Pro 51,2 36,9 50,2 Repository-weite Code-Aufgaben
Terminal-Bench 2.1 51,7 43,4 60,7 Terminal- und Systemoperationen
OSWorld-Verified 65,9 58,5 75,6 Desktop-GUI-Operationen
OmniDocBench 1.5 75,8 72,5 77,8 Komplexe Dokumentenanalyse
GPQA Diamond 83,5 - - Fragen auf Abschlussniveau
SWE-Bench Verified 76,0 - - Verifizierte Code-Behebungen
AIME 2026 94,7 - - Mathematikwettbewerb

Wichtige Erkenntnisse:

  1. Führend bei Agenten-Aufgaben: Bei MCP-Atlas (Multi-Tool-Aufrufe), DeepSearch QA (autonome Suche) und SWE-Bench Pro (Code-Behebung) liegt Muse Glimmer vor den gleichklassigen Modellen.

  2. Schwächer bei Desktop-Operationen: Bei Terminal-Bench (Terminalbefehle) und OSWorld (GUI-Operationen) schneidet Qwen3.6-27B besser ab. Wenn Ihr Szenario die Automatisierung von Desktop-Operationen ist, könnte Qwen besser passen.

  3. Multimodal leicht unterlegen: Bei OmniDocBench (komplexes Dokumentenverständnis) erzielt Qwen höhere Werte. Muse Glimmers Perception Encoder ist funktionsfähig, aber nicht so umfassend wie Qwens multimodale Fähigkeiten.

  4. Hervorragende Inferenzfähigkeiten: 94,7 Punkte beim AIME-2026-Mathematikwettbewerb und 83,5 Punkte bei GPQA Diamond zeigen starke logische Schlussfolgerung.

Hinweis: Dies sind vom Hersteller gemeldete Daten. Meta räumt selbst ein, dass seine Tools und System-Prompts möglicherweise nicht für Drittanbietermodelle optimiert sind. Die tatsächliche Leistung muss in Ihrem spezifischen Szenario getestet und validiert werden.

Lokales Deployment in der Praxis: Drei Methoden mit Ollama / vLLM / llama.cpp

Die Modellgewichte von Muse Glimmer sind auf Hugging Face veröffentlicht und unterstützen mehrere gängige Inferenz-Frameworks. Im Folgenden werden die drei häufigsten Methoden für lokales Deployment vorgestellt.

Methode 1: Ollama (am einfachsten, für Einsteiger empfohlen)

Ollama ist das einfachste Tool zum Ausführen lokaler Modelle – Deployment mit nur einem Befehl.

BASH 
# 1. Ollama installieren (falls noch nicht geschehen)
curl -fsSL https://ollama.com/install.sh | sh

# 2. Muse Glimmer herunterladen und ausführen
ollama run muse-glimmer:30b

Ollama lädt automatisch die K-Quant-quantisierte Version herunter und konfiguriert die Standardparameter. Nach dem Start gelangen Sie direkt in die interaktive Dialogschnittstelle.

Benutzerdefinierte Parameter konfigurieren:

BASH 
# Modelfile erstellen
cat > Modelfile << 'EOF'
FROM muse-glimmer:30b
PARAMETER temperature 0.7
PARAMETER num_ctx 32768
PARAMETER num_gpu 99
SYSTEM "You are a helpful AI assistant with access to local tools."
EOF

# Benutzerdefiniertes Modell erstellen
ollama create my-glimmer -f Modelfile
ollama run my-glimmer

Methode 2: vLLM (Produktionsreifes Service-Deployment)

vLLM eignet sich für Szenarien mit hohem Durchsatz im Service-Betrieb und unterstützt eine OpenAI-kompatible API.

BASH 
# 1. vLLM installieren
pip install vllm>=0.8.0

# 2. OpenAI-kompatiblen Service starten
vllm serve meta-models/Muse-Glimmer-30B \
  --dtype auto \
  --quantization kquant \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90 \
  --port 8000

# 3. API testen
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-models/Muse-Glimmer-30B",
    "messages": [{"role": "user", "content": "Zeig mir meinen heutigen Kalender"}]
  }'

Methode 3: llama.cpp (maximale Performance-Optimierung)

llama.cpp ist eine in C++ implementierte Inferenz-Engine, die auf Apple Silicon die beste Leistung bietet.

BASH 
# 1. llama.cpp kompilieren
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
make -j$(nproc)

# 2. GGUF-quantisierte Gewichte herunterladen
huggingface-cli download meta-models/Muse-Glimmer-30B-GGUF \
  muse-glimmer-30b-kquant-q4_k_m.gguf \
  --local-dir ./models

# 3. Inferenz-Service starten
./llama-server \
  -m ./models/muse-glimmer-30b-kquant-q4_k_m.gguf \
  --port 8080 \
  -c 32768 \
  -ngl 99

Python-Integrationsbeispiel

Unabhängig von der gewählten Deployment-Methode kann das Modell über die OpenAI-kompatible API in Python-Anwendungen integriert werden:

PYTHON 
from openai import OpenAI

# Verbindung zum lokalen Muse-Glimmer-Service
client = OpenAI(base_url="http://localhost:8000/v1", api_key="local")

# Tools definieren
tools = [
    {
        "type": "function",
        "function": {
            "name": "search_files",
            "description": "Search local files by keyword",
            "parameters": {
                "type": "object",
                "properties": {
                    "query": {"type": "string"},
                    "path": {"type": "string", "default": "~/Documents"}
                },
                "required": ["query"]
            }
        }
    }
]

# Agenten-Schleife
messages = [{"role": "user", "content": "Finde die Python-Dateien, die letzte Woche geändert wurden"}]

while True:
    response = client.chat.completions.create(
        model="muse-glimmer",
        messages=messages,
        tools=tools,
    )

    msg = response.choices[0].message

    if msg.tool_calls:
        # Tool-Aufrufe ausführen
        for call in msg.tool_calls:
            result = execute_tool(call.function.name, call.function.arguments)
            messages.append(msg)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": result
            })
    else:
        print(msg.content)
        break

Praktische Einsatzszenarien

Die Fähigkeiten von Muse Glimmer decken die wichtigsten Szenarien für lokale Agenten ab:

Szenario 1: Lokaler Code-Assistent

Muse Glimmer erreicht 76,0 % Lösungsrate bei SWE-Bench Verified – das bedeutet, es kann Repository-Strukturen verstehen, Bugs lokalisieren und Fix-Code schreiben. In Kombination mit einem lokalen Codebase-Indexierungstool lässt sich ein vollständig offline arbeitender Programmierassistent aufbauen.

Szenario 2: Bildschirmanalyse und -automatisierung

Durch den Perception Encoder kann Muse Glimmer Screenshots direkt „sehen". In Kombination mit GUI-Automatisierungstools (wie pyautogui) lässt sich ein Agent bauen, der beliebige Desktop-Anwendungen bedienen kann – Formulare ausfüllen, Screenshots analysieren, Fehler diagnostizieren.

Szenario 3: Fragen und Antworten zu privaten Dokumenten

Die Kontextlänge von 131K+ Tokens reicht für große Dokumentenmengen. In Kombination mit einer lokalen Vektordatenbank lässt sich ein RAG-System aufbauen, bei dem Daten das Gerät nie verlassen – für vertrauliche Dokumente und internes Wissen.

Szenario 4: LLM-as-a-Judge

Lokale Ausführung von Bewertungsmodellen, um zu bewertende Inhalte nicht in die Cloud hochladen zu müssen. Geeignet für Szenarien, in denen die Ausgabequalität von Modellen in großen Mengen bewertet werden muss.

Szenario 5: MCP-Tool-Orchestrierung

Muse Glimmer erzielt 75,5 Punkte bei MCP-Atlas, weit vor gleichklassigen Modellen. Es kann über 20 MCP-Server gleichzeitig koordinieren und komplexe toolübergreifende Workflows ausführen.

Technische Architektur und Funktionsweise

Die Architektur von Muse Glimmer ist um das Kernziel „lokaler Agent" herum aufgebaut. Das Verständnis der technischen Prinzipien hilft Ihnen einzuschätzen, ob es zu Ihrem Szenario passt.

Basisarchitektur: Dense Transformer mit 29,6 Milliarden Parametern, ergänzt durch einen Perception Encoder mit 1,8 Milliarden Parametern. Alle Sprachparameter werden bei jedem Token aktiviert – das bedeutet, Speicherbandbreite ist der Leistungsengpass, nicht Rechenleistung.

ATEM-Protokoll: Das Agent Tool Execution Model ist das Tool-Aufrufprotokoll von Muse Glimmer. Es verwendet XML-artige Tags statt JSON und ist in langen Workflows stabiler:

XML 
<atem:function_calls>
  <atem:invoke name="tool_name">
    <atem:parameter name="param1">value1</atem:parameter>
  </atem:invoke>
</atem:function_calls>

Speculative Decoding: DFlash ist ein leichtgewichtiges „Draft-Modell", das mehrere Token-Kandidaten auf einmal generiert, die das Hauptmodell parallel verifiziert. Das ist 3-4× schneller als die autoregressive Token-für-Token-Generierung bei identischer Ausgabequalität. Dies ist die Schlüsseltechnologie, die Muse Glimmer auf Consumer-Hardware Echtzeit-Interaktion ermöglicht.

Steuerbare Inferenzstärke: Muse Glimmer unterstützt die Anpassung der Inferenztiefe (Reasoning Strength) als Abwägung zwischen Qualität und Geschwindigkeit. Einfache Aufgaben werden mit niedriger Stärke schnell beantwortet, komplexe Aufgaben mit hoher Stärke gründlich durchdacht.

Mehrsprachige Unterstützung: Die Trainingsdaten umfassen über 100 Sprachen, die Qualität kann jedoch je nach Sprache variieren. Chinesisch und Englisch sind am besten, bei kleineren Sprachen ist Vorsicht geboten.

Einschränkungen und Hinweise

Muse Glimmer ist kein Allheilmittel – seine Grenzen zu kennen ist wichtiger als seine Stärken:

1. Desktop-Operationen schwächer als Qwen

Bei Terminal-Bench (Terminalbefehle) und OSWorld (GUI-Operationen) schneidet Qwen3.6-27B besser ab. Wenn Ihr Kernszenario die Automatisierung von Desktop-Operationen ist, könnte Qwen die bessere Wahl sein.

2. Begrenzte multimodale Fähigkeiten

OmniDocBench-Tests zeigen, dass Muse Glimmer beim komplexen Dokumentenverständnis nicht an Qwen heranreicht. Der Perception Encoder kann Screenshots und einfache Diagramme verarbeiten, aber bei komplexem Layout, Tabellen und formellastigen Dokumenten stößt es an Grenzen.

3. Wissens-Stichtag

Die Trainingsdaten sind bis zum 4. Januar 2026 aktuell. Für Echtzeitinformationen müssen Retrieval-Tools (RAG) oder Websuch-Tools hinzugezogen werden.

4. Parallelisierung nicht validiert

Alle offiziellen Tests sind Single-User-Szenarien mit batch=1. Leistung, VRAM-Verbrauch und Latenz bei mehreren gleichzeitigen Benutzern müssen selbst getestet werden.

5. Sicherheitsrisiken

Metas eigene Sicherheitstests zeigen, dass Muse Glimmer bei Prompt-Injection-Angriffen nicht vollständig immun ist. Wenn lokale Agenten Zugriff auf Datei-, Netzwerk- und E-Mail-Tools haben, sind strenge Zugriffskontrollen und manuelle Bestätigungsmechanismen erforderlich.

6. Glaubwürdigkeit der Herstellerdaten

Alle Benchmark-Daten sind von Meta selbst gemeldet. Meta hat zuvor bei der Llama-4-Veröffentlichung zugegeben, eine nicht öffentlich bekannt gegebene Sonderversion für bessere Benchmark-Ergebnisse verwendet zu haben. Diese Daten sollten als Ausgangspunkt betrachtet werden, nicht als endgültiges Fazit. Vor dem produktiven Einsatz unbedingt im eigenen Szenario validieren.

Häufig gestellte Fragen (FAQ)

F1: Ist Muse Glimmer wirklich Open Source?

Ja. Meta hat die Modellgewichte auf Hugging Face unter der Apache-2.0-Lizenz veröffentlicht. Diese ist großzügiger als die Llama-Community-Lizenz und erlaubt kommerzielle Nutzung, Modifikation und Weiterverbreitung – es müssen nur der Lizenzhinweis und eine Änderungsbeschreibung beibehalten werden.

F2: Welche Hardware wird zum Ausführen benötigt?

Mindestens 24 GB VRAM (RTX 4090/3090 oder Apple M4 Max), empfohlen werden 32 GB VRAM (RTX 5090 oder M5 Max). Das quantisierte Modell ist ca. 17-20 GB groß, der verbleibende Speicher steht für KV-Cache und Perception Encoder zur Verfügung.

F3: Wie sind die Kosten im Vergleich zu Cloud-APIs?

Nach der einmaligen Hardware-Investition gehen die Grenzkosten gegen null. Bei einer RTX 5090 für ca. 1.600 € und 8 Stunden täglicher Nutzung liegen die Inferenzkosten innerhalb eines Jahres unter 0,02 € pro Anfrage. Im Vergleich zu Cloud-APIs mit Token-Abrechnung bietet lokales Deployment bei häufiger Nutzung klare Kostenvorteile.

F4: Kann es in Produktionsumgebungen eingesetzt werden?

Ja, als Komponente in Produktionsumgebungen, aber nach umfassenden Tests. Es wird empfohlen, zunächst 20-30 repräsentative Aufgaben auf Akzeptanzrate, Latenz, VRAM-Verbrauch und Tool-Aufruf-Fehlerrate zu prüfen. Bei unumkehrbaren Aktionen (wie E-Mails senden, Dateien löschen) muss eine manuelle Bestätigung vorgesehen werden.

F5: Wie wählt man zwischen Gemma4-31B, Qwen3.6-27B und Muse Glimmer?

  • Wenn Ihr Szenario Multi-Tool-Aufrufe, Code-Behebung und autonome Suche ist: Muse Glimmer
  • Wenn Ihr Szenario Desktop-Automatisierung und Terminal-Operationen ist: Qwen3.6-27B
  • Wenn Sie Google-Ökosystem-Unterstützung brauchen: Gemma4-31B
  • Es gibt keinen absoluten Gewinner – entscheiden Sie basierend auf Benchmarks für Ihre spezifischen Aufgaben

Fazit und Bewertung

Muse Glimmer ist Metas wichtiger Schachzug im Bereich lokaler Agenten. Es ist kein „Benchmark-Monster" auf der Jagd nach Parameterzahlen, sondern ein für reale Agenten-Szenarien optimiertes, praktisches Werkzeug.

Stärken: - Echte lokale Ausführung: 24 GB Consumer-GPU reichen, kein Internet erforderlich - Herausragende Agenten-Fähigkeiten: Tool-Aufrufe, mehrstufiges Reasoning, Fehlerwiederherstellung - Open-Source-freundliche Lizenz: Apache 2.0, sorgenfreie kommerzielle Nutzung - Breite Ökosystem-Unterstützung: Ollama, vLLM, llama.cpp, MLX, ExecuTorch

Schwächen: - Desktop-Operationen schwächer als Qwen - Begrenzte multimodale Fähigkeiten - Herstellerdaten müssen validiert werden - Parallelisierung nicht ausreichend getestet

Geeignet für: - Entwickler lokaler Agenten mit Datenschutzanforderungen - Vielfutzer, die API-Kosten senken möchten - Teams, die Offline-Programmierassistenten bauen - Komplexe Workflows mit MCP-Tool-Orchestrierung

Nicht geeignet für: - Szenarien mit höchstem Anspruch an Desktop-Automatisierung (Qwen wählen) - Szenarien mit komplexer Dokumentenverarbeitung (Qwen wählen) - Multi-User-Szenarien mit hoher Parallelität (weitere Tests erforderlich)

Die Veröffentlichung von Muse Glimmer markiert den Eintritt lokaler Agenten in die Praxisphase. Es ist kein Ersatz für Cloud-Agenten, sondern eine Ergänzung – in Szenarien mit Datenschutz-, Latenz- und Kostenanforderungen sind lokale Agenten die bessere Wahl. Mit steigender Hardwareleistung und Modellverbesserungen werden die Fähigkeitsgrenzen lokaler Agenten weiter wachsen.