파트 1에서는 하드웨어, 실행 주체, 그리고 주요 모델을 설정했습니다. 이번 글에서는 해당 하드웨어에서 추론 (Inference)을 제어하는 요소들 — 추론의 두 단계, 긴 컨텍스트 (Long context)의 비용, 그리고 디스크에서 모델을 로드하는 비용 — 을 다루며, 로컬 머신들을 무료 티어 클라우드 모델과 비교합니다.

추론의 두 단계

추론 (Inference)에는 두 가지 단계가 있습니다. _Prefill_은 출력이 나타나기 전에 입력 프롬프트를 처리하며, 연산 제한적 (Compute-bound)이어서 GPU를 필요로 합니다. _Generation_은 출력 토큰을 하나씩 생성하며 메모리 대역폭 (Memory bandwidth)에 의해 제한됩니다. 일반적인 사용은 거의 대부분이 생성 (Generation) 단계이므로 그 차이가 숨겨지지만, 프롬프트가 커지면 Prefill의 비용이 드러나게 됩니다.

머신 및 측정 방법

두 가지 특징이 눈에 띕니다. Prefill은 머신 간에 약 18배 차이(360에서 20 tok/s)가 나는 반면, 생성 (Generation)은 2배 미만(18.3에서 10.0)의 차이를 보입니다. Prefill은 대규모 프롬프트 작업 부하를 지배하는 요소이므로, 어떤 머신은 생성 단계에서는 괜찮아 보일지라도 실제 사용 시에는 무용지물일 수 있습니다. 별도로, 모델 로드 시간은 연산보다는 스토리지에 의해 결정됩니다. 보조 머신의 저가형 SATA SSD는 18 GB 모델을 로드하는 데 50초가 걸리는 반면, NVMe는 8초가 걸리며, 이는 콜드 요청 (Cold request)을 1분간의 정체 상태로 만들어 버립니다.

만약 호출 사이에 모델의 언로드 (unload)가 허용된다면, 모든 호출은 조용히 그 재로드 (reload) 비용을 지불하게 되며, 이는 간헐적인 타임아웃 (timeout)의 실제 원인이 됩니다. 해결책은 사전 예열 (pre-warming)과 함께 긴 유지 시간 (OLLAMA_KEEP_ALIVE=24h)을 설정하는 것입니다. 느린 디스크를 사용하는 노드에서는 이것은 개선 사항이 아니라 필수 전제 조건입니다.

대화는 할 수 있지만 서비스는 할 수 없는 "AI PC"

노트북은 특별한 주의를 기울여 살펴볼 가치가 있습니다. 왜냐하면 "AI PC"로 판매되고 있기 때문이며, 바로 그 프레임워크를 지키지 못하는 것이 핵심이기 때문입니다. 8840U (AMD의 8040 "Hawk Point" 시리즈)는 최대 16 TOPS로 정격화된 전용 XDNA NPU를 탑재하고 있으며 (플랫폼 전체적으로는 약 38 TOPS), 바로 이러한 종류의 로컬 추론 (local inference)을 위해 "Ryzen AI"라는 이름으로 마케팅됩니다. 하지만 NPU는 웹캠 배경 효과나 노이즈 억제와 같은 저전력, 상시 작동 (always-on) 작업용으로 설계되었으며, LLM 러너 (runner)는 이를 전혀 활용하지 않습니다. 따라서 대형 모델 추론은 CPU의 몫이 되며, CPU는 약 20 tok/s의 속도로 프리필 (prefill)을 수행합니다 (위의 표 참조). 결과적으로 1만에서 1만 5천 토큰에 달하는 시스템 프롬프트 (system prompt)를 처리하는 데 단 하나의 토큰이 생성되기 전까지 8분에서 12분이 소요되며, 이는 실제 관찰된 13분의 지연 현상으로 나타납니다.

이 교훈은 마케팅의 허점을 두 번이나 찌릅니다. "AI PC"는 대규모 프롬프트에 대해 수십억 개의 파라미터를 가진 모델을 실행하는 것을 제외한, 가속화된 워크로드 (workload)의 좁은 범주를 의미합니다. 광고된 TOPS는 이 목적을 위해서는 무용지물이며, 결과를 결정지은 수치는 매력적이지 않은 CPU 프리필 (prefill) 속도였습니다. 또한 동일한 NPU는 Microsoft가 AI-PC 라벨에 부착한 40-TOPS 임계값 미만입니다.

컨텍스트 (Context)의 비용

긴 컨텍스트 (Long context)는 메모리 비용을 수반하는데, 이는 KV 캐시 (KV cache)가 컨텍스트 길이에 따라 선형적으로 증가하기 때문입니다. 러너는 기본적으로 4K–8K 윈도우 (window)를 사용합니다. 이는 커스텀 Modelfile (num_ctx 65536)을 통해 64K로 상향되었습니다.

64K 컨텍스트 윈도우(window)가 안정적인 동작 지점으로 유지되었습니다. (num_gpu 99를 사용하여 모든 레이어를 16GB 카드에 강제로 할당하는 것은 완전히 실패하므로, 대신 러너(runner)의 자동 GPU/CPU 분할 기능에 의존하십시오.)

클라우드 모델과의 비교

로컬 머신은 호스팅된 모델과 비교했을 때 어떠할까요? 동일한 약 150단어의 추론 프롬프트(reasoning prompt)를 사용하여, 무료 티어 클라우드 모델(Gemini 3 Flash)을 두 대의 로컬 GPU와 비교하여 엔드 투 엔드(end-to-end) 시간을 측정했습니다.

이것은 순수한 연산(compute) 비교는 아닙니다. 클라우드 수치에는 네트워크 왕복 시간(round-trip)과 Google의 서빙 인프라가 포함되어 있으며, API는 프리필(prefill)/생성(generation) 분할을 노출하지 않습니다. 하지만 이는 실제 사용 시 중요한 요소인 '답변이 얼마나 빨리 도착하는가'를 측정합니다. 클라우드 모델은 205개의 토큰 답변을 내놓기 전 약 536개의 내부 추론 토큰을 소모하며 더 많은 작업을 수행하면서도 여유롭게 승리했습니다. 여기서 얻을 수 있는 교훈은 클라우드가 로컬을 이긴다는 것이 아니라, 배치(placement)가 작업의 성격에 따라야 한다는 것입니다. 일상적이고 대량인 작업은 프라이버시가 보장되고, 사용량 제한이 없으며, 지연 시간이 예측 가능한 로컬에 적합합니다.

향후 계획

프리필(prefill)에는 GPU가 필요하고, 컨텍스트(context) 비용은 메모리에 선형적으로 비례하며, 콜드 모델(cold model)은 상주 모델(resident model)보다 훨씬 더 비싸고, 배치는 작업의 성격을 따라야 한다는 이러한 발견들은 한 번에 하나 이상의 모델을 메모리에 유지해야 할 때 더욱 복합적으로 작용합니다. 여러 모델이 충돌 없이 공존할 수 있는지 여부는 다음 글의 주제입니다.