PAN 2 vs Hi3D v1.0: Två modeller som båda vägrar berätta hur stora saker och ting är

Ber du någon av dessa modeller om en värld är det första du förlorar linjalen. PAN 2 är Institute of Foundation Models världsmodell med öppna vikter och 29 miljarder parametrar, finns på Hugging Face som en Apache-2.0-checkpoint sedan 7 oktober 2026, med kod den 5 november och Day-0-stöd för vLLM-Omni den 10 november: ge den en startbild och en beskriven handling, och den renderar upp till tjugo sekunder 704×1248-video vid 24 bilder per sekund som visar konsekvensen. Hi3D v1.0, tidigare Sparc3D, är en geometriförfinare med öppna vikter som tillkännagavs den 23 oktober 2026 och som tar en bild plus ett grovt mesh och returnerar ett tätare sådant, endast för geometri, där varje resultat centreras om och normaliseras till enhetsradie. Den ena producerar en rörlig bild utan något måttanspråk; den andra producerar en statisk form där den absoluta skalan avsiktligt har tagits bort. Ingen av dem kommer att berätta för dig om saken framför dig är en meter bred, och båda är mer användbara när du slutar förvänta dig att de ska göra det.

Det gemensamma utelämnandet är den ärliga grunden för en jämförelse. Den vanliga inramningen – 3D kontra video, eller geometri kontra dynamik – är sann men inte till någon hjälp, eftersom den får valet att låta som en preferens. Den inramning som avgör något är vad varje modell ger dig, vad den kastar bort för att komma dit, och vad du tillåts göra med resultatet efteråt.

Vad var och en ger dig, punkt för punkt

Namnge utdataobjektet innan du namnger någon kapacitet, eftersom de två objekten inte är samma typ av sak.

• Indata — PAN 2 tar en valfri första bildruta plus en strukturerad aktionsbeskrivning som förfinats av en prompt-rewriter-färdighet; Hi3D v1.0 tar en bild och ett grovt mesh av samma objekt.

• Utdata — PAN 2 returnerar en MP4 på upp till tjugo sekunder; Hi3D returnerar vertexgeometri och inget annat, utan färg, utan textur, utan material och utan vertexfärg.

Tid — PAN 2 finns för att köras framåt, och varje klipp är en förutsägelse av en konsekvens; Hi3D har ingen tidsaxel alls och skulle för evigt returnera samma mesh för samma två indata.

• Skala — PAN 2 gör inget metriskt anspråk på något av det som renderas; Hi3D normaliserar varje resultat till enhetsradie och kastar medvetet bort den absoluta storleken.

• Batchform — PAN 2 renderar ett klipp per anrop; Hi3D kör med batchstorlek ett.

• Upplösning på utdata — PAN 2 renderar 704×1248 vid 24 bilder per sekund i upp till tjugo sekunder; Hi3D förfinar till en effektiv gles extraktionsrutnätsupplösning på upp till 1536°, vilket är en täthet av hörn snarare än ett pixelantal.

• Åtkomst — PAN 2 är 86,17 gigabyte över sextio filer, utan åtkomstbegränsning, Apache-2.0; Hi3D går att ladda ned under dess egen Hi3D Open License, royaltyfri för kommersiellt bruk med angivande av "Powered by Hi3D 1.0".

• Hårdvara – PAN 2:s dokumenterade standard är åtta H200 i BF16, med ett recept där tretton sekunders video tar ungefär 119 sekunder på fyra B300; Hi3D validerades på en enda 96 GB H20 utan någon CPU-inferensväg.

• Vad du själv kan kontrollera — PAN 2:s kort beskriver dess testramverk tillräckligt detaljerat för att man ska kunna argumentera emot: 300 fall med en enskild åtgärd över sex förmågekategorier, 100 flerstegsuppgifter som poängsätts utifrån slutförande av steg och av hela planen över tre slumpfrön, samt en blind parvis studie med tretton granskare; Hi3D:s kort anger att träningskod och artikelns utvärderingsramverk inte ingår i utgåvan, så dess kvalitetspåståenden kan inte köras om från nedladdningen.

De där nio raderna utgör hela köpbeslutet, och åtta av dem är beskrivningar av vad varje verktyg tar emot och returnerar snarare än påståenden om hur bra det är.

Numret som båda modellerna raderar, och varför

Hi3D:s normalisering är dokumenterad och lätt att missa: varje förfinad mesh centreras om och normaliseras till enhetsradie. Det är standardpraxis inom geometrinlärning, eftersom ett nätverk som måste regrediera absoluta koordinater slösar kapacitet på en skala som det skulle kunna få veta, och eftersom träningsset som sammanställts från skanningar och tillgångar sällan använder samma enheter. Det innebär också att ett mesh som kommer ut från Hi3D inte kan placeras i en scen i verklig storlek utan att du återapplicerar en skalfaktor som du måste känna till från någon annanstans. Den förfinade geometrin är metrikfri till sin konstruktion.

PAN 2:s utelämnande är subtilare och får mindre uppmärksamhet än det förtjänar. Modellen återger en fysiskt sammanhängande konsekvens – jordgubbsdemon, där byte av frukt eller vätska förändrar stänket, är den tydligaste formuleringen av idén som någon har åstadkommit – och den gör det utan att någonsin ange ett avstånd. Träningssignalen är video, utdata är video, och video har ingen inneboende skala: en närbild av ett fingerborg och en vid bild av en hink är samma tensor. Modellkortets egen lista över genvägar pekar på samma lucka från andra hållet, med pasta som dyker upp i durkslaget innan den är avrunnen – en scen som fortskred utan den fysik som skulle ha behövt inträffa.

Det är anledningen till att en körsimulator inte kan byggas av PAN 2, oavsett hur bra den blir på stänk. Ett vägnät behöver körfältsbredder i meter och lidarreturer i centimeter, och en modell vars hela representation av världen är latent video har ingenstans att lägga något av dem. Det är också anledningen till att Hi3D inte kan tillhandahålla de meterna: den förfinar formen hos ett enskilt objekt, i en skala som den har normaliserat bort, utifrån en bild som inte hade något djup i sig.

Om din pipeline behöver metriska utdata måste metriken komma in någonstans före endera modellen – från en djupgivare, en markör med känd storlek i bildrutan, en CAD-fil – och båda modellerna ligger nedströms om det beslutet i stället för att fatta det. Det är värt att säga rakt ut, eftersom alternativet är att ett team upptäcker det efter en veckas integration.

Redigerbarhet är den skillnad som överlever kontakten med ett projekt

Genererad video är en återvändsgränd för revidering. Om PAN 2 renderar en plan där en byrålåda öppnas och en kopp slås omkull, och du vill att byrålådan ska öppnas långsammare, redigerar du inte klippet; du skriver om bildtexten och betalar för ytterligare hundra framåtpassningar genom en 29B-transformator. Bildtexten är den enda redigerbara ytan, och den är verkligen bra – strukturerad, tidsförankrad, med handlingar bundna till aktörer och kamerarörelser utskrivna – men den verkar på nivån "vad som händer", inte "vart den här vertexen tar vägen".

Ett förfinat mesh är den motsatta typen av artefakt. Hi3D:s utdata öppnas i en modellerare, retopologiseras, textureras någon annanstans, placeras. Förfiningen är ett irreversibelt steg i en pipeline som annars är full av reversibla sådana, och det är precis vad ett innehållsteam vill ha: ett verktyg som förbättrar en blockout och sedan håller sig undan.

Här är sammansättningen som faktiskt finns, uttryckt utan att överdriva. En grov blockout som förfinas av Hi3D blir en detaljerad rekvisita; en scenbyggare placerar rekvisitan; en världsmodell i PAN 2-stil renderar vad som händer när något påverkar den. De två är närliggande steg, inte konkurrenter. Det som inte finns är en loop: Hi3D kan inte ta en PAN 2-bildruta och ge dig geometri tillbaka, eftersom en enda videobildruta utan djup och med okänd skala inte är ett mesh-problem som Hi3D byggdes för att lösa.

Den plats där ett routinglager gör nytta i den pipeline är det sammanbindande språkarbetet snarare än någon av modellerna. Att sätta bildtext på en rendering så att en simulator kan betinga sig på den, att skriva den strukturerade världstillståndsbeskrivning som PAN 2:s textkodare konsumerar med en budget på 1 480 token mjukt och 1 536 hårt, att bedöma om en genererad bildruta matchar briefen – det är vanliga mätta modellanrop, och de omger båda verktygen. OrcaRouter har fler än 200 modeller bakom ett enda API med 0 % påslag på leverantörens listpris, med automatisk redundansväxling mellan leverantörer, så att en bildtextskrivare och en renderingskritiker kan dela en nyckel och en reservväg. Varken PAN 2 eller Hi3D v1.0 finns i den katalogen och inget här antyder något annat: renderaren är din nod, förfinaren är din GPU, och det vi routar är limmet.

Två licenser som talar om vem kunden är tänkt att vara

Båda modellerna är öppna nog att ladda ner, och villkoren skiljer sig på ett sätt som är mer informativt än vikterna.

PAN 2 är Apache-2.0: inget attribueringskrav utöver licenstexten, ingen användartröskel, ingen intäktsfälla, ingen begränsning av användningsområde. Du kan finjustera det, kvantisera det, skeppa det inuti en produkt och inte säga något om det. För en diffusionstransformer med 29 miljarder parametrar som tränats från grunden på hundratals miljoner videor av ett universitetsanknutet labb är det ett ovanligt tillåtande val, och det är den största praktiska skillnaden mellan PAN 2 och de slutna världsmodeller som det brukar jämföras med.

{{1}}Hi3D v1.0{{/1}} är royaltyfritt för kommersiellt bruk med en "Powered by Hi3D 1.0"-attribution, och ett separat avtal träder i kraft vid fler än {{2}}200 000 månatliga aktiva användare{{/2}} eller mer än {{3}}1 miljon dollar i månatliga intäkter{{/3}}. Den gränsen är ett fingeravtryck: den säger att den avsedda kunden är en studio, en plattform eller en verktygsleverantör, och den säger att författarna förväntar sig att modellen ska bäddas in snarare än studeras. Under gränsen kostar det ingenting; över den förhandlar du.

Ingen av licenserna är en fälla. De är olika satsningar på vad öppenhet är till för: PAN 2:s är en satsning på att bli antagen som infrastruktur, Hi3D:s är en satsning på att bli antagen med en kommersiell dialog kopplad så snart man är tillräckligt stor för att ha en.

Hårdvarukostnaden, som inte är nära

Hi3Ds krav är strikta och billiga att uppfylla om du redan äger maskinen: Linux, Python 3.10, en NVIDIA-GPU med compute capability 8.0 eller högre, CUDA mellan 12.0 och 12.5, flash-attn utan reservväg, ingen CPU-inferens, validerat på en enda 96 GB H20. En studioworkstation klarar det. Felmoden är CUDA-låsningen och den saknade reservvägen, inte minnet.

PAN 2:s krav tillhör en annan kategori. Åtta H200:or i BF16 är den dokumenterade standarden, med VAE-patch-parallellism över fyra rutor ovanpå det, eftersom avkodning av ett tjugo sekunder långt 704×1248-klipp är ett minnesproblem i sig. Siffran på 119 sekunder för tretton sekunder på fyra B300:or kommer från vLLM-receptet, och det är siffran som gör varje designfråga till en räknefråga: femtio samplersteg vid en flow shift på 9 med guidance på 2,5 i varje steg är hundra forward-passar genom 29B-transformatorn per klipp, och en planerare som utvärderar fem kandidatåtgärder per steg i en tiostegsuppgift vill ha femtio klipp.

Kostnadsjämförelsen handlar inte om "vilket som är billigare". Det handlar om att en av dem är ett arbetsstationsverktyg och den andra en klusterarbetsbelastning, och ett team som har råd med det första kanske inte alls kan köra det andra. Den asymmetrin gör inte PAN 2 sämre. Den gör beslutet enkelt för alla vars GPU-budget är ett enda kort.

Vilken fråga du faktiskt ställer

Om ditt problem är att en blockout är för grov, eller att en skannad prop saknar fina detaljer, är Hi3D v1.0 verktyget och PAN 2 irrelevant — det finns inget i en videogenerator som ger dig vertices. Budgetera CUDA-stacken, kontrollera flash-attn-beroendet innan du lovar ett leveransdatum, och kom ihåg att meshen kommer med enhetsradie.

Om ditt problem är att du behöver se vad en åtgärd gör innan du förbinder dig till den – planutvärdering, kontrafaktiska data, en robot eller en agent som förhandsgranskar sina val – är PAN 2 den enda av de två som svarar, och den svarar i pixlar med ett överhoppat steg i ungefär två av tre planer enligt dess eget kort. Bygg in en kontroll i loopen, håll dina prompter inom tokenbudgeten och behandla varje klipp som en hypotes snarare än en mätning.

Om du behöver båda, bygg pipelinen i den ordning artefakterna faktiskt flödar: metrisk indata först, geometri som andra, konsekvens som tredje, och en språkmodell vid varje skarv där en representation måste bli en annan. Det är mer ingenjörsarbete än vad någon av modellernas tillkännagivanden antyder, och det är den form som varje seriös världsmodellstack för 2026 har landat i.

Det som skulle förändra den här sidan är en modell som producerar geometri med metrisk skala och en tidsaxel – en 4D-utdata med enheter. Inget i någon av utgåvorna pekar mot det. Tills något gör det är den korrekta sammanfattningen att PAN 2 visar dig vad som händer och att Hi3D skärper det som finns, att ingen av dem säger hur stor den är, och att den andra begränsningen är den som i tysthet avgör vilka av dina projekt som kan använda någon av dem.