16GB Apple 실리콘 데스크톱에서 로컬 판단 모델을 제공하는 MLX 서비스가 있다. 기존 0.8B 모델을 4B 후보로 바꾸고 같은 30개 평가 문항을 풀게 할 계획이었다. 그러나 정확도를 비교하기 전에 서비스가 준비되는지부터 답해야 했다.
교체 직전 스왑 사용량은 2,528.75MiB였다. 4B 모델을 불러오는 동안 11,316.38MiB를 거쳐 12,808.94MiB까지 늘었다. 마지막 관측 시점은 시작 후 2분 13초였고, 모델 프로세스의 RSS는 1,913,056KiB, CPU 사용률은 27.1%였다. API 리스너는 여전히 열리지 않았다.
이 수치로 모델의 추론 성능을 평가할 수는 없다. 설치된 MLX 로더는 기본 모델을 불러온 뒤 LoRA를 fp32로 병합하고, 코드도 이 단계의 일시적인 메모리 부담을 설명한다. 다만 단계별 계측은 하지 않았으므로 스왑 증가분 전체를 fp32 병합 하나의 탓으로 돌릴 근거는 없다. 메모리 부족으로 종료된 것도 아니며, 4B 모델이 모든 16GB 환경에서 실행 불가능하다는 결과도 아니다.
판단 범위는 더 좁다. 공유 중인 16GB 기기에서 현재 BF16 로딩과 fp32 병합 경로를 그대로 쓴 4B 서비스는 스왑을 계속 늘리면서 준비 상태에 도달하지 못했다. 그래서 시험을 중단했고 30개 문항은 한 개도 실행하지 않았다. 정확도와 응답 속도 비교가 아니라, 이 로딩 경로를 승격하지 않기로 한 용량 판단만 남았다.
원래 설정 파일을 바이트 단위로 복원한 뒤 4B 프로세스가 사라졌고, 기존 0.8B 모델은 다시 요청에 답했다. 확인된 모델 처리 시간은 105.1ms였다. 복원 직후에도 스왑은 6,200.88MiB였고 메모리 여유 지표는 66%였다. 서비스 복구가 곧 메모리 압력 해소를 뜻하지는 않는다. 다음 비교는 검증된 저메모리 로딩이나 양자화 경로를 먼저 마련하거나, 가용 메모리가 더 많은 환경에서 시작해야 한다.