Dify→Ollama-Traffic in privatem Segment statt Public Internet halten.
Agentenqualität hängt nicht nur von Modellparametern ab. Zuverlässige Ollama-Konnektivität, Kontextbudget, Tool-Schemas, RAG-Retrieval, Timeouts und parallele Agenten bestimmen Performance gemeinsam.
Bei Shell-, HTTP- oder Write-Tools nicht darauf vertrauen, dass ein lokales Modell „sicher“ sei. Prompt Injection bleibt möglich; Tool-Policy und Server-Side-Validierung sind getrennte Kontrollen.
Bei Dify und Ollama im Docker-Netz ist `localhost` im Container nicht der andere Service. Bei getrennten Hosts Ollama-API nicht ungeschützt öffentlich exponieren; privates Netz oder authentifizierten Reverse Proxy nutzen.
Bei Dify und Ollama im Docker-Netz ist `localhost` im Container nicht der andere Service. Bei getrennten Hosts Ollama-API nicht ungeschützt öffentlich exponieren; privates Netz oder authentifizierten Reverse Proxy nutzen.
Ollama-Modelle mit Dify-Agent-Workflows verbinden: Netzwerk, Kontext, Tool-Rechte, RAG, Timeouts, Concurrency und Production-Sicherheit.
Dify→Ollama-Traffic in privatem Segment statt Public Internet halten.
Langer Kontext erhöht KV-Cache-Speicher und Latenz.
Tool-Rechte bestimmen reale Auswirkungen stärker als Modelllokalität.
Vector Retrieval ist nicht Modelltraining.
Eine URL, die im Host-Browser funktioniert, kann im Dify-Container-Netz fehlschlagen. Vom tatsächlich anfragenden Container testen.
docker compose psdocker exec -it docker-api-1 sh -lc "getent hosts host.docker.internal || true"curl http://OLLAMA_HOST:11434/api/tagscurl http://OLLAMA_HOST:11434/api/versionKleines schnelles Modell kann für Routing/Klassifikation reichen; Tool-Planning oder lange Dokumente benötigen ggf. mehr Reasoning/Kontext.
| Aufgabe | Priorität |
|---|---|
| Intent/Router | Niedrige Latenz |
| Tool Planning | Instruction Following |
| RAG-Antwort | Kontext + Zitierdisziplin |
| Code-Agent | Tool-Genauigkeit + langer Kontext |
KV-Cache-Speicher und First-Token-Latenz können mit Kontext steigen. Separate Token-Budgets für RAG-Chunks und Conversation History setzen.
Die Wirkung jedes Tools ist wichtiger als die Anzahl. Bei destruktiven Aktionen Confirmation und serverseitige Allow-Lists nutzen.
| Klasse | Beispiel | Kontrolle |
|---|---|---|
| Read | Dokumente suchen | Scope/Filter |
| Write | Ticket erstellen | Schema + Idempotency |
| Destructive | Löschen/Zahlen/Deploy | Human Approval + Allow-List |
Chunks aus Embedding/Vector-Suche werden in den Request-Kontext gegeben. Bei Dokumentänderung Index aktualisieren statt Modell neu trainieren.
Ein Agent kann mehrere Modell-/Tool-Roundtrips machen. „50 tok/s“ beschreibt Workflow-Kapazität nicht allein.
| Metrik | Messung |
|---|---|
| TTFT | Latenz bis erste Modellantwort |
| Tool-Latenz | p95 je Tool-Roundtrip |
| End-to-end | User Request → finale Antwort |
| Queue-Wartezeit | Concurrency-Sättigung |
LLM-Requests können lange dauern; Retry eines Write-/Payment-Tools kann doppelte Side Effects erzeugen. Idempotency je Call-Typ kennen.
Auf Eka Sunucu GPU/VPS separate Ressourcenprofile für Dify Control Plane und Ollama Inference erstellen und Agent-Concurrency testen.
Primärdokumentation und technische Referenzen dieses Leitfadens.
Mit passenden Infrastruktur- und Implementierungsleitfäden fortfahren.
Dify + Ollama
Ohne gemeinsamen Network Namespace meint `localhost` den Dify-Container selbst. Docker-Service-Name, Host-Gateway oder private IP nutzen.
Meist nein. Zugriff per privatem Netzwerk oder authentifiziertem Reverse Proxy begrenzen.
Unterstützte Vector Stores können sich je Release ändern; aktuelle Self-Host-Konfiguration vor Produktion prüfen.
Nein. Tool-Genauigkeit, Latenz, Concurrency, Kontext und Aufgabenkomplexität gemeinsam bewerten.