ML-focus verschuift naar software

Nieuwe machine-learning (ML)-architecturen blijven enorm veel aandacht trekken terwijl de race blijft zorgen voor de meest effectieve acceleratie-architecturen voor de cloud en de edge, maar de aandacht begint te verschuiven van de hardware naar de softwaretools.

De grote vraag is nu of een software-abstractie het uiteindelijk zal winnen van hardwaredetails bij het bepalen wie de toekomstige winnaars zijn.

“Machine learning is historisch gezien ontstaan ​​vanuit een plek waar de nadruk lag op specifieke eindtoepassingen, zoals objectdetectie voor auto’s of het begrijpen van natuurlijke taal met behulp van spraak”, zegt Sree Harsha Angara, productmarketingmanager voor IoT, computing en beveiliging bij Infineon. “Nu begint ML zich uit te breiden naar verschillende soorten applicaties, waarbij meer nadruk wordt gelegd op ontwerptools en softwareframeworks.”

Ontwerpers van machine learning-systemen beginnen steeds meer te eisen van de machine learning software development kits (SDK's), en sommige leveranciers gebruiken hun software om de hardwaredetails te begraven. Uiteindelijk zou minder optimale hardware met goede software wel eens succes kunnen hebben boven betere hardware met minder software.

We zijn hier eerder geweest
Compilers en andere ontwikkelingshulpmiddelen worden aan de softwarekant lange tijd als vanzelfsprekend beschouwd. Maar als het begin jaren '80 op hardware aankwam, werd van ontwerpers verwacht dat ze hun ontwerpen grotendeels handmatig deden. Hoewel dit vandaag de dag is veranderd, was er een moeilijke weg nodig om daar te komen. En de markt voor programmeerbare logica was een van de eerste plaatsen waar ontwerpsoftware een standpunt innam.

Aanvankelijk diende PLD-software alleen maar om het drukke werk te elimineren. In de begindagen van programmeerbare logische apparaten (PLD's) werkten ingenieurs hun logica uit en zochten vervolgens uit welke verbindingen nodig waren in de programmeerbare arrays. Deze zouden letterlijk met de hand worden geschreven in ‘zekeringskaarten’, die vervolgens in programmeerapparatuur konden worden ingevoerd voor het fysiek configureren van een apparaat.

Een grote verandering vond plaats met de introductie van programmeerbare array-logica, of PAL's, door Monolithic Memories. Twee dingen hebben de PLD-industrie in het algemeen een impuls gegeven. Ten eerste was er een architectonische verandering die de kosten verlaagde en de snelheid verhoogde. Maar nog invloedrijker was de eerste release van een zogenaamde PAL-assembler, genaamd PALASM.

Dit elimineerde het moeizame proces van het in kaart brengen van de verbindingen. In plaats daarvan zou je Booleaanse vergelijkingen kunnen invoeren – veel natuurlijker voor ingenieurs om mee te werken – en de tool de programmeerdetails laten uitzoeken. Dit heeft bijgedragen aan het creëren van een serieus keerpunt in het bedrijf.

Een paar jaar daarna verschenen er nieuwe toetreders op de PLD-markt, die voor meer architecturale programmeerbaarheid zorgden. Er was altijd logica geweest die dergelijke apparaten niet konden implementeren, dus de race was begonnen om met de meest flexibele architecturen te komen die nog steeds snel en goedkoop waren.

Een belangrijk keerpunt kwam toen Altera zijn nieuwe architectuur met MAX-PLUS-ontwerpsoftware uitbracht. Ingenieurs hadden moeite om de grenzen te vinden van wat die architectuur kon doen, en waren aangenaam verrast. Vergelijkingen waarvan verwacht werd dat ze niet konden worden gecompileerd, werkten eigenlijk wel, omdat de software nu meer deed dan alleen maar het omzetten van Booleaanse vergelijkingen in verbindingen. In plaats daarvan transformeerde het deze Booleaanse vergelijkingen ook door, onder andere, toe te passen De stelling van DeMorgan om dingen die niet gedaan konden worden, om te zetten in dingen die wel gedaan konden worden.

Dit was een gamechanger en verhoogde de inzet voor de softwarekant van het bedrijf aanzienlijk. Probeer zoveel je kon om architecturale zwakheden in de hardware aan te wijzen, zolang de software die zwakke punten maskeerde, was het een verloren argument.

Het bedrijf werd tot dan toe gedomineerd door hardwarebedrijven, met AMD als leider (nadat het Monolithic Memories had overgenomen). Maar hardwarebedrijven waren niet goed in het maken van software, en ze vonden het niet leuk om te doen. Dus in plaats van te worstelen met software, besteedde AMD het werk uit aan een klein softwarebedrijf. Dat bleek een strategische fout te zijn, en het bedrijf ging uiteindelijk failliet en verkocht een deel van de technologie aan AMD's nieuwe dochteronderneming Vantis (wat uiteindelijk niet succesvol was), en een deel aan Xilinx, destijds een nieuwkomer op het toneel met zijn fraaie FPGA's (die enorm succesvol waren).

Uiteindelijk was het de software die de winnaar bepaalde. Hardwarefuncties volgden een haasje-overpatroon en de tools bleken de onderscheidende factor te zijn.

“De geschiedenis is bezaaid met opmerkelijke FPGA-hardware-architecturen die allemaal struikelden en niet meer bestaan, deels vanwege het ontbreken van een effectieve toolchain”, zegt Stuart Clubb, hoofdproductmanager bij Siemens EDA. “Het maakt niet uit hoe goed een hardwareplatform is als je niet over de software beschikt om dat platform efficiënt en effectief te benutten.”

Een machine-learning parallel?
Tegenwoordig zijn alle ogen gericht op kunstmatige intelligentie en proberen bedrijven de beste architectuur te vinden voor machine-learning accelerators die in de cloud of aan de edge kunnen werken. Hoewel cloud-instanties hebben gedomineerd, edge-implementaties – met hun strenge eisen op het gebied van energie en kosten – hebben tot veel meer creativiteit geleid.

Maar het wordt steeds moeilijker om de impact van de verschillen tussen deze architecturen te begrijpen. Het voelt bijna alsof de grote ideeën achter ons liggen, waarbij bedrijven verschillende parameters in de gaten houden om een ​​goede plek te vinden voor prestaties, kracht en kosten.

“Het probleem waar mensen tegenaan lopen is dat ze deze hardwareoplossingen hebben en niet in staat zijn deze te optimaliseren of het gebruiksniveau te bereiken dat ze willen”, zegt Dana McCarty, vice-president verkoop en marketing, inference products bij FlexLogix.

Machine learning heeft altijd een software-element gehad, omdat het hele idee van het trainen en implementeren van een machine learning-oplossing geen sinecure is. Het bestaan ​​van vroege machine-learning-frameworks zoals Caffe en TensorFlow maakte AI-toepassingen praktisch en toegankelijk voor een groter aantal ontwikkelaars.

Toch komt er veel werk kijken bij het maken van een volledig ontwerp, vooral bij edge-toepassingen. voordeeltest gaf een voorbeeld van het gebruik van AI op testgegevens – een toepassing die veel minder prominent aanwezig is dan bijvoorbeeld visie.

“We krijgen deze grote, onopgeschoonde dataset en het zal enkele weken duren om deze handmatig door te nemen en de tools handmatig toe te passen”, zegt Keith Schaub, vice-president technologie en strategie bij Advantest. “Je hebt honderden kenmerken, soms duizend kenmerken of meer, en je probeert de belangrijkste kenmerken te achterhalen die verband houden met je voorspelling. Ze bedenken die via regressiemethoden en [hoofdcomponentenanalyse]. En dan heb je dit statische model met twaalf functies.”

En dat is alleen nog maar de hoogwaardige feature-engineering. Het volgende deel is het efficiënt in kaart brengen van dat model op een specifiek apparaat, waar een concurrentievoordeel zou kunnen ontstaan. “Je moet dat model efficiënt kunnen overbruggen naar je accelerator, en het bedrijf dat die overbrugging kan doen, zal winnen”, zegt Sam Fuller, senior marketingdirecteur bij Flex Logix.

Terwijl cloud-gebaseerde machines grotendeels kunnen vertrouwen op volledige floating-point hardware, bespaart veel edge-hardware energie en kosten door zich te concentreren op integer-implementaties. Dat betekent dat je een ontwerp en de getrainde parameters moet nemen en deze moet kwantiseren – ze moet converteren van drijvende komma naar geheel getal. Dat introduceert een aantal fouten, die de nauwkeurigheid van de gevolgtrekkingen kunnen schaden, dus het kan nodig zijn om opnieuw te trainen met het gewenste geheeltallige formaat. Het is veelzeggend dat het in de loop van de tijd gemakkelijker is geworden om rechtstreeks naar gehele getallen te trainen.

Het terugdringen van de omvang en het energieverbruik van deze ontwerpen heeft ook werk gekost. Je zou het ontwerp kunnen doornemen door parameters te identificeren die waarschijnlijk te klein waren om er toe te doen, en deze vervolgens weg te snoeien. Dit was oorspronkelijk een handmatig proces, waarbij de nauwkeurigheid opnieuw moest worden geëvalueerd om er zeker van te zijn dat deze niet al te ernstig in gevaar was gebracht door het snoeiproces.

Dan is er nog de kwestie van het aanpassen van software-“kernels” voor welk type processor dan ook dat wordt gebruikt. Dit is vaak bare-metal-code die voor elk knooppunt in het netwerk is geschreven. Sommige architecturen kiezen verwerkingselementen die zich alleen richten op de algemene instructies die voor gevolgtrekking worden gebruikt. Anderen behouden de ‘volledige programmeerbaarheid’, zodat ze flexibeler kunnen worden gebruikt dan gevolgtrekkingen.

En als u toevallig een dataflow-architectuur heeft, moet u mogelijk de hardware opdelen en verschillende lagen en knooppunten aan verschillende regio's toewijzen.

Dit zijn slechts enkele zaken die moeten worden afgehandeld om een ​​volledig functionele machine-learning-applicatie te implementeren. Een deel ervan is handmatig gebeurd, maar de hoeveelheid software-automatisering is geleidelijk opgevoerd.

De volgende fase: hardware geheimhouden
Het afgelopen jaar is er een verandering zichtbaar geworden in de branche. Op conferenties zoals de Linley Processor-conferenties of Hot Chips hebben bedrijven nieuwe aanbiedingen aangekondigd met meer discussie over de software. En met name in sommige gevallen praten ze niet echt over de onderliggende hardware.

Dat kan natuurlijk gebeuren op openbare fora zoals conferenties. Soms maken bedrijven de details alleen onder geheimhoudingsverklaring bekend om verkoopvooruitzichten te legitiem te maken. Maar de teneur van de gesprekken lijkt steeds meer de kant op te gaan van: 'Maak je geen zorgen over de details. De software zal daarvoor zorgen.”

Dat verandert aanzienlijk de verkoopdiscussies van een poging om een ​​prospect ervan te overtuigen dat subtiele architectonische verschillen betekenisvolle resultaten zullen opleveren, naar een discussie waarbij ontwerpervaring het bewijs levert. Kunt u een proefontwerp sneller implementeren dan voorheen? Bereikt u uw beoogde prestatiestatistieken (kosten, snelheid, kracht, nauwkeurigheid, enz.) met minimale handmatige iteratie? Kunt u met weinig tot geen handmatige tussenkomst een goede implementatie realiseren?

Als het antwoord op al deze vragen ja is, maakt het dan uit hoe de hardware dat heeft bereikt? Als de software snel transformaties kan uitvoeren als dat nodig is, maakt het dan uit of de onderliggende poorten een beperking hadden die softwaretransformatie vereiste? Als een andere architectuur veel meer toeters en bellen heeft, maar het kost veel meer moeite om een ​​ontwerp te voltooien, zijn die extra features dan de moeite waard?

Bedrijven die vertrouwen op hun tools om het woord te doen, wedden dat het hun klanten echt niet uitmaakt wat er onder de motorkap zit – zolang het, in combinatie met goede software, maar de gewenste klus kan klaren en met de benodigde snelheid, kracht, nauwkeurigheid en kosten. .

Zal de geschiedenis zich herhalen met machine learning?
Net als mensen hebben bedrijven vaak persoonlijkheden. Sommige zijn hardware-georiënteerd, terwijl andere software-georiënteerd zijn. Een deel van beide is duidelijk vereist voor elk machine-learningaanbod, maar het voelt alsof de voorsprong zich verplaatst naar softwaregeoriënteerde bedrijven. Dat betekent dat software voorop moet blijven staan ​​als een ster van het aanbod, en niet als een vervelende maar noodzakelijke cameo-walk-on. Het betekent ook dat de hardware en de software samen moeten worden ontworpen.

De behoefte aan software om de details te bufferen is bij ML waarschijnlijk groter dan bij FPGA's. Zelfs met tools worden FPGA's ontworpen door hardware-ingenieurs. ML-modellen daarentegen zijn ontworpen door datawetenschappers, die vele niveaus verwijderd zijn van de hardware. Er moeten dus hulpmiddelen zijn om de abstractiekloof te overbruggen.

“Tenzij je hun taal spreekt, maak je geen enkele kans”, zegt Nick Ni, directeur productmarketing voor AI en software bij Xilinx. “Elke leverancier heeft het over TensorFlow- en Python-ondersteuning omdat ze geen andere manier hebben. Of je het nu leuk vindt of niet, je moet het steunen. Maar om zo’n hoog raamwerk te ondersteunen, moet je alles daartussenin doen.”

Een andere mislukking in de PLD-industrie was het ontwerpen van slimme architecturen, maar ontdekte achteraf dat het buitengewoon moeilijk was om daarvoor software te bouwen. De meest succesvolle hardware- en softwareteams werkten samen, waarbij de hardware waar nodig werd aangepast om soepele en krachtige software-algoritmen mogelijk te maken.

Fig. 1: De evolutie van ontwerptools, beginnend met handmatige ontwerpen en voortschrijdend door het elimineren van verveling, het daadwerkelijke vermogen om ontwerpen te manipuleren en uiteindelijk te optimaliseren. In de laatste fasen is co-ontwerp van hardware en software van cruciaal belang voor succes. Bron: Bryon Moyer/Semiconductor Engineering

Dit zal ook gelden voor machine learning. Als een slimme hardwaretruc moeilijk in software kan worden toegepast, zal deze waarschijnlijk nooit worden gebruikt. Uiteindelijk zullen de meest succesvolle aanbiedingen waarschijnlijk architecturen zijn die goed aansluiten bij hun tools en die alle functies hebben verloren die niet effectief door de tools kunnen worden gebruikt.

“Een van de fundamentele uitgangspunten van het bedrijf is dat de behoeften van de software het ontwerp van de hardware moeten bepalen”, zei Nigel Drago, CTO van Quadric.io, afgelopen najaar tijdens de Linley Processor Conference.

Op diezelfde conferentie noemde Ravi Setty, senior vice-president van Roviero, de rol van software bij het definiëren van de architectuur van het bedrijf. “We hebben misschien 5% complexiteit in de hardware toegevoegd om zoiets als 90% eenvoud in de compiler te bereiken. De hardware is puur agnostisch voor alle neurale netwerkinformatie. Het is de compiler die alle kennis heeft. En de hardware: het is slechts een uitvoeringsengine.”

Hoewel de rol van tools groeit, zijn we nog steeds niet zover dat ze de hardware volledig begraven. Er is nog steeds een rijke mix van architecturale verkenningen die nog moeten worden opgelost. Zoals bij veel ontwerpautomatiseringstrajecten betreden we het domein waarin veel ontwerpen automatisch uitvoerbaar zullen zijn, waarbij handmatige aanpassingen nodig zijn om het maximale uit de hardware te halen.

In dit stadium van de markt bestaat er ook een spanning tussen meer algemene architecturen met software-abstractie en speciaal gebouwde architecturen. “Hoewel een softwaregestuurde hardwareoplossing voor algemene doeleinden meer flexibiliteit kan bieden, verliezen dergelijke oplossingen vaak van gespecialiseerde hardware wanneer een bepaalde dimensie (oppervlakte, vermogen, snelheid, kosten) van groter belang is”, aldus Siemens EDA's Clubb.

Dit kan een uitdaging vormen voor software die zich richt op gespecialiseerde hardware. “Elke architectuur heeft unieke voordelen en is geoptimaliseerd voor specifieke gebruiksscenario’s”, legt Anoop Saha, senior manager, strategie en groei bij Siemens EDA uit. “Maar de uitdaging voor de gebruiker blijft: hoe kunnen ze hun netwerk samenstellen op een specifieke hardware-architectuur? En als ze daartoe in staat zijn, hoe kunnen ze het dan optimaliseren voor die specifieke hardware en de verschillende beschikbare componenten benutten? De hardwarespecifieke optimalisaties en flexibiliteit moeten op een meer automatische manier door software worden afgehandeld.”

Zijn tools de baas?
Uiteindelijk voelt het alsof de hardwarewinnaars op de lange termijn degenen zullen zijn die de beste ontwerpervaring bieden, waarbij alleen voldoende hardware beschikbaar is om ontwikkelaars te helpen bij hun ontwerpbeslissingen. Dat is zeker de manier waarop FPGA's tegenwoordig werken. In sommige gevallen zijn er zelfs dingen die de FPGA-hardware theoretisch kan doen, maar die de software niet toestaat.

ML lijkt een soortgelijk pad te volgen. "Innovaties op het gebied van hardware die aanzienlijke voordelen bieden op het gebied van kracht en snelheid, wikkelen zich onder een gemeenschappelijk softwareframework of API", aldus Angara van Infineon. “Dit betekent dat ze aanzienlijke winst opleveren bij het uitvoeren van ML zonder de pijn van ‘ongeavanceerde’ software.”

Het valt nog te bezien of ingenieurs zullen stoppen met nadenken over de hardware. “Kunnen ML-'compilers' slim genoeg zijn om zich te richten op generieke hardwareplatforms tot het punt waarop de hardware er niet meer toe doet? Waarschijnlijk niet”, aldus Clubb. “ML-hardwarespecialisatie heeft zeker voor- en nadelen als het gaat om het beperken van de flexibiliteit en herprogrammeerbaarheid van de oplossing. Inventieve architecten en hardwareontwerpers zullen altijd effectievere oplossingen moeten ontwikkelen als de algemene oplossing niet voldoet aan de behoeften van de toepassing.”

Schaalvergroting en het grootste deel van de markt kunnen hier echter invloed op hebben. Toen synthese nieuw was, waren er veel ingenieurs die dachten dat ze altijd beter werk konden doen dan een hulpmiddel. Dat was misschien waar, maar het werd onpraktisch naarmate ontwerpen groter werden, de productiviteitsverwachtingen hoger werden en de tools verbeterden.

Dus hoewel hardware er tot op zekere hoogte altijd toe zal doen, lijkt het erop dat softwaretools op de lange termijn, net als bij programmeerbare logica, vaak de koningsmaker kunnen worden.

Bron: https://semiengineering.com/ml-focus-shifting-toward-software/