가속기와 시스템 선택

사용자가 문장을 보내면 CPU가 network request를 받고 tokenizer로 token ID를 만들며 queue와 권한을 처리합니다. Storage의 model shard는 host memory에 mapping되거나 읽힌 뒤 runtime이 tensor를 device memory로 옮깁니다. GPU·NPU·TPU가 matrix kernel을 실행해도 sampling, 일부 normalization, tool 호출과 response serialization은 CPU에 남을 수 있습니다. 따라서 accelerator 계산 시간만으로 End-to-End latency(요청부터 최종 응답까지의 지연)를 설명할 수 없습니다.

Driver는 operating system과 장치 사이의 낮은 수준 통신을 제공하고 runtime은 model architecture를 kernel과 memory plan으로 바꿉니다. Compiler가 필요한 장치는 graph와 shape를 장치 명령으로 변환합니다. Model code가 새 operator를 사용하지만 설치된 runtime에 kernel이 없으면 load가 실패하거나 CPU fallback이 일어날 수 있습니다. 화면에 device가 표시되고 package import가 성공했다는 사실은 실제 model graph가 가속된다는 증거가 아닙니다.

실행 도해에서 storage, CPU host, runtime·compiler, device memory와 compute unit 사이 화살표를 따라가며 각 경계의 byte와 시간을 적습니다. Model load, prompt prefill, 한 token decode, cache allocation과 output 전송은 서로 다른 경로 비중을 가집니다. 첫 요청만 느리면 compile·load·warm-up을, 긴 생성이 계속 느리면 memory bandwidth·kernel·cache를, 동시 사용자에서만 느리면 queue·capacity를 먼저 조사합니다.

Profiler가 제공하는 execution device, kernel timeline, memory copy와 utilization을 요청 ID와 model revision에 연결합니다. GPU utilization 20%라는 숫자 하나는 CPU 준비가 느린지, 작은 batch인지, memory wait인지 알려 주지 못합니다. 반대로 100% utilization도 queue 지연이나 thermal throttling을 숨길 수 있습니다. 사용자의 TTFT·전체 latency, 처리 token과 오류를 장치 timeline과 같은 시간축에서 비교해야 합니다.

왜 이런가

가속기는 host가 준비한 graph와 data 중 지원되는 연산만 실행하며 요청은 여러 software·memory 경계를 왕복하기 때문입니다.

언제 문제가 되는가

장치 peak 사양은 높은데 첫 token이 늦거나 CPU 사용률과 transfer가 급증하면 전체 path의 다른 구간이 병목일 수 있습니다.

초보자가 자주 하는 오해

GPU·NPU가 보이면 모든 연산이 자동 offload되거나 낮은 utilization은 곧 hardware 결함이라는 뜻이 아닙니다.

직접 확인하는 방법

한 요청의 CPU 전처리, copy, compile, kernel, cache와 응답 시간을 trace하고 log의 execution device를 exact revision과 대조하십시오.

CPU core 수는 일을 처리할 독립 실행 자원을 나타내지만 모든 core가 같은 model tensor를 효율적으로 읽는다는 뜻은 아닙니다. LLM matrix 연산은 Advanced Vector Extensions(AVX, 여러 숫자를 한 명령으로 처리하는 x86 vector 확장), ARM NEON과 matrix extension을 활용할 수 있습니다. Runtime이 이 instruction set에 맞게 build됐는지, physical core·thread와 Non-Uniform Memory Access(NUMA, socket에 따라 memory 접근 시간이 다른 구조)를 어떻게 배치하는지가 결과를 바꿉니다.

System RAM은 consumer GPU VRAM보다 클 수 있어 큰 quantized model을 담는 데 유리하지만 용량과 bandwidth를 구분해야 합니다. Dual-channel·multi-channel memory, socket과 page placement에 따라 유효 bandwidth가 달라집니다. Thread를 무조건 늘리면 같은 memory channel을 경쟁해 token/s가 더 이상 오르지 않거나 오히려 scheduling overhead가 커질 수 있습니다. Core·thread sweep와 effective bandwidth를 함께 측정합니다.

Llama.cpp는 CPU vector backend와 Metal·CUDA·HIP·Vulkan 등 여러 backend, CPU+GPU hybrid inference를 공개합니다. 이 사실은 모든 조합의 동일 성능을 보증하지 않습니다. Exact build flag와 commit, BLAS backend, model GGUF·quant, layer offload와 context를 기록해야 합니다. GPU에 들어가지 않는 layer를 CPU로 두면 실행 가능성은 높아지지만 PCIe transfer와 CPU bandwidth가 decode 지연을 키울 수 있습니다.

CPU-only 기준선은 장애 격리에 유용합니다. 같은 model·template·작은 입력이 CPU에서는 정확하지만 새 GPU backend에서 틀리면 artifact보다 kernel·precision 경로를 먼저 의심할 수 있습니다. 반대로 CPU와 가속기 모두 틀리면 tokenizer·prompt·model을 봅니다. 기준선은 production만큼 빨라야 하는 것이 아니라 재현 가능하고 단순한 경로로 기능·품질 회복 여부를 확인할 수 있어야 합니다.

왜 이런가

CPU는 다양한 instruction과 운영체제 기능을 직접 지원하고 큰 system memory를 host하므로 가속기와 다른 장점이 있습니다.

언제 문제가 되는가

Thread를 늘려도 속도가 멈추고 memory controller가 포화되거나 offload 때 PCIe wait가 커지면 CPU·memory 경로를 분리해야 합니다.

초보자가 자주 하는 오해

CPU는 AI를 전혀 못 하거나 core 수가 두 배면 token/s도 항상 두 배가 되는 것은 아닙니다.

직접 확인하는 방법

Runtime build·instruction set, physical core·thread, NUMA·memory bandwidth와 layer offload를 고정해 thread별 token/s·전력을 측정하십시오.

GPU는 많은 Arithmetic Logic Unit(ALU, 산술·논리 연산 장치)과 matrix unit이 동일한 kernel을 대량 data에 병렬 적용하도록 설계됩니다. LLM의 matrix multiplication은 이 구조를 활용하지만 작은 tensor, branch가 많은 code와 빈번한 host synchronization은 parallel unit을 충분히 채우지 못할 수 있습니다. Batch와 prefill은 병렬성을 높이는 반면 interactive decode의 batch 1은 memory 접근과 kernel launch 비중이 커질 수 있습니다.

VRAM에는 전체 또는 배치된 weight, activation, KV cache, kernel workspace와 allocator 예약이 함께 들어갑니다. 여러 GPU의 VRAM을 더한 값만으로 model이 들어간다고 결론 내리면 안 됩니다. Tensor parallel은 layer의 tensor를 나누고 pipeline parallel은 layer 구간을 나누며 각각 collective communication과 stage 대기가 생깁니다. PCIe, NVLink 같은 interconnect, 장치별 shard와 peak를 같은 topology에서 측정합니다.

NVIDIA CUDA, AMD ROCm, Intel XPU와 Apple Metal은 driver·compiler·library와 지원 platform이 다릅니다. VLLM의 최신 공식 설치 페이지는 NVIDIA compute capability, AMD GPU architecture와 ROCm, Intel XPU, Apple Silicon plugin 조건을 별도 tab으로 설명합니다. 지원 목록은 version에 따라 바뀌므로 블로그의 오래된 성공 사례나 vendor 이름만으로 현재 내 exact GPU·OS를 승인하지 않습니다.

GPU candidate는 clean environment 또는 고정 container에서 작은 공식 지원 model을 먼저 load합니다. 그다음 목표 architecture·quant, 최장 context와 동시성으로 넓히며 load log의 kernel, execution device, peak와 error를 저장합니다. Runtime wheel과 driver를 바꿀 때 model artifact까지 바꾸지 않습니다. 실패하면 이전 image·driver가 아니라 우선 이전 application container로 돌아갈 수 있는 범위를 정하고 같은 입력을 재시험합니다.

왜 이런가

GPU kernel은 architecture와 software binary에 맞아야 하고 VRAM과 interconnect가 병렬 계산에 data를 계속 공급해야 하기 때문입니다.

언제 문제가 되는가

Load는 되지만 CPU fallback, device 간 통신·한 장치 OOM 또는 낮은 batch utilization로 기대보다 느릴 수 있습니다.

초보자가 자주 하는 오해

CUDA core·stream processor 수나 VRAM 합만 크면 vendor·runtime·workload와 관계없이 같은 성능이 나오는 것은 아닙니다.

직접 확인하는 방법

Official matrix에서 exact GPU·OS·driver·runtime을 찾고 profiler의 kernel·placement·copy·collective와 p50·p95를 기록하십시오.

NPU는 Neural Processing Unit의 약어이며 노트북·mobile System on Chip(SoC, 여러 기능을 한 칩에 통합한 장치)에 포함돼 지속적인 AI inference를 낮은 전력으로 처리하도록 설계되는 경우가 많습니다. 제품의 TOPS는 특정 integer precision, sparsity와 vendor 조건에서의 최대 operation 수일 수 있습니다. Model이 사용하는 precision과 operator, memory traffic·thermal 조건이 다르면 실제 latency와 energy는 표시 수치에서 직접 나오지 않습니다.

Framework model은 Open Neural Network Exchange(ONNX, model graph 교환 형식)나 vendor format으로 export·compile해야 할 수 있습니다. Attention·rotary embedding, dynamic sequence, KV cache update와 quant decompose가 NPU compiler에서 지원되지 않으면 compile error 또는 HETERO·CPU execution이 생깁니다. “NPU 사용” 설정이 성공해도 일부 핵심 연산이 CPU에서 실행되면 전체 token 지연과 전력이 기대와 달라질 수 있습니다.

Intel OpenVINO 2026 NPU 문서는 지원 property, default latency mode와 일부 HETERO 조건을 제시합니다. Exact compiled model에서 available device, execution device, driver·compiler version과 supported property를 질의해야 합니다. 다른 vendor NPU는 같은 property·driver나 model format을 사용하지 않으므로 OpenVINO 절차를 모든 NPU의 표준이라고 일반화하지 않습니다.

NPU benchmark는 wall power와 battery, cold compile·warm latency, input shape·batch 1과 목표 model 품질을 함께 기록합니다. CPU·integrated GPU와 같은 model·업무로 비교하고 fallback을 켠 결과와 목표 device-only 결과를 구분합니다. Compile cache를 지운 뒤에도 복구 가능한지, driver update 후 이전 compiled artifact가 호환되는지 확인해야 일회성 demo가 아닌 운영 경로가 됩니다.

왜 이런가

NPU는 제한된 operator·precision과 compiler 경로를 효율화하므로 지원 graph를 실제로 배치하는 과정이 핵심입니다.

언제 문제가 되는가

Compile error, static shape 요구, CPU fallback이나 작은 shared memory 때문에 TOPS 기대와 다른 지연·품질이 생깁니다.

초보자가 자주 하는 오해

AI PC에 NPU가 있으면 Ollama·vLLM 등 모든 local LLM이 설치 없이 자동으로 NPU를 사용한다고 생각하지 않습니다.

직접 확인하는 방법

Exact model을 compile하고 execution device·operator partition·precision·driver version, wall power와 CPU fallback 유무를 확인하십시오.

Tensor Processing Unit(TPU)은 Google이 machine learning workload를 위해 설계한 Application-Specific Integrated Circuit입니다. 공식 architecture 문서는 TensorCore 안의 Matrix Multiply Unit(MXU), vector unit과 scalar unit, High Bandwidth Memory를 구분합니다. Matrix unit은 multiply-accumulate를 systolic array에서 처리하지만 activation·softmax와 control, address 계산은 다른 unit과 host가 담당합니다. TPU도 모든 프로그램을 한 unit에서 실행하지 않습니다.

PyTorch나 JAX가 만든 graph는 Accelerated Linear Algebra(XLA) compiler를 거쳐 TPU machine code가 됩니다. Host VM은 input을 준비하고 compile·runtime과 device를 관리합니다. 처음 보는 shape나 graph에서 compile 시간이 늘 수 있고 dynamic Python control이 device 실행을 방해할 수 있습니다. GPU용 custom CUDA kernel을 그대로 TPU에서 실행할 수 없으며 framework·XLA 지원과 model implementation을 확인해야 합니다.

여러 TPU chip은 Inter-Chip Interconnect(ICI, TPU chip 사이 고속 연결)로 묶인 slice와 topology를 이룹니다. Model·data parallel collective는 chip 수뿐 아니라 topology와 mapping에 영향을 받습니다. Multi-host에서는 host와 network, input pipeline도 병목이 될 수 있습니다. “TPU N개”라는 수치만 기록하지 않고 version, slice·topology, TensorCore·chip 단위와 software version을 정확히 남깁니다.

Cloud candidate에는 quota·region, provisioning·compile 시간, storage와 data 이동, failure·checkpoint와 비용을 포함합니다. 같은 code가 chip 수가 다른 type에서 tuning 없이 같은 효율을 보장하지 않는다는 공식 문서의 조건을 고려합니다. Small local inference와 대규모 training을 하나의 순위로 비교하지 않고, TPU를 선택한 workload가 matrix 규모와 반복 사용으로 compile·distributed overhead를 상쇄하는지 실제 job으로 측정합니다.

왜 이런가

TPU 성능은 ASIC 내부 unit뿐 아니라 XLA graph, host, HBM과 chip topology가 data를 공급하고 집단 통신하는 방식에 달려 있습니다.

언제 문제가 되는가

Compile 반복, input starvation, collective와 topology mismatch가 생기면 chip peak가 높아도 job step이 느리거나 중단됩니다.

초보자가 자주 하는 오해

TPU는 일반 PC용 GPU의 더 빠른 이름이거나 모든 Python code와 CUDA kernel을 수정 없이 실행하는 장치는 아닙니다.

직접 확인하는 방법

TPU version·slice·topology, XLA compile·step trace, HBM, input queue와 collective 시간을 같은 job revision에서 확인하십시오.

Capacity 예산은 weight artifact의 실제 loaded byte, KV cache, activation·workspace와 운영 여유의 합입니다. Decimal GB와 binary GiB를 구분하고 unified memory에서는 운영체제·다른 process가 쓰는 공간을 뺍니다. 90% 같은 안전선은 보편 법칙이 아니라 출발점이며 allocator, burst와 recovery를 실제 peak로 교체해야 합니다. 한 번 load된 결과보다 최장 context·동시성에서 반복되는 peak가 중요합니다.

Bandwidth 상한은 같은 workload의 read·write byte를 실행 시간으로 나눈 effective bandwidth에서 시작합니다. Product sheet의 theoretical bandwidth는 memory clock과 bus 조건의 상한이며 access pattern, cache, quant unpack과 contention을 포함하지 않습니다. NVIDIA CUDA guide가 제시하는 effective bandwidth 관점처럼 profiler에서 kernel이 읽고 쓴 byte와 시간을 측정하고 prefill·decode를 따로 계산합니다.

Compute 상한은 지원 precision에서 실제 유효 operation rate를 token당 operation으로 나눕니다. TOPS의 Tera는 10의 12승 operation/s이고 token당 수치는 Giga Operations(GOPS, 10의 9승)로 쓸 수 있습니다. 하지만 multiply와 accumulate를 몇 operation으로 세는지, sparsity·matrix shape와 utilization 조건이 다를 수 있어 서로 다른 vendor 표를 바로 나누지 않습니다. 같은 profiler·benchmark 정의를 사용합니다.

Roofline 모형은 memory ceiling과 compute ceiling 중 작은 쪽이 먼저 닿는 상한임을 보여 줍니다. 관측값이 훨씬 낮으면 host transfer, kernel launch, unsupported fallback, queue나 thermal을 조사합니다. 관측값이 단순 상한보다 높으면 cache reuse를 빠뜨렸거나 GB·GiB, prefill과 decode, 서로 다른 batch 측정을 섞었는지 확인합니다. 모형의 목적은 정확한 예언이 아니라 단위가 맞는 반증 질문을 만드는 것입니다.

왜 이런가

저장 공간, data 이동과 연산 처리량은 각각 다른 물리 자원이며 workload가 그중 작은 공급률에 제한되기 때문입니다.

언제 문제가 되는가

TOPS는 높은데 token/s가 낮거나 계산 상한보다 관측이 큰 모순이 생기면 단위·조건·effective byte를 다시 확인해야 합니다.

초보자가 자주 하는 오해

VRAM이 충분하면 속도도 충분하거나 TOPS를 parameter 수로 나누면 정확한 token/s가 나온다고 생각하지 않습니다.

직접 확인하는 방법

Loaded peak GiB, kernel read·write GB/s, precision별 유효 operation과 token당 byte·operation을 같은 run에서 수집하십시오.

INT4 weight는 FP16보다 file과 weight read를 줄일 수 있지만 scale·zero point, group metadata와 dequantization이 필요합니다. Activation과 accumulation은 FP16·BF16·FP32 또는 integer로 섞일 수 있습니다. Hardware의 INT8 TOPS가 높아도 runtime이 model quant format을 해당 matrix unit에 맞게 변환하지 못하면 weight를 풀어 floating-point kernel을 사용할 수 있습니다. 저장량 이득과 계산 가속을 별도 결과로 보고합니다.

BF16은 FP16과 같은 16bit지만 exponent와 precision 배치가 달라 numeric range와 오차 특성이 다릅니다. Device가 BF16을 이름상 지원해도 특정 operator와 generation에서 kernel이 있는지 확인합니다. Softmax, normalization이나 sampling 같은 부분은 높은 precision으로 남을 수 있습니다. Mixed precision은 오류가 아니라 정확도와 속도의 설계일 수 있으므로 profiler와 runtime 문서를 통해 실제 tensor dtype을 확인합니다.

OpenVINO 공식 precision control 설명처럼 model storage precision과 inference precision은 같은 개념이 아니며 hardware acceleration이 없는 integer type은 다른 실행 precision을 사용할 수 있습니다. 이 원칙을 모든 runtime의 세부 동작으로 일반화하지는 않지만, file 이름만으로 실행 unit을 확정하면 안 된다는 확인법은 공통입니다. Runtime option, compiled graph와 device capability query를 함께 기록합니다.

Precision candidate는 같은 prompt·seed·template에서 숫자, 희귀 한국어, JSON·tool schema, 긴 context와 안전 거부 품질을 평가합니다. Token/s와 memory만 좋아도 필수 품질이 gate를 넘지 못하면 보류합니다. 새 precision이 실패하면 artifact·kernel·device 중 하나만 이전 기준선으로 되돌려 재시험하고, 변환 recipe와 source revision·hash를 보존해 같은 결과를 다시 만들 수 있게 합니다.

왜 이런가

Weight 저장 형식과 operator가 사용할 activation·accumulation dtype은 runtime과 hardware capability에 따라 따로 결정될 수 있습니다.

언제 문제가 되는가

INT4 file이 작아도 kernel이 fallback해 느리거나 특정 값에서 overflow·품질 회귀가 나면 실제 inference precision을 봐야 합니다.

초보자가 자주 하는 오해

Model 이름의 Q4나 device의 INT8 TOPS가 전체 graph의 모든 계산 precision을 뜻하지 않습니다.

직접 확인하는 방법

Compiled graph·profiler에서 operator별 device·dtype을 확인하고 같은 평가 세트의 품질·memory·지연을 FP16·BF16 기준선과 비교하십시오.

Compatibility는 “AMD GPU”, “NVIDIA GPU”, “NPU”처럼 넓은 범주가 아니라 exact tuple입니다. Device architecture, firmware·driver, OS·kernel, runtime·compiler, framework·Python, container image와 model feature를 한 행에 적습니다. AMD ROCm과 vLLM 공식 문서는 GPU·ROCm·OS와 wheel 조건을 version별로 나누며 지원 범위가 release마다 변합니다. 검토 날짜와 URL, 사용한 version을 함께 남깁니다.

공식 production support, preview, community-enabled와 source build 가능은 같은 상태가 아닙니다. Community patch로 한 번 실행됐더라도 security update, regression test와 장애 지원 경로가 없으면 production 위험이 큽니다. 반대로 공식 목록에 없다고 기술적으로 절대 불가능하다는 뜻도 아니지만, 실험 환경과 운영 승인 수준을 구분해 표시해야 의사결정자가 비용을 알 수 있습니다.

Container는 user-space dependency를 고정하지만 host driver·kernel·firmware와 physical topology까지 담지 못합니다. `latest` tag 대신 image digest를 기록하고 base library와 runtime가 요구하는 host 조건을 확인합니다. Token이나 비밀번호를 image layer·command history에 넣지 않습니다. Model cache와 compiled artifact도 source revision·license·hash와 함께 관리하며 서로 다른 test의 cache를 같은 결과로 오인하지 않습니다.

Manifest 검증은 작은 model import에서 시작해 목표 model load, 최장 input, 목표 concurrency와 feature까지 단계적으로 넓힙니다. Structured output, quant, prefix cache, tensor parallel 같은 기능은 hardware backend마다 지원 시점이 다를 수 있습니다. 설치 page의 “GPU 지원” 아래에 별도 feature matrix가 있다면 둘 다 확인하고, log에서 조용한 feature disable·CPU fallback이 없는지 확인합니다.

왜 이런가

Kernel binary와 compiler는 device architecture·driver·library ABI와 맞아야 하며 backend별 feature 구현 속도가 다르기 때문입니다.

언제 문제가 되는가

Import는 되지만 model load·quant kernel·distributed feature에서 crash 또는 fallback이 나면 tuple 일부가 맞지 않을 수 있습니다.

초보자가 자주 하는 오해

Container를 쓰면 host driver 조건이 사라지거나 같은 vendor의 모든 GPU가 한 runtime version에서 공식 지원된다고 생각하지 않습니다.

직접 확인하는 방법

Exact tuple과 image digest를 manifest에 적고 official matrix·feature table, load log와 목표 workload 재시험을 연결하십시오.

Prefill은 입력 token 전체를 attention과 feed-forward layer에 통과시켜 첫 KV cache를 만드는 단계입니다. 여러 token을 matrix에 묶을 수 있어 compute unit을 비교적 잘 채우고 arithmetic intensity가 높아질 수 있습니다. 입력이 길면 Time to First Token이 늘고 activation·temporary workspace가 커집니다. 같은 GPU라도 200-token 질문과 30,000-token 문서의 prompt token/s와 peak가 다르므로 input 길이별로 표를 나눕니다.

Decode는 이미 만든 cache를 사용해 다음 token을 한 step씩 생성합니다. Batch 1에서는 매 step 큰 weight를 읽는 memory-bound 성격과 kernel launch가 두드러질 수 있습니다. 여러 sequence를 continuous batching하면 weight를 재사용해 전체 throughput이 좋아질 수 있지만 짧은 요청이 긴 요청 뒤에서 기다리거나 cache block이 늘어 p95가 나빠질 수 있습니다. 사용자별 token/s와 server 전체 token/s를 같은 지표로 보고하지 않습니다.

Training과 fine-tuning은 forward뿐 아니라 gradient, optimizer state와 backward activation을 저장하고 통신합니다. Inference에서 16GiB에 들어간 model이 같은 장치에서 그대로 full training된다고 생각하면 안 됩니다. LoRA 같은 parameter-efficient tuning도 activation·optimizer와 batch memory를 필요로 합니다. Training candidate는 step time, sample throughput, gradient·checkpoint와 failure recovery를 별도 workload로 평가합니다.

평가 계약에는 목적을 한 문장으로 씁니다. 한 사용자의 interactive chat인지, 네 사용자의 API throughput인지, 긴 문서 prefill인지, adapter training인지에 따라 최적 장치와 runtime이 달라집니다. 각 단계의 input·output token, batch와 concurrency를 고정하고 profiler에서 compute·memory·communication 비율을 확인합니다. “LLM benchmark”라는 이름 하나로 서로 다른 단계를 섞지 않습니다.

왜 이런가

Prefill은 token 축 병렬성이 크고 decode는 반복적인 작은 step이며 training은 gradient·optimizer를 더해 같은 model에서도 자원 사용이 달라집니다.

언제 문제가 되는가

긴 prompt의 TTFT, batch 1 decode, 동시 요청 throughput 또는 training OOM 중 하나만 실패해도 평균 token/s가 원인을 숨길 수 있습니다.

초보자가 자주 하는 오해

한 번 측정한 token/s나 inference load 성공이 모든 context·batch·training 성능을 대표하지 않습니다.

직접 확인하는 방법

Cold·warm 상태에서 prefill·decode, concurrency 1·목표값과 training step을 분리해 token·sample, peak, p50·p95와 profiler 비율을 기록하십시오.

Tensor parallelism은 한 layer의 matrix를 여러 device에 나누고 partial result를 collective communication으로 합칩니다. Model weight는 분산할 수 있지만 token step마다 all-reduce 같은 통신이 필요할 수 있습니다. Device 내부 HBM bandwidth가 높아도 GPU 사이 PCIe나 network가 느리면 작은 batch decode에서 통신 비중이 커집니다. Parallel size, shard와 collective byte를 exact topology에 맞춰 측정합니다.

Pipeline parallelism은 layer 묶음을 stage로 나눕니다. Stage마다 memory를 분배할 수 있지만 앞 stage의 출력을 기다리고 micro-batch가 작으면 빈 구간인 pipeline bubble이 생깁니다. 한 stage에 큰 layer나 느린 device가 몰리면 나머지가 기다리는 straggler가 됩니다. GPU utilization 평균 대신 device·stage별 active·wait time과 peak를 봐야 불균형을 찾을 수 있습니다.

Data parallelism은 model replica가 서로 다른 batch를 처리하고 training에서는 gradient를 동기화합니다. Serving replica는 request routing과 cache locality, health·failure domain을 고려해야 합니다. Cloud TPU slice와 GPU cluster는 interconnect와 topology 표현이 다르며 같은 device 개수라도 collective path가 달라집니다. Vendor의 peak interconnect 숫자만이 아니라 실제 message size와 collective trace를 확인합니다.

Scale-out 시험은 1→2→4개처럼 단계적으로 늘리고 처리량 증가와 latency·전력·비용 증가를 같이 기록합니다. 두 장치가 1.6배 빨라졌다면 실패가 아니라 workload와 communication의 결과일 수 있지만 목표 비용 대비 이득은 평가해야 합니다. 한 device 기준선과 이전 parallel config를 보존하고 node 한 개 장애, collective timeout과 재시작 뒤 같은 checkpoint·request가 회복되는지 시험합니다.

왜 이런가

분산 계산은 partial tensor와 상태를 장치 사이에 교환하고 가장 느린 stage·device가 전체 step 완료를 제한하기 때문입니다.

언제 문제가 되는가

Device 수를 늘렸는데 throughput이 거의 오르지 않거나 p95가 튀면 collective, pipeline bubble, shard imbalance와 network를 확인합니다.

초보자가 자주 하는 오해

VRAM과 TOPS를 장치 수만큼 더하면 통신 없이 정확히 같은 배수의 model 크기·속도를 얻는 것은 아닙니다.

직접 확인하는 방법

1·2·목표 device에서 shard·collective byte, stage active·wait, interconnect utilization, throughput·p95·전력과 장애 복구를 비교하십시오.

Processor는 온도와 전력 한도 안에서 clock을 조절합니다. 노트북 GPU·NPU와 desktop GPU가 같은 silicon 이름을 공유해도 configured power와 cooling이 다르면 지속 성능이 달라질 수 있습니다. 첫 20초의 빠른 생성 뒤 clock이 내려가면 짧은 benchmark는 실제 회의 요약이나 긴 batch를 대표하지 못합니다. Warm-up 후 목표 시간만큼 반복하고 시간에 따른 token/s를 저장합니다.

Device software가 보고하는 chip power는 system 전체 전력이 아닐 수 있습니다. CPU host, DRAM, fan, storage와 power supply 손실을 포함하려면 신뢰할 수 있는 wall measurement가 필요합니다. Energy per token 또는 job을 계산할 때 input·output token과 성공 여부를 함께 기록합니다. 느리지만 낮은 전력인 장치와 빠르지만 idle·peak가 높은 장치의 비용은 실제 요청률과 duty cycle로 비교합니다.

Thermal throttling은 token/s 하락, clock 변화와 온도 상승을 같은 timeline에서 확인합니다. Error correction, device reset과 compiler crash도 장시간·고온에서 나타날 수 있습니다. Fan을 무조건 고정하거나 power limit을 높이는 변경은 소음·수명·안전과 warranty 조건을 포함하므로 교육 site에서 보편 명령으로 강요하지 않습니다. Vendor 도구와 장비 운영 규칙 안에서 보수적으로 시험합니다.

승인 기준에는 peak가 아니라 예를 들어 30분 반복의 p95·최저 throughput, 최대 온도·wall energy와 error 0처럼 지속 조건을 넣습니다. 시간 자체를 강의 소요 시간으로 표시하지 않고 workload 측정 조건으로 명시합니다. Cooling 변경이나 driver update 뒤 같은 장문·동시성 세트를 다시 실행하고 이전 power profile로 돌아갔을 때 성능·안정성이 회복되는지 확인합니다.

왜 이런가

장치는 전력·온도 한도를 지키기 위해 clock을 동적으로 바꾸므로 짧은 peak와 지속 workload의 공급률이 다를 수 있습니다.

언제 문제가 되는가

처음에는 빠르지만 시간이 지나 token/s가 떨어지거나 reset·오류가 생기면 온도·clock·power와 cooling 조건을 확인합니다.

초보자가 자주 하는 오해

제품의 peak TOPS나 한 번의 빠른 응답이 하루 종일 같은 성능·전력·소음으로 유지된다는 보장은 없습니다.

직접 확인하는 방법

충분히 긴 반복에서 시간별 token/s, clock·온도·device와 wall power, 오류를 기록하고 같은 cooling·room 조건으로 재시험하십시오.

Local CPU·GPU·NPU는 입력을 조직 내부 장치에 둘 수 있지만 이것만으로 보안이 완성되지는 않습니다. Model download, telemetry, remote management, shared account와 log 경로를 확인해야 합니다. Device memory와 local disk의 cache·prompt가 누가 볼 수 있는지, 퇴사·분실·수리 때 어떻게 삭제하는지 정합니다. 민감한 원문을 benchmark log에 그대로 남기지 않고 익명 정상·경계 세트를 사용합니다.

Cloud TPU·GPU는 큰 장비를 바로 사용할 수 있지만 region·quota, VM·slice provisioning, storage와 data egress, network latency와 service limit이 있습니다. Hardware 시간만이 아니라 compile·idle, attached storage, traffic과 운영 인력 비용을 포함합니다. Local 구매는 감가, 전력·냉각, rack·소음, spare와 장애 시간까지 더합니다. 서로 다른 기간과 사용률을 섞지 않고 같은 workload당 비용으로 비교합니다.

가용성은 장치 한 개의 안정성이 아니라 failure domain과 복구 시간입니다. Local workstation 한 대는 단순하지만 고장 시 전체 중단이 될 수 있고 cloud slice는 교체 가능하지만 capacity 부족이나 region 장애를 만날 수 있습니다. Checkpoint·model artifact와 config를 다른 failure domain에 보존하고, 새 장치를 얻었을 때 exact manifest로 복원할 수 있는지 시험합니다.

구매·cloud 승인표에는 data classification, 허용 region·network, 담당자, 월간·workload당 비용 상한, 지원 계약과 종료 절차를 넣습니다. 최고 token/s 후보가 data boundary를 위반하거나 복구 시간을 못 맞추면 보류합니다. 반대로 느린 CPU local이 traffic과 privacy 요구에 충분하면 더 복잡한 cluster를 만들지 않는 것도 기술적으로 성숙한 결정입니다.

왜 이런가

실제 서비스는 장치 외에 data 이동, account·network, 비용과 장애 복구 자원에 의존하며 이 조건이 사용 가능성을 제한하기 때문입니다.

언제 문제가 되는가

Cloud quota·network 또는 local 단일 장치 고장, 예상 밖 비용과 log 노출이 생기면 hardware benchmark만으로는 복구할 수 없습니다.

초보자가 자주 하는 오해

Local이면 자동으로 안전·무료이고 cloud면 자동으로 확장·복구되거나 가장 빠른 장치가 전체 비용도 가장 낮은 것은 아닙니다.

직접 확인하는 방법

Data flow, failure domain, quota·region, wall energy·cloud bill과 복원 절차를 같은 workload·기간 기준으로 기록하십시오.

Load 실패는 exact model architecture·quant와 runtime feature, driver·binary compatibility, artifact integrity와 memory allocation log부터 봅니다. Error message를 지우고 무작정 package를 upgrade하면 처음 실패 조건을 잃습니다. 작은 공식 support model이 같은 backend에서 load되는지 확인해 device·driver 경로와 목표 model 지원을 분리합니다. Community patch를 적용하기 전 현재 environment manifest와 rollback image를 보존합니다.

OOM은 file 크기만 보지 않고 load, prefill, decode와 concurrency 순간의 device·host peak를 기록합니다. Context·batch·sequence를 작은 성공 값으로 줄이고 하나씩 늘립니다. Quant를 낮추거나 offload를 동시에 켜면 quality와 transfer라는 새 변수가 생깁니다. Admission limit으로 새 요청을 보호하고 실패 request가 작은 기준선과 이전 backend에서 회복되는지 확인합니다.

응답이 느리면 CPU preparation, compile, host-device copy, kernel, collective, cache·queue와 thermal timeline을 나눕니다. 조용한 fallback과 unsupported fused kernel은 장치 utilization만으로 놓칠 수 있습니다. Cold만 느린지, prefill·decode 중 어디인지, concurrency에 따른 변곡점을 찾습니다. 더 큰 장치로 교체하기 전 profiler의 가장 긴 구간을 한 항목씩 바꿉니다.

출력 품질이 달라지면 model·tokenizer·template·sampling이 같은지 확인한 뒤 operator device와 inference precision, quant artifact를 대조합니다. Runtime kernel 차이를 원인으로 단정하지 않고 같은 실패 입력이 CPU 또는 높은 precision 기준선에서 회복되는지 시험합니다. Runbook에는 각 증상의 첫 log·metric, 안전 한도, 변경 순서, 이전 container·artifact와 종료 gate를 적어 다음 담당자가 같은 절차를 재현하게 합니다.

왜 이런가

Load·memory·latency·quality는 서로 다른 system layer에서 생길 수 있어 증상에 맞는 가장 싼 증거부터 분리해야 하기 때문입니다.

언제 문제가 되는가

재시작·upgrade·quant 변경을 동시에 하면 잠시 성공해도 원인을 잃고 같은 workload에서 장애가 반복됩니다.

초보자가 자주 하는 오해

가속기 장애는 모두 driver 문제이거나 더 큰 VRAM·높은 TOPS 장치로 바꾸면 자동으로 해결된다고 생각하지 않습니다.

직접 확인하는 방법

Exact 실패 입력과 manifest를 보존하고 작은 지원 model·짧은 context·concurrency 1·높은 precision 기준선에서 한 변수씩 비교하십시오.

평가표는 후보 이름보다 workload에서 시작합니다. Exact model·revision·artifact, tokenizer·template, normal·boundary·failure input, input·output token, sampling, batch·concurrency와 필수 품질을 고정합니다. 장치마다 지원되는 quant가 달라 완전히 같은 artifact를 못 쓰면 차이를 공개하고 높은 precision 기준선과 업무 품질을 함께 둡니다. 결과를 본 뒤 prompt나 목표 latency를 후보별로 바꾸지 않습니다.

Cold 측정에는 process 시작, model load와 compile·첫 요청을 포함하고 warm 측정은 cache가 준비된 반복 요청을 봅니다. Prefill token/s, TTFT, decode token/s, End-to-End latency와 target concurrency throughput을 분리합니다. Average뿐 아니라 p50·p95·최대, 성공률과 실제 token을 기록합니다. Power와 temperature, clock throttling도 장시간 요청에서 측정해 짧은 burst 사양이 지속 성능처럼 보이지 않게 합니다.

첫 실습은 memory 계산, official compatibility와 execution log가 모두 있어야 후보를 통과시킵니다. 둘째 실습은 memory·compute ceiling과 관측값의 차이를 보여 줍니다. Browser 통과는 장비 증거가 아니며 실제 profiler 값으로 입력을 교체해야 합니다. 서로 다른 장치의 결과가 좋더라도 업무 정확도·형식·안전 gate가 실패하면 speed 순위를 이유로 승인하지 않습니다.

Runtime update 뒤 p95가 튀면 model·quant·driver를 동시에 바꾸지 않습니다. 이전 container·같은 model·실패 request로 작은 성공 기준선을 복구하고, context와 concurrency를 한 항목씩 늘립니다. 최종 runbook에는 증상, 먼저 볼 device·copy·kernel·queue 지표, admission limit, 이전 image·artifact와 회복 조건을 적습니다. 31과목 품질 gate와 마찬가지로 장비 승격도 검증되지 않은 빈칸이 있으면 hold가 정상입니다.

왜 이런가

장치 이점은 compile·cache 상태, prompt 단계, batch와 workload 품질에 따라 달라 한 숫자로 재현할 수 없기 때문입니다.

언제 문제가 되는가

평균 token/s는 높지만 cold start·p95·품질·전력 또는 목표 concurrency가 실패하면 실제 서비스에는 맞지 않습니다.

초보자가 자주 하는 오해

한 번의 짧은 benchmark나 vendor demo가 내 model·runtime·업무의 구매·배포 승인을 대신하지 않습니다.

직접 확인하는 방법

고정 manifest로 cold·warm, prefill·decode, concurrency와 품질·전력을 반복하고 이전 backend rollback 후 같은 실패 입력을 재시험하십시오.

“16GB GPU면 충분한가”라는 질문은 모델, context와 사용자가 빠져 있어 판정할 수 없습니다. 업무 manifest에는 exact model ID·revision·artifact·quantization, tokenizer와 chat template, 정상 입력과 최대 입력 token, 최대 출력 token, 동시에 처리할 sequence 수와 sampling을 적습니다. 대화형 서비스라면 Time To First Token(TTFT), 생성 속도와 p95 End-to-End 지연을 나누고, batch 처리라면 시간당 완료 건수와 실패율을 우선합니다. 이 계약이 없으면 후보마다 유리한 조건으로 측정하게 됩니다.

품질은 장비 선택의 바깥 조건이 아닙니다. 예를 들어 규정 상담은 정답과 인용 일치, 모르면 보류하는 비율, JSON 추출은 schema 유효성과 field별 정확도, coding은 test 통과와 보안 규칙을 측정합니다. Q4 model이 memory와 지연을 통과해도 필수 정확도가 실패하면 그 GPU에 맞는 후보라고 승인할 수 없습니다. 더 높은 precision이나 큰 model이 필요해지면 memory 장부부터 다시 계산해야 하므로 품질과 장비는 하나의 반복 과정입니다.

필수 gate와 선호 지표를 구분합니다. “인용 정확도 95% 이상, p95 TTFT 2초 이하, peak VRAM 90% 이하, 목표 동시성에서 오류 0”은 하나라도 실패하면 보류할 조건입니다. 평균 token/s, fan 소리, 확장 여지는 통과 후보끼리 순위를 정하는 선호 항목일 수 있습니다. 모든 값을 임의 점수로 더하면 필수 품질 실패가 높은 peak 성능에 가려지므로 먼저 통과·실패를 판정한 뒤 선호를 비교합니다.

현재 보유한 CPU나 GPU에서 필수 품질을 통과하는 가장 작은 model을 baseline으로 보존합니다. 새 후보가 해결해야 할 문제를 “32K context”, “동시 사용자 4명”, “더 높은 precision”처럼 한 문장으로 적습니다. 구매 후 문제가 생기면 이 baseline은 서비스 지속과 원인 분리를 위한 rollback 경로가 됩니다. 기존 장비가 목표를 이미 충족한다면 최고 사양으로 교체하지 않는 것도 유효한 결론입니다.

왜 이런가

GPU의 적합성은 장치 자체가 아니라 실행할 model·입력·동시성·품질과 지연 목표의 조합에서만 정의되기 때문입니다.

언제 문제가 되는가

후보별로 prompt·context·quant와 합격선을 바꾸면 결과가 좋아 보여도 장치 차이의 원인을 설명하거나 재현할 수 없습니다.

초보자가 자주 하는 오해

모델 parameter와 VRAM만 알면 모든 사용자의 추천이 정해지거나 가장 큰 model이 항상 업무 품질도 가장 높다는 생각은 틀립니다.

직접 확인하는 방법

후보 이름을 지운 상태에서 exact artifact, 정상·경계·실패 입력, 동시성, 품질·p95 gate와 현재 baseline을 한 장에 먼저 작성하십시오.

GPU 기록에는 vendor, full model name, desktop add-in board인지 notebook 내장형인지, 전용 VRAM, board manufacturer와 power limit을 포함합니다. “RTX 4060 Ti”처럼 같은 이름에 memory variant가 있거나 “RTX 3080”처럼 여러 용량이 유통된 사례에서는 이름만으로 모델 범위를 추천할 수 없습니다. 운영체제의 장치 조회와 실제 총 VRAM을 확인하고, 다른 process를 제외한 시작 시 available VRAM도 별도로 기록합니다. Shared GPU memory 표시는 discrete VRAM과 같은 자원으로 더하지 않습니다.

공식 NVIDIA·AMD 제품 페이지는 memory size·type, bandwidth, board power와 지원 OS 같은 사실의 1차 자료입니다. 그러나 partner card는 길이·cooler·전원 connector와 factory clock이 달라질 수 있고 notebook은 제조사가 전력을 제한합니다. 예를 들어 desktop과 notebook에 같은 계열 숫자가 붙어도 장시간 LLM 처리량을 같은 값으로 예상할 수 없습니다. 완제품 제조사 사양과 firmware power mode까지 확인한 뒤 로컬 device query로 대조합니다.

중고 장비는 BIOS 변경, cooling 상태, power connector와 실제 memory 오류를 추가로 봅니다. 부팅과 짧은 화면 출력이 정상이어도 큰 VRAM allocation이나 긴 compute에서 오류가 날 수 있습니다. 구매 승인 전에 memory test와 반복 inference를 실행하고 temperature·clock·error log를 저장합니다. 외관과 판매자의 게임 benchmark만으로 LLM workload 안정성을 대신하지 않습니다.

장치 manifest에는 공식 URL의 검토 월과 로컬 조회 결과, driver version, OS build를 함께 남깁니다. 제품 페이지는 업데이트되고 driver 지원 범위도 변하므로 “최신”이라는 단어 대신 exact version을 적습니다. 장비를 교체하거나 OS를 재설치한 뒤 같은 이름이 보여도 이전 검증이 자동 승계되지 않습니다. 새 manifest가 이전과 같은지 대조한 뒤 smoke test부터 다시 실행합니다.

왜 이런가

Model name의 일부만 같아도 memory·power·cooling과 driver 경로가 달라 실제 load와 지속 처리량이 바뀔 수 있기 때문입니다.

언제 문제가 되는가

판매 제목의 VRAM을 믿고 구매하면 다른 variant나 notebook power 제한 때문에 예상 model이 들어가지 않거나 장시간 성능이 낮을 수 있습니다.

초보자가 자주 하는 오해

새 세대 숫자가 크면 더 오래된 큰 VRAM 제품보다 언제나 더 큰 model을 안정적으로 실행한다는 순위는 성립하지 않습니다.

직접 확인하는 방법

공식 사양, board 또는 notebook 제조사 문서, 로컬 device name·VRAM·power limit을 세 줄로 대조하고 서로 다른 값은 승인 전에 해소하십시오.

가중치 이론값은 parameter 수와 저장 bit로 시작하지만 exact artifact에는 quantization scale, tensor별 mixed type, metadata와 alignment가 포함됩니다. Dense와 Mixture of Experts의 total weight, vision projector 같은 추가 artifact도 확인합니다. 이름이 8B Q4라고 해서 모든 파일이 정확히 4GB이거나 같은 runtime allocation을 쓰는 것은 아닙니다. 다운로드한 파일 byte, checksum과 model load 뒤 device allocation을 출발식 대신 기록합니다.

KV cache는 layer 수, KV head, head dimension, token, cache precision과 동시 sequence에 따라 늘어납니다. Runtime workspace, graph·kernel buffer와 allocator reserve도 필요합니다. 예를 들어 weight 9GiB가 12GiB GPU에 load되어도 긴 입력의 KV cache 2.2GiB와 workspace 1.5GiB가 더해지면 안전선이 사라집니다. 평균 대화가 아니라 최대 허용 입력·출력과 목표 concurrency에서 peak를 측정합니다.

Desktop display와 브라우저, 다른 compute process도 VRAM을 사용합니다. 시작 전 free VRAM과 요청 중 peak를 모두 기록하고, model reload나 여러 worker가 동시에 뜨는 배포 절차도 시험합니다. 고정 10% 또는 20%를 모든 환경에 기계적으로 적용하는 대신 부하 반복에서 관찰한 변동과 실패점을 근거로 headroom을 정합니다. 여유가 없는 후보는 한 번 성공해도 안정적이라고 승인하지 않습니다.

Out of Memory가 나면 작은 context·동시 1의 성공 기준선으로 돌아갑니다. Model, quant, context, batch와 offload를 동시에 바꾸지 않고 한 항목만 낮춰 같은 실패 입력을 재시험합니다. 실패 시점의 설정과 log를 버리지 않아야 용량 경계를 설명할 수 있습니다. 다음 실습에서는 제품 VRAM이 아니라 weight·cache·workspace 합계, 90% 안전선, 공식 지원과 rollback을 함께 판정합니다.

왜 이런가

LLM 실행 memory는 정적인 weight 외에 요청 길이와 동시성에 따라 변하는 cache·workspace를 포함하므로 peak가 제품 용량에 먼저 닿을 수 있습니다.

언제 문제가 되는가

파일 load만 시험하면 최대 context prefill이나 동시 요청에서 처음으로 발생하는 OOM과 allocator 변동을 구매 전에 발견하지 못합니다.

초보자가 자주 하는 오해

VRAM이 model file보다 크면 남은 모든 공간을 context에 쓸 수 있거나 일정 비율의 여유가 모든 runtime에서 똑같이 안전한 것은 아닙니다.

직접 확인하는 방법

정상·최대 context, 동시성 1·목표값, reload에서 weight·KV·workspace·다른 process와 peak를 측정해 한 장부에 적으십시오.

일부 runtime은 model layer를 GPU에 가능한 만큼 올리고 나머지를 CPU RAM에서 계산합니다. 이 방식은 더 큰 model을 실행할 수 있게 하지만 host-device link를 통한 tensor 이동과 CPU 계산이 decode 병목이 될 수 있습니다. System RAM 64GB와 VRAM 16GB를 동일한 80GB 고속 memory로 더하지 않습니다. Offloaded layer 수, host RAM peak, 전송 byte, CPU utilization과 p95를 완전 GPU 기준선과 비교합니다.

여러 GPU도 단순 VRAM 합계가 아닙니다. Tensor parallel, pipeline 또는 layer split은 각 장치에 weight와 cache를 나누는 방식, 통신량과 지원 operator가 다릅니다. 예를 들어 12GB 카드 두 장이 24GB 한 장과 같은 model을 담을 수 있는 경우에도 GPU 사이 link가 느리거나 runtime split이 제한되면 token/s와 안정성이 다릅니다. Motherboard slot bandwidth, peer access, 전원·냉각과 backend multi-GPU 지원을 함께 확인합니다.

llama.cpp 공식 multi-backend·operator 문서는 CUDA·ROCm·Vulkan 등의 기능 범위가 같지 않음을 보여 줍니다. Backend가 장치를 인식해도 특정 quant, Flash Attention, KV cache 기능이나 multi-GPU mode가 부분 지원일 수 있습니다. Startup log의 offloaded layer, backend별 tensor allocation과 CPU fallback을 보존합니다. “GPU 99% 사용” 한 숫자는 모든 operator가 예상 경로에 있다는 증거가 아닙니다.

복구할 때는 단일 GPU·작은 model·짧은 context로 돌아가고, offload layer 또는 두 번째 GPU를 한 항목씩 추가합니다. Output 품질도 함께 비교해 잘못된 kernel이나 불안정한 peer path를 놓치지 않습니다. OOM만 사라졌다는 이유로 승인하지 않고 목표 동시성의 p95와 반복 오류까지 통과시킵니다. Multi-GPU가 비용·전력·복잡성까지 포함해 단일 큰 VRAM 후보보다 나은지 같은 workload로 판단합니다.

왜 이런가

Memory 위치가 나뉘면 계산 사이에 data를 이동하거나 동기화해야 하므로 총 용량과 실제 처리량이 독립적으로 변하기 때문입니다.

언제 문제가 되는가

VRAM 합계만 보고 설계하면 model은 load되지만 CPU fallback·PCIe·GPU간 통신 때문에 p95와 token/s가 목표를 크게 벗어날 수 있습니다.

초보자가 자주 하는 오해

두 GPU의 VRAM을 더하면 모든 runtime에서 같은 크기의 단일 GPU처럼 자동으로 사용되거나 system RAM offload가 공짜라는 생각은 틀립니다.

직접 확인하는 방법

단일 GPU, offload, multi-GPU를 같은 manifest로 실행해 tensor 배치, 전송·통신, host/device peak, 품질과 p95를 비교하십시오.

NVIDIA 경로는 GPU architecture, installed driver, application이 요구하는 CUDA runtime, framework wheel 또는 container와 model feature가 연결됩니다. `nvidia-smi`가 장치를 표시한다고 vLLM container와 quant kernel까지 보증되는 것은 아닙니다. NVIDIA CUDA compatibility 문서는 major release별 minimum driver와 minor-version compatibility의 제한을 설명합니다. 배포 기록에는 driver, toolkit 또는 container CUDA, framework와 application version을 각각 적습니다.

새 application이 오래된 driver에서 initialization error를 내거나 새 feature에 필요한 PTX·driver 지원이 없을 수 있습니다. 반대로 새 driver가 오래된 CUDA application을 실행할 수 있는 backward compatibility 범위도 조건을 갖습니다. Error를 model 크기나 VRAM 문제로 바꾸어 설명하지 않고 device query와 작은 공식 smoke test로 software 사슬부터 확인합니다. Driver update 전 이전 package·image와 rollback 절차를 보존합니다.

Quantization method도 GPU 세대와 독립적이지 않습니다. vLLM 공식 quantization 문서의 hardware compatibility 표는 method별 지원이 달라지고 바뀔 수 있음을 밝힙니다. 예를 들어 특정 FP8·AWQ·GPTQ 조합의 지원을 다른 GPU 또는 오래된 vLLM version에 일반화하지 않습니다. Exact build의 startup log와 profiler에서 선택한 quant kernel, attention feature와 execution device를 확인하고 CPU fallback이나 feature disable을 기록합니다.

문제를 분리하는 순서는 device query, 작은 matrix 또는 runtime smoke test, 지원이 명확한 작은 model, 목표 artifact load, 짧은 generation, 최대 context와 동시성입니다. 한 번에 driver·CUDA·framework·model을 모두 업데이트하지 않습니다. 이전 image에서 같은 실패 입력이 회복되면 한 구성 요소씩 올려 최초 실패 경계를 찾습니다. 최종 승인은 “CUDA 지원”이 아니라 exact version manifest와 실행 log를 근거로 합니다.

왜 이런가

GPU에서 실행되는 application은 user-space library와 kernel driver, architecture별 compiled code와 model feature가 모두 맞아야 하기 때문입니다.

언제 문제가 되는가

장치가 보여도 initialization error, no kernel image, 미지원 quant 또는 조용한 fallback으로 load·속도·품질이 실패할 수 있습니다.

초보자가 자주 하는 오해

`nvidia-smi`의 CUDA 숫자가 설치한 모든 toolkit·framework version과 feature를 뜻하거나 NVIDIA GPU면 모든 CUDA build가 실행되는 것은 아닙니다.

직접 확인하는 방법

Exact driver·container·framework·application·quant를 기록하고 작은 공식 model에서 device·kernel·feature log를 확인한 뒤 목표 model로 넓히십시오.

AMD 공식 제품 페이지는 exact Radeon의 memory size·type·bandwidth와 board power 같은 하드웨어 사실을 제공합니다. 예를 들어 RX 9070 XT의 공식 16GB 사양은 그 제품의 용량 근거이지 모든 RX 9000 partner board나 LLM runtime의 성능 보증이 아닙니다. Peak FP·INT 수치도 특정 precision·matrix 조건의 이론 상한입니다. NVIDIA의 같은 VRAM 후보와 token/s가 같거나 다르다고 이 숫자만으로 결론 내리지 않습니다.

ROCm 지원은 GPU 이름 하나가 아니라 운영체제·kernel 또는 Windows/WSL, driver, ROCm release와 framework version의 조합입니다. AMD compatibility matrix는 최신 release와 이전 release, Radeon·Ryzen·Instinct 경로를 구분합니다. 배포할 exact version의 행을 저장하고 다른 release의 성공 사례를 옮겨 쓰지 않습니다. 목록 밖 GPU를 override로 실행한 community 절차는 실험 가능성이지 공식 production support가 아닙니다.

llama.cpp의 HIP/ROCm과 Vulkan, PyTorch ROCm, vLLM ROCm은 서로 다른 application 경로입니다. 한 경로에서 GGUF model이 실행된 사실이 다른 framework의 지원을 뜻하지 않습니다. 예를 들어 Vulkan backend가 답을 생성해도 ROCm용 training library와 동일한 kernel·feature 집합을 쓰는 것은 아닙니다. Exact build option, device discovery, offloaded layer와 operator 표를 확인하고 목적에 맞는 backend를 고릅니다.

작은 공식 지원 구성에서 device discovery와 generation을 성공시킨 뒤 목표 quant·context·concurrency를 한 항목씩 올립니다. 실패를 install, driver, architecture·operator, memory, latency와 quality 단계로 분류합니다. Workaround가 필요하면 upgrade 때 깨질 가능성, 지원 주체와 이전 build 복구 절차를 승인표에 적습니다. AMD인지 NVIDIA인지에 대한 선호가 아니라 업무 gate를 통과한 exact 조합을 선택합니다.

왜 이런가

ROCm과 application 지원 범위는 release·platform·framework별로 바뀌며 backend마다 operator·quant 기능이 다르기 때문입니다.

언제 문제가 되는가

GPU VRAM만 보고 구매하면 선택한 OS에서 framework가 설치되지 않거나 CPU fallback·미지원 quant로 목표 성능과 기능을 잃을 수 있습니다.

초보자가 자주 하는 오해

Radeon이면 모든 ROCm release·Windows·Linux에서 같은 지원을 받거나 Vulkan·HIP·ROCm application을 하나의 동일 backend로 볼 수 없습니다.

직접 확인하는 방법

공식 matrix의 GPU·OS·driver·ROCm·framework 행과 application build·device log·operator 실행을 exact version으로 연결하십시오.

Cold run에는 process 시작, model load·compile과 첫 요청을 포함하고 warm run은 준비된 cache에서 반복 요청을 측정합니다. Prefill은 긴 입력을 읽는 단계, decode는 새 token을 한 개씩 만드는 단계이므로 병목이 다를 수 있습니다. TTFT, prefill token/s, decode token/s와 End-to-End latency를 나누고 목표 concurrency에서 request throughput과 오류율을 기록합니다. 한 번의 짧은 token/s만으로 사용자가 기다리는 시간을 설명하지 않습니다.

각 조건을 최소 3회 반복하고 평균뿐 아니라 p50·p95·최대와 run별 변동을 남깁니다. 예를 들어 후보 A가 warm decode 50 token/s여도 cold compile이 길고 동시 4에서 p95 TTFT가 5초라면 대화 서비스 gate를 실패할 수 있습니다. 후보 B가 decode 40 token/s지만 필수 품질과 p95를 안정적으로 통과하면 더 적합할 수 있습니다. 결과를 본 뒤 목표를 낮춰 통과시키지 않습니다.

Profiler와 system metric에는 peak device·host memory, GPU utilization, host-device transfer, CPU queue, power·temperature와 clock을 같은 시간축으로 기록합니다. 30초 burst는 빠르지만 20분 뒤 thermal throttling으로 처리량이 떨어질 수 있습니다. Desktop의 fan noise와 room power, notebook의 battery·power mode도 실제 사용 조건입니다. 냉각이나 power limit을 후보마다 다르게 두면 그 조건을 숨기지 않고 별도 configuration으로 기록합니다.

측정 도구가 실제 workload를 왜곡하지 않는지도 확인합니다. 출력 token 수와 종료 조건을 같게 하고, cache hit 여부와 concurrent arrival pattern을 고정합니다. Browser 실습의 숫자는 판정 절차를 배우는 예시이며 실제 장비 증거가 아닙니다. Exact runtime의 log·profiler와 익명화한 업무 평가를 사용하고, 변경된 driver·model·prompt가 있으면 새 run으로 분리합니다.

왜 이런가

LLM 요청의 입력 처리·생성·queue와 장시간 power·thermal 상태는 서로 다른 병목을 가지므로 peak 한 숫자가 실제 체감을 대표하지 못합니다.

언제 문제가 되는가

한 번의 warm decode만 비교하면 cold start, 긴 입력, 목표 동시성, p95 지연과 지속 부하 오류가 배포 후 처음 드러날 수 있습니다.

초보자가 자주 하는 오해

TOPS·TFLOPS나 최고 token/s가 큰 후보가 모든 context·batch와 사용자 수에서 항상 더 빠르고 안정적인 것은 아닙니다.

직접 확인하는 방법

고정 manifest로 cold·warm, prefill·decode, 동시성 단계와 20분 지속 부하를 3회 이상 실행해 품질·지연·memory·전력을 함께 저장하십시오.

Desktop 후보는 GPU 길이와 두께, motherboard slot 간격, power supply 용량·품질과 connector, case airflow를 확인합니다. 고출력 카드가 들어가도 cable bend나 막힌 intake 때문에 안정적이지 않을 수 있습니다. CPU와 system RAM, storage에서 model을 읽는 속도도 cold start와 offload에 영향을 줍니다. GPU만 바꾸는 비용표에 필요한 PSU·case·fan·UPS 교체가 빠지지 않게 합니다.

전력과 소음은 단순 취향이 아니라 지속 운용 조건입니다. 예를 들어 공동 사무실에서 fan noise 제한이 있거나 notebook battery로 작업해야 하면 peak power mode의 결과를 기본값으로 쓸 수 없습니다. Wall power와 장치 power, room temperature, fan profile을 측정 조건에 적습니다. Power limit을 낮춘 효율 후보도 같은 품질·지연 gate로 시험하면 작은 성능 손실로 운영 조건을 만족하는 선택을 찾을 수 있습니다.

가격은 제품의 고정 기술 속성이 아니라 지역, 재고, 세금, 중고 상태와 날짜가 붙는 견적입니다. 교육 본문에 특정 가격 대비 순위를 영구 규칙으로 넣지 않고, 구매 시점의 두세 견적과 warranty·반품·지원 조건을 별도 표에 적습니다. 총비용에는 전력, 추가 부품, 설치와 driver 문제를 해결할 시간, 장애 시 대체 장비를 포함합니다. 최고 VRAM/가격 비율이 지원 공백과 긴 복구 시간을 상쇄한다고 가정하지 않습니다.

유지보수 책임도 선택 기준입니다. 개인 실험은 community backend를 감수할 수 있지만 다중 사용자 서비스는 지원되는 release, 보안 update, monitoring과 rollback image가 더 중요합니다. 다음 분기의 OS·runtime upgrade 시 matrix를 누가 다시 검토할지 정합니다. 장비 수령 후 반품 가능 기간 안에 대표 workload와 실패 복구를 완료하고 필수 gate를 못 맞추면 작은 model, 다른 GPU 또는 cloud 후보로 돌아갑니다.

왜 이런가

GPU는 전원·공간·열·host system과 software maintenance에 의존하며 이 비용과 제한이 실제 사용 가능 시간을 결정하기 때문입니다.

언제 문제가 되는가

카드만 구매한 뒤 PSU·공간·온도 문제가 생기거나 지원되지 않는 update에 운영 시간이 소모되면 benchmark 이익을 얻지 못합니다.

초보자가 자주 하는 오해

GPU 가격만 비교하면 총비용을 알 수 있거나 가장 비싼·최신 제품이 내 장소와 지원 인력에도 가장 적합한 것은 아닙니다.

직접 확인하는 방법

설치 치수·전원·냉각·소음, wall power, 날짜 있는 견적, warranty와 update·rollback 담당자를 승인표에 넣으십시오.

최종 비교표의 행은 exact GPU·OS·driver·runtime·artifact 조합입니다. 열에는 공식 hardware·compatibility 근거, weight·cache·workspace와 peak, 정상·경계·실패 품질, cold·warm·p95·동시성, 지속 전력·온도와 설치 조건을 둡니다. 측정 날짜, command와 config, log·screenshot 위치를 연결합니다. Vendor 전체를 한 행으로 만들거나 “AMD는 저렴함”, “NVIDIA는 호환됨” 같은 일반 평가로 exact 증거를 대신하지 않습니다.

실패 결과도 지우지 않습니다. 예를 들어 16GB 후보가 32K·동시 2에서 OOM이면 8K·동시 1의 성공 기준선과 최초 실패점을 함께 기록합니다. 더 작은 model 또는 quant로 복구했으면 품질 회귀를 다시 측정합니다. 이 정보는 구매를 보류하는 근거이면서 실제 운영에서 admission limit을 정하는 자료입니다. 빈칸은 평균값으로 메우지 않고 확인 책임자와 재시험 조건을 적습니다.

승인 전에는 이전 CPU/GPU backend 또는 이전 driver·container로 rollback하고 같은 실패 입력이 회복되는지 시험합니다. Hardware 장애라면 요청을 이전 장치나 작은 model로 전환하고 새 요청을 제한하는 절차가 필요합니다. Rollback artifact, command, 예상 복구 시간과 확인 지표를 다른 담당자가 실행할 수 있게 씁니다. Checkbox만 선택한 browser 실습은 절차 이해 증거일 뿐 실제 복구 증거가 아닙니다.

추천의 유효 범위는 날짜와 manifest에 묶입니다. Driver·ROCm·CUDA·runtime, model revision, context·동시성 또는 업무 품질 기준이 바뀌면 공식 matrix와 회귀 세트를 다시 실행합니다. 결론은 “NVIDIA가 AMD보다 우수”가 아니라 “이 exact 후보가 이 workload의 모든 필수 gate를 통과했고, 이 조건 밖에서는 재검증한다”여야 합니다. 그래야 다른 사람이 같은 장비를 사거나 업데이트할 때 판단을 재현할 수 있습니다.

왜 이런가

Hardware와 software 지원, workload는 계속 변하므로 선택 근거와 복구 경로가 없으면 같은 이름의 추천을 재사용할 수 없기 때문입니다.

언제 문제가 되는가

통과 값만 남기면 업데이트 후 회귀 원인을 찾지 못하고, 문제 발생 시 이전 안정 구성으로 돌아갈 수 없어 서비스 중단이 길어집니다.

초보자가 자주 하는 오해

한 번 통과한 GPU 추천은 모든 model·runtime·OS에 영구 적용되거나 브랜드별 순위표가 exact 검증을 대신할 수 없습니다.

직접 확인하는 방법

다른 사람이 manifest·artifact·command와 실패 입력만 보고 동일 결과와 rollback을 재현할 수 있는지 독립 검토하십시오.

Personal AI system은 CPU와 GPU가 통합된 compact box, Apple Silicon workstation, NVIDIA software stack을 묶은 개발 system처럼 서로 다른 제품을 포함합니다. 모두 책상 위에서 큰 model을 다룬다고 설명할 수 있지만 CPU architecture, memory bandwidth, accelerator와 운영체제·runtime이 다릅니다. 제품 크기나 “AI computer” 이름은 내 artifact가 load되고 필요한 operator가 실행된다는 근거가 아닙니다. Exact 구성과 workload를 한 행으로 만들어 비교합니다.

업무를 한 사용자의 대화형 inference, 문서 batch, LoRA·QLoRA, 여러 사용자의 API로 나눕니다. 예를 들어 70B Q4 한 명 대화는 큰 weight를 담는 capacity가 중요하지만 14B 동시 8명 service는 KV cache·queue와 p95가 더 중요할 수 있습니다. LoRA는 activation·gradient·optimizer와 checkpoint가 필요해 동일한 base model의 inference보다 memory·storage를 더 씁니다. 하나의 최대 model 숫자로 세 목적을 동시에 승인하지 않습니다.

Data boundary와 가용성도 먼저 씁니다. Local system은 원문을 내부에 둘 수 있지만 account, telemetry, remote management, model download와 log가 외부와 연결될 수 있습니다. Box 한 대와 내부 SSD 한 개에 service와 artifact가 모두 있으면 hardware 장애가 전체 중단과 data 손실로 이어집니다. 허용 downtime, backup 위치, spare·cloud 또는 기존 장비 fallback과 실제 복구 시간을 업무 계약에 넣습니다.

현재 장비의 품질·지연 baseline을 남기고 새 box가 해결할 한계를 명시합니다. 목표가 없는 상태에서 큰 memory만 구매하면 model은 load돼도 속도·software·운영이 맞지 않을 수 있습니다. 후보를 가린 채 동일 artifact·입력·출력·동시성과 평가 rubric을 실행하고, 필수 gate에 실패한 system은 광고의 최대 수치와 관계없이 보류합니다.

왜 이런가

같은 memory 용량도 inference·training·service가 요구하는 cache·activation·queue와 복구 책임이 다르기 때문입니다.

언제 문제가 되는가

목적을 섞으면 큰 model load 성공을 LoRA·동시 사용자·24시간 availability의 통과로 오판할 수 있습니다.

초보자가 자주 하는 오해

AI box라는 이름이 같은 제품은 비슷한 runtime과 속도·가용성을 제공하거나 한 대면 개발부터 production까지 모두 충분한 것이 아닙니다.

직접 확인하는 방법

Exact model·precision·context·동시성, 품질·p95·job 시간과 장애 허용·fallback을 후보 이름 없이 먼저 작성하십시오.

Unified memory는 CPU와 GPU가 하나의 physical pool에 접근할 수 있어 discrete VRAM보다 큰 weight를 배치하기 쉽습니다. 그러나 운영체제, desktop display, filesystem cache, tokenizer와 database도 같은 총량을 사용합니다. 예를 들어 128GB system에서 OS·application 10GB, weight 82GB, KV·workspace 22GB와 안전 여유 12GB를 잡으면 새 concurrency에 남는 공간은 2GB입니다. 제품 memory 전체를 artifact byte와 같다고 두지 않습니다.

Model 이름으로 weight를 추정한 뒤 exact file byte와 load allocation으로 교체합니다. Quant scale·metadata, mixed tensor, vision projector와 MoE total weight가 이름 계산에 빠질 수 있습니다. KV cache는 context와 concurrent sequence에 따라 늘고 training은 activation·gradient·optimizer가 추가됩니다. Load, 최대 prefill, 긴 decode, 목표 concurrency와 training step에서 system 전체와 accelerator allocation peak를 따로 측정합니다.

Memory 보고 도구의 의미도 system별로 확인합니다. Unified architecture에서는 CPU와 GPU 사용량을 중복 또는 다른 관점으로 보일 수 있고 display reserved memory·firmware 설정이 가용량을 바꿀 수 있습니다. 한 숫자만 저장하지 말고 process resident, system available, GPU allocation과 swap·memory pressure를 시간축으로 수집합니다. Tool이 “VRAM 0” 또는 unsupported라고 표시하는 경우 공식 문서의 권장 보고 경로를 사용합니다.

실패 복구는 가장 작은 model·context·batch로 돌아가 한 항목씩 확장합니다. Swap이 켜져 OOM 없이 계속됐더라도 storage I/O 때문에 p95 지연이나 training step 소요 시간이 급증할 수 있으므로 성공으로 처리하지 않습니다. Quant를 낮췄다면 품질 회귀를, context를 줄였다면 업무 completeness를 다시 평가하고 이전 artifact·설정으로 같은 실패가 회복되는지 확인합니다.

왜 이런가

하나의 physical pool을 여러 system component가 공유하고 workload 단계마다 allocation이 달라 제품 총량이 process의 안전 예산과 같지 않기 때문입니다.

언제 문제가 되는가

Weight load만 확인하면 최대 context·동시성·training step에서 memory pressure, swap과 OOM이 처음 나타날 수 있습니다.

초보자가 자주 하는 오해

Unified memory는 GPU가 총 memory를 독점하거나 capacity 부족과 data movement·동기화 비용을 없애는 기술이 아닙니다.

직접 확인하는 방법

시작·load·prefill·decode·목표 concurrency 또는 training step에서 OS·app·weight·cache·workspace·swap peak를 한 장부로 기록하십시오.

작은 batch decode는 weight를 반복 읽는 비중이 커 memory bandwidth 제한을 받기 쉽습니다. 예를 들어 token당 유효 read 80GB, effective bandwidth 240GB/s라면 단순 memory ceiling은 약 3 token/s입니다. Cache reuse와 quant kernel에 따라 가정이 달라지므로 이 식은 정확한 예측이 아니라 실측과 단위의 모순을 찾는 sanity check입니다. 공식 peak bandwidth를 그대로 넣지 않고 profiler의 유효값을 사용합니다.

긴 prompt prefill과 training은 matrix compute와 activation·memory traffic의 조합이 다릅니다. 제품의 FP4 sparsity TOPS를 BF16 LoRA throughput이나 모든 LLM token/s로 바꾸지 않습니다. Exact operator·precision이 hardware unit을 사용하고 runtime kernel이 지원하는지 profiler에서 확인합니다. Candidate가 다른 quant만 지원하면 품질과 artifact 차이를 공개하고 공통 높은 precision baseline을 함께 둡니다.

Power와 thermal도 ceiling을 움직입니다. Compact system은 짧은 burst에서 높은 clock을 보이다가 장시간 생성·training에서 temperature 또는 power limit에 닿을 수 있습니다. Wall power, SoC 또는 package power, clock·temperature와 token/s·step/s를 같은 시간축으로 기록합니다. 30초 demo와 30분 job을 같은 지속 성능으로 보고하지 않으며 사무실 소음·room temperature 조건도 적습니다.

두 번째 실습에서는 공식 bandwidth·TOPS를 직접 순위로 만들지 않고 업무 품질, p95·job time, memory peak와 30분 유지율을 함께 판정합니다. 결과가 실패하면 목표를 사후에 낮추지 않고 model·runtime·power mode나 system 후보 중 한 항목만 바꿉니다. 더 느려도 모든 필수 gate를 안정적으로 통과하는 후보가 실제로 더 적합할 수 있습니다.

왜 이런가

Capacity, data 공급률, 연산률과 장시간 power 상태는 서로 다른 물리 제약이며 workload 단계마다 먼저 닿는 제한이 달라집니다.

언제 문제가 되는가

최대 model load 또는 peak TOPS만 보면 대화 token/s, 긴 prefill과 training step·지속 부하 실패를 구매 후 발견하게 됩니다.

초보자가 자주 하는 오해

Memory가 크면 반드시 빠르거나 공식 bandwidth·TOPS가 큰 system이 모든 precision·runtime에서 항상 우세한 것은 아닙니다.

직접 확인하는 방법

같은 manifest에서 load·prefill·decode·training과 30분 부하의 effective bandwidth, 지연·처리량, power·temperature를 분리해 측정하십시오.

NVIDIA 공식 hardware 문서는 DGX Spark가 Grace Blackwell architecture, 20-core Arm processor, 128GB LPDDR5x unified system memory와 273GB/s bandwidth를 사용한다고 명시합니다. 240W supplied power adapter와 140W GB10 TDP, storage와 10GbE·ConnectX-7도 system 조건입니다. 이 사양을 desktop RTX의 GDDR VRAM 또는 datacenter GPU HBM과 같은 memory path로 표시하지 않습니다.

공식 최대 200B model 또는 dual system의 더 큰 model 지원은 어떤 artifact·precision·context·software에서 가능한지 풀어 써야 합니다. 200B parameter가 200GB file이나 일정 token/s를 뜻하지 않으며 MoE는 activated보다 total weight가 load 조건을 정할 수 있습니다. 먼저 official example의 exact image·model을 재현하고 file byte·memory peak·token/s를 확인한 뒤 내 업무 model과 평가 세트로 교체합니다.

한 대와 두 대도 같은 system이 아닙니다. Dual configuration은 network link, model split·runtime 지원과 통신을 추가합니다. 두 system의 memory 합계를 단일 pool처럼 처리하지 않고 placement, link byte·latency, 실패 시 partial system과 recovery를 검증합니다. 큰 model이 분산 load되어도 단일 사용자의 p95와 동시 처리량이 목표를 만족하는지 별도 측정합니다.

제품 페이지와 user guide는 업데이트되므로 검토 날짜와 exact DGX OS·driver·CUDA, firmware를 고정합니다. Release note의 known issue와 unified memory reporting 변경을 확인하고 update 전 이전 image와 model artifact를 보존합니다. Update 뒤 작은 sample→목표 model→경계 workload 순으로 재시험하며 문제가 나면 이전 system image에서 같은 요청이 회복되는지 확인합니다.

왜 이런가

제품 capability는 특정 architecture·memory·power·software와 artifact 조건의 결합이며 parameter 숫자만으로 실행 결과를 정할 수 없기 때문입니다.

언제 문제가 되는가

최대 model 문구를 구매 보증으로 쓰면 실제 artifact·context가 들어가지 않거나 속도·quality·dual 통신이 목표를 못 맞출 수 있습니다.

초보자가 자주 하는 오해

DGX 이름이 datacenter GPU와 동일한 HBM·x86 environment를 뜻하거나 200B 이하 모든 model이 같은 속도와 기능으로 실행되는 것은 아닙니다.

직접 확인하는 방법

Exact DGX OS·firmware·container·model·precision·context에서 official example와 내 workload의 file byte·peak·품질·p95를 각각 저장하십시오.

DGX Spark의 CPU는 ARM64입니다. Model server가 공식 ARM image를 제공하더라도 주변 Python wheel, vector database, OCR, audio codec와 custom CUDA extension이 x86_64 binary만 제공할 수 있습니다. Container manifest와 package wheel tag를 확인하고 multi-arch image 또는 source build가 가능한지 조사합니다. “CUDA 지원”만 보고 전체 RAG·agent workflow를 옮기지 않습니다.

예를 들어 model generation은 정상인데 document parser가 실행되지 않거나 browser automation image가 없으면 사용자의 업무는 완료되지 않습니다. Manifest에 model runtime뿐 아니라 ingestion, embedding·reranker, database, API gateway와 monitoring component를 모두 나열합니다. 각 component의 architecture, version·license, test command와 대체 경로를 적고 작은 end-to-end request를 실행합니다.

Source build는 해결책이지만 compiler·library version과 시간이 새 운영 부담이 됩니다. 성능이 낮은 fallback이나 unsupported patch를 사용하면 upgrade마다 다시 빌드해야 할 수 있습니다. Build recipe와 hash, cache·artifact 저장소, failure log를 보존하고 clean machine 또는 container에서 재현합니다. Community patch를 NVIDIA 공식 support와 같은 상태로 기록하지 않습니다.

복구는 알려진 official container와 작은 sample에서 시작해 주변 component를 한 개씩 추가합니다. System update, container base와 application dependency를 동시에 올리지 않습니다. x86 baseline에서 같은 input이 통과하는지와 ARM candidate에서 최초 실패 component를 비교합니다. Production 후보라면 dependency update 책임자와 이전 image rollback, security update 지연의 한계도 승인표에 남깁니다.

왜 이런가

LLM service는 GPU runtime 밖의 host binary와 native extension에 의존하고 instruction set이 다르면 package 자체가 실행되지 않을 수 있기 때문입니다.

언제 문제가 되는가

Model demo만 성공시키면 실제 RAG·agent·media workflow의 x86-only component가 구매 후 처음 막힐 수 있습니다.

초보자가 자주 하는 오해

CUDA application이면 host architecture와 상관없이 모든 x86 container·wheel이 ARM64에서 그대로 실행된다고 볼 수 없습니다.

직접 확인하는 방법

End-to-end component inventory에서 image architecture·wheel·native extension을 확인하고 clean ARM environment에서 정상·실패 request를 재현하십시오.

AMD Ryzen AI Max+ 395 공식 page는 16-core Zen 5 CPU, Radeon 8060S, 256-bit LPDDR5x, 최대 128GB와 45~120W configurable TDP를 제시합니다. 이 최대값은 모든 laptop·desktop의 실제 구성이 아닙니다. Vendor가 선택한 32·64·96·128GB memory, speed·channel, cooling과 power profile을 exact product page에서 확인합니다. Soldered memory는 구매 후 확장할 수 없는 경우가 많으므로 미래 workload도 보수적으로 계산합니다.

AMD Halo developer platform처럼 exact system 문서는 128GB, 256GB/s, 120W 같은 조합을 명시할 수 있습니다. 이 값은 해당 platform의 공식 조건이며 다른 Ryzen AI Max+ 제품에 그대로 적용하지 않습니다. Firmware의 GPU memory allocation 또는 dynamic behavior, OS가 남기는 memory와 display 사용을 로컬 측정합니다. “최대 128GB”와 “GPU가 128GB를 독점”을 같은 문장으로 쓰지 않습니다.

ROCm은 exact APU·OS·driver·release·framework matrix를 확인합니다. Radeon 8060S가 화면에 보이거나 Vulkan GGUF가 실행되는 사실이 PyTorch training·vLLM의 공식 지원을 뜻하지 않습니다. llama.cpp HIP·Vulkan, Ollama와 framework마다 operator·quant·multi-user feature가 다릅니다. 목표 application의 startup log와 device placement, CPU fallback을 확인합니다.

TDP·memory allocation·backend를 한 번에 바꾸지 않고 작은 support model부터 확장합니다. Linux와 Windows 결과를 섞지 않으며 workaround를 쓰면 support gap과 upgrade·rollback 비용을 기록합니다. Exact model의 품질·p95, memory pressure와 30분 sustained result가 목표를 통과해야 processor의 큰 memory가 실제 가치가 됩니다.

왜 이런가

Processor vendor가 허용하는 최대와 완제품 제조사의 memory·power·cooling, software release 조합이 서로 다른 결정이기 때문입니다.

언제 문제가 되는가

CPU 이름만 보고 구매하면 실제 제품 memory가 작거나 target framework가 미지원이고 thermal limit으로 지속 성능이 낮을 수 있습니다.

초보자가 자주 하는 오해

Ryzen AI Max+ 395가 들어간 모든 제품은 128GB·동일 bandwidth·120W이며 모든 ROCm application이 자동 지원된다는 생각은 틀립니다.

직접 확인하는 방법

Exact 완제품의 RAM·speed·power·firmware와 ROCm matrix 행, runtime device log·30분 workload를 하나의 manifest로 연결하십시오.

Apple 공식 Mac Studio 사양은 M4 Max와 M3 Ultra, GPU core와 unified memory option, 410·546·819GB/s 같은 bandwidth 구성이 다름을 보여 줍니다. “Mac Studio 128GB”처럼 memory만 적지 않고 exact chip·GPU·memory·storage와 macOS version을 기록합니다. 공식 bandwidth를 내 model token/s로 직접 환산하지 않고 같은 artifact·context에서 effective throughput을 측정합니다.

Apple MLX 공식 문서는 Apple Silicon CPU와 GPU가 unified memory array에 접근하는 model을 설명합니다. MLX LM은 model load·generation·fine-tuning 도구를 제공하지만 exact model architecture, quant와 feature 지원은 version별로 확인해야 합니다. MLX용 artifact와 GGUF·Hugging Face checkpoint를 같은 file로 간주하지 않고 source revision, conversion과 hash를 기록합니다.

CUDA-only container, custom extension과 일부 server framework는 macOS·Metal에서 직접 실행되지 않습니다. 대체 runtime으로 옮기면 API, batching, structured output, quant와 quality가 달라질 수 있습니다. 개인 inference가 편하다는 사실을 multi-user production 지원으로 바꾸지 않습니다. 필요한 component inventory를 만들고 macOS native, container VM 또는 외부 service 중 실제 path를 end-to-end로 시험합니다.

복구는 exact macOS·MLX·model bundle을 고정하고 작은 sample→업무 model→최대 context→LoRA 또는 service 순으로 넓힙니다. OS update 뒤 quality·latency가 바뀌면 model과 runtime을 동시에 교체하지 않습니다. 이전 environment와 artifact로 같은 failure input이 회복되는지 확인하고 CUDA-only dependency가 필수라면 Mac 후보를 보류하거나 별도 NVIDIA node를 설계합니다.

왜 이런가

Apple Silicon의 성능·용량과 software 기능은 chip·memory option·macOS·MLX/Metal runtime 조합에서 결정되기 때문입니다.

언제 문제가 되는가

Memory GB만 보면 낮은 bandwidth 구성이나 CUDA-only dependency, 필요한 serving feature 공백을 구매 후 발견할 수 있습니다.

초보자가 자주 하는 오해

모든 Mac Studio가 같은 bandwidth·GPU를 가지거나 unified memory면 CUDA software도 번역 없이 실행되는 것은 아닙니다.

직접 확인하는 방법

Exact chip·memory·bandwidth·macOS와 MLX/llama.cpp version·artifact, end-to-end dependency와 업무 품질·p95를 함께 기록하십시오.

Inference 장부에는 weight, KV cache와 runtime workspace가 들어갑니다. LoRA·QLoRA는 activation, trainable parameter, gradient, optimizer와 batch가 추가되고 full fine-tuning은 범위가 훨씬 큽니다. 예를 들어 공식 “fine-tune up to N B” 문구가 있다면 method, precision, sequence·batch, adapter rank와 checkpoint 조건을 확인합니다. 한 번 step이 실행된 것과 목표 dataset이 시간·quality gate 안에 완료된 것은 다릅니다.

Storage에는 base·quant·adapter, optimizer checkpoint, dataset와 evaluation output이 쌓입니다. Internal SSD 용량과 sustained write, free space·encryption을 확인하고 download·load와 checkpoint 시간을 측정합니다. System disk와 유일한 artifact가 같은 box에 있으면 장애 시 모두 잃을 수 있습니다. External 또는 network backup에서 exact model·config와 secret 제외 data를 실제 restore해 hash와 완료 시간을 확인합니다.

Service는 authentication, rate limit, queue·admission, log privacy와 monitoring이 필요합니다. Restart 뒤 model warm-up, concurrent context의 memory fragmentation, p95·p99와 error rate를 측정합니다. Compact box 한 대는 network·power와 hardware single point of failure이므로 목표 availability에 따라 spare, cloud fallback 또는 작은 emergency model을 둡니다. 개인 desktop success를 production readiness로 표시하지 않습니다.

각 목적은 정상·경계·실패 workload를 최소 3회 실행하고 품질, load·job·p95 시간, memory·storage peak, power·temperature와 오류를 남깁니다. Training OOM, disk full, network loss와 service restart를 의도적으로 복구합니다. 이전 장비·cloud로 같은 job 또는 request가 회복돼야 변경을 승인하며, 통과하지 않은 목적은 별도로 hold로 남깁니다.

왜 이런가

Inference, training과 service는 weight 이외의 activation·optimizer·checkpoint·queue·availability 자원이 서로 다르기 때문입니다.

언제 문제가 되는가

Model load만 시험하면 training 중 OOM·disk full 또는 동시 service p95·restart 장애를 실제 사용 때 처음 만나게 됩니다.

초보자가 자주 하는 오해

큰 model inference가 되면 같은 크기 full fine-tuning과 다중 사용자 24시간 service도 자동으로 가능한 것은 아닙니다.

직접 확인하는 방법

목적별 exact recipe와 정상·경계·실패 workload에서 memory·storage·시간·품질·복구를 분리해 실행하십시오.

비교표 행은 DGX Spark 일반, AMD APU 일반, Mac 일반이 아니라 exact model·memory·storage configuration과 OS·firmware·runtime·artifact 조합입니다. 열에는 공식 memory·bandwidth·power source, 사용 가능 memory·effective bandwidth, architecture·dependency, 품질·p95·job 시간·30분 유지율과 recovery를 둡니다. 공식 peak와 로컬 측정을 다른 열로 분리하고 미확인은 추정치로 채우지 않습니다.

가격은 지역·세금·재고·warranty와 날짜가 붙는 견적입니다. System price 외에 storage·network, monitor·UPS, backup·spare, 전력과 software porting·maintenance 시간을 포함합니다. 값이 자주 바뀌므로 본문에 영구 가격 순위를 고정하지 않습니다. 필수 gate를 모두 통과한 후보끼리 workload당 cost와 2~3년 시나리오를 비교합니다.

결함과 실패 결과도 증빙입니다. 특정 model이 load되지만 decode 3 token/s, ARM dependency 미지원, ROCm matrix 공백, CUDA-only 기능 부재 같은 조건을 기록합니다. 더 작은 model·다른 runtime으로 복구했다면 품질과 운영 feature를 다시 평가합니다. 결과를 본 뒤 합격선을 낮추거나 실패 screenshot·log를 지우지 않습니다.

승인 전 이전 장비·cloud에서 같은 failure input 또는 training job을 복원합니다. System image, model·adapter hash, config·build recipe, backup restore와 담당자를 runbook에 둡니다. OS·driver·runtime, model revision, context·concurrency나 업무 rubric이 바뀌면 공식 문서와 회귀를 다시 실행합니다. 결론은 “어느 브랜드가 최고”가 아니라 exact workload와 날짜에 묶인 통과·hold 기록이어야 합니다.

왜 이런가

제품·software·가격과 업무가 변하므로 exact 구성과 실패·복구 증거가 없으면 추천을 재현하거나 업데이트할 수 없기 때문입니다.

언제 문제가 되는가

최고값과 성공 결과만 남기면 dependency·지속 부하·장애 회귀를 숨기고 update 뒤 원인과 복구 경로를 잃습니다.

초보자가 자주 하는 오해

한 번 만든 브랜드 순위나 price/performance 점수가 모든 목적·지역·version에 영구 적용되는 것은 아닙니다.

직접 확인하는 방법

다른 담당자가 공식 source·manifest·command·failure input과 rollback artifact만으로 같은 통과·hold를 재현하는지 독립 검토하십시오.