Kimi K2.5: bilion parametrów, natywne vision i rój agentów
Techniczna analiza Kimi K2.5: MoE 1T/32B, 15T tokenów multimodalnych, MoonViT, 256K context, natywne INT4, Agent Swarm i wdrożenie.
- AUTOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLIKACJA
- 27 stycznia 2026
- CZAS CZYTANIA
- 16 min czytania
- TEMAT
- Bezpieczeństwo AI
Kimi K2.5 był jednym z najważniejszych otwartych modeli początku 2026 roku, ponieważ połączył natywną multimodalność, architekturę Mixture-of-Experts i eksperymentalny Agent Swarm. Moonshot AI udostępnił wagi, raport techniczny i kod wdrożeniowy, dzięki czemu architekturę można analizować dokładniej niż zamknięty endpoint API.
Model ma około 1 biliona parametrów łącznie, ale dla pojedynczego tokena aktywuje około 32 miliardy. Składa się z 61 warstw, 384 ekspertów i wybiera osiem ekspertów na token; posiada też eksperta współdzielonego. Kontekst ma 256K tokenów, mechanizm uwagi wykorzystuje MLA, a encoder wizji MoonViT ma 400 mln parametrów. Te liczby pochodzą z model card projektu — opisują konstrukcję, a nie gwarantowaną jakość każdej odpowiedzi.
Co oznacza „natywnie multimodalny”
K2.5 powstał przez continual pretraining na około 15 bilionach mieszanych tokenów tekstowych i wizualnych na bazie Kimi-K2-Base. Obraz nie jest tylko zewnętrznym OCR-em dołączonym do modelu tekstowego. Reprezentacje obrazu i języka uczestniczą we wspólnym treningu, co ma wspierać reasoning zakotwiczony w elementach UI, dokumentach, wykresach i klatkach wideo.
Praktyczny scenariusz to „coding with vision”: użytkownik pokazuje layout, screenshot błędu albo wideo procesu, a model generuje kod i dobiera narzędzia do obróbki danych wizualnych. To zwiększa użyteczność, ale także powierzchnię ataku. Obraz może zawierać niewidoczne dla człowieka instrukcje, dane osobowe albo treść próbującą wpłynąć na agentowy workflow.
MoE: bilion parametrów nie oznacza biliona obliczanego naraz
Router MoE wybiera niewielki podzbiór ekspertów dla tokena. Dzięki temu model może mieć ogromną pojemność, a koszt jednego kroku jest bliższy aktywnym 32B niż pełnemu 1T. Nie oznacza to, że model jest łatwy do uruchomienia na jednej karcie. Trzeba przechować wagi, obsłużyć routing, komunikację między GPU i duży KV cache dla długiego kontekstu.
Moonshot udostępnił natywną kwantyzację INT4 i wymienił vLLM, SGLang oraz KTransformers jako wspierane ścieżki. W produkcji trzeba mierzyć nie tylko tokens/s, lecz time-to-first-token, inter-token latency, cache hit rate, pamięć per request i zachowanie przy wielu jednoczesnych agentach. Benchmark jednego promptu nie opisuje systemu wieloużytkownikowego.
Agent Swarm: równoległość z rachunkiem za koordynację
Agent Swarm dekomponuje złożone zadanie na podzadania wykonywane przez dynamicznie tworzone role. Równoległość może skrócić czas researchu, analizy repozytorium albo przetwarzania wielu źródeł. Nie jest to osobny model o magicznej inteligencji — wynik zależy od orchestratora, narzędzi, budżetu, sposobu scalania i kontroli jakości.
Każdy dodatkowy agent powiększa:
- liczbę tokenów i wywołań narzędzi;
- ryzyko niespójnych założeń;
- liczbę credentiali i endpointów w zasięgu;
- trudność odtworzenia decyzji;
- potrzebę rate limitów, timeoutów i anulowania.
Rój powinien mieć centralny policy enforcement, osobne scope’y narzędzi, limity kosztu i obowiązek przedstawienia artefaktów źródłowych. Nie wolno przekazywać wszystkim subagentom jednego szerokiego klucza chmurowego.
Jak oceniać wyniki z model card
Moonshot porównuje K2.5 z GPT-5.2, Claude 4.5 Opus, Gemini 3 Pro i DeepSeek V3.2 na benchmarkach reasoning, vision, coding i agentic search. Część wyników konkurentów została odtworzona przez autora, a różne modele używały różnych trybów reasoning. To wartościowy punkt startowy, lecz nie ranking absolutny.
Przed wdrożeniem zbuduj własny eval:
- reprezentatywne zadania PL i EN;
- poprawność cytowań i pracy z obrazem;
- odporność na prompt injection w screenshotach i dokumentach;
- skuteczność tool use oraz procent błędnych akcji;
- koszt całego zadania swarm, nie jednego calla;
- powtarzalność przy kilku seedach;
- zachowanie po przekroczeniu budżetu lub awarii narzędzia.
Bezpieczne wdrożenie lokalne i API
Wagi pobieraj z oficjalnego repozytorium, pinuj revision i weryfikuj hash. Uruchamiaj model w oddzielonej sieci inferencyjnej, a narzędzia przez gateway z allowlistą. Obraz i wideo traktuj jak niezaufane dane. Loguj decyzje routera narzędzi, ale nie zapisuj bezterminowo pełnych promptów z danymi klientów.
Dla API Moonshot stosuj osobne klucze per środowisko, limity kosztu i politykę retencji zgodną z aktualną dokumentacją. Dla self-hosted uwzględnij poprawki vLLM/SGLang, bezpieczeństwo formatu wag i kontrolę dostępu do endpointu zgodnego z OpenAI — kompatybilny protokół nie oznacza kompatybilnego modelu zagrożeń.
Projekt referencyjny dla produkcyjnego roju
Bezpieczna architektura nie łączy modelu bezpośrednio z narzędziami. Żądanie powinno najpierw trafić do warstwy tożsamości i klasyfikacji danych, następnie do planera bez uprawnień wykonawczych, a dopiero potem do brokera narzędzi. Broker sprawdza schemat argumentów, tenant, dozwolone zasoby, budżet oraz to, czy akcja wymaga zatwierdzenia. Każdy worker dostaje krótkotrwały token ograniczony do jednego podzadania. Wynik wraca do niezależnego walidatora, który nie dziedziczy pamięci ani instrukcji wykonawcy.
W telemetrii rozdziel prompt_id, plan_id, agent_id, wywołanie narzędzia i artefakt końcowy. Pozwala to ustalić, który agent wprowadził błędne założenie, bez przechowywania pełnej treści w logu. Alarmuj na gwałtowny wzrost fan-outu, powtarzające się wywołania, próby dostępu poza allowlistą i skok kosztu względem mediany dla danego typu zadania.
Testy awarii ważniejsze od dema
Przed produkcją zasymuluj niedostępność jednego workera, częściową odpowiedź narzędzia, sprzeczne rezultaty dwóch agentów, przekroczenie limitu oraz unieważnienie credentiala w połowie pracy. Orchestrator powinien zakończyć zadanie w kontrolowanym stanie, wskazać brakujące dowody i nie ponawiać mutacji bez klucza idempotencji. W przypadku operacji na danych lub chmurze kompensacja musi wynikać z kodu procesu, nie z improwizacji modelu.
K2.5 warto zestawić z bezpieczeństwem agentów AI, routerami modeli i rejestrem modeli. Jeśli chcesz porównać jakość, koszt i ryzyko na własnych danych, BreachRoad może przygotować techniczny eval.
Źródła pierwotne: Moonshot AI — Kimi K2.5, raport techniczny w repozytorium.


