Personlig AI: bærbare computere, arbejdsstationer og deres muligheder
Opdateret: for 1 dag siden
Fremkomsten af kraftige centralprocessorer fra NVIDIA, AMD og Apple Silicon kombineret med store mængder delt hukommelse har gjort lokal AI tilgængelig i forskellige formater: fra bærbare computere til kompakte arbejdsstationer til hjemmet. Denne nye klasse af computere, der primært er udviklet til at køre AI-modeller lokalt, kaldes også nogle gange „agentiske computere“.
De har en fælles arkitektur, hvor processoren og den integrerede grafikaccelerator bruger den samme store pulje af hurtig hukommelse. Det gør det muligt at holde en stor og funktionelt kapabel LLM-model tæt på beregningsenhederne uden konstant at flytte dele af den over en langsom forbindelse til et separat grafikkort.
Den vigtigste praktiske grund til at køre AI lokalt er muligheden for at behandle dokumenter, kildekode og interne vidensbaser uden at sende dem til en cloudtjeneste. For en virksomhed er det nyttigt og ofte afgørende, når man arbejder med fortrolige oplysninger eller et lukket virksomhedsrepository med kildekode.
En anden fordel ved at køre LLM lokalt er, at man undgår betaling for hvert API-kald, når man arbejder med en lokal model. Den direkte driftsudgift ved sådan en model er den elektricitet, der skal til for at drive computeren, men man bør også tage højde for købsprisen på maskinen, som til gengæld vil tjene én i flere år. Lokal kørsel giver også mulighed for at arbejde uden internet og selv vælge den model, der passer bedst til bestemte opgaver (programmering, agentarbejde, oversættelse, generering af billeder, video, lyd osv.).
Hvorfor er en stor mængde delt hukommelse så vigtig?
En almindelig PC med en dedikeret GPU kan også være en fremragende maskine til lokal AI. Så længe den valgte model kan være fuldt ud i VRAM, og der er plads til KV-cache og arbejdsbuffere, kan acceleratoren behandle forespørgsler meget hurtigt. Det ville derfor ikke være helt korrekt at betragte alle computere med et separat grafikkort som uegnede til AI.
Begrænsningen opstår, når en stor model (og netop store modeller er de mest værdifulde og nødvendige til professionel brug) ikke længere har plads i grafikhukommelsen. Programmet melder enten om manglende hukommelse, flytter en del af arbejdet til CPU og systemets RAM eller indlæser vægte fra RAM eller SSD. Sådanne overførsler og langsommere lagring kan øge ventetiden markant, helt op til et niveau, der er uacceptabelt for en interaktiv assistent. Der findes ingen enkeltfaktor for hastighedstabet: programmet til at køre modellen, andelen af flyttede vægte, modellen og hardwaren spiller alle en rolle. I praksis kan ydeevnen dog falde med en faktor 5-10 i sådanne situationer.
Store mængder system-RAM ved siden af en lille dedikeret GPU bliver ikke automatisk til en tilsvarende mængde hurtig VRAM.
I løsninger baseret på NVIDIA RTX/DGX Spark, AMD Ryzen AI Max og Apple Silicon Max/Ultra er fokus et andet: grafikacceleratoren har adgang til en stor mængde delt hukommelse inden for den understøttede arkitektur. Det udvider udvalget af store modeller.
128GB og derover er den rettesnor, som denne artikel bruger for store modeller, der kan løse opgaver, som brugerne normalt henvender sig til cloudmodeller via API eller abonnement for at få løst. Til mindre specialiserede modeller eller forsøg med stærkt kvantiserede og destillerede modeller og et begrænset kontekstvindue kan en mindre mængde være tilstrækkelig.
Store mængder hukommelse giver også råderum til mindre komprimering af vægtene (og dermed bedre bevarelse af kvaliteten) og et større kontekstvindue.
Hvor lokal AI er nyttig i det daglige arbejde
Assistent til interne dokumenter. Hvis du har en stor database med dokumentation, kan det give mening at bygge et RAG-system, som først finder relevante uddrag i den lokale vidensbase og derefter sender dem til LLM-modellen for at få et svar med henvisninger til dokumenterne. LLM kan søge efter nøgleord i dokumentationen, men hvis arbejde med dokumentarkiver er hovedopgaven, kan RAG gøre søgningen mere præcis og effektiv, fordi det er en vektordatabase.
Arbejde med kildekode. Modellen hjælper med at forklare dele af et projekt, foreslå ændringer, skrive kode og teste. Topmodeller fra Anthropic eller OpenAI giver et bedre resultat, men det er cloudløsninger, som ikke er tilgængelige for alle, ikke altid kan bruges af hensyn til fortrolighed og kan være meget dyre i drift. Hvis cloudløsninger er tilladt i dit arbejdsmiljø, kan man fordele belastningen, så rutineopgaver delegeres til lokale modeller, mens den afsluttende gennemgang og arkitekturen håndteres af topmodeller i skyen.
Kørsel af tests og rutineopgaver i baggrunden (om natten). Dit team kan have regelmæssige, tilbagevendende opgaver, der skal startes efter et bestemt scenarie, en hændelse eller en tidsplan og involverer brug af værktøjer: parsing og analyse af logs, test af udgivelser og søgning efter nye dokumenter både i lokale kilder og på internettet.
Fællesassistent til et mindre team. En kompakt station kan placeres på kontoret, og den lokale model kan tilgås fra flere computere. NVIDIA PAIR kan fordele uafhængige forespørgsler fra Ollama eller LM Studio mellem tilsluttede kompatible systemer.
Billedgenerering. Til en computer med 128GB hukommelse er det værd at overveje FLUX.1-dev til billeder: det valgte sæt Diffusers-vægte sammen med tekstencodere og VAE fylder cirka 33.74GB. NVIDIA udgiver en vejledning til kørsel via ComfyUI på DGX Spark.
Videogenerering. Et eksempel på en lokal model til dette formål er Wan2.2-T2V-A14B: det oprindelige sæt med to eksperter i FP32, en tekstencoder og VAE fylder cirka 126.18GB. Modellens officielle eksempel til 720p kræver mindst 80GB.
Talesyntese. Til at generere tale på forskellige sprog kan man bruge Qwen3-TTS-12Hz-1.7B-CustomVoice sammen med en taletokenizer; vægtfilerne fylder cirka 4.52GB. Et større alternativ er MOSS-TTS-v1.5 med 8B parametre: 31 sprog, stemmekloning ud fra en prøve, lange optagelser samt styring af varighed, udtale via IPA og pauser. De primære vægte fylder cirka 16.98GB, og den obligatoriske MOSS-Audio-Tokenizer yderligere 7.10GB, i alt cirka 24.08GB. Apache 2.0-licensen tillader kommerciel brug. Det er et bredere udvalg af funktioner, ikke et bevis på bedre lyd med enhver tekst.
Talegenkendelse. Til lokal transskription af møder, interviews og stemmenoter kan man bruge Qwen3-ASR-1.7B: modellen understøtter 30 sprog, herunder russisk, automatisk sproggenkendelse og løbende talegenkendelse. BF16-vægtfilerne fylder cirka 4.70GB. Til tidsstempler på ord bruges desuden Qwen3-ForcedAligner-0.6B med vægte på cirka 1.84GB. Begge modeller er tilgængelige under Apache 2.0. Hukommelsesforbruget ved kørsel er større end filstørrelsen og afhænger af buffere og parallelle streams.
En stor mængde delt hukommelse garanterer ikke i sig selv, at modellen kan køres: for hver chip, især AMD og Apple, skal man kontrollere kompatibiliteten med programmet til modelkørsel, den hukommelse, acceleratoren kan bruge, og den understøttede præcision.
Hvilke modeller passer til computere med 32-768GB
Selvom vi har fremhævet, at seriøst professionelt arbejde med modeller, der i mange situationer kan erstatte cloudløsninger, kræver en maskine med 128GB hukommelse, gives der nedenfor en rettesnor i form af dense-modellen Qwen3.8-27B, som også kan bruges til programmering og indlæses på en maskine med mindre hukommelse.
Den primære rettesnor vil dog være moderne og meget kapable åbne MoE-modeller Qwen3.8-Flash-Next og GLM-5.3-Flash. Qwen3.8 Flash er en udgivelse til skyen, mens Flash-Next er en åben udgivelse til lokal installation.
I MoE-modeller er kun en del af parametrene aktive for hvert token, men hele sættet af vægte skal kunne være i hukommelsen.
Kvantisering af modeller reducerer størrelsen på vægte og cache ved at repræsentere tal mere kompakt; blandede UD-varianter bruger forskellig præcision til forskellige dele af modellen. Kvantisering påvirker uundgåeligt kvaliteten, men det afhænger af, hvor aggressiv den er. Kvantisering ned til 4 bit (Q4) anses for at kunne være acceptabel i brug, mens Q8 ofte ligger meget tæt på originalen. Nedenfor vises konkrete offentliggjorte GGUF og summen af alle dele af deres vægte. Filstørrelsen svarer ikke til hele programmets hukommelsesforbrug: der skal desuden bruges hukommelse til OS, arbejdsbuffere, KV-cache og den valgte kontekstlængde.
Hvis maskinen eller klyngen har meget ledig hukommelse, kan man placere flere kopier af modellen eller forskellige modeller til samtidig brug.
Hukommelse | Betingelser for valg | |||
|---|---|---|---|---|
32GB | Q4 + reserve kan ikke være der | Q4 + reserve kan ikke være der | Qwen27B: 32K kontekst kan være der; 64K er på grænsen; 128K+ kan ikke være der. | |
64GB | Q4 + reserve kan ikke være der | Q4 + reserve kan ikke være der | Qwen27B: op til 256K kontekst kan være der. | |
128GB | Q4 + reserve kan ikke være der | Qwen27B: op til 256K. Flash-Next: 32K/64K kan være der; 128K er på grænsen. | ||
192GB | Q4 + reserve kan ikke være der | Qwen27B og Flash-Next: op til 256K. | ||
256GB | Kontekst op til 256K kan være der. | |||
512GB | Kontekst op til 256K. Til en klynge med 4 noder skal der bruges yderligere 36GB til Qwen27B, 60GB til Flash-Next og 72GB til GLM Flash: OS og buffere er nødvendige på hver node. | |||
768GB | Kontekst op til 256K. Til en klynge med 4 noder skal der bruges yderligere 36GB til Qwen27B, 60GB til Flash-Next og 72GB til GLM Flash: OS og buffere er nødvendige på hver node. |
Sammenligning af modeller på de samme testversioner
Værdierne nedenfor er procenttal fra udviklernes publikationer om de oprindelige udgivelser, ikke resultater for de valgte kvantiserede GGUF-versioner. De samme testversioner garanterer ikke det samme agentmiljø og de samme indstillinger. For eksempel blev Qwen3.8-27B testet i SWE-bench Pro og DeepSWE 1.1 med Claude Code som agentmiljø og 256K kontekst.
Ud over de åbne modeller viser tabellen benchmarkscores for kendte cloudmodeller som reference.
SWE-bench Pro og DeepSWE viser arbejde med kode;
Terminal-Bench 2.1 viser agentopgaver med selvstændig udførelse;
GPQA Diamond og HLE with tools viser komplekse spørgsmål og ræsonnement, i det andet tilfælde med værktøjer.
Model og kilde | SWE-bench Pro | Terminal-Bench 2.1 | DeepSWE v1.1 | GPQA Diamond | HLE with tools |
|---|---|---|---|---|---|
61.7 | 73.0 | 42.2 | 89.2 | Ingen værdi angivet | |
62.5 | Ingen værdi angivet | 58.7 | 91.7 | Ingen værdi angivet | |
Ingen værdi angivet | 84.3 | 63.4 | Ingen værdi angivet | 55.3 | |
Ingen værdi angivet | 90.6 | 74.2 | 90.9 | 63.9 | |
Ingen værdi angivet | Ingen værdi angivet | Ingen værdi angivet | Ingen værdi angivet | 64.5 | |
Ingen værdi angivet | Ingen værdi angivet | Ingen værdi angivet | 89.9 | 49.0 | |
Ingen værdi angivet | 88.8 | 72.7 | Ingen værdi angivet | 64.5 | |
53.4 | Ingen værdi angivet | Ingen værdi angivet | 91.3 | Ingen værdi angivet | |
Ingen værdi angivet | 85.0 | 58.0 | Ingen værdi angivet | 57.9 |
Sammenligning af processorydelse og hukommelseshastighed
Det maksimale tal nedenfor stammer fra producenternes dokumentation. NVIDIA's FP4-ydelse og AMD's samlede TOPS beskriver forskellige tilstande og kan ikke bruges som en direkte rangliste over hastighed. Apple offentliggør ikke en sammenlignelig maksimal AI-metrik i de anførte specifikationer, så beregningskerner og hukommelsesbåndbredde er angivet i stedet.
Chip i den største konfiguration | Offentliggjort ydeevne | Hukommelse og dens hastighed | Kilde |
|---|---|---|---|
NVIDIA RTX Spark N1X | Op til 1PFLOP FP4; CPU 20 kerner, GPU 6144 CUDA-kerner | Op til 128GB delt hukommelse; 300GB/s, 256 bit bus ifølge NVIDIA's dokumentation | |
NVIDIA GB10 Grace Blackwell | Op til 1PFLOPS FP4 med sparsitet; CPU 20 kerner | 128GB LPDDR5X; 273GB/s | |
Ryzen AI Max+ / PRO 395 | 126TOPS samlet, NPU op til 50TOPS; CPU 16 kerner, Radeon 8060S 40 CU | 128GB; hos Framework LPDDR5X 8000MT/s, 256 bit (beregning: 256GB/s) | |
Ryzen AI Max+ PRO 495 | 131TOPS samlet, NPU op til 55TOPS; CPU 16 kerner, Radeon 8065S 40 CU | 192GB hos Framework; LPDDR5X 8533MT/s, 256 bit (beregning: 273.1GB/s) | |
Apple M4 Max | CPU 16 kerner, GPU 40 kerner, NPU 16 kerner | 128GB; 546GB/s | |
Apple M3 Ultra | CPU 32 kerner, GPU 80 kerner, NPU 32 kerner | Op til 512GB ved lanceringen; 819GB/s | |
Apple M5 Max | CPU 18 kerner, GPU 40 kerner, NPU 16 kerner | 128GB; 614GB/s | |
Apple M5 Ultra | CPU 36 kerner, GPU 80 kerner, NPU 32 kerner | Op til 512GB; 1.2TB/s |
RTX Spark N1X og GB10 har lignende arkitektur: i de største versioner har begge 20 Arm-kerner i CPU og en Blackwell-GPU med 6144 CUDA-kerner. De officielle RTX Spark-specifikationer skelner dog mellem N1X til bærbare med TDP på 45-80W og desktopversionen med en processor-TDP på 140W; GB10 har også TDP på 140W. Der findes også en mindre N1X til bærbare med 18 CPU-kerner og 5120 CUDA-kerner. Vær opmærksom på processorversionen.
For hukommelsen angiver NVIDIA for N1X 300GB/s, og for GB10 273GB/s.
N1X er beregnet til Windows on Arm, mens DGX Spark bruger Linux.
I de kontrollerede kilder blev der ikke fundet en sammenlignende test af N1X og GB10 med samme model, kvantisering og kontekst, så man kan kun antage, at resultaterne for desktop-N1X vil være sammenlignelige med GB10.
For AMD findes der direkte målinger: Tom's Hardware sammenlignede Ryzen AI Halo med Max+ 395 og Dell Pro Max med GB10 i llama.cpp via llama-benchy. Tabellen viser resultater ved en kontekstdybde på 8192 tokens, et input på 2048 og et svar på 256 tokens; forfatteren brugte GGUF Unsloth Q4_K_M. AMD-maskinen havde 128GB LPDDR5X-8000 og en nominel TDP på 120W. TTFT er ventetiden til det første token; ved generering betyder flere tokens pr. sekund et hurtigere svar.
Testmodel | AMD 395: TTFT | GB10: TTFT | AMD 395: generering | GB10: generering |
|---|---|---|---|---|
Qwen3.6-35B-A3B | 11.4s | 5.0s | 43.8 tokens/s | 58.9 tokens/s |
gpt-oss-120B | 26.0s | 5.9s | 46.4 tokens/s | 50.7 tokens/s |
I disse to tests vinder GB10 både på TTFT og genereringshastighed. Forfatteren bemærker, at caching af input kan mindske forskellen i TTFT.
Hastigheden for hele agentopgaven kan give et andet resultat. I AMD's egen HEPA-test kørte begge maskiner Qwen3.6-35B-A3B i 4-bit-format og lavede en præsentation ud fra de samme lokale dokumenter. AMD Halo afsluttede arbejdet på 311.6s, DGX Spark på 367.1s, selvom den særskilte GPU-fase var hurtigere på Spark: 137.2s mod 159.5s. Syv ud af otte faser blev udført på CPU. Det er et eksempel på en konkret producenttest: for en agent bør man også måle tiden til et færdigt resultat, inklusive søgning, dokumentbehandling og kontrol af svaret.
Til sammenligning af løsninger fra Apple og NVIDIA angiver udvikleren EXO for M3 Ultra cirka 26TFLOPS FP16 og for DGX Spark cirka 100TFLOPS FP16. Disse estimater giver en forskel på cirka 3.8 gange i maksimal FP16-ydeevne, men det er ikke en garanteret forskel i hastigheden for en lokal LLM.
Hvad er vigtigst for hastigheden: hukommelse eller beregningsenheder?
Når en dense-model (for eksempel Qwen3.8-27B) genererer et svar, bruger den alle sine lag og vægte. Ved en eller nogle få forespørgsler venter acceleratoren ofte på, at data bliver læst, så hukommelsesbåndbredden er vigtig: den påvirker, hvor hurtigt de næste tokens kommer.
Under prefill behandler computeren inputteksten og opbygger KV-cache; et langt input giver flere muligheder for parallelle matrixberegninger. I denne prefill-fase kan stærke beregningsenheder forkorte ventetiden på det første token. Effekten af store batches af forespørgsler og forudsigelse gennemgås i en særskilt artikel fra NVIDIA.
For en agent, som gentagne gange modtager kontekst og returnerer et kort svar eller et værktøjskald, kan prefill stå for en betydelig del af ventetiden. De nævnte MoE-modeller Qwen3.8-Flash-Next og GLM-5.3-Flash bruger desuden kun udvalgte eksperter, hvilket mindsker kravet til hukommelseshastighed (sammenlignet med dense-modeller), selvom det stadig er en vigtig faktor for den samlede ydeevne.
Udvikleren EXO målte den samme Llama-3.1 8B FP16: input på 8192 tokens og svar på 32 tokens. På DGX Spark tog prefill 1.47s, generering 2.87s, i alt 4.34s; på M3 Ultra Mac Studio var tallene 5.57s, 0.85s og 6.42s. I denne test vandt Spark på inputbehandling og Mac på generering.
Klynger: 512GB hos NVIDIA og 768GB hos AMD
På DGX Spark med GB10 har hver maskine i den største konfiguration 128GB. Fire maskiner giver i alt 512GB. NVIDIA Sync understøtter opsætning af sådan en klynge; fire noder kræver en passende QSFP-netværksswitch, mens en direkte forbindelse passer til mindre konfigurationer.
AMD har også en vej til distribueret kørsel: virksomheden udgiver et eksempel med fire noder og llama.cpp RPC. Derudover oplyser Framework at fire Desktop med Ryzen AI Max+ PRO 495 og 192GB pr. node kan forbindes, med op til 768GB samlet.
I begge tilfælde bliver den samlede hukommelse ikke automatisk til ét adresserum. Orkestreringsprogrammet skal fordele modellen mellem noderne; hastigheden afhænger af netværket og måden, arbejdet paralleliseres på.
En klynge kan sættes op til at rumme en stor model, øge hastigheden på en enkelt forespørgsel eller øge tjenestens samlede ydeevne. Til det bruges flere fordelingsstrategier:
Tensorparallelisering: noderne beregner samtidig dele af matricerne i de samme lag. De behandler forespørgslen sammen, men udveksler ofte resultater.
Ekspertparallelisering: MoE-eksperter placeres på forskellige noder, og tokens sendes til de relevante eksperter. Parallelisering kan hjælpe, men dataudveksling og ujævn belastning kan æde gevinsten.
Pipelineparallelisering: grupper af lag opdeles i sekventielle faser. Et token passerer dem efter tur; flere forespørgsler eller mikrobatches kan fylde forskellige faser samtidig. Der kan opstå tomgang i pipelinen, men det er en effektiv løsning ved en stor strøm af sekventielle opgaver.
Dataparallelisering: forskellige kopier af modellen betjener uafhængige forespørgsler. Det øger tjenestens samlede kapacitet, hvis der er nok hukommelse til kopierne, men gør ikke automatisk en enkelt forespørgsel hurtigere.
Tilstandene kan kombineres, for eksempel tensor + pipeline eller tensor + expert, hvis det valgte program understøtter det. Fire noder i sig selv garanterer ikke en hastighedsforøgelse: netværk, synkronisering, batchstørrelse og belastningsbalance er afgørende. NVIDIA forklarer særskilt, hvordan man vælger modelopdeling efter hardwaren.
Til DGX Spark findes der en officiel vLLM-vejledning med to noder: Qwen3.8-27B NVFP4, tensor parallel på to noder og løbende samling af flere forespørgsler i et batch. Eksemplet viser, at fælles beregning af modellen også kan betjene parallelle forespørgsler.
Løsninger til lokale AI-modeller fra førende computerproducenter
Tabellerne viser computerfamilier med de største konfigurationer på 128GB og derover.
Det angives særskilt, hvilken opladningsprotokol adapteren skal understøtte, og hvilken effekt den skal have for at forsyne computeren.
Bærbare computere og arbejdsstationer med NVIDIA RTX Spark N1X
Model, chip og hukommelsesinterval | Opladning med USB-C-adapter (PD) | Dokumentation og butik |
|---|---|---|
Acer SFF RTX Spark | NVIDIA RTX Spark | op til 128GB fælles hukommelse | - | |
ASUS ProArt P16 H7607 | N1X | 32-128GB | PD3.1, 140W | |
ASUS ProArt P14 H7407 | N1X | 32-128GB | PD3.1, 140W | |
ASUS ProArt GR1X | NVIDIA RTX Spark N1X | 64/128GB delt hukommelse | USB-C PD IN, EPR PD 3.1; adapter på 240W medfølger; den nødvendige indgangseffekt og profil er ikke angivet | |
Dell Creator Edition Desktop | NVIDIA RTX Spark | op til 128GB fælles hukommelse | - | |
Dell XPS 16 Creator Edition | N1X | 128GB | Power Delivery er angivet for tre USB-C 4.0-porte | |
HP OmniBook Ultra 16, 16-bk0000 | N1X | 32-128GB | PD3.2 USB-C 140W | |
HP OmniBook X 14 | NVIDIA RTX Spark N1X | op til 128GB fælles hukommelse | USB PD 3.2; USB-C GaN strømadapter 140W | |
Lenovo Yoga Pro 9n / Pro 9n 15 Gen 11 | N1X | 32-128GB | USB-C PD 3.0; en USB-C-adapter på 140W medfølger til udvalgte konfigurationer; den maksimale indgangseffekt er ikke angivet. | |
Microsoft Surface Laptop Ultra | N1X | 24-128GB | USB PD 3.1, mindst 115W | |
Microsoft Surface RTX Spark Dev Box | NVIDIA RTX Spark | 128GB fælles hukommelse | - | |
MSI EdgeMesa N AI+ | NVIDIA RTX Spark N1X | op til 128GB LPDDR5X fælles hukommelse | USB-C PD IN; strømadapter 240W | |
MSI Prestige N16 Flip AI+ | N1X | 32-128GB | PD3.1, 65-140W |
NVIDIA GB10 / DGX Spark arbejdsstationer
Model, chip og hukommelsesinterval | Opladning med USB-C-adapter (PD) | Dokumentation og butik |
|---|---|---|
Acer Veriton GN100 | GB10 | 128GB | Medfølgende USB-C-strømforsyning 240W | |
ASUS Ascent GX10 | GB10 | 64/128GB | PD3.1 EPR. Databladet angiver en indgang på op til 180W; medfølgende strømforsyning 240W | |
Dell Pro Precision with GB10 (FCM1253; tidligere Dell Pro Max with GB10) | GB10 | 128GB | Standard USB-C-strømforsyning 280W, 48V5.83A; PD-version er ikke angivet. Dette er en ikke-standardiseret tilstand på 240W-48V5A | |
GIGABYTE AI TOP ATOM | GB10 | 128GB | USB-C PD IN; adapter på 240W medfølger; den nødvendige indgangseffekt, spændingsprofil og PD-version er ikke angivet. | |
HP ZGX Nano G1n AI | GB10 | 128GB | Dedikeret USB-C-indgang, strømforsyning 240W. | |
Lenovo ThinkStation PGX | GB10 | 128GB | Dedikeret USB-C-indgang med USB PD 3.1; medfølgende strømforsyning 240W | |
MSI EdgeXpert MS-C931 | GB10 | 128GB | Standard strømforsyning USB PD 3.1 240W, 48V5A | |
NVIDIA DGX Spark | GB10 | 128GB | Standard USB-C PD3.1 240W | |
PNY NVIDIA DGX Spark | GB10 | 128GB | Strømforsyning medfølger, effekt og PD-tilstand er ikke angivet |
Ryzen AI Max+ 395 og nye modeller med 192GB
Model, chip og hukommelsesinterval | Opladning med USB-C-adapter (PD) | Anden DC-indgang eller strømforsyning fra elnettet | Dokumentation og butik |
|---|---|---|---|
Acer Veriton RA110 | Max+ 395 | 128GB | - | Separat DC-stik på bagsiden; effekten på den medfølgende adapter er ikke angivet i den kontrollerede kilde. | |
AMD Ryzen AI Halo | Max+ 395 | 128GB | Dedikeret USB-C-indgang til opladning med standardstrømforsyningen | - | |
AMD Ryzen AI Halo | Max+ PRO 495 | 192GB fælles hukommelse | - | - | |
ASUS ProArt PX13 HN7306 | Max+ 395 | 128GB | USB PD 45-100W understøttes | Rektangulær DC-indgang: strømforsyning 200W, 20V10A | |
ASUS ROG Flow Z13 GZ302 | Max+ 395 i den største version | 32-128GB | USB PD 3.0, 45-100W | Rektangulær DC-indgang: strømforsyning 200W, 20V10A | |
Beelink GTR9 Pro | Max+ 395 | 128GB | - | Intern strømforsyning fra elnettet 230W | |
CORSAIR AI Workstation 300 | Max+ 395 | 64/128GB | - | Intern Flex ATX-strømforsyning 300W | |
Framework Desktop | 32/64/128/192GB; Max+ 395: 64/128GB, Max+ PRO 495: 192GB | - | Intern Flex ATX-strømforsyning 400W | |
GEEKOM A9 Mega | AMD Ryzen AI Max+ 395 | 128GB delt hukommelse | USB-C PD-indgang er ikke angivet i det kontrollerede materiale | DC-in; adapter på 330W medfølger | |
GMKtec EVO-X2 | Max+ 395 | 64-128GB | - | DC5525: strømforsyning 19.5V11.8A, cirka 230W | |
GMKtec EVO-X5 Pro | Ryzen AI Max+ PRO 495 | 192GB fælles hukommelse | Strømtilførsel via USB-C understøttes ikke | DC IN 19.5V16.9A, 330W; stik 5.5 x 2.5 mm | |
HP Z2 Mini G1a | Max+ PRO 395 i den største version | 16-128GB | - | Intern strømforsyning fra elnettet 300W | |
HP ZBook Ultra 14 G1a | Max+ PRO 395 i den største version | 16-128GB | USB-C-strømforsyning 140W | - | |
HP ZBook Ultra G3a 16 | Ryzen AI Max+ PRO 495 | op til 192GB fælles hukommelse | - | - | |
Lenovo ThinkCentre X Ultra | Ryzen AI Max+ PRO 495 | op til 128GB fælles hukommelse | - | - | |
MINISFORUM MS-S1 MAX | Max+ 395 | 64/128GB | - | Intern strømforsyning fra elnettet 320W | |
MINISFORUM MS-S1 MAX-P495 | Max+ PRO 495 | 192GB fælles hukommelse | - | Intern strømforsyning 320W | |
MSI PRO MAX EDGE AI+ 11M | Max+ 395 | 128GB | USB PD-indgang er ikke oplyst; begge USB-C: PD-udgang 15W | Intern Flex-strømforsyning fra elnettet 300W |
Apple Silicon: de seneste to generationer
For MacBook Pro ser vi på M5 Max og M4 Max med 40 GPU-kerner og 128GB. For Mac Studio er det generationen M5 Max / M5 Ultra og den foregående M4 Max / M3 Ultra. Apple oplyste om en M3 Ultra-version med 512GB ved lanceringen, men den aktuelle specifikationsside viser højst 256GB.
Model, chip og hukommelsesinterval | Opladning med USB-C-adapter (PD) | Anden DC-indgang eller strømforsyning fra elnettet | Dokumentation og butik |
|---|---|---|---|
MacBook Pro 14" (2024) | M4 Max | 36-128GB; 128GB kræver en GPU med 40 kerner | PD3.0 (<100W) | MagSafe 3: fra PD 3.0 | Specifikationer | Hurtig opladning | Amazon.com(36Gb) |
MacBook Pro 16" (2024) | M4 Max | 36-128GB; 128GB kræver en GPU med 40 kerner | PD3.1 (140W) | MagSafe 3: fra PD 3.1 | Specifikationer | Hurtig opladning | Amazon.com(48Gb) |
Mac Studio (2025) | M4 Max | 36-128GB; 128GB kræver en GPU med 40 kerner | - | Indbygget strømforsyning fra elnettet; 480W | Specifikationer | Amazon.com(36Gb) |
Mac Studio (2025) | M3 Ultra | 96-256GB i den aktuelle specifikation; 512GB ved lanceringen | - | Indbygget strømforsyning fra elnettet; 480W | Specifikationer | Amazon.com(256Gb) |
Mac Studio | M5 Ultra | 96/256/512GB; 512GB: levering senere i oktober 2026 | - | Indbygget strømforsyning fra elnettet; 480W | |
MacBook Pro 14" | M5 Max | 36-128GB; 128GB kræver en GPU med 40 kerner | PD3.0 (<100W) | MagSafe 3: fra PD 3.0 | Specifikationer | Hurtig opladning | Amazon.com(128Gb) |
MacBook Pro 16" | M5 Max | 36-128GB; 128GB kræver en GPU med 40 kerner | PD3.1 (140W) | MagSafe 3: fra PD 3.1 | |
Mac Studio | M5 Max | 36-128GB; 128GB kræver en GPU med 40 kerner | - | Indbygget strømforsyning fra elnettet; 480W | Specifikationer | Amazon.com(36Gb) |
MagSafe 3 på MacBook er et proprietært stik på den bærbares side, som modtager strøm fra en USB-C-adapter via det passende kabel.
Sådan sikrer du pålidelig strømforsyning til computeren
Kontrollér pakkens indhold: visse computerkonfigurationer sælges uden adapter (især i Europa), mens andre har en inkluderet.
En computer, der hver dag skal arbejde mange timer med en lokal AI-model, har brug for en pålidelig strømforsyning, som kan levere den nødvendige effekt kontinuerligt uden udfald.
Kontrollér spænding, strøm, protokol og det tilladte kabel mod dokumentationen for den konkrete maskine. Hvis producenten kræver en proprietær strømforsyning eller en ikke-standardiseret tilstand, er et USB-C-stik ikke grundlag for at erstatte den med en hvilken som helst kraftig oplader.
Hvis du vælger en strømforsyning med flere porte, skal du være opmærksom på effekten fra en enkelt port og på, hvordan den ændres, når en anden enhed tilsluttes (hvis det scenarie er relevant for dig).