AI డెమోలు ఎక్కడ చూసినా కనిపిస్తున్నాయి. ఒక చిన్న Python స్క్రిప్ట్ ద్వారా ఒక ఫోటోలో ముఖాన్ని మార్చవచ్చు, అది చూడటానికి అద్భుతంగా ఉంటుంది. కానీ నిజమైన వ్యక్తులు ఉపయోగించుకోగలిగేలా, వారు అప్లోడ్ చేసి, వెళ్ళిపోయి, మళ్ళీ తిరిగి వచ్చి చూసుకునేలా ఒక అప్లికేషన్ను నిర్మించడం అనేది పూర్తిగా భిన్నమైన పని. నేను ఇటీవల ఒక వెబ్ టూల్ను రూపొందించాను; ఇది ఒక యానిమేటెడ్ GIF మరియు ఒక రిఫరెన్స్ ఫేస్ను తీసుకుని, ప్రతి ఫ్రేమ్లో ముఖాన్ని మార్చి అదే యానిమేషన్ను తిరిగి ఇస్తుంది. మోడల్ విజువల్ పనులను చేస్తుంది, కానీ అసలైన ఇంజనీరింగ్ శ్రమ దాని చుట్టూ ఉన్న ఆర్కిటెక్చర్పై జరిగింది: కనెక్షన్లను నిలిపి ఉంచడం, పేజీ రిఫ్రెష్ అయినా డేటా పోకుండా చూడటం, మరియు రెండు నిమిషాల ఇన్ఫరెన్స్ (inference) జాబ్ 504 Gateway Timeout వల్ల ఆగిపోకుండా చూసుకోవడం.
ఇది ఒక ప్రోటోటైప్ (prototype) మరియు ఒక ప్రొడక్ట్ (product) మధ్య ఉన్న తేడా. ఇంజనీర్లు డిఫ్యూజన్ ఆర్కిటెక్చర్స్ (diffusion architectures) మరియు ఇన్ఫరెన్స్ పారామీటర్ల గురించి మాట్లాడటానికి ఇష్టపడతారు. కానీ ఒక యూజర్ రెండు వందల ఫ్రేమ్లు ఉన్న భారీ GIFని అప్లోడ్ చేసినప్పుడు, బ్రౌజర్ ట్యాబ్ ముప్పై సెకన్ల తర్వాత ఆగిపోతే, మీ మోడల్ గురించి ఎవరికీ పట్టదు. ఇన్ఫరెన్స్ ఎంత ముఖ్యమో, దాని చుట్టూ ఉండే ఇన్ఫ్రాస్ట్రక్చర్ కూడా అంతే ముఖ్యం.
వేచి ఉండటంలో ఉన్న సమస్య
సాధారణ వెబ్ ఆర్కిటెక్చర్ వేగవంతమైన స్పందనలను ఆశిస్తుంది. యూజర్ ఒక బటన్ను క్లిక్ చేస్తారు, సర్వర్ సమాధానం ఇస్తుంది, మరియు పేజీ అప్డేట్ అవుతుంది. కానీ డజన్ల కొద్దీ GIF ఫ్రేమ్లలో ఫేస్ స్వాపింగ్ చేయడం వల్ల ఈ అంచనా వెంటనే తప్పుతుంది. మోడల్ నా సర్వర్లో కాకుండా Replicate యొక్క GPUs పై నడుస్తుంది, మరియు ఒక పెద్ద GIF ప్రాసెస్ కావడానికి నిమిషం లేదా అంతకంటే ఎక్కువ సమయం పట్టవచ్చు. అంత సేపు HTTP రిక్వెస్ట్ను అలాగే ఉంచడానికి ప్రయత్నిస్తే, సమస్యలు తప్పవు. లోడ్ బ్యాలెన్సర్లు (Load balancers) ఖాళీగా ఉన్న కనెక్షన్లను కట్ చేస్తాయి. బ్రౌజర్లు నెట్వర్క్ ఫెయిల్ అయిందని భావించి మళ్ళీ ప్రయత్నిస్తాయి. యూజర్లు ఫ్రీజ్ అయిన స్పిన్నర్ను చూస్తూ యాప్ పాడైపోయిందని అనుకుంటారు.
సబ్మిషన్ (submission) మరియు రిజల్ట్ (result) మధ్య సంబంధాన్ని వేరు చేయడం ద్వారా నేను ఈ సమస్యను పూర్తిగా నివారించాను. యూజర్ ఒక GIF మరియు ఫేస్ ఇమేజ్ను అప్లోడ్ చేసినప్పుడు, నా Next.js బ్యాకెండ్ Replicateలో ఒక ప్రిడిక్షన్ను ప్రారంభిస్తుంది మరియు వెంటనే ఒక job IDని తిరిగి ఇస్తుంది. యూజర్కు తక్షణ నిర్ధారణ లభిస్తుంది. GPU పని పూర్తయిన తర్వాత, వెబ్హుక్ (webhook) ద్వారా అసలు ఫలితం తర్వాత వస్తుంది. ఈ పద్ధతి కొత్తదేమీ కాదు, కానీ ఎక్కువ సమయం తీసుకునే మీడియా జాబ్ల కోసం ఇది చాలా అవసరం. ఇది అనిశ్చితమైన వేచి ఉండటాన్ని ఒక నమ్మకమైన ప్రక్రియగా మారుస్తుంది: జాబ్ అంగీకరించబడింది, మరియు అది పూర్తయినప్పుడు మీకు నోటిఫికేషన్ వస్తుంది.
మీరు నమ్మగలిగే స్టేట్ మెషీన్ (State Machine) నిర్మించడం
మీరు అసింక్రోనస్ (asynchronous) పద్ధతిని ఎంచుకున్నప్పుడు, మీకు విజిబిలిటీ (visibility) అవసరం. యూజర్లు పేజీని రిఫ్రెష్ చేస్తారు. వారు ట్యాబ్ను మూసివేసి మళ్ళీ తెరుస్తారు. వారు లింక్ను కాపీ చేసి సహోద్యోగికి పంపుతారు, వారు రెండు గంటల తర్వాత దానిని చూస్తారు. ఏం జరిగిందో తెలిపే శాశ్వత రికార్డు లేకపోతే, అక్కడ అంతా గందరగోళంగా మారుతుంది.
నేను Supabaseను 'సింగిల్ సోర్స్ ఆఫ్ ట్రూత్' (single source of truth) గా ఉపయోగించాను. ప్రతి అప్లోడ్ ఒక ప్రత్యేకమైన job IDతో ఒక రో (row)ను సృష్టిస్తుంది, మరియు ఆ రో నిర్దిష్ట స్టేట్ల ద్వారా మారుతుంది: queued, processing, succeeded, failed, లేదా expired. యూజర్ మొదట సబ్మిట్ చేసినప్పుడు, ఆ రో 'queued' స్టేట్లో ఉంటుంది. Replicate ప్రిడిక్షన్ను అంగీకరించిన వెంటనే, అది 'processing' కి మారుతుంది. వెబ్హుక్ దానిని 'succeeded' లేదా 'failed' కి మారుస్తుంది. కాల్బ్యాక్ లేకుండా ఎక్కువ సేపు నిలిచిపోయే జాబ్ల కోసం నేను 'expired' అనే స్టేట్ను జోడించాను, తద్వారా సిస్టమ్ అనవసరంగా వాటి కోసం వెతకదు.
TypeScriptలో నిర్మించిన ఫ్రంటెండ్, తక్కువ వ్యవధిలో Supabaseని పోల్ (poll) చేస్తూ, ప్రస్తుత స్టేట్ ఏంటో చూపిస్తుంది. ఈ పోలింగ్ పద్ధతి ప్రాథమికంగా అనిపించినప్పటికీ, ఇది రిఫ్రెష్ సమస్యను పూర్తిగా పరిష్కరిస్తుంది. యూజర్ తన లాప్టాప్ను మూసివేసి, మరుసటి రోజు తెరిచినా, పనులు ఎక్కడ ఉన్నాయో ఖచ్చితంగా చూడగలరు, ఎందుకంటే బ్రౌజర్ మెమరీ కాదు, డేటాబేస్ మాత్రమే ప్రోగ్రెస్ (progress)ను కలిగి ఉంటుంది. Supabase క్రెడిట్లను కూడా ట్రాక్ చేస్తుంది, కాబట్టి స్టేట్ను ట్రాక్ చేసే అదే జాబ్ రికార్డుతో అకౌంటింగ్ కూడా ముడిపడి ఉంటుంది. అంతా ఒకే చోట ఉంటుంది.
బ్రౌజర్పై భారం పడకుండా ఫైళ్లను హ్యాండిల్ చేయడం
GIFలు ప్రజలు అనుకున్నదానికంటే బరువుగా ఉంటాయి. AI పైప్లైన్ కోసం సరిగ్గా ఉన్న ఫైల్ కూడా కొన్ని మెగాబైట్ల బరువు ఉండవచ్చు. దానిని బ్రౌజర్లోనే లూపింగ్ ప్రివ్యూగా రెండర్ చేయడం వల్ల, ముఖ్యంగా తక్కువ సామర్థ్యం ఉన్న పరికరాలలో పనితీరు దెబ్బతింటుంది. నాకు రెండు వేర్వేరు ఫైల్ పైప్లైన్లు అవసరమయ్యాయి: ఒకటి AI కోసం, మరొకటి యూజర్ ఇంటర్ఫేస్ కోసం.
ప్రివ్యూల కోసం, నేను WebAssemblyకి కంపైల్ చేసిన FFmpeg ఉపయోగించి పెద్ద GIFలను యానిమేటెడ్ WebPగా మారుస్తాను. ఇది పూర్తిగా బ్రౌజర్లోనే క్లయింట్-సైడ్ (client-side) నడుస్తుంది. దీనివల్ల ఒరిజినల్ ఫైల్ను తాకకుండానే, ఇంటర్ఫేస్ వేగంగా ఉండేలా ఒక లైట్వెయిట్ ప్రివ్యూ లభిస్తుంది. Replicateకి పంపే GIF యథాతథంగా ఉంటుంది. ఆ విభజన చాలా ముఖ్యం. ప్రివ్యూ నుండి వచ్చే కంప్రెషన్ ఆర్టిఫాక్ట్స్ (compression artifacts) మీ ట్రైనింగ్ డేటాలోకి లేదా ఫైనల్ రెండర్లోకి రాకూడదు, అలాగే AI ఆలోచిస్తున్న సమయంలో యూజర్ ఇంటర్ఫేస్ భారీ ఫైల్ వల్ల ఆగిపోకూడదు.
అప్లోడ్ బ్రౌజర్ నుండి బయటకు వెళ్లే ముందే, FFmpeg WASM ఇతర GIF పనులను కూడా నిర్వహిస్తుంది. ఫ్రేమ్ కౌంట్లను విశ్లేషించడానికి (parse), డైమెన్షన్లను ధృవీకరించడానికి మరియు పాడైపోయిన ఫైళ్లను ముందుగానే గుర్తించడానికి నేను దీనిని ఉపయోగిస్తాను. GPU క్రెడిట్లు ఖర్చయ్యే ముందే సమస్యను గుర్తించడం వల్ల డబ్బు మరియు యూజర్ ఓపిక రెండూ ఆదా అవుతాయి.
ఒక డెమోను ప్రజలు నమ్మే సాఫ్ట్వేర్గా మార్చడం
మార్కెట్లో ఉన్న దాదాపు ప్రతి జనరేటివ్ AI టూల్కు వర్తించే ఒక విస్తృతమైన పాఠం ఇక్కడ ఉంది. మోడల్ స్వయంగా కేవలం ముప్పై శాతం పని మాత్రమే కావచ్చు. మిగిలిన డెబ్బై శాతం పని ఎవరూ ట్వీట్ చేయని, ఆకర్షణీయంగా కనిపించని అంతర్గత వ్యవస్థలు: స్టేట్ రికవరీ, వెబ్హుక్ సిగ్నేచర్స్, ఫైల్ కన్వర్షన్, క్రెడిట్ ట్రాకింగ్ మరియు గ్రేస్ఫుల్ ఫెయిల్యూర్.
నా స్టాక్ సరళమైనది మరియు ఆలోచనాత్మకమైనది. Next.js మరియు TypeScript ఇంటర్ఫేస్ మరియు API రూట్లను నిర్వహిస్తాయి. Replicate మోడల్స్ను రన్ చేస్తుంది. Supabase స్టేట్స్, డేటా మరియు క్రెడిట్లను నిర్వహిస్తుంది. FFmpeg WASM క్లయింట్-సైడ్ మీడియా పనులను నిర్వహిస్తుంది. Animated WebP UIని వేగంగా ఉంచుతుంది. ప్రతి భాగం ఒకే పనిని చేస్తుంది, మరియు అవి బలహీనమైన, ఎక్కువ సమయం తీసుకునే రిక్వెస్ట్ల ద్వారా కాకుండా, స్పష్టమైన స్టేట్ ట్రాన్సిషన్స్ ద్వారా అనుసంధానించబడతాయి.
ఒక యూజర్ ఫేస్ స్వాప్ కోసం క్రెడిట్లను ఉపయోగించినప్పుడు, వారు విశ్వసనీయతను ఆశిస్తారు, రీసెర్చ్ పేపర్ను కాదు. ఒకవేళ ప్రిడిక్షన్ విఫలమైతే, సిస్టమ్ ఆ విషయాన్ని గుర్తించి తెలియజేయాలి. యూజర్ వేచి ఉండాల్సి వస్తే, వారికి చూడటానికి ఒక లైట్వెయిట్ ప్రివ్యూ మరియు బ్రౌజర్ రీస్టార్ట్ చేసినా మారకుండా ఉండే స్టేటస్ ఉండాలి. ఇవి సరిగ్గా పనిచేస్తున్నప్పుడు ఎవరికీ కనిపించవు, కానీ విఫలమైనప్పుడు తీవ్రమైన సమస్యలుగా మారుతాయి.
ఫేస్ స్వాప్ అనేది ఒక చక్కని ట్రిక్ మాత్రమే. కానీ యూజర్ అప్లోడ్ చేసి, వెళ్ళిపోయి, మళ్ళీ తిరిగి వచ్చినప్పుడు కూడా వారు చేస్తున్న పని ఎక్కడితో అక్కడే ఉండేలా ఉండటం వల్ల మాత్రమే ఈ టూల్ నిజమైనదిగా అనిపిస్తుంది. ఒక API కాల్ను ప్రజలు నిజంగా నమ్మే సాఫ్ట్వేర్గా మార్చేది ఇదే.