Qwen-Image-2.1 opent lokale RGBA-workflows; één CMP 170HX houdt 250K context op snelheid

Qwen heeft Image-2.1 uitgebracht met open gewichten: één model voor beeldgeneratie én -bewerking, inclusief native transparantie. Daarnaast laat een gedocumenteerde test op één gebruikte datacenter-GPU zien dat lange context vooral een runtime- en schedulerprobleem blijft, niet alleen een vraag van voldoende VRAM.

Qwen-Image-2.1 koppelt generatie, editing en transparante lagen

Qwen-Image-2.1 is volgens Qwen een compact 7B-model voor zowel genereren als bewerken van beelden. De release noemt native RGBA/transparantie, lokale bewerkingen en maximaal tien referentiebeelden; Qwen zegt ook dat de gewichten beschikbaar zijn. Aankondiging van Qwen · HN-discussie

Dat is praktisch interessanter dan een zuiver text-to-image-model wanneer een workflow losse assets, overlays of product- en portretbewerkingen nodig heeft: transparantie hoeft dan niet per se als nabewerking buiten het model te worden geconstrueerd. vLLM-Omni meldt meteen ondersteuning voor de combinatie van een 7,1B-DiT en Qwen3-VL-8B, met prefix-KV-hergebruik voor tekst en referentiebeelden, CUDA Graphs en fasebewuste batching. vLLM-Omni-aankondiging

De grens is belangrijk: de kwaliteits- en snelheidsclaims komen van de maker; de kleine HN-discussie levert nog geen onafhankelijke vergelijking op. Ook circuleren vragen over de licentie, maar de beschikbare context bevat daarover geen gezaghebbende bevestiging. Controleer daarom licentie, werkelijk geheugenverbruik en de kwaliteit op eigen edit-taken voordat je een bestaande beeldpipeline vervangt.

Eén CMP 170HX: FP8-KV en minder concurrency helpen bij 250K context

Een gebruiker publiceert een repository en meetlog voor Qwen3.8-27B met DFlash2 op één Nvidia CMP 170HX met 64GB, via vLLM 0.27.1. In de gekozen single-stream, greedy opzet meldt de auteur 147 tok/s decode bij 32K context en 64,9 tok/s bij 250K. Dit zijn expliciet decodecijfers, dus geen end-to-end-resultaten inclusief prefill. Meetopzet, code en resultaten

Dit is een concrete aanvulling op de namiddagupdate van gisteren, die een twaalf-kaartenopstelling vooral als capaciteitsexperiment behandelde. Hier gaat het om één kaart en een specifieke servingroute: W4A16-target en -drafter, FP8-KV voor het target, BF16-KV voor de drafter, een aangepaste SM80-verifier en CUDA Graphs. De auteur rapporteert dat de verifierlatency bij 250K van 103,3 naar 46,9 ms per stap daalde tijdens dit optimalisatietraject.

De nuttigste les zit in de ruilen, niet in één topscore. In deze test was INT8-KV bij 250K 139% trager per speculative iteratie dan FP8; bij lange context werkte drie drafttokens beter dan vijf of zeven. Twee gelijktijdige lange aanvragen maakten zelfs de totale doorlooptijd slechter. Dat is geen universeel vLLM-profiel — kaart, kernel, quant, prompts en workload zijn hier bepalend — maar wel een reden om KV-formaat, draftlengte en MAX_SEQS samen te meten in plaats van concurrency automatisch op te voeren. De auteur documenteert bovendien een herstelde int32-overflow in een KV-pool groter dan 5 GiB; de implementatie verdient dus nog onafhankelijke reproductie.

Een catalogus maakt de agentkeuze weer een ontwerpvraag

Een Reddit-gebruiker heeft 158 agentprojecten ingedeeld in zeven groepen, van execution harnesses en coding-orchestration tot memory, coördinatie, testing en infrastructuur. Het overzicht is geen uitputtende marktkaart en de auteur zegt nadrukkelijk niet alle projecten zelf te hebben gedraaid. Catalogus en toelichting

Toch is zo'n indeling bruikbaar voor teams die hun lokale of hybride agentstack moeten afbakenen: een dashboard, planner, toolregistry en runtime zijn verschillende lagen, ook als één product meerdere ervan aanbiedt. In de discussie komt een concreet ontwerpdetail naar voren: wie tools dynamisch configureerbaar maakt, moet versies per run vastleggen en geïsoleerde uitvoer gebruiken; anders kan een tussentijdse wijziging of gedeelde namespace onverwacht gedrag veroorzaken.

Dat zijn ervaringen uit één projectdiscussie, geen gevalideerde referentiearchitectuur. Gebruik de lijst daarom als inventaris voor een eigen shortlist, en toets vervolgens vooral rechtenmodel, versiebeheer, observability, state-isolatie en herstelgedrag — niet alleen hoeveel agentrollen een framework belooft.

Verder nog

• Cronjob-monitoring via heartbeat en SSH: Sigabrt.dev is een klein nieuw monitoringsproject waarbij een script periodiek een endpoint aanroept en je een melding krijgt als dat uitblijft; er is ook een experimentele read-only TUI via SSH. Handig als minimalistische externe check, maar geen nieuwe categorie: de HN-reacties noemen onder meer crontab-mail, systemd-timers en bestaande heartbeatdiensten als alternatieven. Beoordeel dus vooral authenticatie, retentie en afhankelijkheid van een externe dienst.