Resposta curta: per optimitzar els models d'IA, trieu una restricció principal (latència, cost, memòria, qualitat, estabilitat o rendiment) i, a continuació, captureu una línia de base fiable abans de canviar res. Primer elimineu els colls d'ampolla de la canonada i, a continuació, apliqueu guanys de baix risc com ara precisió mixta i processament per lots; si la qualitat es manté, passeu a les eines de compilació/temps d'execució i només llavors reduïu la mida del model mitjançant quantificació o destil·lació quan calgui.
Conclusions clau:
Restricció : Trieu una o dues mètriques objectiu; l'optimització és un paisatge de compromisos, no de victòries gratuïtes.
Mesura : Crea perfils de càrregues de treball reals amb p50/p95/p99, rendiment, utilització i pics de memòria.
Pipeline : Corregiu la tokenització, els carregadors de dades, el preprocessament i el processament per lots abans de tocar el model.
Publicació : utilitzeu la memòria cau, el processament per lots deliberat, l'ajust de la concurrència i vigileu de prop la latència de la cua.
Baranes de seguretat : Executeu indicacions d'or, mètriques de tasques i comprovacions puntuals després de cada canvi de rendiment.

🔗 Com avaluar els models d'IA de manera eficaç
Criteris i passos clau per jutjar els models de manera justa i fiable.
🔗 Com mesurar el rendiment de la IA amb mètriques reals
Utilitzeu punts de referència, latència, cost i senyals de qualitat per comparar.
🔗 Com provar models d'IA abans de la producció.
Flux de treball pràctic de proves: divisions de dades, casos d'estrès i monitorització.
🔗 Com utilitzar la IA per a la creació de contingut
Converteix idees en esborranys més ràpidament amb indicacions estructurades i iteració.
1) Què significa «optimitzar» a la pràctica (perquè tothom ho fa servir de manera diferent) 🧠
Quan la gent diu "optimitzar un model d'IA", potser volen dir:
-
Fes-ho més ràpid (latencia més baixa)
-
Fer-ho més barat (menys hores de GPU, menys despesa al núvol)
-
Fer-ho més petit (empremta de memòria, desplegament perimetral)
-
Fer-ho més precís (millores de qualitat, menys al·lucinacions)
-
Fer-lo més estable (menys variància, menys errors en la producció)
-
Facilitar el servei (rendiment, processament per lots, rendiment predictible)
Aquí teniu la veritat lleugerament molesta: no podeu maximitzar-ho tot alhora. L'optimització és com prémer un globus: si en feu un costat cap a dins, l'altre surt. No sempre, però prou sovint com per planificar els inconvenients.
Així doncs, abans de tocar res, trieu la vostra restricció principal :
-
Si doneu servei als usuaris en directe, us importa la latència p95 ( percentils d'AWS CloudWatch ) i el rendiment final ( pràctica recomanada de "latència final" ) 📉
-
Si estàs entrenant, t'importa el temps de qualitat i l'ús de la GPU 🔥
-
Si esteu implementant en dispositius, us importa la RAM i la potència 🔋
2) Quin aspecte té una bona versió de l'optimització de models d'IA ✅
Una bona versió d'optimització no és només "aplicar quantificació i pregar". És un sistema. Les millors configuracions solen tenir:
-
Una línia de base en què confies
Si no pots reproduir els teus resultats actuals, no pots saber que has millorat res. Simple... però la gent s'ho passa per alt. Aleshores entren en espiral. -
Una mètrica objectiu clara
"Més ràpid" és imprecisa. "Reduir la latència de p95 de 900 ms a 300 ms amb la mateixa puntuació de qualitat" és un objectiu real. -
Baranes per a la qualitat
Cada victòria en el rendiment corre el risc d'una regressió silenciosa de la qualitat. Necessiteu proves, avaluacions o, si més no, un conjunt de mesures de seguretat. -
Consciència del maquinari
Un model "ràpid" en una GPU pot rastrejar-se en una altra. Les CPU són el seu propi tipus especial de caos. -
Canvis iteratius, no una reescriptura a cops de gegant
Quan canvies cinc coses alhora i el rendiment millora, no saps per què. La qual cosa és... inquietant.
L'optimització hauria de ser com afinar una guitarra: petits ajustos, escolta atentament, repeteix 🎸. Si et sembla fer malabars amb ganivets, alguna cosa no va bé.
3) Taula comparativa: Opcions populars per optimitzar models d'IA 📊
A continuació es mostra una taula comparativa ràpida i una mica desordenada d'eines/enfocaments d'optimització comuns. No, no és perfectament "just", la vida real tampoc ho és.
| Eina / Opció | Públic | Preu | Per què funciona |
|---|---|---|---|
PyTorch torch.compile ( documentació de PyTorch ) |
Gent de PyTorch | Gratuït | Els trucs de captura de gràfics i compilació poden reduir la despesa general... de vegades és màgia ✨ |
| Temps d'execució d'ONNX ( documents d'ONNX Runtime ) | Equips de desplegament | Gratuït | Optimitzacions d'inferència fortes, suport ampli, bo per a la publicació estandarditzada |
| TensorRT ( documentació de NVIDIA TensorRT ) | Implementació d'NVIDIA | Vibracions de pagament (sovint incloses) | Fusió agressiva del nucli + maneig de precisió, molt ràpid quan fa clic |
| DeepSpeed ( documents de ZeRO ) | Equips de formació | Gratuït | Optimitzacions de memòria + rendiment (ZeRO, etc.). Pot semblar un motor de reacció |
| FSDP (PyTorch) ( documentació de PyTorch FSDP ) | Equips de formació | Gratuït | Paràmetres/gradients de Shards, fa que els models grans siguin menys aterridors |
| quantificació de bitsandbytes ( bitsandbytes ) | Retocadors de LLM | Gratuït | Pesos baixos en bits, grans estalvis de memòria: la qualitat depèn, però uf 😬 |
| Destil·lació ( Hinton et al., 2015 ) | Equips de producte | "Cost de temps" | El model d'estudiant més petit hereta el comportament, normalment el millor retorn de la inversió a llarg termini |
| Poda ( tutorial de poda amb PyTorch ) | Recerca + producció | Gratuït | Elimina el pes mort. Funciona millor quan es combina amb un reentrenament |
| Flash Attention / grans fusionats ( paper FlashAttention ) | Friquis del rendiment | Gratuït | Atenció més ràpida, millor comportament de memòria. Una veritable victòria per als transformadors |
| Servidor d'inferència Triton ( processament per lots dinàmic ) | Operacions/infraestructures | Gratuït | Servei de producció, processament per lots, pipelines multimodel: sembla empresarial |
Confessió de peculiaritat del format: el "preu" és desordenat perquè el codi obert encara et pot costar un cap de setmana de depuració, cosa que és... un preu. 😵💫
4) Comença amb les mesures: fes un perfil amb sinceritat 🔍
Si només feu una cosa de tota aquesta guia, feu això: mesureu correctament.
En les meves pròpies proves, els majors "avenços en optimització" van venir de descobrir alguna cosa vergonyosament simple com ara:
-
carregador de dades que deixa la GPU sense recursos
-
Coll d'ampolla de preprocessament de la CPU
-
mides de lots petites que causen una sobrecàrrega d'arrencada del nucli
-
tokenització lenta (els tokenitzadors poden ser vilans tranquils)
-
fragmentació de la memòria ( notes de l'assignador de memòria CUDA de PyTorch )
-
una computació dominant d'una sola capa
Què cal mesurar (conjunt mínim)
-
Latència (p50, p95, p99) ( SRE en els percentils de latència )
-
Rendiment (tokens/segon, sol·licituds/segon)
-
Ús de la GPU (càlcul + memòria)
-
Pics de VRAM / RAM
-
Cost per 1k tokens (o per inferència)
Mentalitat pràctica de perfilació
-
Fes un perfil d'un escenari que t'interessi (no és una joguina).
-
Registra-ho tot en un petit "diari perfecte".
Sí, és tediós... però t'estalvia haver de manipular-te més tard.
(Si voleu una eina concreta per començar: PyTorch Profiler ( documentació de torch.profiler ) i Nsight Systems ( NVIDIA Nsight Systems ) són les eines habituals.)
5) Optimització de dades + entrenament: el superpoder silenciós 📦🚀
La gent s'obsessiona amb l'arquitectura del model i s'oblida del pipeline. Mentrestant, el pipeline crema silenciosament la meitat de la GPU.
Victòries fàcils que apareixen ràpidament
-
Utilitzeu precisió mixta (FP16/BF16 on sigui estable) ( PyTorch AMP / torch.amp ).
Normalment més ràpid, sovint correcte, però aneu amb compte amb les peculiaritats numèriques. -
Acumulació de gradient quan la mida del lot és limitada ( 🤗 Guia d'acceleració )
Manté l'optimització estable sense fer explotar la memòria. -
Punts de control de gradient ( torch.utils.checkpoint )
Intercanvia la computació per la memòria: fa factibles contextos més grans. -
Tokenització eficient ( 🤗 Tokenitzadors )
La tokenització pot convertir-se en el coll d'ampolla a gran escala. No és glamurós; importa. -
Ajust del carregador de dades
Més treballadors, memòria fixada, precàrrega: poc vistós però efectiu 😴➡️💪 ( Guia d'ajust del rendiment de PyTorch )
Ajustament fi eficient dels paràmetres
Si esteu ajustant models grans, els mètodes PEFT (com els adaptadors d'estil LoRA) poden reduir enormement el cost d'entrenament alhora que es mantenen sorprenentment forts ( 🤗 Guia Transformers PEFT , article LoRA ). Aquest és un d'aquells moments de "per què no ho vam fer abans?".
6) Optimització a nivell d'arquitectura: dimensionar correctament el model 🧩
De vegades, la millor manera d'optimitzar és... deixar d'utilitzar un model que és massa gran per a la feina. Ho sé, un sacrilegi 😄.
Fes una trucada sobre alguns conceptes bàsics:
-
Decideix si necessites vibracions d'intel·ligència general completa o un especialista.
-
Mantingueu la finestra de context tan gran com calgui, no més gran.
-
Utilitzeu un model entrenat per a la feina en qüestió (models de classificació per a treballs de classificació, etc.).
Estratègies pràctiques de mida correcta
-
Canvieu a una xarxa troncal més petita per a la majoria de sol·licituds.
A continuació, encamineu les "consultes difícils" a un model més gran. -
Utilitzeu una configuració de dues etapes.
Esborranys ràpids del model, verificacions o edicions més sòlides del model.
És com escriure amb un amic exigent: molest, però eficaç. -
Reduir la longitud de la sortida
Els tokens de sortida costen diners i temps. Si el vostre model divaga, pagueu per la divagació.
He vist equips reduir costos dràsticament imposant resultats més curts. Sembla insignificant. Funciona.
7) Compilador + Optimitzacions de gràfics: D'on ve la velocitat 🏎️
Aquesta és la capa de "fer que l'ordinador faci coses informàtiques més intel·ligents".
Tècniques comunes:
-
Fusió d'operadors (combinació de nuclis) ( NVIDIA TensorRT "fusió de capes" )
-
Plegament constant (precalcula valors fixos) ( optimitzacions de gràfics en temps d'execució d'ONNX )
-
Selecció del nucli ajustada al maquinari
-
Captura de grafs per reduir la sobrecàrrega de Python ( visió general
de torch.compile)
En termes senzills: el vostre model pot ser ràpid matemàticament, però lent operativament. Els compiladors solucionen part d'això.
Notes pràctiques (també conegudes com a cicatrius)
-
Aquestes optimitzacions poden ser sensibles als canvis de forma del model.
-
Alguns models acceleren molt, d'altres amb prou feines es mouen.
-
De vegades tens una acceleració i un error desconcertant, com si s'hagués instal·lat un gremlin 🧌
Tot i això, quan funciona, és una de les victòries més netes.
8) Quantificació, poda, destil·lació: Més petit sense plorar (massa) 🪓📉
Aquesta és la secció que la gent vol... perquè sona a actuació gratuïta. Pot ser-ho, però cal tractar-ho com si fos cirurgia.
Quantització (pesos/activacions de menor precisió)
-
Ideal per a la velocitat d'inferència i la memòria
-
Risc: baixades de qualitat, especialment en casos extrems
-
Millor pràctica: avaluar en un conjunt de proves real, no en vibracions
Sabors comuns dels quals sentiràs a parlar:
-
INT8 (sovint sòlid) ( tipus quantificats TensorRT )
-
INT4 / baix bit (gran estalvi, augmenta el risc de qualitat) ( quantització de bits i bytes de k-bit )
-
Quant mixt (no tot necessita la mateixa precisió)
Poda (eliminar paràmetres)
-
Elimina pesos o estructures "no importants" ( tutorial de poda de PyTorch )
-
Normalment necessita una reeducació per recuperar la qualitat
-
Funciona millor del que la gent pensa... quan es fa amb cura
Destil·lació (l'alumne aprèn del professor)
Aquesta és la meva palanca a llarg termini preferida. La destil·lació pot produir un model més petit que es comporta de manera similar, i sovint és més estable que la quantització extrema ( Destil·lació del coneixement en una xarxa neuronal ).
Una metàfora imperfecta: la destil·lació és com abocar una sopa complicada a través d'un filtre i obtenir... una sopa més petita. La sopa no funciona així, però ja ho entens 🍲.
9) Servir i inferència: la veritable zona de batalla 🧯
Pots "optimitzar" un model i seguir servint-lo malament. El servei és on la latència i el cost es tornen reals.
Servir guanya coses que importen
-
Processament per lots
Millora el rendiment. Però augmenta la latència si s'excedeix. Equilibra-ho. ( Triton dynamic lotging ) -
en memòria cau
de les indicacions i la reutilització de la memòria cau KV poden ser massius per a contextos repetits. ( Explicació de la memòria cau KV ) -
Sortida en temps real
Els usuaris senten que és més ràpid fins i tot si el temps total és similar. La percepció importa 🙂. -
Reducció de la despesa addicional per cada token
Algunes piles fan feina addicional per token. Reduïu aquesta despesa i guanyareu molt.
Vigileu la latència de la cua
La teva mitjana pot semblar fantàstica mentre que el teu p99 és un desastre. Malauradament, els usuaris viuen a la cua. ( "Latència de la cua" i per què les mitjanes menteixen )
10) Optimització basada en maquinari: fes coincidir el model amb la màquina 🧰🖥️
Optimitzar sense tenir en compte el maquinari és com afinar un cotxe de carreres sense comprovar els pneumàtics. Segur que ho pots fer, però és una mica absurd.
Consideracions sobre la GPU
-
L'amplada de banda de memòria sovint és el factor limitant, no el càlcul en brut
-
Els lots més grans poden ajudar, fins que ja no ho fan
-
La fusió del nucli i les optimitzacions d'atenció són enormes per als transformadors ( FlashAttention: atenció exacta amb consciència d'E/S )
Consideracions sobre la CPU
-
El threading, la vectorització i la localitat de la memòria importen molt
-
La sobrecàrrega de tokenització pot dominar ( 🤗 Tokenitzadors "ràpids" )
-
Potser necessiteu estratègies de quantificació diferents de les de la GPU
Consideracions sobre la perifèria / mòbil
-
La petjada de memòria esdevé la prioritat número u
-
La variància de latència és important perquè els dispositius són... malhumorats
-
Els models més petits i especialitzats sovint superen els grans models generals
11) Baranes de protecció de qualitat: no us "optimitzeu" fins a convertir-vos en un error 🧪
Cada victòria ràpida hauria de venir amb una comprovació de qualitat. Si no, ho celebrareu, enviareu i després rebreu un missatge com ara "per què l'assistent de sobte parla com un pirata?" 🏴☠️
Baranes pragmàtiques:
-
Indicacions d'or (conjunt fix d'indicacions que sempre proves)
-
Mètriques de tasca (precisió, F1, BLEU, el que s'adapti)
-
Controls puntuals humans (sí, de debò)
-
Llindars de regressió ("no es permet una caiguda superior a un X%)
També feu un seguiment dels modes de fallada:
-
deriva de formatació
-
canvis de comportament de rebuig
-
freqüència d'al·lucinacions
-
inflació de la longitud de resposta
L'optimització pot canviar el comportament de maneres sorprenents. De manera peculiar. Irritant. Previsiblement, en retrospectiva.
12) Llista de comprovació: Com optimitzar els models d'IA pas a pas ✅🤖
Si voleu un ordre clar d'operacions per a Com optimitzar els models d'IA , aquest és el flux de treball que tendeix a mantenir la gent assenyada:
-
Definiu l'èxit.
Trieu 1 o 2 mètriques principals (latència, cost, rendiment, qualitat). -
Mesurar
les càrregues de treball reals del perfil de referència, registrar p50/p95, memòria, cost. ( PyTorch Profiler ) -
Corregir els colls d'ampolla de la canonada.
Càrrega de dades, tokenització, preprocessament i processament per lots. -
Aplica victòries de computació de baix risc.
Precisió mixta, optimitzacions del nucli, millor processament per lots. -
Prova optimitzacions del compilador/temps d'execució.
Captura de gràfics, temps d'execució d'inferència, fusió d'operadors. ( tutorialde torch.compile, documentació d'ONNX Runtime ) -
Reduir el cost del model
Quantificar amb cura, destil·lar si es pot, podar si s'escau. -
Ajusta el servei de memòria
cau, concurrència, proves de càrrega i correccions de latència de la cua. -
Validar la qualitat
Executar proves de regressió i comparar els resultats una al costat de l'altra. -
Iterar
Petits canvis, aclarir notes, repetir. Discret - efectiu.
I sí, això encara és Com optimitzar els models d'IA, fins i tot si sembla més aviat "Com deixar de trepitjar els rastrejadors". El mateix.
13) Errors comuns (perquè no els repetiu com la resta de nosaltres) 🙃
-
Optimitzar abans de mesurar
Perdràs temps. I aleshores optimitzaràs la cosa equivocada amb confiança... -
Perseguir un únic punt de referència
Els punts de referència menteixen per omissió. La teva càrrega de treball és la veritat. -
Ignorar la memòria
Els problemes de memòria provoquen alentiments, bloquejos i fluctuacions. ( Comprensió de l'ús de memòria CUDA a PyTorch ) -
Sobrequantitzar massa aviat
La quantificació de bits baixos pot ser sorprenent, però comenceu primer amb passos més segurs. -
Sense pla de reversió
Si no es pot revertir ràpidament, cada desplegament esdevé estressant. L'estrès crea errors.
Notes finals: La manera humana d'optimitzar 😌⚡
Com optimitzar els models d'IA no és un truc únic. És un procés per capes: mesurar, arreglar el pipeline, utilitzar compiladors i temps d'execució, ajustar el servei i, a continuació, reduir el model amb quantització o destil·lació si cal. Fes-ho pas a pas, mantén les barreres de seguretat de qualitat i no confiïs en "se sent més ràpid" com a mètrica (les teves sensacions són encantadores, les teves sensacions no són un perfilador).
Si voleu el menjar per emportar més curt:
-
Mesura primer 🔍
-
Optimitza el pipeline a continuació 🧵
-
Aleshores optimitzeu el model 🧠
-
Aleshores, optimitza el servei 🏗️
-
Mantingueu sempre controls de qualitat ✅
I si us ajuda, recordeu-vos: l'objectiu no és un "model perfecte". L'objectiu és un model que sigui ràpid, assequible i prou fiable com per poder dormir a la nit... la majoria de les nits 😴.
Preguntes freqüents
Què significa optimitzar un model d'IA a la pràctica
«Optimitzar» normalment significa millorar una restricció principal: la latència, cost, petjada de memòria, precisió, estabilitat o rendiment de servei. La part difícil són els compromisos: impulsar una àrea pot afectar-ne una altra. Un enfocament pràctic és triar un objectiu clar (com la latència p95 o el temps de qualitat) i optimitzar en funció d'aquest. Sense un objectiu, és fàcil «millorar» i tot i així perdre.
Com optimitzar els models d'IA sense perjudicar silenciosament la qualitat
Tracteu cada canvi de velocitat o cost com una possible regressió silenciosa. Utilitzeu barreres com ara indicacions d'or, mètriques de tasques i comprovacions puntuals humanes ràpides. Establiu un llindar clar per a una deriva de qualitat acceptable i compareu els resultats una al costat de l'altra. Això evita que "és més ràpid" es converteixi en "per què de sobte s'ha tornat estrany en producció?" després d'enviar.
Què cal mesurar abans de començar a optimitzar
Comença amb els percentils de latència (p50, p95, p99), el rendiment (tokens/segon o sol·licituds/segon), l'ús de la GPU i el màxim de VRAM/RAM. Fes un seguiment del cost per inferència o per 1000 tokens si el cost és una restricció. Crea un perfil d'un escenari real que serveixis, no d'una proposta de joguina. Portar un petit "diari de rendiment" t'ajuda a evitar endevinar i repetir errors.
Victòries ràpides i de baix risc per al rendiment de l'entrenament
La precisió mixta (FP16/BF16) sovint és la primera palanca més ràpida, però cal anar amb compte amb les peculiaritats numèriques. Si la mida del lot és limitada, l'acumulació de gradient pot estabilitzar l'optimització sense consumir memòria. Els punts de control de gradient intercanvien càlcul addicional per menys memòria, permetent contextos més grans. No ignoreu la tokenització i l'ajust del carregador de dades: poden deixar la GPU sense funcionar.
Quan s'ha d'utilitzar torch.compile, ONNX Runtime o TensorRT
Aquestes eines es centren en la sobrecàrrega operativa: captura de gràfics, fusió de nuclis i optimitzacions de gràfics en temps d'execució. Poden oferir acceleracions d'inferència netes, però els resultats varien segons la forma del model i el maquinari. Algunes configuracions semblen màgiques; d'altres amb prou feines es mouen. Espereu sensibilitat als canvis de forma i errors ocasionals de "gremlin": mesureu abans i després amb la vostra càrrega de treball real.
Si val la pena la quantització i com evitar anar massa lluny
La quantificació pot reduir la memòria i accelerar la inferència, especialment amb INT8, però la qualitat pot baixar en casos límit. Les opcions de bits més baixos (com INT4/k-bit) aporten un estalvi més gran amb un risc més elevat. L'hàbit més segur és avaluar en un conjunt de proves real i comparar els resultats, no la intuïció. Comenceu primer amb passos més segurs i després aneu a una precisió més baixa només si cal.
La diferència entre la poda i la destil·lació per a la reducció de la mida del model
La poda elimina els paràmetres de "pes mort" i sovint necessita un nou entrenament per recuperar la qualitat, sobretot quan es fa de manera agressiva. La destil·lació entrena un model d'estudiant més petit per imitar el comportament d'un professor més gran, i pot ser un retorn de la inversió a llarg termini més fort que la quantificació extrema. Si voleu un model més petit que es comporti de manera similar i es mantingui estable, la destil·lació sovint és el camí més net.
Com reduir el cost i la latència de la inferència mitjançant millores en el servei
El servei és on l'optimització esdevé tangible: el processament per lots augmenta el rendiment però pot perjudicar la latència si s'excedeix, així que ajusteu-lo amb cura. L'emmagatzematge en memòria cau (emmagatzematge en memòria cau ràpida i reutilització de la memòria cau KV) pot ser massiu quan els contextos es repeteixen. La sortida de transmissió en temps real millora la velocitat percebuda fins i tot si el temps total és similar. També busqueu la sobrecàrrega token per token a la vostra pila: una petita feina per token s'acumula ràpidament.
Per què la latència de la cua és tan important a l'hora d'optimitzar models d'IA
Les mitjanes poden semblar molt bones mentre que p99 és un desastre, i els usuaris tendeixen a viure a la cua. La latència de la cua sovint prové del jitter: fragmentació de la memòria, pics de preprocessament de la CPU, alentiments de la tokenització o un mal comportament de processament per lots. És per això que la guia emfatitza els percentils i les càrregues de treball reals. Si només optimitzeu p50, encara podeu oferir una experiència que "se sent lenta aleatòriament"
Referències
-
Amazon Web Services (AWS) - Percentils d'AWS CloudWatch (definicions d'estadístiques) - docs.aws.amazon.com
-
Google - La cua a escala (pràctica recomanada per a la latència de la cua) - sre.google
-
Google - Objectius de nivell de servei (Llibre SRE) - percentils de latència - sre.google
-
PyTorch - torch.compile - docs.pytorch.org
-
PyTorch - FullyShardedDataParallel (FSDP) - docs.pytorch.org
-
PyTorch - PyTorch Profiler - docs.pytorch.org
-
PyTorch - Semàntica CUDA: gestió de memòria (notes sobre l'assignador de memòria CUDA) - docs.pytorch.org
-
PyTorch - Precisió mixta automàtica (torch.amp / AMP) - docs.pytorch.org
-
PyTorch - torch.utils.checkpoint - docs.pytorch.org
-
PyTorch - Guia d'ajustament del rendiment - docs.pytorch.org
-
PyTorch - Tutorial de poda - docs.pytorch.org
-
PyTorch - Comprendre l'ús de memòria CUDA a PyTorch - docs.pytorch.org
-
PyTorch - tutorial / visió general de torch.compile - docs.pytorch.org
-
Temps d'execució d'ONNX - Documentació del temps d'execució d'ONNX - onnxruntime.ai
-
NVIDIA - Documentació de TensorRT - docs.nvidia.com
-
NVIDIA - Tipus quantificats TensorRT - docs.nvidia.com
-
NVIDIA - Nsight Systems - developer.nvidia.com
-
NVIDIA - Servidor d'inferència Triton - processament dinàmic per lots - docs.nvidia.com
-
DeepSpeed - Documentació de la fase 3 de ZeRO - deepspeed.readthedocs.io
-
bitsandbytes (bitsandbytes-foundation) - bitsandbytes - github.com
-
Abraçant la Cara - Accelera: Guia d'Acumulació de Gradient - huggingface.co
-
Cara d'abraçada - Documentació de tokenitzadors - huggingface.co
-
Cara Abraçadora - Transformers: Guia PEFT - huggingface.co
-
Cara Abraçadora - Transformers: explicació de la memòria cau KV - huggingface.co
-
Cara Abraçadora - Transformers: Tokenitzadors "ràpids" (classes de tokenitzadors) - huggingface.co
-
arXiv - Destil·lant el coneixement en una xarxa neuronal (Hinton et al., 2015) - arxiv.org
-
arXiv - LoRA: Adaptació de baix rang de models de llenguatge grans - arxiv.org
-
arXiv - FlashAttention: Atenció exacta ràpida i eficient en memòria amb IO-Awareness - arxiv.org