Verteiltes Training 2026: DDP, FSDP2, DeepSpeed, Megatron und die fünf Achsen der Parallelität

Sobald mehr als eine GPU im Gehäuse steckt, steht eine Entscheidung an. Vier Open-Source-Stacks dominieren das verteilte Training heute – PyTorch DDP, PyTorch FSDP2, Microsoft DeepSpeed und NVIDIA Megatron-Core –, ergänzt um TorchTitan als neue Referenz für groß angelegtes Training in nativem PyTorch. Jeder löst ein anderes Problem. Die falsche Wahl kostet Wochen: Entweder passt das Modell nicht und Sie merken es bei Schritt 30 am Out-of-Memory-Absturz, oder Sie haben für einen Workload überkonstruiert, den DDP mit einem Zehntel des Aufwands erledigt hätte.

Dieser Artikel betrachtet verteiltes Training aus Einkäufer- und Architektensicht. Er geht die fünf Parallelisierungsachsen durch, die vier (inzwischen fünf) Frameworks, die sie kombinieren, und die Rezepte, die auf Hardware der Kentino-Klasse tatsächlich funktionieren – vor allem 4× und 8× RTX 5090, 4090 und RTX Pro 6000 Blackwell auf AMD-EPYC-Hosts, mit PCIe Gen5 und handelsüblichem Ethernet oder InfiniBand zwischen den Knoten. Die ehrliche Pointe steht gleich am Anfang, damit der Rest des Artikels sie nicht ständig belegen muss: Die meisten Kentino-Kunden führen Fine-Tuning durch, kein Pretraining – und FSDP2 auf einem einzelnen 8-GPU-Knoten deckt 90 % aller Fine-Tuning-Anforderungen ab. Megatron-Core und 3D-Parallelität rechnen sich erst, wenn Sie oberhalb der 30B-Marke von Grund auf pretrainieren, und dieser Club ist deutlich kleiner, als das Marketing suggeriert.

Die fünf Achsen

Jedes moderne Framework für verteiltes Training kombiniert eine Teilmenge derselben fünf Parallelisierungsachsen. Sie sind keine Alternativen – Rezepte für große Modelle setzen drei oder vier gleichzeitig ein. Lesen Sie die Kommunikationsspalte von oben nach unten; darum geht es im Kern.

DP ruft einmal pro Schritt. TP ruft zweimal pro Layer. PP flüstert einmal pro Stufe. SP/CP ruft einmal pro Attention-Block, aber entlang einer anderen Dimension. EP führt All-to-All nur auf den MoE-aktiven Layern aus. Allein diese Spalte entscheidet, wo jede Achse hingehört – in eine schnelle Box oder über eine langsamere Fabric.

Die „3D-Parallelität“, die in jedem NVIDIA-Blog auftaucht, ist DP × TP × PP. Kommen SP und EP hinzu, wird daraus 4D oder 5D – mehr ein Notationsspiel als eine architektonische Änderung. Entscheidend ist das Layout: TP innerhalb des Knotens (wo Bandbreite günstig ist), PP zwischen den Knoten (wo Bandbreite teuer ist), DP obendrauf zur Skalierung des Durchsatzes. SP fügt sich neben TP ein; EP gilt nur für MoE.

Querverweise: die knoteninterne Bandbreite für Tensorparallelität wird in K07aufgeschlüsselt, der Nachteil von PCIe gegenüber NVLink in N03und die Fabric zwischen den Knoten in N08.

DDP – wenn das Modell passt und Sie einfach mehr Durchsatz wollen

PyTorch DDP (DistributedDataParallel) ist die älteste, einfachste und nach wie vor richtige Antwort, wenn das Modell auf eine GPU passt. Jeder Rank hält eine vollständige Kopie von Modell und Optimizer-State. In jedem Schritt führt jeder Rank Forward, Backward und Gradientenberechnung auf seinem eigenen Micro-Batch aus. Danach summiert ein einziges All-Reduce die Gradienten über alle Ranks, und alle wenden dasselbe Update an.

DDP in PyTorch 2.x ist dasselbe DDP wie immer, mit zwei erwähnenswerten Verbesserungen: einem robusteren static_graph=True -Pfad für compilerfreundliche Graphen und einer engeren Integration mit torch.compile. Das Kommunikationsmuster ist unverändert – ein All-Reduce pro Schritt, überlappt mit dem Backward, linear skalierend, bis das All-Reduce dominiert.

Wann DDP die richtige Antwort ist:

• Das vollständige Modell plus Optimizer-States und Aktivierungen passt auf eine GPU. Für Optimizer vom Adam-Typ mit FP32-Master-Weights lautet die Faustregel rund 16 Byte pro Parameter Speicher allein für den trainierbaren State (4 Byte Weights, 4 Byte Gradienten, 8 Byte Optimizer), zuzüglich Aktivierungen. Ein 8B-Modell ergibt 128 GB State – das passt auf eine RTX Pro 6000 Blackwell (96 GB) nur mit Mixed Precision und BF16-Master-Weights. Unterhalb von 8B Parametern fühlt sich DDP auf einer einzelnen 5090 wohl; darüber sollten Sie FSDP2 prüfen.
• Sie wollen maximalen Durchsatz, nicht maximale Modellgröße. DDP hat von allen datenparallelen Ansätzen das niedrigste Verhältnis von Kommunikation zu Rechenzeit, weil die Gradienten nur einmal pro Schritt reduziert werden, nach der gesamten lokalen Backward-Arbeit.
• Sie fahren Reinforcement-Learning-Rollouts, LoRA oder ein Setup, bei dem jeder Rank einen kleinen trainierbaren Adapter über eingefrorenen Basisgewichten hält.

Wann DDP falsch ist: wenn das Modell nicht passt. Die Lösung heißt nicht „kleinerer Batch“. Die Lösung heißt FSDP2.

torchrun --standalone --nproc-per-node=8 train.py

Das ist der komplette Launcher. DDP ist der langweilige Standard, den alle vergessen – und für den passenden Workload das Schnellste, was Sie fahren können.

FSDP2 – der neue Standard für alles, was DDP nicht schafft

FSDP (Fully Sharded Data Parallel) verteilt Modellparameter, Gradienten und Optimizer-States über die datenparallele Gruppe. Jede GPU speichert 1/N der Parameter. Für einen Forward-Pass sammelt der Rank per All-Gather den gerade benötigten Layer ein, rechnet und verwirft die eingesammelten Gewichte anschließend wieder. Der Speicherbedarf sinkt gegenüber DDP etwa um den Faktor N; die Kommunikation steigt, weil jeder Layer eingesammelt und erneut eingesammelt wird.

Die Geschichte des Jahres 2025 heißt FSDP2. Das ursprüngliche FSDP (FSDP1) fasste Parametergruppen zu einem einzigen FlatParameterzusammen, was das Nachdenken über einzelne Parameter – teilweises Einfrieren, gemischte Datentypen, parameterspezifische Optimizer-Einstellungen – mühsam bis unmöglich machte. FSDP2 hat die Interna auf Basis von DTensor neu geschrieben: Jeder Tensor bleibt ein echter torch.Tensor , der zufällig entlang seiner Dimension 0 über die Ranks verteilt ist. Die nach außen sichtbare API wechselte von FSDP(model, ...) zu fully_shard(model, ...).

Was FSDP2 gegenüber FSDP1 tatsächlich liefert – laut veröffentlichten Benchmarks und unseren eigenen Läufen:

• ~7 % weniger GPU-Speicher bei Llama 2 7B unter gleicher Konfiguration, weil FSDP2 das record_stream -Muster vermeidet, das Speicher pessimistisch festhielt.
• ~1.5 % mehr Durchsatz bei gleicher Konfigurationund bis zu 50 % Durchsatzgewinn in Kombination mit torch.compile und torchao -Float8-Training auf Hardware der Hopper-Klasse.
• Sharded State Dicts, die schnell laden und sauber neu verteilt werden über unterschiedliche Parallelisierungs-Layouts hinweg – das FSDP1-Checkpoint-Format war bekanntlich schwer zwischen Training und Inferenz umzuformen.
• Teilweises Einfrieren von Parametern ohne Verrenkungen, was für LoRA und Adapter-Training zählt.

FSDP1 ist seit PyTorch 2.11 veraltet. Neue Projekte sollten fully_shardverwenden. Der alte FullyShardedDataParallel -Wrapper existiert aus Kompatibilitätsgründen weiter, steht aber auf der Streichliste.

FSDP2 bietet außerdem zwei Sharding-Strategien, die bestimmen, wo das Modell liegt:

• Full Shard. Parameter vollständig über alle Ranks verteilt (der FSDP1-Standard). Geringster Speicherbedarf, höchste Kommunikation.
• Hybrid Shard. Parameter werden innerhalb eines Knotens verteilt und repliziert über Knoten hinweg. Innerhalb des Knotens läuft die Kommunikation über PCIe/NVLink (schnell). Zwischen den Knoten überquert nur das Gradienten-All-Reduce die langsame Fabric. Das ist der Sweet Spot für 2–4 Knoten an 100/200 Gbps Ethernet/IB.

Wann FSDP2 die richtige Antwort ist (der typische Kentino-Fall):

• Fine-Tuning von 8B–70B auf einem 8-GPU-Knoten. Full Shard, BF16, Gradient Checkpointing an, torch.compile. Fertig.
• Fine-Tuning von 70B–405B über 2–4 Knoten. Hybrid Shard mit Full Shard innerhalb jedes Knotens, repliziert über die Knoten.
• Alles rund um LoRA / QLoRA – bei der Behandlung einzelner Parameter schlägt FSDP2 hier FSDP1 klar.

from torch.distributed.fsdp import fully_shard, MixedPrecisionPolicy

mp = MixedPrecisionPolicy(param_dtype=torch.bfloat16, reduce_dtype=torch.float32)
for block in model.transformer_blocks:
    fully_shard(block, mp_policy=mp)
fully_shard(model, mp_policy=mp)

Gestartet wird genauso wie bei DDP, über torchrun. Nur der Wrapper ändert sich.

DeepSpeed und die ZeRO-Stufen – noch da, aber nicht mehr Standard

DeepSpeed ist der Stack für verteiltes Training von Microsoft. Berühmt wurde er durch ZeRO (Zero Redundancy Optimizer), das Jahre vor FSDP erschien und den modernen Ansatz „alles sharden“ definierte.

ZeRO-3 ist architektonisch gleichwertig mit FSDP Full Shard. Beide lösen dasselbe Problem mit denselben Kommunikationsprimitiven.

Die Realität 2025–2026: Beim Anwendungsfall dichter LLMs hat FSDP2 DeepSpeed den Rang abgelaufen. PyTorch-nativ, kein Zusatzpaket, integriert mit torch.compile– und dasselbe Rezept lässt sich auf Hugging Face Transformers, Accelerate und TorchTitan übertragen. Interne Benchmarks von Lightning und Hugging Face zeigen, dass FSDP Full Shard pro Iteration in manchen Setups 2–5× schneller läuft als ZeRO-3; bei sehr großen Modellen (10B+) holt DeepSpeed allerdings wieder auf, weil seine CPU- und NVMe-Offload-Pfade dort nach wie vor echten Nutzen bringen.

DeepSpeed bleibt aus drei Gründen kennenswert:

1. ZeRO-Infinity-Offload. Wenn Sie ein Modell feinabstimmen müssen, das überhaupt nicht in den gesamten GPU-Speicher passt – etwa ein 405B-Basismodell auf einer Box mit 4× RTX Pro 6000 Blackwell –, kann DeepSpeed Parameter in den CPU-RAM (günstig, langsam) und auf NVMe (noch günstiger, deutlich langsamer) auslagern. FSDP beherrscht CPU-Offload ebenfalls, doch der NVMe-Pfad von DeepSpeed ist ausgereifter. Nützlich für „Ich habe eine Maschine und ein störrisches Modell“; nicht die richtige Antwort, wenn Sie einen zweiten Knoten mieten oder kaufen können.
2. Sequenzparallelität mit DeepSpeed-Ulysses. Ein kommunikationseffizientes sequenzparalleles Verfahren, das für Attention All-to-All statt Ring-All-Gather nutzt. Demonstriert wurden Kontexte bis 1 Mio. Tokens auf 64 A100 sowie das Training von Llama-8B mit 15 Mio. Tokens Kontext auf 32 H100 in 2025 veröffentlichten Arbeiten. Wenn Sie gezielt Training mit sehr langem Kontext anstreben, liegt Ulysses für manche Formen noch vor der Context-Parallel-Implementierung von Megatron.
3. DeepSpeed-MoE. Mixture-of-Experts-Training mit Expertenparallelität. Für Fine-Tuning weniger relevant, für das Pretraining von MoE sehr.

Für den Großteil des Fine-Tunings bei Kentino-Kunden lautet die richtige Wahl FSDP2 – es sei denn, es gibt einen konkreten Grund für DeepSpeed (langer Kontext, CPU-/NVMe-Offload, MoE-Pretraining). Die Dynamik im Ökosystem weist eindeutig Richtung FSDP2.

Megatron-LM, Megatron-Core, NeMo – wo das schwere Gerät steht

Megatron begann 2019 als NVIDIAs Paper zu tensorparallelen Transformern. Heute hat die Familie drei Ebenen:

• Megatron-LM – die ursprüngliche Forschungs-Codebasis. Wird weiterhin genutzt und gepflegt.
• Megatron-Core – die modulare Bibliotheksvariante. Kombinierbare Bausteine für TP/PP/DP/EP/CP, Mixed Precision (FP16/BF16/FP8/FP4) und Referenz-Transformer-Architekturen. Das, was Sie tatsächlich integrieren.
• NVIDIA NeMo – das durchgängige Framework auf Basis von Megatron-Core. Rezepte, Datenpipelines, Alignment, Deployment.

Megatron-Core ist das Framework, das am oberen Ende gewinnt – und zwar genau deshalb, weil es Tensor-, Pipeline-, Sequenz-, Kontext- und Expertenparallelität in einem kombinierbaren Mesh umsetzt. Wer ein dichtes 405B-Modell auf mehr als 512 GPUs trainiert, kommt um die Kombination von mindestens dreien dieser Achsen nicht herum – und Megatron-Core ist die am häufigsten eingesetzte und am gründlichsten erprobte Kombination.

Die Megatron-Empfehlungen zur Parallelität für 2026 aus NVIDIAs eigener Dokumentation decken sich mit der Hardware-Realität:

Diese Tabelle erklärt, warum es Megatron gibt. Es ist das Framework, dessen Autoren mit genau jener Bandbreiten-Mathematik leben, die wir in N03 und K07beschreiben – und seine Rezepte sind darauf abgestimmt.

Wo Megatron überdimensioniert ist: bei jedem Single-Node-Fine-Tune, bei jedem Modell, das in FSDP2-freundlichen Speicher passt, bei jedem Workload ohne TP-Bedarf. Megatrons TP-Maschinerie ist tatsächlich schneller als selbstgebautes TP auf PCIe – aber TP auf PCIe bleibt langsam, siehe die Zahlen in K07. Seine Stärke spielt Megatron auf SXM-Hardware aus, die Kentino nicht baut.

Wo Megatron die richtige Antwort ist: beim Pretraining dichter Modelle von 70B bis 405B+ auf gemieteter oder eigener Hardware der NVLink-Klasse oder beim Aufbau produktiver Trainingsinfrastruktur für ein Forschungslabor. Wenn das auf Sie zutrifft, sind Sie vermutlich ohnehin schon im NeMo-Ökosystem unterwegs.

TorchTitan – die neue Referenz

TorchTitan ist Metas PyTorch-native Referenz für groß angelegtes Training, angenommen auf der ICLR 2025 und inzwischen das De-facto-Beispiel für die Frage: „Wie sollte ein Rezept aus TP × PP × FSDP2 × CP im Jahr 2026 aussehen?“ Es erfindet keine neue Parallelität – es kombiniert die Bausteine, die PyTorch ohnehin mitbringt (fully_shard, torch.distributed.tensor.parallel, pipelining, DTensor), zu einem sauberen, vierdimensionalen parallelen Trainingsskript mit asynchronem Sharded Checkpointing, torch.compileund Float8.

Warum es zählt, selbst wenn Sie es nicht direkt einsetzen:

• Es ist das kanonische Beispiel dafür, wie FSDP2 ohne Drittanbieter-Framework mit TP und PP zusammenspielt.
• Dieselben APIs stecken im Standard-PyTorch. Es gibt keinen Zaubertrick.
• AMD hat Ende 2025 einen für ROCm optimierten TorchTitan-Fork veröffentlicht; die im Oktober 2025 angekündigte Partnerschaft mit Lightning AI macht TorchTitan-Rezepte auf Lightning Studios lauffähig.

Für Kunden der Kentino-Klasse ist TorchTitan eher eine Referenz zum Nachlesen als ein Framework zum Ausrollen. Wenn Sie feinabstimmen, sind Accelerate oder Axolotl über FSDP2 ergonomischer. Wenn Sie in moderatem Maßstab (8–64 GPUs) auf Standardhardware pretrainieren, ist TorchTitan mit NeMo konkurrenzfähig und operativ deutlich leichtgewichtiger.

Die Framework-Matrix

Accelerate und Axolotl sind keine eigenständigen Parallelisierungsstrategien – sie umhüllen die oben genannten Backends. Die meisten Kentino-Kunden, die feinabstimmen, werden am Ende Axolotl über FSDP2 nutzen, ohne groß darüber nachzudenken. Und das ist richtig so.

Das Kommunikationsbudget – warum Ihr Netzwerk das Modell begrenzt

Querverweis: N08 führt durch die Mathematik von RDMA und Uplinks; hier geht es um die trainingsspezifische Sicht.

Bei Datenparallelität (DDP oder FSDP) ist die Kommunikation zwischen den Ranks pro Schritt in etwa proportional zur Parameteranzahl (zu reduzierende Gradienten). Bei Tensorparallelität ist sie proportional zu Aktivierungsgröße × Layer-Anzahl – pro Schritt um Größenordnungen mehr.

Faustregel für das Gradientenvolumen eines einzelnen Schritts bei BF16:

Allein das All-Reduce für 70B dauert auf einer 200-Gbps-Fabric 5.6 Sekunden. Wenn Ihr Forward plus Backward pro Schritt ebenfalls 5 Sekunden braucht, sind Sie bereits zu 50 % kommunikationsgebunden; bei 2 Sekunden Rechenzeit warten Sie zu über 70 % auf das Netzwerk. Genau deshalb würgt 100 GbE das Training ab 70B ab und Sie brauchen 400 GbE / NDR IB. Die Rechenleistung wächst weiter; das Netzwerk muss mithalten, sonst stehen die GPUs still.

FSDP2 verbirgt einen Teil davon durch Überlappung (das Einsammeln des nächsten Layers startet, während der aktuelle gerechnet wird). Hybrid Shard verbirgt mehr, indem es das Gradienten -All-Reduce in der schnellen knoteninternen Fabric hält und über die Knoten hinweg nur replizierte Gradienten reduziert. Die obigen Zahlen sind der Worst Case für Full-Shard-FSDP über Knoten hinweg ohne Überlappung.

Bei Tensorparallelität skaliert die Kommunikation pro Token mit Hidden Size und Layer-Anzahl. Die Zahlen in K07 zeigen warum: ~80 MB pro generiertem Token beim Decode, ~300 GB pro Prefill bei 70B und Batch 32. In diesem Bereich ist PCIe (realistisch 50 GB/s) rund 14× langsamer als NVLink (realistisch 700+ GB/s) – und hier funktioniert das Pretraining eines dichten Modells ab 70B auf PCIe schlicht nicht mit akzeptabler Effizienz.

Rezepte aus der Praxis

Fine-Tuning von Llama 8B auf einem 8-GPU-Knoten – FSDP2

Hardware: 8× RTX 5090 oder 8× RTX Pro 6000 Blackwell, EPYC-Host, keine knotenübergreifende Fabric nötig.

torchrun --standalone --nproc-per-node=8 \
  finetune.py \
    --model meta-llama/Llama-3.1-8B \
    --batch-size 1 --grad-accum 16 --seq-len 4096 \
    --bf16 --fsdp full_shard --fsdp-reshard-after-forward \
    --gradient-checkpointing --torch-compile

Zu erwarten: ~2000 Tok/s aggregiert bei BF16, passt bequem samt KV und Aktivierungen; Full-Shard-FSDP2 über PCIe Gen5 wickelt das Gradienten-All-Reduce innerhalb der Box ab. So sehen auch 90 % aller Fine-Tuning-Jobs bei Kentino aus.

Fine-Tuning von Llama 70B auf 2× 8-GPU-Knoten – FSDP2 Hybrid Shard

Hardware: 2× 8× RTX Pro 6000 Blackwell, 200 Gbps IB oder 100 GbE RoCE zwischen den Knoten.

torchrun --nnodes=2 --nproc-per-node=8 \
  --rdzv-backend=c10d --rdzv-endpoint=node0:29500 \
  finetune.py \
    --model meta-llama/Llama-3.3-70B \
    --batch-size 1 --grad-accum 32 --seq-len 4096 \
    --bf16 --fsdp hybrid_shard \
    --gradient-checkpointing --torch-compile \
    --activation-cpu-offload

Hybrid Shard behält Full Shard innerhalb jedes 8-GPU-Knotens bei und repliziert über die beiden Knoten. Die knotenübergreifende Fabric trägt nur das Reduce-Scatter der replizierten Gradienten – rund 70 GB pro Schritt bei BF16, etwa 3 s auf 200 Gbps IB. Die Überlappung verbirgt den größten Teil davon. Bei 100 GbE kostet derselbe Schritt ~5–6 s und die GPUs zeigen erste Leerlaufzeiten; das Rezept funktioniert weiterhin, nur mit längerer Epochendauer.

Pretraining von 405B auf 8× 8-GPU-Knoten – Megatron-Core 3D

Hardware: 8 Knoten mit je 8 GPUs, NVLink/SXM, 400 Gbps NDR IB. Nicht von Kentino gebaut – der Vollständigkeit halber.

# Megatron-Core launcher (abbreviated)
torchrun --nnodes=8 --nproc-per-node=8 \
  pretrain_gpt.py \
    --tensor-model-parallel-size 8 \
    --pipeline-model-parallel-size 8 \
    --sequence-parallel \
    --context-parallel-size 1 \
    --num-layers 126 --hidden-size 16384 --num-attention-heads 128 \
    --seq-length 8192 --micro-batch-size 1 --global-batch-size 2048 \
    --bf16 --use-flash-attn --transformer-impl transformer_engine

TP=8 × PP=8 = 64 Ranks pro Replik; 8 Knoten × 8 GPUs = 64 GPUs insgesamt, also exakt eine Replik. Für mehrere Repliken und damit höheren Durchsatz multiplizieren Sie mit DP. Hier spielt Megatron seine Stärke aus. Dasselbe Modell allein auf FSDP2 würde den Großteil seiner Zeit mit Kommunikation zwischen den Ranks verbringen; das 3D-Layout legt die schwerste Kommunikation (TP) in die NVLink-Domäne.

Die ehrliche Einschätzung für Kentino-Kunden

Die meisten Kentino-Kunden betreiben kein Pretraining. Sie stimmen Open-Weight-Basismodelle – Llama, Qwen, Mistral, gelegentlich Gemma – auf ihre Fachdaten ab, mal mit LoRA oder QLoRA, mal als vollständiges Fine-Tuning. Für diese Arbeit gilt bei der Framework-Wahl:

• Ein Modell, das bei BF16 samt Optimizer-State auf eine GPU passt. DDP verwenden. Kopien replizieren, um den Durchsatz zu steigern.
• Ein Modell, das nicht auf eine GPU passt, aber in Summe auf einen 8-GPU-Knoten. FSDP2 Full Shard verwenden. Das deckt Fine-Tunes von 8B bis 70B ab.
• Ein Modell, das in Summe auf zwei 8-GPU-Knoten passt. FSDP2 Hybrid Shard verwenden. Fine-Tunes von 70B bis 200B.
• Ein noch größeres Modell oder Pretraining von Grund auf. Das ist das Gespräch, in das Megatron-Core, SXM-Hardware und NDR IB gehören. Wir bauen den Storage und die Management-Ebene, aber die GPUs werden für diese Phase meist gemietet.

Die 10 % der Kunden, die wirklich eng gekoppeltes Multi-Node-Training brauchen, sind überwiegend Forschungslabore mit finanzierten Pretraining-Programmen – und die wissen vor dem Anruf, was sie benötigen. Den anderen 90 % sollte man keinen Cluster verkaufen, sondern einen gut spezifizierten 8-GPU-Knoten mit dem passenden Fabric-Stub für einen späteren zweiten Knoten, während die Netzwerktechnik als P2-Posten offenbleibt.

---

Dieser Beitrag ist Teil des Kentino Wiki, einer Referenzreihe zu KI-Compute, Robotik und den Systemen, die beides verbinden. Anmerkungen und Korrekturen sind willkommen unter info@kentino.com.