Den nye Gemini-bildemodellen (aka "nanobanan") fungerer ganske bra og er veldig morsom å bruke med barna dine (jeg gjorde den ene til en dronning, den andre Blippi, på deres forespørsel). Den har imidlertid noen ganske rare begrensninger. Noen ganger får den likheten veldig nøyaktig. Andre ganger ser ansiktene helt ugjenkjennelige ut. Det ser ikke ut til å være mye av et mønster som jeg kan skjelne når det gjelder når det fungerer og når det mislykkes. Google har allerede ganske god teknologi for å gjenkjenne ansikter, siden de gjør dette i Google Bilder. Jeg lurer på hvorfor de ikke legger til et automatisk kvalitetskontrolltrinn som sjekker om ansiktet i det genererte bildet passer godt til ansiktet i originalbildet og prøver automatisk de som faller på nytt. Inkonsekvensen gjør at produktet føles mye mindre magisk. Det større problemet er at revisjoner av et bilde som har gått galt bokstavelig talt aldri fungerer. Den er helt ute av stand til å komme seg når den går ned en dårlig vei. Selv om revisjonene er ganske entydige og beskjedne. Føles nesten som "kontekstforgiftning" av noe slag. Dette virker som det mye mer alvorlige problemet med at dette er et produktivitetsverktøy som konkurrerer med Photoshop. Men kan sannsynligvis også løses ved å alltid gjøre flere generasjoner bak kulissene og gradere dem og bare vise den beste. De lar deg heller ikke regenerere ("rulle på nytt") et bilde, så du må starte en ny samtale hver gang. Dette er irriterende og forurenser samtaleloggen din. Men med alt det sagt, fungerer det ganske bra, og absolutt mye bedre enn den lignende funksjonaliteten i Facebook Messenger. Adobe må absolutt ha et svar på dette hvis de vil holde seg relevante.

Jeg kan ikke tro at jeg ventet så lenge med å bytte fra mypy til ty (fra produsenten av uv og ruff). Jeg tror jeg ble skremt av at det ble annonsert som "pre-release". Tull, det fungerer utmerket! Og det er bokstavelig talt hundrevis av ganger raskere enn mypy. Det er en kvalitativ forskjell.

Det er fint når et gammelt prosjekt du har laget blir delt et sted og du plutselig får en haug med nye stjerner på GitHub. Jeg har alltid syntes dette var et kult prosjekt, og jeg hadde noen virkelige gjennombrudd mens jeg gjorde det når det gjelder å bruke LLM-er på kreative nye måter:

Jeg gikk meg litt vill i alle akronymene og sjargongen her, så jeg fikk Claude til å forklare det uten å bruke noen akronymer, og nå gir det hele perfekt mening (tldr; båndbredde ⟹ enkelhet): Dette er en fascinerende teknisk diskusjon om trening av store språkmodeller i stor skala. Kjernesamtalen Jingyuan Liu uttrykker overraskelse over å oppdage at du ikke trenger visse komplekse optimaliseringsteknikker når du bruker TPU-er (Tensor Processing Units - Googles spesialiserte AI-brikker) kontra GPUer (Graphics Processing Units - vanligvis NVIDIAs brikker). Viktige tekniske konsepter forklart: Maskinvare typer: •GPU (Graphics Processing Unit): Opprinnelig designet for grafikk, nå mye brukt for AI. NVIDIA dominerer dette markedet. •TPU (Tensor Processing Unit): Googles spesialdesignede brikker spesielt for maskinlæring. Parallellisme strategier: Når du trener massive AI-modeller, må du dele arbeidet på tvers av mange brikker. Det er flere måter å gjøre dette på: 1) Dataparallellitet (DP): Hver brikke behandler forskjellige datapartier med samme modellkopi 2) Tensorparallellitet (TP): Modellens matematiske operasjoner er delt på brikker 3) Pipeline Parallelism (PP): Ulike lag av modellen er plassert på forskjellige brikker, og skaper en rørledning Den tekniske utfordringen som diskuteres: Hjelpetapsproblemet: Når du trener veldig store modeller, legger du ofte til "hjelpetap" (ekstra treningsmål) på mellomlag for å hjelpe gradienter til å flyte bedre gjennom nettverket. Under PPVP-begrensninger (Pipeline Parallelism with Variable Partitioning) blir dette komplisert fordi: •Du må gjøre "alle f alle b" (alle foroverpasseringer, deretter alle bakoverpasseringer) •Dette er utfordrende for topp minnebruk fordi du må lagre mellomliggende resultater DeepSeeks innovasjon: De utviklet et "auxfree bias"-design som tilsynelatende unngår å trenge disse hjelpetapene mens de fortsatt trener effektivt. Den overraskende avsløringen: Senioreksperten fortalte Jingyuan at med TPU-er i K2- eller DSV3-skala (dette er klyngekonfigurasjoner med hundrevis eller tusenvis av brikker), kan du oppnå utmerket MFU (Model FLOPs Utilization - i utgangspunktet hvor effektivt du bruker maskinvaren) UTEN å bruke Pipeline Parallelity. Hvorfor er dette overraskende? •Pipeline-parallellitet anses vanligvis som avgjørende for opplæring i stor skala •Det er en kompleks teknikk som krever nøye optimalisering •Å kunne unngå det forenkler alt betydelig Horace er forklaring: Han forklarer HVORFOR dette er mulig med TPU-er: Båndbreddefordelen: TPU-er og avanserte NVIDIA-klynger (som NVL72 - NVIDIAs nyeste 72-GPU-konfigurasjon med NVLink-sammenkoblinger) har så høy båndbredde mellom brikker at de kan håndtere kommunikasjonskravene uten Pipeline Parallelity. Den viktigste innsikten: •Pipeline-parallellitet er først og fremst nødvendig når du er "flaskehals på DP-kommunikasjon" (begrenset av hvor raskt du kan kommunisere under parallell datatrening) •Hvis du har nok båndbredde over et stort nok domene (sammenkoblet klynge), kan du bare bruke enklere parallellitetsstrategier •Dette fungerer "i veldig lang tid" - noe som betyr at du kan trene selv veldig store modeller uten å treffe grensene Intuisjonen: Tenk på det som et motorveisystem: •Tradisjonelle GPU-klynger er som å ha smale veier mellom byer, så du trenger kompleks ruting (Pipeline Parallelity) for å unngå trafikkork •TPU-klynger eller NVLink-tilkoblede GPUer er som å ha massive motorveier – du kan bare sende alt direkte uten fancy ruting Dette er en stor sak fordi Pipeline Parallelism er komplisert å implementere, feilsøke og optimalisere. Å kunne unngå det samtidig som man oppnår høy effektivitet gjør hele opplæringsprosessen mye enklere og mer pålitelig. Diskusjonen fremhever hvordan fremskritt innen maskinvaresammenkoblingsteknologi ("veiene" mellom brikker) fundamentalt kan endre programvarestrategiene som trengs for effektiv AI-opplæring.

Jeg gikk meg litt vill i alle akronymene og sjargongen her, så jeg fikk Claude til å forklare det uten å bruke noen akronymer, og nå gir det hele perfekt mening (tldr; båndbredde ⟹ enkelhet): Dette er en fascinerende teknisk diskusjon om trening av store språkmodeller i stor skala. Kjernesamtalen Jingyuan Liu uttrykker overraskelse over å oppdage at du ikke trenger visse komplekse optimaliseringsteknikker når du bruker TPU-er (Tensor Processing Units - Googles spesialiserte AI-brikker) kontra GPUer (Graphics Processing Units - vanligvis NVIDIAs brikker). Viktige tekniske konsepter forklart: Maskinvare typer: •GPU (Graphics Processing Unit): Opprinnelig designet for grafikk, nå mye brukt for AI. NVIDIA dominerer dette markedet. •TPU (Tensor Processing Unit): Googles spesialdesignede brikker spesielt for maskinlæring. Parallellisme strategier: Når du trener massive AI-modeller, må du dele arbeidet på tvers av mange brikker. Det er flere måter å gjøre dette på: 1Dataparallellitet (DP): Hver brikke behandler forskjellige datagrupper med samme modellkopi 2Tensorparallellitet (TP): Modellens matematiske operasjoner er delt på brikker 3Pipeline Parallelism (PP): Ulike lag av modellen er plassert på forskjellige brikker, og skaper en rørledning Den tekniske utfordringen som diskuteres: Hjelpetapsproblemet: Når du trener veldig store modeller, legger du ofte til "hjelpetap" (ekstra treningsmål) på mellomlag for å hjelpe gradienter til å flyte bedre gjennom nettverket. Under PPVP-begrensninger (Pipeline Parallelism with Variable Partitioning) blir dette komplisert fordi: •Du må gjøre "alle f alle b" (alle foroverpasseringer, deretter alle bakoverpasseringer) •Dette er utfordrende for topp minnebruk fordi du må lagre mellomliggende resultater DeepSeeks innovasjon: De utviklet et "auxfree bias"-design som tilsynelatende unngår å trenge disse hjelpetapene mens de fortsatt trener effektivt. Den overraskende avsløringen: Senioreksperten fortalte Jingyuan at med TPU-er i K2- eller DSV3-skala (dette er klyngekonfigurasjoner med hundrevis eller tusenvis av brikker), kan du oppnå utmerket MFU (Model FLOPs Utilization - i utgangspunktet hvor effektivt du bruker maskinvaren) UTEN å bruke Pipeline Parallelity. Hvorfor er dette overraskende? •Pipeline-parallellitet anses vanligvis som avgjørende for opplæring i stor skala •Det er en kompleks teknikk som krever nøye optimalisering •Å kunne unngå det forenkler alt betydelig Horace er forklaring: Han forklarer HVORFOR dette er mulig med TPU-er: Båndbreddefordelen: TPU-er og avanserte NVIDIA-klynger (som NVL72 - NVIDIAs nyeste 72-GPU-konfigurasjon med NVLink-sammenkoblinger) har så høy båndbredde mellom brikker at de kan håndtere kommunikasjonskravene uten Pipeline Parallelity. Den viktigste innsikten: •Pipeline-parallellitet er først og fremst nødvendig når du er "flaskehals på DP-kommunikasjon" (begrenset av hvor raskt du kan kommunisere under parallell datatrening) •Hvis du har nok båndbredde over et stort nok domene (sammenkoblet klynge), kan du bare bruke enklere parallellitetsstrategier •Dette fungerer "i veldig lang tid" - noe som betyr at du kan trene selv veldig store modeller uten å treffe grensene Intuisjonen: Tenk på det som et motorveisystem: •Tradisjonelle GPU-klynger er som å ha smale veier mellom byer, så du trenger kompleks ruting (Pipeline Parallelity) for å unngå trafikkork •TPU-klynger eller NVLink-tilkoblede GPUer er som å ha massive motorveier – du kan bare sende alt direkte uten fancy ruting Dette er en stor sak fordi Pipeline Parallelism er komplisert å implementere, feilsøke og optimalisere. Å kunne unngå det samtidig som man oppnår høy effektivitet gjør hele opplæringsprosessen mye enklere og mer pålitelig. Diskusjonen fremhever hvordan fremskritt innen maskinvaresammenkoblingsteknologi ("veiene" mellom brikker) fundamentalt kan endre programvarestrategiene som trengs for effektiv AI-opplæring.

Jeg er litt overrasket over at ingen ennå har laget en Dwarf Fortress MCP-server som kan tillate en agent som Codex eller Claude Code å effektivt kontrollere spillet og overvåke tilstanden og fremgangen. Jeg spilte det egentlig aldri selv, bare lastet det ned og sjekket det ut kort for rundt 10 år siden, men jeg likte å lese om det. Det føles som om det ville være en veldig god test av en LLM for å se hvor lenge det kan holde dvergene i live og trives. Fordi hvert spill til slutt resulterer i en kaskadekatastrofe som får alle dvergene til å dø, bør det være et naturlig stoppepunkt for det, noe som gjør det til en god referansekandidat. Det er i hvert fall min forståelse av det (spillernes motto er "Å tape er gøy"). Å gjøre en god jobb med disse spillene vil være avhengig av verktøykallende nøyaktighet og vedvarende sammenheng med lange oppgaver, pluss evnen til å overvåke og forstå dynamikken i et komplekst system og gjøre rettidige intervensjoner som forutser og motvirker problemer. Og fordi det er terminalt innfødt, kan det effektivt overføres og behandles ved hjelp av vanlige tokens uten å trenge multimodal bildebehandling, noe som vil gjøre det langt mer effektivt enn andre spill. I tillegg vet du at ingen AI-laboratorier har trent for dette (ennå!), så det er ubesmittet av "benchmaxxing."

En morsom ting å gjøre når du trenger å vente i noen minutter, er å bruke telefonen til å stille Claude Opus følgende spørsmål om en tilfeldig disiplin eller et felt: "Hva vil du si er kjerneinnsikten eller analytiske trikset til krystallografi?" Bytt ut krystallografi med alt du kan tenke deg. Så langt har jeg prøvd: QED; standardmodellen; Biokjemi; Sannsynlighet; Evolusjonsteori; og mange flere. Det er noe med å tvinge modellen til å gjøre det umulige, å kondensere et stort, komplekst felt til «ett merkelig triks», som får den til å virkelig søke etter det beste dype, samlende prinsippet i feltet og deretter artikulere det kortfattet. Dette har en tendens til å være noe som er åpenbart for utøvere, men som med stor sannsynlighet er ukjent for de fleste med bare en forbigående interesse for emnet. Interessant nok kan du også trykke gjentatte ganger på "prøv på nytt" -knappen med samme ledetekst og noen ganger få veldig forskjellige, men vanligvis veldig fascinerende forklaringer. Jeg har allerede lært MYE av å gjøre dette, og det kan bare være den høyeste "forståelsen per minutt" jeg har møtt i noen selvstyrt læring. Fordi de ikke bare er morsomme fakta eller kule godbiter. De er, ved konstruksjon, gjennomtrengende og forenende ideer som binder sammen en enorm mengde teori og observerte fenomener i verden. Det er absolutt mye mer høy båndbredde enn å se enda en YouTube-forklaringsvideo med animasjoner og annonser for Brilliant/KiwiCo! Ikke at det er noe galt med dem.

Ideen om at det har vært en slik "talentflukt" fra OpenAI nylig at de ikke lenger er posisjonert til å være ledende i rommet, er omtrent like misforstått og feil som ideen om at GPT-5 "var en stor flopp og modellen er ikke så stor og er veldig inkrementell." Ikke bare er GPT-5 Pro den smarteste modellen i verden nå i veldig stor grad på de mest utfordrende oppgavene i den virkelige verden (spesielt kodeoppgaver, som har størst økonomisk betydning nå), men det nye codex cli-verktøyet fra OpenAI er utrolig godt utført. De gikk fra en fjern 3.-plass i koding av cli-verktøy til å ha det som uten tvil er det beste som finnes nå (merk at jeg fortsatt liker og bruker Claude Code, det er ikke enten/eller!), med den desidert beste ytelsen, laveste ventetiden osv. Og nå er dette cli-verktøyet kombinert med den beste kodemodellen som har den beste påliteligheten for verktøyanrop og den beste sammenhengen for lange oppgaver, med minst mulig hallusinasjoner. Og unødvendig å si at iOS-appen deres også er dramatisk bedre enn alle andre AI-apper når det gjelder polering og funksjoner. Claude-appen er bare webappen i en Safari-sandkasse! Og webappen deres er også fortsatt den beste. Ting som søk fungerer bare bedre enn i andre apper. Grunnleggende blokkering og takling. Så, ja. Noen veldig smarte mennesker som Ilya og John Schulman dro til andre selskaper. Men de har fortsatt et helt fantastisk teknisk team med utrolig gode produktfolk og fantastiske ingeniører. Ikke la din avsky for Altman gjøre deg blind for det åpenbare. Hver gang jeg ser enda en person snakke om hvor dårlig GPT-5 er, kryper jeg sammen, fordi personen viser at de ikke kan tenke selv basert på bevis og fornuft, og ble medet til å tenke en mening (og spytte den ut på nettet) fordi de tror det får dem til å høres smarte ut.

Hvor kult er det at hver av de små brikkene har 8 terabyte superrask lagring? Og du kan koble dem begge til det blå kabinettet og få 20 Gbps over USB 3.3 (jeg har ingen USB 4-porter, og alle pci-e-sporene mine er okkupert av GPUer) Vi lever i en tid med slik overflod.

Som en oppdatering til mine to nylige tråder om bruk av GPT-5 Pro for å starte en prosess for å oppdage banebrytende teorier som kombinerer nye anvendelser av avansert matematikk AI-brukstilfellene, fikk jeg modellen til å lage demoimplementeringer i Python ved hjelp av Jax og Numpy for hver av de 11 ideene. Så satte jeg dem sammen i et prosjekt og la til en fin CLI for å kjøre dem, og en serie ende-til-ende-tester som målte om koden er matematisk korrekt, sjekker at koden har de matematiske egenskapene vi ønsker, og til slutt, om den gjør noe nyttig i forhold til dagens standardtilnærminger. Jeg brukte codex CLI med GPT-5 for å integrere alt og fikse og feil. Jeg vil lenke til repoen, som inneholder detaljert dokumentasjon for hele prosjektet og deretter oppskrifter for hver av de 11 demoene som inneholder alle utdataene generert av modellen under prosessen.