Introducere: Întrebarea reală din spatele „Alternativelor TensorRT-LLM”
Fiecare schimbare în stiva AI nu se referă doar la viteză; este vorba despre unde se acumulează valoarea. Căutarea de alternative TensorRT-LLM este aparent despre performanța inferenței pentru modelele lingvistice mari (LLM-uri), dar întrebarea strategică de dedesubt este mai importantă: cine captează marja în era AI-ului constrâns de GPU-uri, sensibil la latență? TensorRT-LLM se află la intersecția a două realități - dominația hardware a NVIDIA și complexitatea operațională a inferenței de producție. Orice alternativă credibilă trebuie fie să 1) neutralizeze blocarea software a NVIDIA, 2) să îmbunătățească costul total de proprietate (TCO) prin portabilitate și scalare automată, sau 3) să creeze noi puncte de agregare mai sus în stivă. Acest articol evaluează alternativele TensorRT-LLM prin prisma modelelor de afaceri, a constrângerilor de performanță și a realităților de implementare - concentrându-se pe cine câștigă și de ce.
Intenția utilizatorului pentru interogarea „alternative TensorRT-LLM” este tranzacțională-informațională: echipele sunt aproape de implementare, conștiente de avantajele de accelerare ale NVIDIA și explorează opțiuni care păstrează performanța, îmbunătățind în același timp portabilitatea, costul sau viteza dezvoltatorilor. Miza este simplă. Economia inferenței determină marjele produsului. Latența determină experiența utilizatorului. Și ambele sunt dependente de alegerile de arhitectură care înclină puterea către furnizori - sau către propriul dvs. produs diferențiat.
Cadru: Trei straturi de avantaj al inferenței
Pentru a analiza alternativele, luați în considerare trei straturi în care se acumulează avantajul:
- Cuplare hardware: Cuplare strânsă la GPU-uri, nuclee și planuri de memorie; performanță absolută maximă; blocare mai mare.
- Orchestrare runtime: Batching dinamic, decodare speculativă, strategii de cuantificare; performanță prin programare mai degrabă decât prin nuclee.
- Distribuția modelului și rețele de servire: Modele pre-optimizate, rutare multi-cloud și livrare edge/PoP; performanță prin scală și agregare.
TensorRT-LLM domină primul strat. Majoritatea alternativelor concurează pe al doilea și al treilea. Scopul dvs. nu este să „bateți” NVIDIA pe nuclee bare-metal; este să obțineți performanțe echivalente sau acceptabile cu un TCO mai bun și flexibilitate strategică.
Ce optimizează TensorRT-LLM - și de ce contează asta
TensorRT-LLM integrează optimizări la nivel de nucleu (atenție fuzionată, planificare a aspectului memoriei), compilarea graficului, suport pentru cuantificare (de exemplu, INT8/FP8) și batching dinamic. Beneficiile sunt clare: latență mai mică, mai mulți tokens pe secundă și utilizare îmbunătățită a GPU-ului pe hardware NVIDIA. Costul este blocarea ecosistemului: căi de cod specifice NVIDIA, portabilitate limitată pe AMD/CPU/ASIC și complexitate operațională care presupune o capacitate NVIDIA stabilă, de înaltă performanță.
Răspunsul pieței se grupează în trei strategii alternative:
- Compilatoare și runtime-uri de inferență agnostice de furnizor: Vizează performanțe „suficient de bune” pe GPU-uri/CPU-uri.
- Sisteme de servire specializate: Câștigă cu orchestrare - batching, caching, decodare speculativă, atenție paginată - peste nuclee brute.
- Rețele agregate de livrare a modelelor: Distribuie inferența în cloud-uri, regiuni și furnizori, mascând complet detaliile hardware.
Cartografierea peisajului alternativelor TensorRT-LLM
Această evaluare presupune o cerință de nivel enterprise: fiabilitate de producție, confidențialitate, controlul costurilor și performanțe aproape de cele mai recente.
- Compilatoare și runtime-uri agnostice de furnizor
- ONNX Runtime + EPs (Execution Providers):
- Ce este: Un motor de execuție grafic care vizează mai multe backends (CUDA, TensorRT, DirectML, OpenVINO, ROCm) prin EPs.
- De ce contează: Portabilitatea mai întâi; puteți rula același model pe backends NVIDIA, AMD sau CPU. Performanța variază în funcție de maturitatea EP.
- Compromisuri: Performanța NVIDIA este încă cea mai bună prin TensorRT EP; EP-urile non-NVIDIA se îmbunătățesc, dar sunt inegale.
- Ce este: O stivă de compilare specializată în auto-reglarea nucleelor și optimizări la nivel de grafic pe ținte hardware.
- De ce contează: Control și portabilitate. TVM oferă echipelor de inginerie o pârghie pentru a reduce dependența de lanțurile de instrumente NVIDIA.
- Compromisuri: Necesită expertiză și timp de construire; performanța de vârf poate rămâne în urma stivei de furnizor NVIDIA pe cele mai recente GPU-uri.
- Ce este: Suita de optimizare a inferenței Intel pentru CPU, iGPU și acceleratoare selectate.
- De ce contează: Servirea centrată pe CPU cu cuantificare (INT8) poate fi rentabilă atunci când bugetele de latență permit; util pentru implementări edge și bazate pe conformitate.
- Compromisuri: Mai puțin competitiv în ceea ce privește randamentul pur al GPU-ului NVIDIA; strălucește în CPU și hibrid.
- Ce este: Runtime-ul și compilatorul de grafice AMD pentru GPU-uri Radeon/Instinct.
- De ce contează: Alternativă reală dacă pariați pe capacitatea și prețurile AMD; îmbunătățirea suportului pentru operațiuni LLM și cuantificare.
- Compromisuri: Ecosistemul software și maturitatea nucleului rămân în urma NVIDIA; traiectoria este pozitivă, dar inegală per familie de modele.
- Căi de inferență WebGPU / Vulkan (experimentale/edge):
- Ce este: Accelerare browser/edge prin WebGPU; există proiecte Vulkan pe partea de server pentru portabilitate.
- De ce contează: Distribuție edge pentru costuri reduse și confidențialitate; suprafață de dezvoltator emergentă.
- Compromisuri: Începuturi pentru servirea LLM la scară largă; promițător pentru modele mai mici și UX hibrid.
- Sisteme de servire specializate (Programare > Nuclee)
- Ce este: Un motor de servire construit în jurul PagedAttention și gestionarea eficientă a cache-ului KV.
- De ce contează: Câștiguri mari de randament prin batching eficient din punct de vedere al memoriei pentru LLM-uri; adoptat pe scară largă, open source.
- Compromisuri: Câștigurile depind de forma sarcinii de lucru (sesiuni concurente, lungimi de context, streaming); optimizările brute ale nucleului depind de backend.
- Derivate FasterTransformer și stive bazate pe Triton:
- Ce este: Biblioteci și nuclee adiacente NVIDIA; uneori utilizate în afara TensorRT-LLM pentru conducte personalizate.
- De ce contează: Control granular cu piese de nivel inferior dacă aveți nevoie de arhitecturi personalizate.
- Compromisuri: Povară de întreținere; încă cuplat cu NVIDIA.
- Text Generation Inference (TGI):
- Ce este: Un server de producție de la Hugging Face care pune accent pe performanță și observabilitate; se integrează cu cuantificare și batching.
- De ce contează: Performanță solidă, suport pentru ecosistem și implementare ușoară pe cloud-urile principale.
- Compromisuri: Mai puțin control bare-metal; plafonul de performanță depinde de backend și de familia de modele.
- Ray Serve + nuclee personalizate:
- Ce este: Un strat de servire distribuit excelent pentru elasticitate și scalare automată; conectabil cu vLLM/TGI.
- De ce contează: Ajută la potrivirea capacității cu cererea fluctuantă, ceea ce are adesea un impact mai mare asupra costurilor decât stoarcerea ultimilor 10% de latență.
- Compromisuri: Complexitate operațională; nu este un substitut pentru accelerarea la nivel de nucleu.
- Ce este: O cale de compilare și runtime pentru rularea LLM-urilor pe diverse dispozitive (mobile, edge, GPU-uri) prin TVM.
- De ce contează: Portabilitate reală - inferență acolo unde este utilizatorul. Bun pentru cazuri de utilizare pe dispozitiv și care protejează confidențialitatea.
- Compromisuri: Intensiv de reglare; nu este încă un înlocuitor direct pentru randamentul masiv pe partea de server.
- Rețele agregate de livrare a modelelor și platforme gestionate
- AWS SageMaker/Bedrock, Azure AI, Google Vertex AI:
- Ce sunt: Endpoint-uri gestionate cu scalare automată, A/B, observabilitate și rutare multi-model opțională.
- De ce contează: Reduce sarcina operațională; negociază implicit disponibilitatea hardware.
- Compromisuri: Blocarea furnizorului; reglare opacă a performanței; primă de cost.
- Replicate, Modal, Anyscale:
- Ce sunt: Găzduire de modele și inferență serverless axate pe dezvoltatori.
- De ce contează: Configurare rapidă, economie pay-per-use; bun pentru experimentare și scară moderată.
- Compromisuri: Mai puțin control la nivel de nucleu; curba costurilor depinde de sarcina susținută.
- OctoAI, Together, Mosaic (Databricks) și altele similare:
- Ce sunt: Platforme optimizate de servire LLM cu modele și cuantificare organizate.
- De ce contează: Combină instrumentele de performanță cu operațiuni gestionate; adesea pun accent pe optimizarea costului per token.
- Compromisuri: Dependență de platformă; căile de migrare variază.
- Straturi de inferență Edge/CDN (Cloudflare Workers AI, Fastly, stive bazate pe NVIDIA NIM):
- Ce sunt: Puncte de prezență distribuite pentru inferență cu latență scăzută.
- De ce contează: Reducerea latenței prin geografie; poate fi decisiv pentru UX interactiv.
- Compromisuri: Constrângeri de dimensiune a modelului; provocări de orchestrare pentru contexte lungi.
Cadru de decizie: Alegerea unei alternative TensorRT-LLM
Tentația este să întrebăm cine este „cel mai rapid”, dar întrebarea corectă este valoarea totală livrată: obiective de latență, fiabilitate, timp de dezvoltator și portabilitate. Utilizați această scară de decizie:
- Începeți cu forma sarcinii de lucru și SLA
- Aveți constrângeri de latență (latență token sub 100 ms) sau constrângeri de randament (cost per milion de tokeni)?
- Care este distribuția dumneavoastră de concurență: multe prompturi scurte sau puține sesiuni lungi?
- Aveți nevoie de contexte lungi (128k+) sau de latență ultra-scăzută?
- Care este cerința dumneavoastră de observabilitate și conformitate?
- Alegeți stratul de avantaj
- Dacă trebuie să maximizați performanța NVIDIA: TensorRT-LLM, eventual combinat cu vLLM sau TGI pentru programare.
- Dacă portabilitatea este critică: ONNX Runtime + EPs, TVM/MLC-LLM sau căi ROCm; acceptați un delta de performanță de 5-25% pentru flexibilitate strategică.
- Dacă elasticitatea operațională domină: Platforme gestionate sau Ray Serve + vLLM/TGI pentru a potrivi capacitatea cu cererea.
- Aplicați strategii de cuantificare și memorie
- Cuantificarea INT8/FP8 sau 4-bit (AWQ, GPTQ) poate oferi cele mai mari reduceri de costuri; asigurați-vă testarea și calibrarea acurateței.
- Gestionarea cache-ului KV și atenția paginată bat frecvent micro-optimizările nucleului atunci când concurența este ridicată.
- Validați TCO, nu doar benchmark-uri
- Randamentul tokenilor per dolar (TT/$) este metrica relevantă, nu TFLOPS sintetice.
- Măsurați latența p95/p99 în condiții de concurență realiste; experiența utilizatorului final este modelată de latențele extreme.
Analiză comparativă: Unde câștigă fiecare alternativă
- vLLM + CUDA/ROCm: Cea mai bună soluție open source de uz general atunci când vă controlați flota. PagedAttention este o deblocare semnificativă pentru sesiuni concurente. Adăugați cuantificare pentru eficiența costurilor.
- ONNX Runtime + TensorRT EP: Un teren de mijloc pragmatic pe NVIDIA - utilizați portabilitatea ORT și obțineți în continuare viteza TensorRT. Pentru alternative reale, schimbați EP-urile cu ROCm sau OpenVINO; performanța se schimbă, operațiunile rămân similare.
- TGI cu scalare automată pe un serviciu GPU gestionat: Cea mai rapidă cale către producție cu performanțe acceptabile. Mai puține eroisme de nucleu, mai multă fiabilitate.
- TVM/MLC-LLM pentru strategie edge sau multi-hardware: Atunci când controlul pe termen lung și implementarea pe mai multe dispozitive contează mai mult decât viteza maximă absolută.
- ROCm/MIGraphX pe AMD: Viabil atunci când aprovizionarea cu GPU-uri, prețul sau diversificarea furnizorilor sunt strategice. Așteptați-vă la mai multă inginerie; evaluați riguros suportul per model.
Realitatea performanței: De ce „Suficient de bine” câștigă adesea
Teoria agregării este instructivă: în produsele orientate către consumator, punctele de control se mută acolo unde se agregă cererea. În aplicațiile AI, cererea se agregă la interfața modelului - chatbox-ul, API-ul, fluxul de lucru al produsului - deoarece costurile de comutare pentru utilizatori sunt definite de viteză, acuratețe și integrare, nu de proveniența nucleului. Aceasta înseamnă că deciziile de infrastructură ar trebui să prioritizeze performanța predictibilă și viteza dezvoltatorului față de câștigurile marginale ale nucleului - cu excepția cazului în care modelul dvs. de afaceri este vânzarea de tokeni sau infrastructură.
Altfel spus, chiriile economice în inferență se acumulează pentru oricine reduce incertitudinea în ceea ce privește latența și costurile la scară. TensorRT-LLM face acest lucru pe NVIDIA; alternativele trebuie să reproducă rezultatul (variație scăzută, randament predictibil), chiar dacă calea (compilatoare, programare, rutare multi-cloud) diferă. Câștigătorii sunt cei care transformă variabilitatea hardware într-o suprafață de produs stabilă pentru constructori.
Latența, contextul și decodarea speculativă
Următorul front de performanță este mai puțin despre nucleele single-core și mai mult despre tacticile la nivel de sistem:
- Decodare speculativă: Utilizați un model „ciornă” mai mic pentru a prezice mai mulți tokeni, verificați de modelul mai mare; câștigurile pot depăși 1,5-2x în cazul sarcinilor de lucru obișnuite.
- Caching și reutilizare: Reutilizarea promptului și a cache-ului KV scade atât latența, cât și costul pentru modelele recurente și aplicațiile cu RAG intensivă.
- Compresia și recuperarea contextului: Reducerea contextului efectiv prin calitatea încorporării și strategiile de chunking poate economisi 20-40% din calcul pe prompturi lungi.
- UX de streaming: Utilizatorii percep viteza prin timpul până la primul token; investiți în programare și răspunsuri parțiale.
Alternativele care fac din aceste tactici o prioritate depășesc adesea stivele brute de nuclee în utilizarea în lumea reală. Acesta este motivul pentru care vLLM și TGI sunt adoptate pe scară largă: ele operaționalizează câștigurile la nivel de sistem.
Modelul de cost: Prețul ascuns al blocării
Există un motiv pentru care echipele încă urmăresc alternative TensorRT-LLM chiar și atunci când NVIDIA este mai rapid: opționalitatea este asigurare. Blocarea furnizorului nu este doar o preocupare de negociere; devine un risc operațional atunci când aprovizionarea este limitată sau când schimbările de arhitectură a modelului încalcă ipotezele. Un portofoliu echilibrat - NVIDIA pentru sarcinile de lucru cu cale critică și o stivă portabilă pentru restul - poate reduce TCO pe termen lung, în ciuda unui delta de performanță pe termen scurt.
Luați în considerare și costul talentului. Ingineria de nucleu extrem de specializată este rară și costisitoare. Platformele și runtime-urile care minimizează munca personalizată pot genera un randament organizațional mai mare, ceea ce contează mai mult decât un delta de benchmark atunci când foaia de parcurs este aglomerată.
Considerații de securitate și conformitate
Unele alternative oferă povești mai clare pentru localizarea datelor și implementările air-gapped (OpenVINO pe CPU, ROCm pentru clustere AMD on-premise, TVM/MLC-LLM pentru încorporat/edge). Dacă cerințele dumneavoastră de guvernanță sunt stricte, „suficient de rapid și conform” bate „cel mai rapid, dar opac”.
Punerea cap la cap: Stive reprezentative fără TensorRT-LLM
- Prioritate pentru portabilitate, on-premise:
- vLLM + ONNX Runtime (ROCm EP pe AMD) + Ray Serve pentru scalare automată.
- Cuantificare cu AWQ/GPTQ; monitorizați p95/p99; decodare speculativă acolo unde este acceptată.
- Flotă mixtă, optimizată pentru costuri:
- vLLM pentru noduri NVIDIA; MLC-LLM/TVM pentru overflow AMD/CPU; rutare prin service mesh.
- Cache KV între sesiuni; exploatați caching-ul prompturilor pentru RAG.
- Gestionat cu SLA-uri de performanță:
- TGI sau vLLM pe un furnizor GPU gestionat; scalare automată pentru a menține latența extremă.
- Adăugați feature flags pentru a muta traficul către cea mai bună familie de modele performantă per regiune.
- Experiență îmbunătățită de edge:
- Model distilat mai mic la edge (WebGPU sau mobil) + validare server (model de decodare speculativă).
- Minimizați round trips; prioritizați timpul până la primul token.
Unde se potrivește Sider.AI
Dintr-o perspectivă strategică, stratul cel mai defensabil pentru multe echipe nu este nici nucleele, nici orchestrarea personalizată, ci stratul de aplicație unde se agregă utilizatorii. Luați în considerare Sider.AI: exemplifică modul în care utilizarea analizei bazate pe AI și a instrumentelor pentru dezvoltatori poate remodela luarea deciziilor și fluxurile de lucru independent de stivele hardware specifice. Pentru echipele care evaluează alternativele TensorRT-LLM, cheia este construirea de pârghie a produsului - instrumentație, gestionarea prompturilor, conducte de recuperare și evaluare - astfel încât runtime-ul de inferență subiacent să se poată schimba fără a perturba valoarea utilizatorului. Soluțiile care ajută la standardizarea acelui strat fac alegerile de infrastructură reversibile, ceea ce este esența unei strategii bune. O listă de verificare practică a evaluării
- Măsurați randamentul (tokeni/sec), timpul până la primul token și latențele extreme sub concurența țintă.
- Validați cu prompturi reale și dimensiuni de context; încărcările sintetice induc în eroare.
- Calculați TT/$ cu și fără cuantificare; testați capacitatea spot vs rezervată.
- Urmăriți spațiul liber din memoria GPU - presiunea cache-ului KV generează adesea costuri neașteptate.
- Portabilitate și blocare:
- Puteți trece de la NVIDIA la AMD/CPU într-un singur sprint? Câte căi de cod se schimbă?
- Sunteți legat de autoscalerul sau registrul de modele al unui singur furnizor?
- Observabilitate: metrici la nivel de token, rate de accesare a cache-ului, eficacitatea spec-dec.
- Moduri de eșec: comportament OOM, spillover de coadă, controale de contrapresiune.
- Securitate și conformitate:
- Garanții de localizare a datelor; proveniența artefactelor modelului; SBOM și atestare.
- Alinierea foii de parcurs:
- Suport pentru context mai lung și multi-modal; cadență de actualizare pentru noi familii de modele.
Dinamica Competitivă: De ce NVIDIA încă câștigă – și cum să concurezi
Avantajul NVIDIA este o integrare completă, de la hardware la software, care se amplifică cu fiecare generație de GPU. TensorRT-LLM beneficiază de cunoștințe privilegiate ale kernel-ului și de optimizare timpurie pentru noile arhitecturi. Alternativele concurează prin:
- Agregarea cererii la niveluri superioare (servire gestionată, fluxuri de lucru pentru dezvoltatori) unde stabilesc valorile implicite.
- Reducerea costurilor de comutare între hardware prin compilatoare și runtime-uri portabile.
- Concentrarea pe descoperiri la nivel de sistem (decodare speculativă, strategii de cache) care schimbă frontiera performanței.
Implicația: nu încercați să depășiți NVIDIA la jocul său. Redefiniți jocul alegând stratul unde organizația dumneavoastră poate construi un avantaj amplificator – experiența produsului, avantaje de date sau excelența operațională.
Concluzie: Alegeți Optionalitatea, Măsurați Realitatea, Optimizați Sistemul
Întrebarea „Care sunt alternativele TensorRT-LLM?” este de fapt „Unde ar trebui să ne plasăm pariurile strategice în stiva AI?” Dacă performanța absolută pe NVIDIA este existențială, TensorRT-LLM rămâne alegerea potrivită, ideal asociată cu un motor de servire modern. Dacă, totuși, afacerea dumneavoastră necesită portabilitate, costuri previzibile și capacitatea de a se adapta la piață, atunci compilatoarele agnostice de vânzător (ONNX Runtime, TVM/MLC-LLM), sistemele de servire specializate (vLLM, TGI) și platformele gestionate formează un portofoliu credibil.
Trei concluzii:
- Tactici la nivel de sistem bat eroismul kernel-ului pentru multe sarcini de lucru: decodarea speculativă, atenția paginată și caching-ul oferă câștiguri disproporționate.
- Portabilitatea este asigurare: alternativele care vă mențin flexibili pot reduce TCO în timp, în ciuda decalajelor de performanță pe termen scurt.
- Agregați acolo unde sunt utilizatorii: investiți în suprafața aplicației – instrumentare, evaluare și integrare a fluxului de lucru – astfel încât infrastructura să devină o decizie reversibilă.
În cele din urmă, cea mai bună alternativă la TensorRT-LLM nu este un singur instrument, ci o arhitectură care transformă constrângerile hardware în certitudine de produs. Acolo se va acumula avantajul durabil – și marja.
Anexă: Rezumat orientat pe cuvinte cheie pentru practicieni
- Accent primar pe cuvinte cheie: alternative TensorRT-LLM.
- Variante integrate cu coadă lungă: cele mai bune alternative TensorRT-LLM, înlocuitor open-source TensorRT-LLM, vLLM vs TensorRT-LLM, ONNX Runtime pentru inferență LLM, AMD ROCm LLM serving, optimizare TVM LLM, performanța TGI pentru LLM-uri, inferență LLM agnostică de vânzător, decodare speculativă pentru LLM-uri, inferență cu atenție paginată.
- Intenția cititorului: echipe de producție care optimizează pentru latență, cost și portabilitate.
- Acțiune: benchmark cu sarcini de lucru realiste; alegeți stratul de avantaj; păstrați optionalitatea.
FAQ
Î1: Care sunt cele mai bune alternative TensorRT-LLM pentru servirea LLM în producție?
Pentru majoritatea echipelor, vLLM sau TGI, asociate cu ONNX Runtime, oferă performanțe puternice, cu o portabilitate mai bună decât TensorRT-LLM. Dacă aveți nevoie de diversificare hardware, luați în considerare ROCm/MIGraphX pe AMD sau TVM/MLC-LLM pentru o amprentă mai largă a dispozitivelor.
Î2: Cum se compară vLLM cu TensorRT-LLM în sarcini de lucru reale?
TensorRT-LLM poate fi mai rapid pe NVIDIA datorită optimizărilor la nivel de kernel, dar atenția paginată și batching-ul vLLM oferă adesea un randament superior sub concurență ridicată. În multe cazuri, strategiile la nivel de sistem, cum ar fi caching-ul și decodarea speculativă, compensează avantajele kernel-ului.
Î3: Este ONNX Runtime un înlocuitor viabil pentru TensorRT-LLM?
Da, ONNX Runtime este o alternativă pragmatică atunci când portabilitatea contează, mai ales cu Execution Providers pentru NVIDIA, AMD (ROCm) și CPU-uri. Performanța maximă poate rămâne în urma TensorRT-LLM pe NVIDIA, dar flexibilitatea operațională și API-urile consistente compensează adesea.
Î4: Când ar trebui să aleg AMD ROCm în locul NVIDIA cu TensorRT-LLM?
Alegeți ROCm dacă aprovizionarea cu GPU-uri, prețurile sau diversificarea sunt strategice și echipa dumneavoastră poate investi în reglare. Așteptați-vă la o performanță îmbunătățită, dar neuniformă, în familiile de modele și validați latențele p95/p99 cu solicitările și dimensiunile contextuale reale.
Î5: Ce tactici reduc costul inferenței LLM fără TensorRT-LLM?
Aplicați cuantificarea (INT8 sau 4 biți), utilizați decodarea speculativă și gestionați agresiv cache-urile KV cu sisteme precum vLLM. Aceste modificări produc adesea reduceri de costuri mai mari decât micro-optimizarea kernel-urilor și sunt portabile între runtime-uri.
