Jede taktische Umgebung ist anders. Manche Einheiten arbeiten mit dauerhafter, breitbandiger Konnektivität zu einem klassifizierten Cloud-Enklave; andere stoßen in Gebiete vor, in denen das einzige Netzwerk das Mesh-Radio im Rucksack des Soldaten ist. KI-Copiloten, die nur dann funktionieren, wenn die Bedingungen stimmen — volle Konnektivität, kommerzieller Cloud-Zugang, keine Klassifizierungsbeschränkungen — sind für den Militäreinsatz keine nützlichen Werkzeuge. TAKpilot, Corvus Intelligences KI-Chat-Copilot für CloudTAK, basiert auf einer modell-agnostischen Architektur, die Kommandeuren und Systemintegratoren eine echte Wahl lässt: Claude Opus 4.7 über die Anthropic API für maximale analytische Leistung betreiben, oder Llama 3.3 70B auf einem gehärteten GPU-Server ohne jede Internetabhängigkeit bereitstellen. Dieser Artikel erläutert, wie diese Architektur funktioniert, wie das richtige Modell für einen bestimmten Missionskontext ausgewählt wird und wie TAKpilot Schritt für Schritt für air-gapped Edge-Deployments konfiguriert wird.

Warum Modell-Agnostizismus für Verteidigungsdeployments wichtig ist

Kommerzielle KI-Produkte kodieren in der Regel einen einzelnen Anbieter fest. Dieser Ansatz erzeugt eine harte Abhängigkeit von Internetkonnektivität, kommerzieller API-Verfügbarkeit und den Datenschutzbestimmungen des Anbieters — Einschränkungen, die häufig mit klassifizierten oder operativ sensiblen Umgebungen unvereinbar sind. TAKpilots Architektur löst dies, indem der Modellzugriff hinter einer einzigen Schnittstelle abstrahiert wird: der OpenAI-kompatiblen API-Spezifikation. Jedes Modell, das dieses Protokoll spricht — ob gehostet von Anthropic, AWS, Google oder einem lokalen Inferenzserver, der im selben Rack wie der CloudTAK-Knoten läuft — ist ein gültiges TAKpilot-Backend.

Das ist keine theoretische Flexibilität. TAKpilot ist operativ bei den ukrainischen Streitkräften im Einsatz, wo Netzwerkbedingungen, Konnektivitätsbeschränkungen und Klassifizierungsanforderungen innerhalb der Streitkräfte erheblich variieren. Ein Hauptquartierelement mit zuverlässiger Konnektivität nutzt Claude Sonnet 4.6 über die Anthropic API. Eine vorgeschobene Einheit mit nur taktischer Funkverbindung betreibt Llama 3.3 8B auf einem lokalen Inferenzknoten. Beide Einheiten interagieren mit derselben TAKpilot-Schnittstelle; nur das Backend unterscheidet sich.

Wichtige Erkenntnis: TAKpilot kodiert keinen KI-Anbieter fest. Die Modellauswahl ist eine Laufzeit-Konfigurationsentscheidung des Deployers — keine Produktbeschränkung. Eine einzelne TAKpilot-Installation kann durch Änderung von zwei Umgebungsvariablen und einen Neustart des Prozesses von einem Cloud-Backend auf ein air-gapped lokales Modell umgestellt werden.

Modellauswahl-Leitfaden: Fähigkeiten dem Missionskontext anpassen

TAKpilot unterstützt drei Stufen von Claude-Modellen über die Anthropic API sowie das gesamte Spektrum offener Modelle über die OpenAI-kompatible Schnittstelle. Die Wahl zwischen ihnen beinhaltet Abwägungen zwischen Schlussfolgerungstiefe, Latenz, Betriebskosten und Konnektivitätsanforderungen.

Claude Opus 4.7: komplexe mehrstufige Analyse

Opus 4.7 ist das leistungsfähigste Claude-Modell und die richtige Wahl für Aufgaben, die anhaltende mehrstufige Schlussfolgerungen erfordern: Synthese von ISR-Berichten aus mehreren Quellen, Generierung detaillierter Missionsaufträge aus bruchstückhaften Anweisungen oder Analyse mehrdeutiger Sensordaten, bei denen falsch-positive Ergebnisse ernste operative Konsequenzen haben. Der Kompromiss ist die Latenz — Opus 4.7 produziert Token langsamer als Sonnet oder Haiku, und die Kosten pro Token sind höher. Für S2- und S3-Analysearbeiten auf Hauptquartierebene, bei denen die Antwortzeit in Minuten statt Sekunden gemessen wird, ist Opus 4.7 die geeignete Wahl. Es erfordert Konnektivität zur Anthropic API oder zu AWS Bedrock / Google Vertex mit aktiviertem Opus-Modell.

Claude Sonnet 4.6: ausgewogene Leistung für die tägliche COP-Verwaltung

Sonnet 4.6 ist das standardmäßig empfohlene Modell für aktive Operationen, bei denen Operatoren konversationelle COP-Befehle erteilen — Marker setzen, Einheitenpositionen abfragen, Datenpakete erstellen, Kanäle abonnieren. Es bietet starke Anweisungsfolge- und Tool-Nutzungsgenauigkeit bei geringerer Latenz als Opus, was es reaktionsschnell genug für den interaktiven Einsatz macht, ohne den Kostenaufwand von Opus für jede Kartenmarkierung. Sonnet 4.6 ist das in TAKpilots operativem Einsatz bei ukrainischen Streitkräften als Basiskonfiguration für verbundene Elemente verwendete Modell.

Claude Haiku 4.5: geschwindigkeitsorientiert für hochfrequente Aufgaben

Haiku 4.5 ist auf Latenz und Durchsatz optimiert. Es ist die geeignete Wahl für hochfrequente, gut strukturierte Befehle — aktuelle Tracks abfragen, Missionen auflisten, Positionsdaten für bestimmte Rufzeichen abrufen — bei denen die Aufgabe routinemäßig genug ist, dass maximale Schlussfolgerungsfähigkeit nicht benötigt wird. Haiku antwortet schneller als Sonnet und zu deutlich geringeren Kosten pro Token, was in Umgebungen wichtig ist, in denen TAKpilot ein hohes Volumen an Operatoranfragen über mehrere gleichzeitige Sitzungen verarbeitet. Es ist auch sinnvoll als Fallback-Modell bei API-Ratendruck.

Offene Modelle für air-gapped Umgebungen

Wenn Cloud-Konnektivität nicht verfügbar ist oder Klassifizierungsanforderungen externe API-Aufrufe verbieten, leitet TAKpilot Inferenzen über den OpenAI-kompatiblen Endpunkt an ein lokal gehostetes Modell weiter. Drei Modelle wurden für TAKpilots Tool-Nutzungsmuster validiert:

  • Llama 3.3 70B — Metas 70B-instruktionsabgestimmtes Modell bietet die stärkste Tool-Nutzungsgenauigkeit unter den mit TAKpilot validierten offenen Modellen. In 4-Bit-Quantisierung (Q4_K_M) passt es auf einen Dual-GPU-Server oder einen einzelnen A100 und liefert 25–40 Token pro Sekunde — ausreichend für konversationelle COP-Interaktionen. Dies ist der empfohlene air-gapped Standard für gut ausgestattete Edge-Deployments.
  • Qwen 2.5 72B — Alibabas Qwen 2.5 mit 72B-Parametern erzielt vergleichbare Leistung wie Llama 3.3 70B bei strukturierten Tool-Aufrufen und weist eine stärkere mehrsprachige Leistung auf, was bei Koalitionsoperationen oder nicht-englischsprachigen Einheiten wertvoll sein kann. Die Hardwareanforderungen sind ähnlich.
  • Mistral Large — Mistrals instruktionsabgestimmtes Modell ist als lokale Deployment-Option verfügbar und erzielt gute Ergebnisse bei Klassifizierungs- und Routing-Aufgaben. Es ist eine vernünftige Wahl, wenn ein kleinerer Footprint erforderlich ist und die Befehlsarbeitslast relativ strukturiert ist.
  • Llama 3.3 8B — Für stark hardwarebeschränkte Umgebungen (einzelne Consumer-GPU, 8–12 GB VRAM) bietet die 8B-Variante in 4-Bit-Quantisierung akzeptable Leistung für einfache COP-Abfragen. Komplexe mehrstufige Tool-Sequenzen werden im Vergleich zum 70B-Modell schlechter, sodass Operatoren eine explizitere Anweisungsformulierung erwarten sollten.

Wichtige Erkenntnis: Die Zuverlässigkeit der Tool-Nutzung nimmt mit der Modellgröße ab. Die 70B-Klasse-Modelle (Llama 3.3 70B, Qwen 2.5 72B) erhalten akzeptable Tool-Aufruf-Genauigkeit für TAKpilots CloudTAK API-Aufrufe. Modelle unter 13B Parametern zeigen deutlich höhere Raten von fehlgeformten Tool-Aufrufen und sollten vor dem operativen Einsatz gegen Ihre spezifische COP-Befehlsarbeitslast validiert werden.

Cloud-Backends für klassifizierte Umgebungen: AWS Bedrock und Google Vertex

Nicht alle Cloud-Deployments sind aus Sicht der Klassifizierung und Datenspeicherung gleichwertig. Die Anthropic API leitet Inferenzdatenverkehr an die Infrastruktur von Anthropic weiter. Für Umgebungen, die erfordern, dass Daten innerhalb eines bestimmten Cloud-Enklave verbleiben — AWS GovCloud, Azure Government oder ein Google Workspace for Government-Mandant — unterstützt TAKpilot die Weiterleitung von Claude-Modellen über AWS Bedrock und Google Vertex AI, die das Modell-Hosting innerhalb der Cloud-Grenze des Kunden übernehmen.

AWS Bedrock stellt Claude Opus 4.7, Sonnet 4.6 und Haiku 4.5 über das Standard-AWS-SDK bereit. Aus TAKpilots Sicht besteht die Konfigurationsänderung in einem Austausch der API-Basis-URL und der Authentifizierungsmethode: Ersetzen des Anthropic API-Schlüssels durch AWS-IAM-Anmeldeinformationen (über Umgebungsvariablen oder eine Instanzrolle) und Setzen von TAKPILOT_PROVIDER=bedrock mit der entsprechenden AWS-Region. Dieselben Claude-Modelle sind verfügbar; der Inferenzdatenverkehr verbleibt innerhalb der AWS-Netzwerkgrenze und unterliegt den AWS-Datenverarbeitungsvereinbarungen des Kunden anstelle von Anthropics kommerziellen Bedingungen.

Google Vertex AI bietet denselben Claude-Modellzugang über Googles Modellgarten. Die Konfiguration folgt demselben Muster: Setzen von TAKPILOT_PROVIDER=vertex mit einer GCP-Projekt-ID und Service-Account-Anmeldeinformationen. Für Organisationen, die bereits in Googles verteidigungsgeeigneten Cloud-Angeboten arbeiten, hält dies den gesamten Inferenzdatenverkehr innerhalb des bestehenden Sicherheitsperimeters.

Unterstützung für OpenAI-kompatible Endpunkte

TAKpilots air-gapped Pfad verwendet dieselbe OpenAI Chat Completions API-Spezifikation, die zum De-facto-Standard für lokale Modellinferenzserver geworden ist. Das bedeutet, dass TAKpilot mit jedem Inferenz-Runtime kompatibel ist, der diese Schnittstelle implementiert — Ollama, vLLM, llama.cpp-Server, LM Studio, Hugging Face TGI und jeder benutzerdefinierte Container, der ein Modell mit einer OpenAI-kompatiblen REST-Schicht verpackt.

Die Konfiguration ist absichtlich minimal gehalten. Zwei Umgebungsvariablen reichen aus, um TAKpilot von der Anthropic API auf einen beliebigen lokalen Endpunkt umzuleiten:

# TAKpilot auf einen lokalen Ollama-Inferenzserver umleiten
TAKPILOT_API_BASE=http://192.168.1.50:11434/v1
TAKPILOT_MODEL=llama3.3:70b-instruct-q4_K_M
TAKPILOT_API_KEY=ollama

# Oder auf einen vLLM-Server mit Qwen 2.5
TAKPILOT_API_BASE=http://10.0.1.20:8000/v1
TAKPILOT_MODEL=Qwen/Qwen2.5-72B-Instruct
TAKPILOT_API_KEY=vllm-token

Wenn TAKPILOT_API_BASE gesetzt ist, versucht TAKpilot unter keinen Umständen, die Anthropic API zu erreichen. Es gibt keinen Fallback auf Cloud-Modelle, wenn der lokale Endpunkt nicht erreichbar ist — TAKpilot gibt dem Operator einen Fehler zurück, anstatt Datenverkehr still an einen unbeabsichtigten Endpunkt weiterzuleiten. Dies ist ein bewusstes Sicherheitsverhalten für klassifizierte Umgebungen.

Sitzungs-Sandbox für Operatordaten

Unabhängig davon, welches Modell-Backend verwendet wird, erzwingt TAKpilot dasselbe Sitzungsisolationsmodell. Jede Operatorverbindung erstellt einen In-Memory-Sitzungskontext, der den Gesprächsverlauf, ausstehende Tool-Aufrufe und alle während der Sitzung von CloudTAK abgerufenen COP-Daten enthält. Dieser Kontext wird niemals auf Disk geschrieben, niemals mit anderen Sitzungen geteilt und niemals an einen anderen Endpunkt als das konfigurierte Modell-Backend gesendet.

Wenn der Operator die Verbindung trennt — entweder durch Schließen des CloudTAK-Chat-Panels oder nach einem konfigurierbaren Sitzungs-Timeout — wird der Sitzungskontext aus dem Speicher gelöscht. Es gibt keine Sitzungspersistenz zwischen Verbindungen. Ein Operator, der sich erneut verbindet, beginnt mit einem frischen Kontext ohne Kenntnis der Befehle oder abgerufenen Daten der vorherigen Sitzung.

Wichtige Erkenntnis: TAKpilots Sitzungs-Sandbox bedeutet, dass selbst bei cloud-verbundenen Deployments das Expositionsfenster durch die Sitzungsdauer begrenzt ist. Eine Sitzung, die eine einzelne taktische Abfrage verarbeitet und sich schließt, hat nur die Daten dieser Abfrage dem Modell-Backend gegenüber exponiert. Es gibt keinen akkumulierenden Datenspeicher, der mit der Nutzung wächst.

Bei air-gapped Deployments ist die Sandbox-Garantie absolut: Der Sitzungskontext überschreitet niemals eine Netzwerkgrenze, da das Modell-Backend im selben Netzwerksegment liegt. Operatoren, die klassifizierte COP-Daten verarbeiten, sollten TAKpilot stets im air-gapped Modus gegen ein lokales Modell betreiben — die Sitzungs-Sandbox stellt sicher, dass klassifizierte Daten nur vom lokalen Inferenzknoten verarbeitet und beim Sitzungsende gelöscht werden.

Anleitung zur Bereitstellung von TAKpilot mit Llama 3.3 auf air-gapped taktischer Hardware

Das folgende Verfahren setzt eine bereits bereitgestellte TAKpilot Node.js-Instanz voraus, die mit einem CloudTAK-Server verbunden ist. Für das initiale CloudTAK-Deployment siehe den CloudTAK Server-Deployment-Leitfaden. Der Inferenzserver muss sich im selben taktischen LAN wie CloudTAK und TAKpilot befinden.

Schritt 1: GPU-Inferenzserver im taktischen LAN bereitstellen

Installieren Sie Ollama auf einem Linux-Server (Ubuntu 22.04 LTS empfohlen) mit mindestens einer NVIDIA-GPU. GPU-Erkennung überprüfen:

curl -fsSL https://ollama.com/install.sh | sh
nvidia-smi   # sollte GPU(s) auflisten
ollama --version

Weisen Sie dem Server eine statische IP im taktischen LAN zu (z.B. 192.168.1.50). Stellen Sie sicher, dass Port 11434 vom TAKpilot-Host erreichbar ist. Standardmäßig bindet Ollama nur an 127.0.0.1 — um LAN-Verbindungen zu akzeptieren, setzen Sie OLLAMA_HOST=0.0.0.0 in der Ollama-Dienst-Umgebung.

Schritt 2: Llama 3.3 Modell laden

# 70B-Modell — erfordert ~40 GB VRAM (Dual-GPU oder A100)
ollama pull llama3.3:70b-instruct-q4_K_M

# 8B-Modell — passt auf eine einzelne 8 GB GPU
ollama pull llama3.3:8b-instruct-q4_K_M

Der Pull-Befehl lädt die Modellgewichte über das Internet herunter. Für vollständig air-gapped Umgebungen, in denen sogar dieser initiale Download untersagt ist, übertragen Sie die Modelldatei manuell: Laden Sie die GGUF-Datei auf einem verbundenen Rechner herunter, kopieren Sie sie über Wechseldatenträger auf den Server und importieren Sie sie mit ollama create. Die Ollama-Dokumentation beschreibt das Offline-Importverfahren.

Schritt 3: OpenAI-kompatiblen Endpunkt überprüfen

# Vom TAKpilot-Host aus
curl http://192.168.1.50:11434/v1/models
# Erwartet: {"object":"list","data":[{"id":"llama3.3:70b-instruct-q4_K_M",...}]}

Wenn die Anfrage ein Timeout hat, prüfen Sie, ob Ollama an 0.0.0.0 gebunden ist und keine Host-Firewall Port 11434 blockiert.

Schritt 4: TAKpilot-Umgebungsvariablen konfigurieren

# .env oder systemd-Dienst-Umgebung
TAKPILOT_API_BASE=http://192.168.1.50:11434/v1
TAKPILOT_MODEL=llama3.3:70b-instruct-q4_K_M
TAKPILOT_API_KEY=ollama

# Nicht gesetzt oder leer lassen — TAKpilot fällt nicht auf Anthropic zurück
# ANTHROPIC_API_KEY=

Schritt 5: TAKpilot starten und Modell-Routing bestätigen

Starten Sie den TAKpilot Node.js-Prozess und prüfen Sie das Startprotokoll auf die Modell-Backend-Zeile. Senden Sie dann einen Testbefehl über die CloudTAK-Chat-Oberfläche und bestätigen Sie, dass eine Antwort zurückgegeben wird. Überwachen Sie die GPU-Auslastung des Inferenzservers mit nvidia-smi dmon, um zu überprüfen, ob die Inferenz lokal läuft.

Schritt 6: Tool-Nutzung mit einem COP-Befehl testen

Senden Sie einen strukturierten COP-Befehl: „Alle aktiven Einheiten in Alpha Company auflisten." TAKpilot sollte das CloudTAK-Tool list_units aufrufen und eine formatierte Antwort zurückgeben. Wenn das Modell eine Klartextantwort ohne Tool-Aufruf zurückgibt, ist die Anweisungsfolge-Fähigkeit des Modells für TAKpilots Tool-Call-Schemas unzureichend — wechseln Sie zur 70B-Variante oder zu Qwen 2.5 72B.

Schritt 7: Sicherstellen, dass kein Datenverkehr die Netzwerkgrenze verlässt

# Auf dem TAKpilot-Host — jeden Datenverkehr außerhalb des LAN erfassen
tcpdump -i eth0 -n 'not net 192.168.1.0/24 and not net 10.0.0.0/8'

Senden Sie mehrere TAKpilot-Befehle und bestätigen Sie, dass in der tcpdump-Ausgabe keine Pakete erscheinen. Der gesamte Modellinferenzdatenverkehr sollte im taktischen LAN verbleiben. Wenn Pakete zu externen IPs beobachtet werden, überprüfen Sie die TAKpilot-Umgebungskonfiguration — stellen Sie sicher, dass TAKPILOT_API_BASE korrekt gesetzt und ANTHROPIC_API_KEY in der Umgebung nicht vorhanden ist.

Leistungsabwägungen für häufige COP-Aufgaben

Die praktischen Leistungsunterschiede zwischen Cloud- und Edge-Modellen werden schnell im gesamten Spektrum der von TAKpilot behandelten Aufgaben sichtbar. Die folgenden Charakterisierungen basieren auf beobachtetem Verhalten in TAKpilot-Deployments, nicht auf veröffentlichten Benchmarks.

Markierungsplatzierung und Einheitenabfragen sind die häufigsten COP-Interaktionen. Sowohl Claude Haiku 4.5 als auch Llama 3.3 8B verarbeiten diese genau und mit geringer Latenz. Die Aufgabe ist gut strukturiert — der Operator sagt, wo ein Marker platziert werden soll, TAKpilot ruft die CloudTAK API auf — und erfordert minimales Schlussfolgern. Jedes Modell ist geeignet. Für die 8B-Variante verbessern explizite Koordinatenformate (Dezimalgrad oder MGRS) die Genauigkeit; das Modell kann mit mehrdeutigen Ortsreferenzen Schwierigkeiten haben.

Mehrstufiges Missionsmanagement — eine Mission erstellen, Gruppen zuweisen, ein Datenpaket anhängen und das Ergebnis bestätigen — erfordert, dass das Modell den Kontext über mehrere Tool-Aufrufe hinweg aufrechterhält. Claude Sonnet 4.6 verarbeitet dies zuverlässig. Llama 3.3 70B verarbeitet es mit akzeptabler Genauigkeit. Llama 3.3 8B hat Schwierigkeiten mit Sequenzen, die länger als drei Tool-Aufrufe sind, und sollte nicht für komplexe Missionsmanagement-Workflows verwendet werden.

Dokument- und Bildintelligenz — Verarbeitung von PDFs, Bildern und Geheimdienstberichten, die in die TAKpilot-Sitzung hochgeladen werden — profitiert erheblich von größeren Modellen. Claude Opus 4.7 und Sonnet 4.6 bieten die kohärenteste Synthese mehrseitiger Dokumente. Aufgaben mit Bildverarbeitung (Analyse von PNG/JPG-Anhängen) erfordern ein Modell mit Sehvermögen; Llama 3.3 ist rein textbasiert. Für Sehaufgaben in air-gapped Umgebungen wäre LLaVA oder eine Qwen-VL-Variante erforderlich.

Häufig gestellte Fragen

+Welche KI-Modelle unterstützt TAKpilot standardmäßig?

TAKpilot wird mit Unterstützung für die gesamte Claude-Modellfamilie ausgeliefert — Opus 4.7, Sonnet 4.6 und Haiku 4.5 — über die Anthropic API oder AWS Bedrock und Google Vertex AI. Es unterstützt außerdem jedes Modell, das über einen OpenAI-kompatiblen Endpunkt erreichbar ist, was Llama 3.3, Qwen 2.5, Mistral Large und jedes andere offene Modell umfasst, das von Ollama, vLLM, llama.cpp oder einem benutzerdefinierten Inferenz-Container bereitgestellt wird. Das aktive Modell wird über die Umgebungsvariablen TAKPILOT_MODEL und TAKPILOT_API_BASE ausgewählt — ohne Codeänderungen.

+Kann TAKpilot ohne Internetverbindung betrieben werden?

Ja. TAKpilots air-gapped Deployment-Pfad leitet alle Modellinferenzen an einen lokalen OpenAI-kompatiblen Inferenzserver weiter, der im selben taktischen LAN oder auf demselben physischen Host läuft. Es verlässt kein Datenverkehr das Netzwerk. Operatoren stellen ein Modell wie Llama 3.3 70B oder Qwen 2.5 72B auf einem gehärteten GPU-Server bereit, machen es über einen privaten Endpunkt erreichbar (z.B. http://192.168.1.50:11434/v1) und setzen TAKPILOT_API_BASE auf diese Adresse. TAKpilot verbindet sich damit identisch wie mit einem Cloud-Anbieter — nur die Transportschicht unterscheidet sich.

+Wie stellt TAKpilot sicher, dass Operatordaten das Netzwerk nicht verlassen?

TAKpilot erzwingt eine Sitzungs-Sandbox für alle Operatordaten. Jede Operatorsitzung erhält einen isolierten Kontext, der niemals auf Disk geschrieben oder zwischen Sitzungen geteilt wird. Wenn der Operator die Verbindung trennt, wird der Sitzungskontext — einschließlich aller Nachrichten, Tool-Call-Ergebnisse und COP-Referenzen — aus dem Speicher gelöscht. Bei cloud-gehosteten Modellen (Claude über die Anthropic API) gelten Anthropics Enterprise-Datenrichtlinien; bei air-gapped Deployments mit lokalen Modellen verlassen Daten das taktische LAN nie, da der Inferenzendpunkt lokal ist. Operatoren mit klassifizierten Arbeitslasten sollten TAKpilot stets im air-gapped Modus gegen ein lokal gehostetes Modell betreiben.

+Welche Hardwareanforderungen gelten für den Betrieb von Llama 3.3 70B auf einem taktischen Edge-Server?

Llama 3.3 70B in 4-Bit-Quantisierung (GGUF Q4_K_M) erfordert ungefähr 40 GB VRAM. Eine einzelne NVIDIA RTX 4090 (24 GB) ist bei voller Präzision unzureichend; für vollständige 70B-Parameterinferenz wird ein Dual-GPU-Setup oder ein Server-Grade A100/H100 empfohlen. Für eingeschränktere taktische Hardware bieten Llama 3.3 8B (Q4_K_M, ~5 GB VRAM) oder Qwen 2.5 7B akzeptable Leistung auf einer einzelnen Consumer-GPU. Die Inferenzgeschwindigkeit bei 70B auf einem A100 beträgt ca. 25–40 Token pro Sekunde, was für konversationelle COP-Interaktionen mit akzeptabler Latenz ausreicht.

+Kann TAKpilot das Modell während des Betriebs wechseln, ohne den Server neu zu starten?

Die Modellauswahl in der aktuellen TAKpilot-Version wird beim Start über Umgebungsvariablen festgelegt und gilt für alle Sitzungen. Hot-Switching von Modellen ohne Server-Neustart wird in der Basiskonfiguration nicht unterstützt. Da TAKpilot jedoch unter AGPL-3.0 als Open-Source verfügbar ist, können Deployer, die eine sitzungsbasierte Modellauswahl benötigen, die Konfigurations-API erweitern. Ein gängiges Muster für Mehrklassifizierungsumgebungen ist der Betrieb von zwei TAKpilot-Instanzen auf separaten Ports — eine verbunden mit einem Cloud-Claude-Endpunkt für nicht klassifizierte Arbeit, eine mit einem lokalen Llama-Endpunkt für klassifizierte Operationen — und die Weiterleitung von Operatoren zur entsprechenden Instanz über einen Reverse-Proxy.