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 병합 때문이라고 단정할 수는 없다. 메모리 부족으로 종료된 것도 아니고 모든 16GB 환경에서 4B 모델을 실행할 수 없다는 증거도 아니다.
확인한 범위는 공유 중인 16GB 기기의 현재 BF16 로딩과 fp32 병합 경로다. 이 경로로 띄운 4B 서비스는 스왑을 계속 늘리면서도 준비 상태에 도달하지 못했다. 시험을 중단했으므로 30개 문항은 한 개도 실행하지 않았다. 정확도나 응답 속도를 비교한 것이 아니라 이 로딩 경로를 승격하지 않기로 한 용량 판단이었다.
원래 설정 파일을 바이트 단위로 복원하자 4B 프로세스가 사라졌고 기존 0.8B 모델은 다시 요청에 답했다. 확인된 모델 처리 시간은 105.1ms였다. 다만 복원 직후 스왑은 여전히 6,200.88MiB였고 메모리 여유 지표는 66%였다. 서비스가 복구돼도 메모리 압력이 바로 해소되는 것은 아니었다. 다음 비교를 시작하려면 검증된 저메모리 로딩이나 양자화 경로를 먼저 마련하거나 가용 메모리가 더 많은 환경을 써야 한다.