DeepSeek V4 je stigao, ovaj put sam zaista oduševljen (priložen tehnički analitički izveštaj).

Marko Marković2286 reči8 minuta

DeepSeek V4 (pregledna verzija), 1.6 trilion parametara V4-Pro, 284B parametara V4-Flash, nativni 1M kontekst, Agentic Coding evaluacija direktno usklađenje Opus 4.6.

Zato ovaj broj da povežemo DeepSeek V4 u PaiCLI. Može kroz /model deepseek prebaciti na DeepSeek V4, /model glm prebaciti na GLM-5.1.

Kao OpenClaw.

01, koje optimizacije DeepSeek V4 ima?

V4-Pro u Agentic Coding evaluaciji je već došao do open-source najboljeg nivoa, zvanični sud je "bolji od Sonnet 4.5, kvalitet isporuke približan Opus 4.6 ne-mislio način".

Prethodno DeepSeek V3.2 na početku svake nove korisničke poruke bi odbacio thinking trace, jednako model svaki krug ponovo misli. V4 promenjeno u sceni poziva alata kompletno zadržava sav reasoning content, uključujući preko korisničke poruke granice.

To znači, V4 može između više krugova poziva održavati akumulirane razmišljajuće tragove, koherentnost je mnogo bolja.

V4 podržava Non-think (intuitivni odgovor), Think High (logička analiza), Think Max (zaključak ekstrem) tri stepena. Jednostavna poziv alata ide Non-think, kompleksna analiza kôda će prebaciti na Think Max.

To znači isti model može između brzine i dubine fleksibilno prebacivati.

02, prebacivanje modela je vrlo jednostavno

Zato što GLM i DeepSeek API protokol su kompatibilni sa OpenAI i Anthropic.

Znali da ne treba za svaki model pisati potpuno nezavisni klijent. Samo treba obezbediti base_url, api_key i model.

Prvi korak, definiši jedinstven interfejs LlmClient.

Mi GLMClient.Message, GLMClient.ToolCall, GLMClient.ChatResponse sve stavimo na nivo interfejsa:

Dva chat metoda, jedan sa striming listener, jedan bez.

getModelName() vraća trenutno ime modela (npr. glm-5.1), getProviderName() vraća ime dobavljača (npr. deepseek).

reasoningContent je pripremljen za modele koji podržavaju chain-of-thought izlaz, GLM-5.1 i DeepSeek V4 podržavaju.

// Pre transformacije
public Agent(String apiKey) {
    this.llmClient = new GLMClient(apiKey);
    // ...
}

// Nakon transformacije
public Agent(LlmClient llmClient) {
    this.llmClient = llmClient;
    // ...
}

Interfejs definicija je gotova, sledeći korak je implementacija.

Zato koristimo metodu šablona, deljenu logiku izdvajamo u baznu klasu AbstractOpenAiCompatibleClient:

Tri apstraktna metoda——getApiUrl(), getModel(), getApiKey().

Bazna klasa zadužena za sastavljanje HTTP zahteva, parsiranje SSE itd., podklasa samo treba reći baznoj klasi "moja API adresa je šta, koji model koristim, moj ključ je šta".

Striming čitanje je takođe vrlo jednostavno.

Veliki model vraća tool_calls nije jednokratno daje kompletnan JSON, već parametre deli u mnogo malih fragmenata, komad po komad vraća.

Npr. parametar {"path": "/src/main/java"} može biti podeljen u tri delta: {"pa, th": "/src/m, ain/java"}.

ToolCallAccumulator zadužen da ove fragmente spaja:

private static final class ToolCallAccumulator {
    private String id;
    private final StringBuilder name = new StringBuilder();
    private final StringBuilder arguments = new StringBuilder();
}

Svaki delta dolazi, dodaje u odgovarajući StringBuilder. Nakon kompletnog prijema, koristi buildToolCalls metoda da akumulator pretvori u konačnu ToolCall listu.

HTTP klijent je deljen:

protected static final OkHttpClient SHARED_HTTP_CLIENT = new OkHttpClient.Builder()
        .connectTimeout(60, TimeUnit.SECONDS)
        .readTimeout(120, TimeUnit.SECONDS)
        .writeTimeout(60, TimeUnit.SECONDS)
        .build();

Koristi static final garantuje ceo JVM samo jedna OkHttpClient instanca. Zato što OkHttp interno održava connection pool i thread pool, više instanci će dovesti do gubitka resursa. I prebacivanje modela ne treba ponovo kreirati HTTP klijent, samo menja URL i ključ.

Imajući baznu klasu, GLMClient i DeepSeekClient postaju vrlo jednostavni:

DeepSeekClient je skoro isti, samo URL i default model se razlikuju:

Podklase imaju, ko da odlučuje kreiranje podklase?

Direktno u Main.java napišemo gomilu if-else?

Koristimo fabrični oblik:

create metoda prema ime dobavljača kreira odgovarajući klijent. createFromConfig metoda prvo pokušava default provider konfigurisan od strane korisnika, ako nije konfigurisan ili API Key nedostaje, po prioritetu pokušava redom.

03, /model komanda prebacuje model

Konfiguracija i fabrika su spremne, poslednji korak je dodati runtime prebacivanje sposobnost u CLI.

CliCommandParser dodao SWITCH_MODEL tip komande:

if (trimmed.equalsIgnoreCase("/model")) {
    return new ParsedCommand(CommandType.SWITCH_MODEL, null);
}
if (trimmed.regionMatches(true, 0, "/model ", 0, 7)) {
    return new ParsedCommand(CommandType.SWITCH_MODEL,
            trimmed.substring(7).trim());
}

/model bez parametara prikazuje trenutne informacije modela, /model glm ili /model deepseek prebacuje model.

Prilikom prebacivanja radi tri stvari:

Prvo, kroz fabriku kreira novi LlmClient. Ako target provider nema konfigurisan API Key, direktno javi grešku, neće izgubiti trenutno dostupan model.

Drugo, ažurira default provider i perzistira u config.json. Sledeći put kad pokreneš PaiCLI automatski će koristiti model koji si poslednji put birao.

Treće, kroz setLlmClient() hot replace Agent interni model klijent. Obrati pažnju ovde nije rekonstrukcija Agent-a, već in-place replace——istorija razgovora, registry alata, menadžer sećanja sve zadržava. Tako dok koristiš GLM do pola mislis dovoljno dobro, možeš direktno prebaciti na DeepSeek nastavi, novi model može videti prethodni kontekst razgovora. Ako hoćeš čistu poređenje, ručno /clear jedan put.

Implementacija u Agent-u je vrlo jednostavna, llmClient polje iz final promenjivo u promenjivo, setLlmClient istovremeno ažurira referencu unutar MemoryManager:

public void setLlmClient(LlmClient llmClient) {
    this.llmClient = llmClient;
    this.memoryManager.setLlmClient(llmClient);
}

Korišćeni dizajn oblici su tri:

Strategijski oblik: LlmClient interfejs je strategija. Agent ne zna da li koristi GLM ili DeepSeek, on samo zavisi od LlmClient interfejsa. Runtime kroz /model komandu menja implementaciju strategije.

Metoda šablona: AbstractOpenAiCompatibleClient je šablon. Skeleton logika (HTTP zahtev, SSE parsiranje) u baznoj klasi je upisana, podklasa samo treba popuniti getApiUrl(), getModel(), getApiKey() tri metoda.

Fabrični oblik: LlmClientFactory enkapsulira logiku kreiranja klijenta.

Strategijski oblik upravlja "prema kome programirati", metoda šablona upravlja "kako ponovno iskoristiti zajedničku logiku", fabrični oblik upravlja "kako kreirati objekat".

04, garantuj dva modela su pravedna

Nakon povezivanja dva modela, prva misla sigurno je——pusti ih da trče isti zadatak uporede.

Ali ovde postoji jedna laka zamka: ako dva modela primaju različit kontekst, rezultat poređenja nema smisla.

Prvi, system prompt potpuno konzistentan. Dva modela primaju sistemski prompt isti SYSTEM_PROMPT, ne menja se sa promenom modela. Memory pretraga injektovani kontekst ide istom putanjom.

private void updateSystemPromptWithMemory(String memoryContext) {
    if (memoryContext == null || memoryContext.isEmpty()) {
        conversationHistory.set(0, LlmClient.Message.system(SYSTEM_PROMPT));
    } else {
        String enrichedPrompt = SYSTEM_PROMPT + "\n" + memoryContext;
        conversationHistory.set(0, LlmClient.Message.system(enrichedPrompt));
    }
}

Drugi, istorija razgovora default zadržava, ručno prazna. /model deepseek prilikom prebacivanja modela, PaiCLI neće rekonstruisati Agent, već kroz setLlmClient() in-place menja model klijent, istorija razgovora zadržava. Ako hoćeš čisto poređenje, nakon prebacivanja modela ručno /clear obriši istoriju razgovora.

reactAgent.setLlmClient(llmClient);
// kontekst razgovora je zadržan, koristi /clear možeš obrisati

Treći, definicija alata potpuno isti. toolRegistry.getToolDefinitions() vraćena lista alata ne zavisi od modela, GLM i DeepSeek primaju opis alata, definicija parametara potpuno isti. Dva modela suočavaju se sa istim "alat kutijom".

Četvrti, razlika u tretmanu reasoningContent-a. Ovo je jedino gde dva modela ponašaju se različito. DeepSeek V4 u sceni poziva alata će zadržati kompletnan reasoning_content, dok GLM-5.1 chain-of-thought ponašanje nije isto. Ali LlmClient.Message-ovo reasoningContent polje je jedinstveno——dva modela razmišljaju sadržina ide istim poljem za čuvanje i prenos, neće zbog različitog modela biti izgubljena ili format drugačiji.

// Odgovora oba modela idu istu record strukturu
record ChatResponse(String role, String content, String reasoningContent,
                    List<ToolCall> toolCalls, int inputTokens, int outputTokens)

05, isti zadatak, dva modela trče kako izgleda

Rekoh mnogo, direktno trčimo jednu stvarnu scenu vidimo.

Zadatak je da PaiCLI analizira projekat pom.xml, pronađe core zavisnosti i daje kratak opis. Ovaj zadatak upravo može pokriti poziv alata (read_file) i generisanje teksta dva dela, može istovremeno poređeti strategiju korišćenja alata i kvalitet odgovora.

Prvo koristi GLM-5.1:

✅ Učitano model: glm-5.1 (glm)
🔄 Koristi ReAct mod

👤 Ti: čitaj pom.xml reci mi koji core zavisnosti projekat koristi

Prebaci na DeepSeek V4:

👤 Ti: /model deepseek
✅ Prebačeno na: deepseek-v4-flash (deepseek)

👤 Ti: čitaj pom.xml reci mi koje core zavisnosti projekat koristi

Potrošnja Token poređenje:

GLM-5.1: 2719 ulaz / 511 izlaz / 3230 ukupno | ⏱ 22.4s
DeepSeek V4: 3028 ulaz / 648 izlaz / 3676 ukupno | ⏱ 19.2s

06, rastavi DeepSeek V4 tehnički izveštaj

Ovaj deo sam tražio od Claude Opus 4.6 da mi pomogne žvakati DeepSeek zvanični tehnički izveštaj, plus moja sposobnost učenja, ako ima grešaku svi mogu istaći, zajednički učimo (sebično.

Hybrid Attention

V4 je kontekst doveo do nativnog 1M, core se oslanja na jedan set hibridne pažnje dizajn.

Svi znamo standard Transformer pažnja kalkulacija je O(n²), 1 milion token tvrdo računa ne može izdržati. V4 rešenje je veoma pametno——pošto puna pažnja ne može, onda promišljaj.

Prvi je CSA (Compressed Sparse Attention). Prvo susednih nekoliko token kompresuje zajedno (Flash verziji svaki 4 token kompresuje jedan blok), onda svaki query samo bira najrelevantnijih nekoliko stotina kompresovanih blokova gleda. Analogijom, 1 milion token prvo kompresuje u 250 hiljada blokova, onda iz njih samo bira 512 blokova računa pažnju, ekvivalentno samo gledao originalni hiljaditi deo, kalkulacija pada off stenom.

Drugi je HCA (Heavily Compressed Attention). Kompresija granulacija je mnogo veća od CSA (Flash verzija svaki 128 token kompresuje jedan blok), beneficija je može koristiti pune pažnje——ne bira ne odbacuje, svaki query gleda sve kompresovane blokove. Kao koristi ultra-nisku rezoluciju kameru radi celokupno monitoring, detalji su mutni ali neće propustiti velike trend promene.

CSA je zadužen za precizno preuzimanje daljih informacija, HCA je zadužen za održavanje celokupnog grubog razumevanja. Još svaki sloj nosi klizni prozor grana specijalno procesira obližnje token-e, sprečava kompresiju da lokalni kontekst odnos izgubi.

Koliko je ušteđeno?

Prema tehničkom izveštaju podacima, pod 1M dužinom, V4-Pro inferencija računar potrošnja je pala na V3.2 manje od tri decenije, VRAM u KV keš je manje od desetine. Flash verzija je još teža, računar pao na jednu deceniju, keš pao ispod jedne decenije.

Šta znači?

Više krugova ReAct loop, model može se setiti više puta razgovorne istorije i rezultate alata.

Tri stepa mislio način kako je treniran

Prethodno pomenuto V4 podržava Non-think, Think High, Think Max tri stepa.

Treniranje metode V4 je napravio hrabru paradigmu promenu: post-treniranje faza više ne koristi prethodni V3.2 onaj set hibridnog reinforcement learning, promenjeno u jedan metoda koji se zove On-Policy Distillation (OPD).

Prvi korak, po domenu (matematika, kôd, Agent, instrukcija praćenje itd.) svaki treniraj specijalizovan model, svaki domén još podeljen tri tipa inferencija budžeta: brza intuitivna verzija za kraki prozor, srednje mislio verzija za 128K prozor, duboka inferencija verzija direktno daje 384K prozor da model misli dovoljno.

Drugi korak je ključan. Koristi OPD da sve domene specijalizovane modele kombinuje u jedan jedinstven učenik model. I tradicionalne destilacije razlika je, učenik ne uči na podacima nastavnika, već dok sam generiše sadržinu, istovremeno se poravnjuje sa izlaz distribucijom više nastavnika. Suštinski je bliži jedan online optimizacija strategije.

Jednostavan read_file poziv ide Non-think dovoljno, brzina je brza, štedi token. Naiđe kompleksnu analizu kôda zadatak, model automatski dodaje duboko mislio. API nivo kroz reasoning_effort parametar kontroliše, prema Claude Code ovakav kompleksan Agent zahtev još automatski diže na Max.

Infrastruktura ovaj put je vrlo dostojna

V4 tehnički izveštaj infrastrukturi posebno napisao jedan celo poglavlje, ovo u veliki model izveštaj je vrlo retko, znači DeepSeek ovaj put u inženjerskoj strani mnogo radio.

Biram par koji mislim da su zanimljivi pričaj:

Inferencija ubrzanje kernel MegaMoE. MoE arhitektura najveća glavobolja je komunikacija trošak između stručnjaka, DeepSeek na svom DeepGEMM osnovi napravio veliku granulaciju fusion kernel, dispatch, kalkulacija, combine sinteziše jedan korak. Stvarno test dnevna inferencija ubrzanje pet do sedam deset, reinforcement learning faza onaj mali batch long-tail zahtev čak može brzo dva puta. I ovaj kernel istovremeno prilagođen N karti i Huawei Ascend.

Ponovljivu kalkulaciju. Izveštaj puno truda govori o determinizmu: isti set podataka promeni redosled rasporeda, ili isti input trči dva puta, rezultat mora biti bit-level identičan. Od pre-treniranja do post-treniranja do inferencija, tri faze numerički potpuno poravnata. Ova stvar zvuči jednostavno, stvarno na distribuiran GPU realizovati mnogo truda, ali za rešavanje treniranje bug i garantovanje model konzistentnost je vrlo ključno.

KV keš disk. Pošto prethodna dva pažnja već kompresovala KV vrlo malo, onda direktno kompresovani keš sačuvaj na disk. Sledeći zahtev ako pogodi isti prefiks, direktno sa diska čita, izbjegava dupliranje kalkulacije. Klizni prozor onaj deo zato što je volumen mnogo veći, dao je pun keš, redovno snapshot, ne sačuvaj direktno preračunavaj tri opcionalne sheme. Ovaj dizajn daje 1M kontekst u ograničenom VRAM može trčiti.

Agent treniranje sandbox DSec. Ovaj me najiznenađenije. DeepSeek za treniranje Agent napravio specijalan sandbox sistem, jedan klaster može istovremeno trčati stotine hiljada izolovanih okruženja. Najpametnije je treniranje prekid povratak dizajn——kada zadatak je preempted sandbox ne aktivno uništava, nakon povratka direktno od breakpoint nastavlja, neće ponoviti one operacije koje ne mogu biti idempotentne (npr. komanda koja je već upisala u bazu podataka).

PaiCLI kako da napišeš na CV?

Naziv projekta: PaiCLI — Java Agent CLI

Projekat opis: Baziran na ReAct paradigmi od nule realizovan Java Agent naredbeni alat, integrisan Plan-and-Execute, Memory, RAG, Multi-Agent, HITL ljudsko odobrenje, asinhrono paralelno i multi-model runtime prebacivanje, kompletno pokriva AI Agent core tehnički stek.

Core odgovornosti:

Baziran na strategijskom obliku dizajnirao LlmClient jedinstven interfejs, GLMClient interne tipove (Message, ToolCall, ChatResponse) dignuo na nivo interfejsa zajednički tip, realizovao potpunu dekopljiciju Agent sloja i model implementacije sloja
Koristi metod šablona realizovao AbstractOpenAiCompatibleClient baznu klasu, deljena SSE striming parsiranje, zahtev konstrukcija i poziv alata inkrementalno spajanje logika, dodavanje model adaptacije samo treba 20 linija podklasa kôd
Kroz fabrični oblik LlmClientFactory enkapsulirao kreiranje klijenta, kombinovao tri-sloj konfiguraciju fallback (config.json → promenljiva okruženja → .env fajl), podržava runtime /model komandu jedno-klik prebacivanje GLM-5.1 i DeepSeek V4
U Agent izvršnom loop integrisao Token potrošnja statistiku, akumulira svaki krug LLM poziva ulaz/izlaz token broj i trajanje, pogodno za različit model trošak i performanse poređenje