MOSS-Image vs HY-Image 3.5: Båda säljer renderad text till dig, och bara en visar dig testet

Fråga vilken av leverantörerna som helst vad deras bildmodell egentligen är till för, och du får samma svar. M​OSS-Image, som släpptes av OpenMOSS den 16 oktober 2026 som Apache 2.0-checkpointarna M​OSS-Image-Base och M​OSS-Image-SFT, profilerar sig med textrendering och layout. H​Y-Image 3.5, Tencent:s nuvarande bildmodell inom Hunyuan-serien, profilerar sig med förbättrad noggrannhet för text som renderas i bilden – både på kinesiska och engelska. Två leverantörer, fem tusen engelska mil ifrån varandra, som väljer att marknadsföra samma förmåga, vilket är en rimlig signal om var kategorins verkliga felmod har varit under de senaste två åren.

De två påståendena kommer emellertid i helt olika förpackningar. Ett av dem kommer med ett benchmark och en siffra. Det andra kommer med en mening. Den asymmetrin – inte bildkvaliteten, som ingen har mätt för dessa två – är hela jämförelsen, och den är värd att gå igenom noggrant eftersom siffran som finns är leverantörens egen, och meningen som inte finns kommer från en leverantör med längre historia.

Vad "text rendering" betyder på varje sida

Tencents påstående är ett påstående om korrekthet i två skriftsystem. HY-Image 3.5 uppges förbättra noggrannheten hos text som ritas inuti bilden, och materialet säger uttryckligen att detta omfattar kinesiska och engelska. Det är ett snävare och mer praktiskt påstående än det låter. Kinesiska är det skriftsystem som västerländska bildmodeller hanterar sämst — glyftätheten är högre, teckenuppsättningen omfattar tusentals snarare än dussintals, och en modell som återger trovärdiga latinska bokstavsformer kan rendera helt påhittade kinesiska tecken utan att någon märker det förrän en korrekturläsare gör det. En leverantör vars hemmamarknad skriver kinesiska har en uppenbar anledning att angripa det först, och Tencent har sagt det rakt ut.

OpenMOSS påstående handlar om längd snarare än täckning av skriftsystem. M​OSS-Images främsta demonstration är stycken — litterär text med en genomsnittlig mållängd på ungefär 1 340 tecken som hålls läsbar över en bild. Det är ett annat problem än att få fyra kinesiska tecken rätt. Det är skillnaden mellan att rendera ett ordmärke och att rendera en sida.

• Vad leverantören lyfter fram – MOSS-Image: rendering av långformad text, med layout som kontrollmekanism. HY-Image 3.5: textnoggrannhet på kinesiska och engelska, med motivkonsistens vid upprepade redigeringar.

• Vad gränssnittet ger dig — MOSS-Image: en JSON-prompt med ett summary-block och en items-array, där varje textelement har en bounding box och den exakta strängen som ska renderas. HY-Image 3.5: en prompt i naturligt språk, plus referensbilder för redigeringsriktningen. Inget dokumenterat strängfält per element.

• Vad utdatataket är — M​OSS-Image: tränad över 576, sedan 3 072, sedan 8 192 tokens över tre upplösningar, med det sista steget på ungefär 1024². H​Y-Image 3.5: upp till 2K, med T​encents egna ord.

• Vad som styr vikterna — MOSS-Image: Apache 2.0, inget intäktströskelvärde. HY-Image 3.5: inget publicerat. Ingen checkpoint, ingen lokal licens, ingen offline-väg.

• Vad du betalar — M​OSS-Image: inget för licensen. H​Y-Image 3.5: 0,024 USD för en 2K-bild på den internationella slutpunkten, 0,15 JPY inrikes, faktureras endast för levererade utdatabilder.

Den där fjärde punkten förtjänar en egen mening, eftersom det är det enda i den här matchningen som du kan agera på idag. Om textrendering är anledningen till att du väljer mellan dessa modeller, kan du bara granska beteendet hos en av dem på din egen maskin. Att testa M​OSS-Image på din egen kopia innebär att ladda ner 27,2 GB och köra den; att testa H​Y-Image 3.5 innebär att skicka prompter till T​encent och titta på vad som kommer tillbaka.

Det enda talet i den här jämförelsen, och vad det är värt

M​OSS-Image har ett benchmark. LongLongTextBench är 240 uppgifter för litterär textrendering – 120 engelska, 120 kinesiska – med en genomsnittlig mållängd på 1 339,8 tecken, och OpenMOSS ger M​OSS-Image 96,3 i Mean-6-texttäckning mot 64,9 för Q​wen-Image-2512. Samma tabell placerar GPT Image 2 på 99,0 och N​ano Banana Pro på 96,6, vilket är värt att notera två gånger: det är en tabell där en konkurrent vinner, och det är en tabell där M​OSS-Images marginal över modellen den slår är större än dess underskott gentemot modellerna före den.

Nu till förbehållen, som inte är små. LongLongTextBench är OpenMOSS eget benchmark, byggt för den här utgåvan, kört av OpenMOSS, på OpenMOSS eget system. Mean-6-texttäckning är OpenMOSS eget mått. Ingen utanför labbet har reproducerat något av det. Det är den första leverantörssiffran i den här kategorin som överhuvudtaget försöker mäta lång text, och det är också precis den typ av siffra som en leverantör tar fram när den har något att visa.

H​Y-Image 3.5 har inget tal här överhuvudtaget. Inte ett publicerat, och inte ett oberoende — ingen testpanel betygsätter någon av dessa två modeller när det gäller textrendering, och de oberoende paneler som faktiskt har T​encents modell testar inte text. Så textfrågan, som är det båda leverantörerna valde att gå i spetsen med, är den enda frågan som den här jämförelsen inte kan besvara med bevis från båda sidor. En leverantör publicerade ett test. Den andra publicerade ett påstående. Det är läget, och varje text som sätter en siffra bredvid H​Y-Image 3.5 på den här axeln har hittat på den.

Där oberoende bevis faktiskt finns, och det är bara halva jämförelsen

Tencents modell finns på Artificial Analysis tavlor under beteckningen HunyuanImage 3.5 (Preview), vilket i sig är användbart eftersom det bekräftar namngivningen: etiketten preview är modellens nuvarande tillstånd, inte ett historiskt. Identifieraren i omlopp är hy-image-v3.5-preview, och ingen andra, stabil identifierare finns vid sidan av. På text-till-bild-tavlan rankas den i mitten av fältet med 976,02 Elo. På bildredigeringstavlan hamnar den i den översta femtedelen, med 1 088 Elo över 5 775 blinda jämförelser — ledarna där är OpenAIs GPT Image 2.5 Sunburst och Flare med 1 198 respektive 1 177, så Tencent ligger omkring 110 Elo under frontlinjen med intervall på ungefär ±14.

Den redigeringsplaceringen är den intressanta för den här jämförelsen, och inte på grund av rankningen. Det är tavlan som delvis täcker den förmåga T​encent faktiskt gör reklam för. Att upprepade gånger redigera ett motiv utan att det driftar är den andra halvan av T​encents pitch om text och konsekvens, och ett redigerings-Elo i den översta femtedelen är åtminstone löst förenligt med påståendet om konsekvens. Det är inte en mätning av text, och det är inte en mätning av drift över en sekvens, men det är oberoende, vilket är mer än vad något på M​OSS-Image-sidan har.

M​OSS-Image finns inte med på de resultattavlorna. Den är en dag gammal. Dess andra benchmark, RealLayoutArena, består av 61 designuppgifter som bedöms genom blind parvis jämförelse och anpassas till en Bradley–Terry-skala – 20 affischer, 20 infografiker, 21 gränssnitt – och det medföljer även utgåvan och byggdes även av leverantören. På end-to-end-arenan får M​OSS-Image 1698,70 i Elo, näst efter GPT Image 2:s 1844,35; begränsat till enbart stommen under gemensamma förbättrade prompter tar den förstaplatsen med 1807,34. Samma utgåva, samma part, samma förbehåll.

Kinesiska, vilket är där de två påståendena faktiskt möts

Här är en strukturell skillnad som ingen av leverantörerna kommer att peka på och som betyder mer än någon av benchmark-raderna.

OpenMOSS byggde ett tvåspråkigt textbenchmark som medvetet är balanserat — 120 engelska uppgifter och 120 kinesiska uppgifter, en jämn fördelning. Det är ett designval, och det säger att modellen utvärderades som en tvåspråkig produkt snarare än en engelsk med kinesiska som bonus. MOSS-Images träningskorpus kom från ReLAION-härledd data som trimmats från ungefär 5B sampel till 3B utan ytterligare filtrering, och layoutformatets items-array tar en etikett av text, character eller object — en taxonomi som med avsikt framstår som skriptagnostisk.

Tencents position är spegelbilden. Kinesiskan är hemmamarknaden; produktmaterialet beskriver modellen som att den erbjuder stark förståelse för kinesiska; den internationella slutpunkten är en andra yta bakom den inhemska, med separat prissättning. Tencent behövde inte bygga ett balanserat engelsk-kinesiskt benchmark eftersom kinesiska aldrig var risken. Det man inte har gjort är att publicera hur den engelska halvan presterar.

Så ett team som levererar kinesiskspråkiga tillgångar har på ena sidan en leverantör med en produkt där kinesiskan kommer först och ett engelskt tal som inte går att publicera, och på andra sidan en leverantör med en avsiktligt balanserad tvåspråkig utvärdering och inga meriter på den kinesiska marknaden. Två olika slags tillförlitlighet, och ingen av dem går att överföra till den andras marknad. Det enda sättet att avgöra saken är en direkt jämförelse på din egen text, och bara en av dessa två modeller gör det möjligt. Kör de kinesiska strängar ni faktiskt levererar – produktnamn, juridiska rader, kinesiska tecken som är lätta att hitta på – genom MOSS-Image-SFT lokalt, och ställ samma strängar mot hy-image-v3.5-preview via API. Det experimentet kostar en eftermiddag och avgör mer än båda leverantörernas material tillsammans.

Kostnad, tillgång och rutfrågan

Kostnadsjämförelsen är snedvriden i den ena riktningen och åtkomstjämförelsen är snedvriden i den andra, vilket är anledningen till att beslutet sällan avgörs av fakturan.

H​Y-Image 3.5 kostar $0,024 för en 2K-bild internationellt — $24 per 1 000, vilket är samma siffra omräknad per tusen som visas på den oberoende tavlan, så leverantörens pris och tavlans priskolumn stämmer överens. Inrikes kostar det ¥0,15 för en 2K-bild, och fakturering sker endast för levererade utdatabilder, så en filtrerad eller misslyckad begäran debiteras inte. Vid hundra tusen bilder i månaden blir det $2 400, med ett dokumenterat felbeteende som inte leder till debitering.

MOSS-Image har ingen prislista. Licensen är Apache 2.0 och nedladdningen är omkring 27,2 GB, varav ungefär 16,8 GB fördelat över fyra shards är den frysta Qwen3.5-9B-textkodaren och omkring 10,2 GB fördelat över tre är transformatorn. 5B-etiketten beskriver enbart diffusionsgeneratorn, och kodaren är den större halvan av nedladdningen. Standardinställningarna för sampling är flow-matching Euler med 50 steg, CFG 3.0 och shift 5.0; standardvägen för guidance kräver två transformator-framåtpassager per steg, så antalet steg är inte den billiga inställning den ser ut att vara. Dina hundratusen bilder kostar vad din GPU-tid kostar, och inget annat.

Det som förenar de två vägarna är att ingen av dem är ett routingproblem. M​OSS-Image finns inte i OrcaRouters katalog — vi tillhandahåller fler än 200 modeller och det är inte en av dem — så den del av den här jämförelsen som rör vikterna är din egen infrastruktur. H​Y-Image 3.5 finns inte heller med, och dess dokumenterade väg är T​encents eget API eller T​encents egna produkter; T​encent har ingen checkpoint, ingen lokal licens och ingen offline-väg, och de ComfyUI-noder som finns för den anropar API:et i stället för att köra bakom det. Den ärliga beskrivningen av båda är den generiska: via leverantörens eget API och, i T​encents fall, dess förstapartsverktyg.

Det routern faktiskt är användbar till här är den tredje saken, nämligen experimentet ovan. Om du vill testa hur M​OSS-Images lokala textrendering står sig mot hostade modeller i stället för mot en resultattavla, är det den hostade sidan där jämförelsen biter, och att ställa en självhostad checkpoint mot flera hostade bildmodeller med identiska prompter är precis den typ av uppgift som en enda endpoint med automatisk failover och leverantörernas listpriser vidarebefordrade oförändrade är byggd för: en nyckel i stället för fyra integrationer, och en körning som blir klar även när en leverantör har en dålig timme. GPT Image 2 och G​oogles bildmodeller finns på den endpointen; M​OSS-Image gör det inte.

Att välja mellan en levererad utvärdering och en levererad produkt

Ta M​OSS-Image om det specifika du behöver är strukturerad kontroll över var text hamnar och hur länge den körs. Layout-JSON:en anger uttryckligen varje textelements sträng och position, Apache 2.0 gör kommersiell granskning kort, och Base-checkpointen lämnades avsiktligt odestillerad — modellkortet säger att ingen efterträning eller destillering av inferensparametrar som CFG tillämpades — vilket är ett medvetet val för att lämna något för LoRA-träning att arbeta med. Utgå från att båda benchmarks som bär dess namn är leverantörens egna, att den starkaste end-to-end-layoutsiffran kommer från en pipeline vars promptspecificerande halva är en tredjepartsmodell snarare än en liten OpenMOSS-modul, och att encodern dominerar nedladdningen.

Välj H​Y-Image 3.5 om du behöver en anropbar slutpunkt den här veckan, om dina tillgångar är kinesiskspråkiga, eller om du hellre vill köpa en modell med en oberoende redigeringsplacering än en med ett leverantörsbenchmark. Gå in i det med vetskapen att identifieraren är en förhandsvisningsbeteckning utan daterad ersättning, att textpåståendet är en mening och inte en poäng, och att det enda som oberoende har mätts hos modellen är ett blindpreferensmedelvärde som inte säger något om huruvida den orörda delen av din bildruta förblev orörd.

Luckan som skulle förändra detta mest är inte en ny modell. Det är en annan part som kör LongLongTextBench på något som inte är M​OSS-Image, eller att T​encent publicerar en poäng för textrendering för förhandsversionen. Ingetdera finns, och tills något av dem gör det är den praktiska versionen av den här jämförelsen en nedladdning mot ett API-anrop och en eftermiddag som läggs på dina egna strängar — vilket är ett bättre sätt att använda tiden på än att läsa någon av leverantörernas tabeller.

De dokumenterade AI-felen och agentincidenterna bakom släpp som detta samlas i OrcaRouter AI Incident Archive, där varje post har sina egna källor, allvarlighetsgrad, konfidensgrad och omstridd flagga.