Mistral Large 3: Δοκιμή, αξιολόγηση, πληροφορίες και τεχνικά χαρακτηριστικά

Γιατί το Mistral Large 3 με έκανε να σηκώσω φρύδι (με την καλή έννοια)

Αν μου έλεγαν πριν λίγα χρόνια ότι θα κατεβάζω “frontier-level” μοντέλο, με βάρη ανοικτά, άδεια Apache 2.0, multimodal (κείμενο+εικόνα) και context 256K tokens, θα απαντούσα κάτι μεταξύ «ναι, και ο Άρης είναι Airbnb» και «στείλε benchmark ή μην ξαναμιλήσεις».

Κι όμως, το Mistral Large 3 εμφανίστηκε ακριβώς ως αυτό: ένα μοντέλο που πατάει γερά στην κορυφή των open-weight LLMs, χωρίς να σου ζητάει να υπογράψεις συμβόλαιο με τον διάβολο (ή με το vendor lock-in).

Το ενδιαφέρον δεν είναι μόνο “πόσο καλό είναι”. Είναι τι αλλάζει επιχειρησιακά:

• Μπορώ να το αξιοποιήσω σε regulated περιβάλλον, γιατί έχω επιλογές on‑prem και έλεγχο της ροής δεδομένων.
• Μπορώ να το τρέξω σε ένα σύγχρονο 8×GPU node (με τις σωστές βελτιστοποιήσεις/ποσοτικοποιήσεις), αντί να χρειάζομαι μικρό data center.
• Μπορώ να χτίσω σοβαρά συστήματα: RAG, agents, function calling, δομημένη έξοδο, OCR pipelines — όλα πάνω σε ένα μοντέλο με τεράστιο context.

Και επειδή η αγορά είναι γεμάτη “θαύματα”, εδώ έβαλα στόχο να το δω τεχνικά: αρχιτεκτονική, εκπαίδευση, επιδόσεις, κόστος, και — το πιο κρίσιμο — πώς το βάζεις σε παραγωγή χωρίς να καείς.

Μικρή ιστορία: από Mixtral σε Mistral 3, και γιατί το “open-weight” έχει σημασία

Η Mistral AI έπαιξε από νωρίς με την ιδέα ότι η Ευρώπη μπορεί να έχει LLMs που δεν εξαρτώνται από μαύρα κουτιά. Το Mistral Large 3 είναι ουσιαστικά η φιλοσοφία αυτή που “κλειδώνει” τεχνικά: open weights + permissive άδεια + ανταγωνιστική απόδοση.

Το μοντέλο ανήκει στην οικογένεια Mistral 3, όπου βλέπουμε και τα μικρότερα Ministral 3B / 8B / 14B (dense Transformers) να συνυπάρχουν με το flagship Large 3 (sparse MoE). Αυτό δεν είναι απλώς marketing. Είναι σωστή μηχανική προϊόντος: άλλο μοντέλο για interactive chat υψηλής ποιότητας, άλλο για batch extraction, άλλο για edge-ish περιπτώσεις, άλλο για “μεγάλη βαριά” κατανόηση εγγράφων.

Πίνακας 1 — Οικογένεια Mistral 3 (σύνοψη τεχνικών χαρακτηριστικών)

Το “trick” εδώ είναι ότι το Large 3 έχει 675B συνολικές, αλλά 41B ενεργές ανά token — και αυτό επηρεάζει απόδοση και κόστος με τρόπο που αξίζει ξεχωριστό κεφάλαιο.

Sparse MoE στα σοβαρά: πως 675B παράμετροι δεν σημαίνουν 675B κόστος

Ας το πω ωμά: τα dense LLMs έχουν ένα πρόβλημα—η αύξηση παραμέτρων αυξάνει FLOPs, latency και κόστος με τρόπο που δεν συγχωρεί.

Το Mixture‑of‑Experts είναι ένας πρακτικός συμβιβασμός: κρατάς μεγάλη “χωρητικότητα γνώσης”, αλλά δεν την ενεργοποιείς όλη σε κάθε token.

Πως δουλεύει (σε επίπεδο μηχανικής)

Σε ένα MoE layer υπάρχουν πολλοί “experts” (συνήθως FFN υποδίκτυα). Ένας router (gating network) αποφασίζει ποιοι experts θα επεξεργαστούν το συγκεκριμένο token. Έτσι, αντί να περνάς πάντα από όλους, περνάς από λίγους.

• Συνολικές παράμετροι: 675B (όλο το σύστημα experts + shared components)
• Ενεργές ανά token: ~41B (μόνο οι experts που επιλέγονται + shared)
• Άρα, υπολογιστικά, συμπεριφέρεται σαν πολύ μεγάλο μοντέλο σε “γνώση”, αλλά σαν 40–50B dense σε κόστος inference (χονδρικά).

Διάγραμμα 1 — MoE routing (απλουστευμένο ASCII)

textToken embeddings
      |
      v
 +-----------+        top-k experts         +-------------------+
 |  Router   |----------------------------->| Expert #3 (FFN)    |
 | (Gating)  |----------------------------->| Expert #7 (FFN)    |
 +-----------+                              +-------------------+
      |                                              |
      +------------------- merge (weighted sum) <-----+
                          |
                          v
                    Next layer

Best practices που κοιτάω σε MoE serving

1. Load balancing: Αν ο router στέλνει τα πάντα στους ίδιους experts, θα δεις bottlenecks. Θέλεις routing που κρατάει ισορροπία.
2. Expert parallelism: Σε multi‑GPU node, μοιράζεις experts έτσι ώστε να μην “πνίγεις” μία GPU.
3. KV cache management: Με 256K context, η cache είναι ο πραγματικός ελέφαντας στο δωμάτιο.

Αυτός είναι και ο λόγος που η βελτιστοποίηση σε kernels (attention/MoE) είναι τόσο κρίσιμη: δεν αρκεί να “τρέχει”, πρέπει να τρέχει καλά.

Εκπαίδευση από το μηδέν σε κλίμακα exascale: τι σημαίνει πρακτικά

Το Mistral Large 3 εκπαιδεύτηκε from scratch σε μεγάλο cluster NVIDIA GPUs, περίπου 3.000 H200. Αυτό μεταφράζεται σε δύο πράγματα:

1. Υπάρχει σοβαρή επένδυση σε data pipeline (καθαρισμός, dedup, quality filtering).
2. Υπάρχει σοβαρή επένδυση σε distributed training (tensor/sequence/expert parallelism, checkpointing, optimizer state sharding).

Τι θεωρώ “σωστό” training pipeline για τέτοια κλίμακα (και γιατί έχει σημασία στο τελικό μοντέλο)

Χωρίς να χρειάζεται να ξέρουμε κάθε λεπτομέρεια του dataset, οι βέλτιστες πρακτικές σήμερα για frontier pretraining συνήθως περιλαμβάνουν:

• Aggressive deduplication (για να μειώσεις overfitting και benchmark leakage).
• PII scrubbing (GDPR reality check: αν φτιάχνεις enterprise μοντέλο, δεν παίζεις).
• Quality classifiers πάνω σε web corpora (φιλτράρισμα spam/low-signal).
• Multilingual balancing (ώστε να μη γίνει το μοντέλο “αγγλοκεντρικό με προφορά”).
• Code & math curriculum: σταδιακή αύξηση δυσκολίας/μορφής προβλημάτων.
• Post‑training: instruction tuning, preference optimization (τύπου DPO/IPO), safety tuning.

Το αποτέλεσμα φαίνεται: το μοντέλο βγαίνει με πολύ καλή συμπεριφορά σε καθημερινά prompts και υψηλή χρηστικότητα, ακόμη κι αν δεν είναι το απόλυτο “ολυμπιονίκης” στα δυσκολότερα reasoning benchmarks.

Context 256K tokens: δεν είναι “ωραίο feature”, είναι αλλαγή αρχιτεκτονικής εφαρμογών

Το 256K context window αλλάζει τον τρόπο που σχεδιάζω συστήματα. Δεν μιλάμε για “χωράει λίγο παραπάνω κείμενο”. Μιλάμε για:

• πλήρη συμβόλαια/νομικά κείμενα,
• ολόκληρα manuals,
• μεγάλες αναφορές risk/compliance,
• αρκετό κομμάτι από codebase για πραγματικό code review.

Πού κολλάει τεχνικά το 256K

Το κόστος attention μεγαλώνει έντονα με το μήκος (κλασικά O(n²) στη naive μορφή). Στην πράξη, το serving βασίζεται σε:

• βελτιστοποιημένους attention kernels,
• paged KV cache (π.χ. λογική τύπου vLLM),
• προσεκτική διαχείριση prefill vs decode,
• ποσοτικοποίηση (NVFP4/FP8/FP16 ανάλογα hardware).

Και εδώ είναι το ζουμί: “μεγάλο context” ≠ “δεν χρειάζομαι RAG”

Το λέω γιατί το βλέπω συνέχεια να παρεξηγείται. Ναι, το 256K μειώνει την ανάγκη για επιθετικό chunking. Όχι, δεν ακυρώνει:

• τη φρεσκάδα δεδομένων,
• την ιχνηλασιμότητα (citations στο εσωτερικό σύστημα),
• τον έλεγχο πρόσβασης (ABAC/RBAC),
• την ακρίβεια σε factual QA.

Εγώ αντιμετωπίζω το 256K ως “μεγαλύτερο buffer” που μου επιτρέπει πιο ευγενικό RAG: λιγότερα chunks, καλύτερα sections, περισσότερη συνοχή.

Multimodal (κείμενο + εικόνα): από “βλέπει” σε “καταλαβαίνει έγγραφα”

Το Mistral Large 3 είναι native multimodal για εικόνες, με ενσωματωμένο vision encoder περίπου 2.5B παραμέτρων. Αυτό πρακτικά σημαίνει ότι δεν μιλάμε για “ένα OCR δίπλα”· μιλάμε για μοντέλο που μπορεί να:

• διαβάσει screenshot,
• καταλάβει layout,
• απαντήσει σε ερωτήσεις πάνω σε διάγραμμα,
• κάνει extraction από πίνακες/φόρμες.

Διάγραμμα 2 — Τυπικό OCR + Document QA pipeline με Large 3

textPDF/Screenshot
   |
   v
[Vision Encoder] --> visual tokens
   |                    |
   +-------- concat -----+
            |
            v
     [LLM Core (MoE)]
            |
            v
  JSON extraction / QA / Summary

Πού το χρησιμοποιώ πρακτικά

• KYC / onboarding: εξαγωγή πεδίων από ταυτότητες/έντυπα (με ανθρώπινη επιβεβαίωση).
• Invoice processing: γραμμές προϊόντων, VAT, IBAN.
• Tech support: screenshot error messages, logs σε εικόνα, UI states.

Best practice που επιμένω: όταν κάνεις extraction, ζήτα δομημένη έξοδο (JSON schema) και κράτα confidence flags / “needs_review”. Multimodal μοντέλα είναι ισχυρά, αλλά δεν είναι λογιστές.

Benchmarks & αξιολόγηση: πού είναι κορυφή και πού κρατάω μικρό καλάθι

Στην αξιολόγηση LLMs, δεν με νοιάζει να “κερδίσει” σε ένα benchmark. Με νοιάζει να ξέρω:

• τι είδους λάθη κάνει,
• πόσο σταθερό είναι,
• τι latency/κόστος έχει,
• αν συνεργάζεται καλά με εργαλεία (function calling / agents).

Με βάση τα διαθέσιμα αποτελέσματα που έχουν δημοσιευτεί ευρέως για το Large 3, η εικόνα είναι ξεκάθαρη: πολύ δυνατό generalist, εξαιρετικό σε καθημερινές εργασίες και coding, αλλά όχι ο απόλυτος βασιλιάς στα πιο σκληρά reasoning τεστ.

Πίνακας 2 — Ενδεικτικά αποτελέσματα και δείκτες που χρησιμοποιώ για positioning

Η “πνευματώδης” αλήθεια των benchmarks

Τα benchmarks είναι σαν τα crash tests: χρήσιμα, αλλά δεν σου λένε αν το αυτοκίνητο είναι άνετο στην Αττική Οδό με μποτιλιάρισμα. Γι’ αυτό, εγώ κάνω και behavioral testing:

• αντιφατικές οδηγίες,
• πολλαπλά constraints (format + policy + business rules),
• “μην εφεύρεις στοιχεία” + έλεγχος αν όντως σταματάει.

Εκεί συνήθως κρίνεται αν θα μπει παραγωγή.

Απόδοση & κόστος: γιατί το NVFP4 και τα kernels είναι η μισή ιστορία

Το Large 3 έχει σχεδιαστεί ώστε να είναι cost‑efficient. Σε API επίπεδο, η τιμολόγηση που έχει κυκλοφορήσει ως σημείο αναφοράς είναι περίπου:

• $0.5 / 1M input tokens
• $1.5 / 1M output tokens

Αυτό είναι επιθετικό, και βγάζει νόημα μόνο αν το serving είναι σωστά βελτιστοποιημένο.

NVFP4 / FP8 / FP16 — πότε τι

• NVFP4: πολύ χαμηλή ακρίβεια, αλλά τρομερό throughput σε κατάλληλο hardware και kernels. Θέλει προσοχή σε regression tests.
• FP8: συχνά sweet spot για production όταν θες καλή σταθερότητα.
• FP16/BF16: ασφαλές, αλλά πιο ακριβό.

Σε κλίμακα, εγώ δεν κοιτάω μόνο tokens/sec. Κοιτάω:

• p95 latency,
• time-to-first-token,
• throughput υπό φόρτο (concurrency),
• σταθερότητα μορφοποίησης (ιδίως σε JSON mode).

Μικρό παράδειγμα κόστους (για να μιλάμε με νούμερα)

Αν μια ροή RAG κάνει ανά αίτημα:

• 12K input tokens (context + query + system)
• 1K output tokens

Τότε, με τις παραπάνω τιμές:

• input: 12K / 1M × $0.5 = $0.006
• output: 1K / 1M × $1.5 = $0.0015
• σύνολο ≈ $0.0075 ανά αίτημα

Αυτό επιτρέπει πράγματα που πριν “πονούσαν” (π.χ. να κάνεις extraction σε χιλιάδες έγγραφα τη μέρα χωρίς να ζητάς αύξηση προϋπολογισμού με δάκρυα).

Self‑hosting σε 8×GPU node: τι χρειάζεται για να μην γίνει άσκηση νευροχειρουργικής

Το Mistral Large 3 έχει παρουσιαστεί ως μοντέλο που μπορεί να τρέξει σε ένα σύγχρονο 8×GPU node, αξιοποιώντας κατάλληλες ποσοτικοποιήσεις και kernels. Αυτό δεν σημαίνει “το σηκώνω στο workstation μου”.

Σημαίνει ότι: με σωστό setup, δεν χρειάζεσαι multi‑node tensor parallelism για βασικές παραγωγικές χρήσεις.

Πού πονάει πραγματικά το 256K: KV cache

Η μνήμη δεν καταναλώνεται μόνο από τα weights. Με μεγάλο context, το KV cache γίνεται dominant. Για να το διαχειριστώ:

• χρησιμοποιώ paged KV (πρακτικά απαραίτητο),
• βάζω όρια context ανά use case (π.χ. 64K για chat, 256K για batch doc QA),
• εφαρμόζω request bucketing και limits ανά tenant.

Πίνακας 3 — Προτεινόμενο “sizing mindset” (ενδεικτικό, όχι ευαγγέλιο)

Αν κάποιος πάει “όλα 256K παντού”, αργά ή γρήγορα θα τον βρει η πραγματικότητα (και ο λογαριασμός GPU).

Serving stack που εμπιστεύομαι: vLLM, TensorRT‑LLM, Kubernetes και λίγη πειθαρχία

Δεν υπάρχει “ένα” σωστό stack, αλλά υπάρχει σωστή λογική: μετρήσιμη απόδοση, παρατηρησιμότητα, και ασφαλή συμβόλαια διεπαφής.

Διάγραμμα 3 — Παραγωγική αρχιτεκτονική (υψηλού επιπέδου)

textClients
  |
  v
API Gateway (Auth, Rate limits, WAF)
  |
  +--> Prompt Router (policy, tenant config, model selection)
          |
          +--> LLM Serving (vLLM or TensorRT-LLM)
          |        |
          |        +--> KV Cache / GPU memory
          |
          +--> Tools (Search, DB, Internal APIs)
          |
          +--> Observability (OTel traces, logs, metrics)

Τι κρατάω ως best practice (τρέχουσα εποχή)

• OpenTelemetry για traces (ιδίως tool calls).
• Κλειδωμένες εκδόσεις runtime:
  • Python 3.11/3.12 για serving apps,
  • CUDA runtime συμβατό με driver stack του cluster,
  • σταθερή έκδοση inference engine (π.χ. vLLM σε pinned minor).
• Canary deployments ανά μοντέλο/quantization profile.
• Golden prompts + regression suite σε κάθε release.
• JSON schema validation στην έξοδο όταν κάνω extraction.

Σε LLM συστήματα, τα “μικρά” engineering λάθη γίνονται ακριβά πολύ γρήγορα.

Function calling, δομημένη έξοδος και agents: εκεί που το Large 3 γίνεται εργαλείο, όχι παιχνίδι

Το Large 3 λάμπει όταν το χρησιμοποιείς όχι σαν “μίλα μου”, αλλά σαν συστατικό σε pipeline.

Παράδειγμα 1 — Structured extraction με JSON Schema (Python)

Παρακάτω δείχνω ένα μοτίβο που χρησιμοποιώ συχνά: ζητάω καθαρά JSON, το περνάω από validator, και κάνω retry αν χρειαστεί.

Pythonimport json
from jsonschema import validate, ValidationError

schema = {
    "type": "object",
    "properties": {
        "invoice_id": {"type": "string"},
        "supplier_vat": {"type": "string"},
        "total_amount": {"type": "number"},
        "currency": {"type": "string"},
        "needs_review": {"type": "boolean"},
        "notes": {"type": "string"},
    },
    "required": ["invoice_id", "total_amount", "currency", "needs_review"],
    "additionalProperties": False,
}

def parse_and_validate(text: str) -> dict:
    data = json.loads(text)
    validate(instance=data, schema=schema)
    return data

# Σε παραγωγή: εδώ θα καλέσω το endpoint του μοντέλου (API ή self-hosted),
# ζητώντας "output strictly valid JSON".
# Αν αποτύχει το validation: retry με πιο αυστηρό prompt ή lower temperature.

Το “μυστικό” δεν είναι το schema. Είναι ότι δεν εμπιστεύομαι ποτέ το μοντέλο χωρίς validator όταν παίζουμε με επιχειρησιακά δεδομένα.

Παράδειγμα 2 — Agentic loop (tool χρήση με guardrails)

Σε agents, η βέλτιστη πρακτική είναι:

• περιορισμένα tools,
• σαφές permissioning,
• logging κάθε κλήσης,
• budget (max tool calls, max tokens).

Pythonfrom dataclasses import dataclass

@dataclass
class ToolResult:
    ok: bool
    payload: dict

def search_kb(query: str) -> ToolResult:
    # Εδώ θα μπει αναζήτηση σε vector DB ή enterprise search.
    return ToolResult(ok=True, payload={"hits": [{"title": "Policy A", "text": "..." }]})

def agent_step(user_question: str) -> dict:
    # 1) αποφάσισε αν χρειάζεται tool
    # 2) κάλεσε tool
    # 3) ξανακάλεσε LLM με τα αποτελέσματα
    # (αφήνω τα LLM calls εκτός για συντομία)
    res = search_kb(user_question)
    if not res.ok:
        return {"answer": "Δεν μπορώ να ανακτήσω δεδομένα αυτή τη στιγμή.", "sources": []}
    return {"answer": "Απάντηση βασισμένη σε KB", "sources": res.payload["hits"]}

Το Large 3, με μεγάλο context, βοηθάει στο να χωράει:

• system policy,
• tool results,
• conversation,
  χωρίς να “στριμώχνεις” τα πάντα σε 8K και να ελπίζεις.

Ακρίβεια, hallucinations και safety: πως το βάζω σε παραγωγή χωρίς να παριστάνω τον ήρωα

Κανένα LLM δεν είναι “αλάθητο”. Το Large 3 έχει πολύ δυνατή γενική απόδοση, αλλά σε δείκτες τύπου factual QA/hallucination (όπως μετρώνται σε ορισμένα τεστ) δεν είναι το μοντέλο που θα διαλέξω αν ο στόχος μου είναι “μηδέν λάθος ποτέ”.

Η λύση δεν είναι να το απορρίψεις. Η λύση είναι να το δέσεις σωστά.

Πρακτικές που εφαρμόζω (και θεωρώ σύγχρονες best practices)

1. RAG με πειθαρχία
   • retrieval με φίλτρα πρόσβασης (RBAC/ABAC),
   • μικρός αριθμός ποιοτικών πηγών,
   • απαίτηση να απαντά “δεν βρέθηκε” όταν δεν υπάρχει τεκμηρίωση.
2. Grounding templates
   Απαντά μόνο με βάση τις παρεχόμενες πηγές. Αν δεν επαρκούν, ζητά διευκρίνιση.
3. Post-generation validators
   • JSON schema,
   • regex για πεδία,
   • αριθμητικοί έλεγχοι (π.χ. σύνολα τιμολογίων).
4. Red teaming & eval harness
   • δοκιμές prompt injection,
   • δοκιμές data exfiltration,
   • adversarial inputs σε OCR.
5. GDPR & data minimization
   • αποφυγή αποθήκευσης raw prompts όπου δεν χρειάζεται,
   • hashing/ανωνυμοποίηση σε logs,
   • retention policies.

Το ωραίο με open-weight είναι ότι μπορείς να κάνεις και on‑prem deployments για να λύσεις μεγάλο κομμάτι του “πού πάνε τα δεδομένα μου;”.

Η δική μου τελική ετυμηγορία: πού ταιριάζει το Mistral Large 3 και πως το αξιοποιώ στρατηγικά

Το Mistral Large 3 είναι, κατά τη γνώμη μου, ένα από τα πιο πρακτικά “μεγάλα” μοντέλα που κυκλοφόρησαν με ανοιχτά βάρη και permissive άδεια. Ο συνδυασμός:

• Sparse MoE (675B total / 41B active),
• 256K context,
• multimodal εικόνα+κείμενο,
• Apache 2.0,
• σοβαρή δουλειά σε serving optimizations (NVFP4, σύγχρονοι kernels),

το κάνει ιδανικό για οργανισμούς που θέλουν:

• ισχυρή ποιότητα χωρίς εξάρτηση από κλειστό provider,
• ευελιξία ανάπτυξης (cloud ή on‑prem),
• εφαρμογές εγγράφων μεγάλης κλίμακας (νομικά/συμμόρφωση/finance),
• coding copilots σε controlled περιβάλλον.

Που δεν το “προτείνω” ως ιδανική λύση

• Σε hardcore multi‑step reasoning χωρίς εργαλεία/verification: θα βάλω agent loop, tool χρήση ή θα περιμένω/επιλέξω reasoning‑specialized variant.
• Σε factual κρίσιμες αποφάσεις χωρίς grounding: πάντα RAG + validators.

Και το πιο σημαντικό: είναι μοντέλο που “στέκεται” αρχιτεκτονικά

Δεν είναι απλώς ένα ακόμη checkpoint. Είναι μια πλατφόρμα πάνω στην οποία μπορείς να φτιάξεις προϊόντα, όχι demo.

Infographic (για ελεύθερη χρήση) — SVG διάγραμμα MoE + Long Context

Το παρακάτω είναι δικό μου SVG, μπορείς να το χρησιμοποιήσεις ελεύθερα (πρακτικά CC0/χωρίς περιορισμούς).

svg<svg xmlns="http://www.w3.org/2000/svg" width="980" height="360" viewBox="0 0 980 360">
  <defs>
    <style>
      .box{fill:#0b1220;stroke:#7aa2ff;stroke-width:2;rx:12;ry:12}
      .txt{fill:#e6edf7;font-family:Inter,Segoe UI,Arial;font-size:16px}
      .sub{fill:#b9c7e6;font-family:Inter,Segoe UI,Arial;font-size:13px}
      .arrow{stroke:#7aa2ff;stroke-width:2;marker-end:url(#m)}
    </style>
    <marker id="m" markerWidth="10" markerHeight="10" refX="6" refY="3" orient="auto">
      <path d="M0,0 L6,3 L0,6 Z" fill="#7aa2ff"/>
    </marker>
  </defs>

  <!-- Input -->
  <rect x="30" y="40" width="240" height="90" class="box"/>
  <text x="50" y="75" class="txt">Είσοδος</text>
  <text x="50" y="102" class="sub">Κείμενο έως 256K tokens</text>

  <!-- Vision -->
  <rect x="30" y="160" width="240" height="90" class="box"/>
  <text x="50" y="195" class="txt">Εικόνα (προαιρετικά)</text>
  <text x="50" y="222" class="sub">Vision encoder ~2.5B</text>

  <!-- Router -->
  <rect x="330" y="95" width="240" height="120" class="box"/>
  <text x="350" y="135" class="txt">Router (Gating)</text>
  <text x="350" y="165" class="sub">Επιλογή top‑k experts ανά token</text>

  <!-- Experts -->
  <rect x="640" y="40" width="300" height="70" class="box"/>
  <text x="660" y="82" class="txt">Experts (MoE FFNs)</text>

  <rect x="640" y="130" width="300" height="70" class="box"/>
  <text x="660" y="172" class="txt">Active params ~41B/token</text>

  <rect x="640" y="220" width="300" height="70" class="box"/>
  <text x="660" y="262" class="txt">Total params 675B (capacity)</text>

  <!-- Arrows -->
  <line x1="270" y1="85" x2="330" y2="130" class="arrow"/>
  <line x1="270" y1="205" x2="330" y2="175" class="arrow"/>
  <line x1="570" y1="155" x2="640" y2="75" class="arrow"/>
  <line x1="570" y1="155" x2="640" y2="165" class="arrow"/>
  <line x1="570" y1="155" x2="640" y2="255" class="arrow"/>

  <!-- Footer -->
  <text x="30" y="330" class="sub">
    Στόχος: Frontier συμπεριφορά (γνώση/ποιότητα) με κόστος inference κοντά σε ~40–50B dense, μέσω sparse ενεργοποίησης experts.
  </text>
</svg>

Διάβασε επίσης την αξιολόγηση και την παρουσίαση των μοντέλων τεχνητής νοημοσύνης Gemini 3 pro και Claude Opus 4.5.