24 GB Mac에서 쓴 Unsloth: 완성도 높은 앱이지만, 첫 이미지가 나오기 전에 메모리가 부족했습니다

설치 파일은 24 MB의 DMG이며, 테스터는 이를 '내가 본 가장 작은 파일'이라고 읽었습니다.

첫 창: 'Getting things ready... This won't take long.'과 'Show setup details' 링크. 테스터: '다른 앱들보다 훨씬 세련돼 보이네요... 명확한 안내입니다.'

상세 로그에는 'Updating existing Unsloth install', 'frontend bundled (Tauri)', 'node v24.13.0 | npm 11.6.2 (system)', 'unsloth 2026.8.18 -> 2026.10.3 available, updating'이 나오고, 이어서 13단계 의존성 진행 막대(pip bootstrap, Apple Silicon용 MLX stack, base packages, unsloth extras, codecs, overrides, studio deps, data designer, local plugin, diffusers pin, finalizing)가 표시됩니다. 참고: 'torch 2.10.0 detected -- installing torchao==0.16.0', 'transformers 5.3.0, 5.5.0, 5.10.2 pre-installed', 'gpu Apple Silicon (Metal, unified memory)', 'installing prebuilt llama.cpp'.

테스터는 약 4~5분 동안 진행된 뒤 앱이 열렸다고 말합니다. 로그에는 소요 시간 안내도 디스크 용량 안내도 없습니다.

설정에 4~5분 걸렸다는 추정입니다. 시간을 재지는 않았습니다.

용량이 작은 DMG는 이 첫 단계에서 소프트웨어 대부분을 내려받는 것으로 보입니다. 확인하지 않았습니다.

'무엇을 하는지 자세히 알려 주는 건 좋은데, 예상 시간이나 용량, 디스크를 얼마나 차지하는지는 전혀 알려 주지 않는다.'

메인 창은 'How can I help?'와 사이드바(New chat, Model hub, Library, Images, Train, More)와 함께 열립니다. 로고에 BETA 표시가 붙어 있습니다.

기존 설치에서 시작했으므로('이전과 같다') 처음 실행하는 테스트가 아니라 업데이트입니다. 온보딩에 대한 결론은 새로 설치해서 확인해야 합니다.

모델 선택기는 Recommended 모델을 27.3B, 271.0M 같은 수치와 함께 나열합니다. 이는 기가바이트가 아니라 파라미터 수입니다. 두 항목(176.9B, 320.8B)은 회색으로 비활성화되어 있습니다.

회색 항목은 이 기기에는 너무 큰 모델인 것으로 보입니다. 캡처한 앱 화면에는 그런 설명이 없습니다.

'크기와 함께 모델이 많이 나열되어 있었다. 아주 좋다.' 표시된 수치는 파라미터 수이므로, 모델에 메모리가 얼마나 필요한지는 알려 주지 않습니다.

모델을 고르는 대신 테스터는 계산을 요청하는 문장을 입력했습니다. 앱이 스스로 모델을 불러오기 시작했습니다. 메모에 따르면 Qwen3.8-27B MLX 4-bit 모델이 1분도 안 되어 시작되었고, 두 번째 토스트에는 Mistral-7B-Instruct-v0.3-4bit 로딩이 표시되었습니다(스크린샷은 제외, 그림 5와 같은 유형).

로딩 토스트에는 /Users/hanskuepper/.lmstudio/models/lmstudio-community/Qwen3.8-27B-MLX-4bit 경로가 나옵니다. 모델은 디스크의 LM Studio 폴더에서 읽혔습니다.

그는 하드 드라이브에서 가져온 것 같다고 의심했는데, '그렇게 큰 모델이 1분 만에 인터넷으로 오지는 않기' 때문입니다. 경로가 이를 뒷받침합니다. Unsloth가 왜 이 모델과 Mistral 모델을 골랐는지는 기록되지 않았습니다.

'what is 5 times 866'이라는 질문에 '5 x 866 = 4,330'(정답)이라고 'Worked for 10s' 뒤에 11.0 tok/s로 답했습니다. 헤더에는 'Local'과 컨텍스트 미터 '120 / 262.1k'가 표시됩니다.

이어서 테스터는 모델에게 그 모델을 어디서 가져왔는지 물었습니다. 캡처된 답변 일부는 MLX 가중치와 Apple Silicon 통합 메모리를 다루며, 전체 답변은 캡처되지 않았습니다. 메모에 따르면 답은 앱이 드라이브를 검색하지 않는다는 내용이었습니다.

채팅 모델이 말하는 앱 설명은 믿을 만한 증거가 아닙니다. 한 답변은 모델을 'Qwen 3 27B MLX 4-bit'라고 부르지만, 앱에서는 Qwen3.8-27B-MLX-4bit로 표시됩니다.

On Device 탭은 모델을 출처별로 나열합니다. CUSTOM FOLDERS 아래에 경로 두 개(.lmstudio/models와 .ollama/models)가 있고 Ollama 모델 gemma4:latest, gemma3:1b, qwen3-coder:30b가 보입니다. LM STUDIO 아래에서는 Qwen3.8-27B 모델에 'Loaded' 표시가 있습니다.

테스터가 두 폴더를 추가했는지, 앱이 스스로 찾았는지는 기록되지 않았습니다. 이전에 앱을 쓰면서 설정되어 있었을 수 있습니다.

qwen3-coder:30b(30.5B, Q4_K_M, GGUF)로 전환하면 'Starting model... Switching models. Loading cached model into memory.'와 Cancel 버튼이 나타납니다. 컨텍스트 미터는 '1.3k / 8.2k'로, 첫 모델의 262.1k보다 훨씬 작습니다.

'모델을 바꾸기 쉬워서 좋다.' '일부 Ollama 모델은 Unsloth 안에서 동작하지 않지만, 시도해 준 것만으로도 훌륭하다.'

메모에 따르면 이전 모델은 동작했고 더 새로운 모델은 비정상 종료되었습니다. 어떤 모델을 말하는지는 기록되지 않았습니다.

그는 자신의 Ollama 모델을 쓰려고 '시도해 준' 것이 훌륭하고, 디스크에 있는 모델을 읽으면 또 큰 다운로드를 피할 수 있다고 말합니다.

허브는 기기 정보('0 GiB VRAM + 24 GiB shared', '24 GiB RAM', '12/12 CPU')와 필터(형식, 기능, 최신순)를 보여 줍니다. 카드에는 좋아요, 다운로드 수, 경과 기간, 라이선스가 표시됩니다(embeddinggemma-2-GGUF: apache-2.0, 1.5 GB).

'네, 훌륭한 모델 허브입니다.' 허브에는 Qwen-Image-2.1-GGUF(다운로드 850.0K, 16일 전), GLM-5.3-GGUF, Qwen3.8-Flash-Next-GGUF 등이 나옵니다.

메모에 따르면 Mac에 너무 큰 파일을 클릭하자 여러 경고('이 파일은 총 30~40 기가바이트입니다')가 나왔지만 다운로드는 여전히 허용됩니다. 스크린샷은 없습니다.

unsloth/Qwen3.8-27B-GGUF UD-Q5_K_S의 다운로드 패널에는 20 GB 중 1.2 GB, 1.4 MB/s, 3 h 47 m 남음이 표시되고, 나중에는 20 GB 중 7.1 GB, 983 KB/s, 3 h 31 m 남음이 표시됩니다.

'이 앱의 전문성이 눈에 보입니다. 타이머가 붙어 있고, 다운로드 속도도 알려 줍니다.'

속도로 보아 테스트 장소의 회선이 느린 것 같지만, 테스터는 그렇게 말하지 않았습니다. 다운로드가 끝났는지는 기록되지 않았습니다.

Z-Image(BF16) 대화 상자에는 모델 파일 12.3 GB와 필수 인코더·디코더 8.2 GB, 합계 20.5 GB가 나옵니다. 테스터가 다른 곳에서 언급한 '모델의 기가바이트와 그 밖의 무언가 사이의 차이'가 이것으로 설명됩니다.

메모에는 '이미지 LLM을 내려받았다'고 적혀 있습니다. 어느 것인지는 기록되지 않았으며, 스크린샷에는 기기에 있는 이미지 모델 FLUX.2-klein-4B와 그 GGUF 변형이 보입니다(그림 18).

테스터는 PromptQuorum 페이지 URL을 붙여 넣고 'from a seo perspective will this help me?'라고 물었습니다. 채팅에는 'Using tool: Reading promptquorum.com'과 'Waiting for approval: web_search', 그리고 Allow, Always allow, Deny 버튼이 표시됩니다. 시각 오후 5:13, 컨텍스트 '648 / 34.4k'.

메모에 따르면 첫 시도에서는 페이지를 읽을 수 없다고 했고, Search 기능을 클릭하자 두 번째에는 동작했습니다. '첫 번째에 경고가 있었어야 할지도 모른다.'

첫 실패는 웹 검색 승인이 없었거나 Search 토글이 꺼져 있었기 때문일 수 있습니다. 확인하지 않았습니다.

실행은 168.10 s 뒤 'Ran out of memory. Try a smaller model or shorter input.'로 끝났고, Retry 버튼이 표시되었습니다.

음성 입력이 내장되어 있습니다. 사용하려면 'Qwen3-ASR 0.6B' 음성 모델(약 1.0 GB)을 내려받아야 하며, Hugging Face 캐시에 한 번만 받는다고 안내합니다. 테스터가 내려받았는지는 기록되지 않았습니다.

지역 행사 검색('What is happening tonight in Heidelberg, Germany?')은 도구 호출을 두 차례 실행한 뒤 110.65 s 후 'Ran out of memory'로 끝났습니다. 헤더에는 빨간 안내 'Failed to load model: No safetensors found in /Users/.../.cache/huggin...'가 표시됩니다.

로드 오류와 메모리 부족 메시지는 서로 관련이 있을 수 있습니다(메모리가 부족한 상태에서 모델이 교체되는 경우). 스크린샷에는 그 연관성이 나타나지 않습니다.

'하지만 그렇죠, 로컬 AI는 늘 문제가 좀 있어요.'

테스터의 목표는 이미지였습니다. 사이드바에는 'Images' 항목이 있습니다. 메모에는 구도와 제외 목록이 딸린 긴 뉴욕 스카이라인 프롬프트(브루클린 전망, 브루클린 브리지, 골든 아워, 8K 디테일)가 있습니다. 그 결과나 오류, 설정은 기록되지 않았습니다.

이미지 모델 flux.2-klein 로드가 거부되었습니다. 'needs about 17 GB of memory for its weights, but only about 2 GB is usable on this device (of the 7 GB currently free, after reserving room for the operating system)'. 또한 Mac은 메모리 풀이 하나뿐이라 CPU로 오프로드해도 확보되는 것이 없다고 설명하고, 더 작은 모델, 더 낮은 양자화, 다른 앱 종료를 권합니다. 우회 방법으로 UNSLOTH_DIFFUSION_ALLOW_OVERSIZED_LOAD=1을 알려 줍니다.

깨끗하게 재부팅한 뒤의 메시지는 약 17 GB 필요, 사용 가능 약 6 GB, 현재 여유 11 GB입니다.

두 메시지는 두 쌍 모두 5 GB 차이가 나므로(7 - 2, 11 - 6) 앱은 운영체제용으로 약 5 GB를 남겨 두는 것으로 보입니다. 데이터는 두 건뿐입니다.

기기 목록에는 FLUX.2-klein-4B-GGUF(7.8 GB), FLUX.2-klein-4B(16 GB), mistral-7b-v0.3-bnb-4bit(4.1 GB)가 보입니다. 테스터: 'This should be small enough.' 테스터는 허브에서 가장 작은 이미지 모델도 24 GB 기기를 비정상 종료시킨다고 하며, 클릭한 모델마다 '7 기가바이트'만 쓸 수 있어 너무 크다고 나왔다고 말합니다.

테스터는 왜 7 기가바이트만 쓸 수 있는지 의아해합니다('훨씬 더 많이 있는데'). 대화 상자에는 그 순간 7 GB가 비어 있었고 다른 앱이 실행 중이었다고 나오며, 재부팅 후에는 11 GB로 나옵니다. 메모는 '7 GB' 발언을 Z-Image 대화 상자 옆에 두었지만, 7 GB라는 수치는 flux.2-klein 메시지에 있습니다.

'길을 잃었어요... 24 기가바이트 기기가 있는데, 저를 도와 일을 해 줄 수 있는 LLM을 찾을 수가 없어요.' 그는 24 GB가 독자의 80퍼센트 넘게 가진 사양이라고 생각합니다(그의 추정이며 측정값이 아닙니다).

'독자의 80% 넘게'가 24 GB 이하를 쓴다고 합니다. 출처는 제시되지 않았습니다.

테스터는 로컬 모델과 일상 작업이 같은 메모리를 놓고 경쟁하며, Chrome과 다른 앱이 5~8 GB를 차지한다고 결론짓습니다. 그는 내내 'VRAM'이라고 썼지만, 허브가 보여 주듯('0 GiB VRAM + 24 GiB shared') Apple Silicon은 메모리 풀이 하나입니다.

Activity Monitor 캡처 한 장: 사용한 메모리 12.92 GB, 캐시된 파일 10.95 GB, 앱 메모리 9.81 GB, 와이어드 1.83 GB, 스왑 0.

Activity Monitor의 다른 캡처: 사용한 메모리 9.67 GB, 캐시된 파일 8.14 GB, 앱 메모리 6.97 GB, 와이어드 1.71 GB, 스왑 0. 짧은 이력 그래프는 최근에 시작했다는 것과 맞습니다.

그림 15의 '현재 여유' 11 GB는 그림 16의 24.00 - 12.92 = 11.08 GB와 일치합니다. 두 캡처가 같은 시점에 찍혔는지는 기록되지 않았습니다.

'재부팅한 뒤에도 일반적인 용도로 이미 9 기가바이트가 사라졌어요.' '컴퓨터를 끄고, 재부팅하고, 모든 프로세스를 멈추거나... 아니면 LLM을 돌릴 수 없는 거죠.'

가능한 답은 두 가지입니다. 모델이 더 작고 좋아지거나, 컴퓨터에 48 또는 64 GB가 필요하다는 것입니다. '당신의 컴퓨터에서 된다는 이런 이야기는 전부 좀 가짜예요.'

48 또는 64 GB면 '확실히' 해결된다는 것은 테스트하지 않았습니다.

모델을 시작하면 'Starting model... Loading cached model into memory.' 토스트가 스피너와 Cancel 버튼과 함께 나타납니다. 퍼센트, 크기, 시간 표시는 없습니다.

대기 시간은 2~3분을 넘었습니다(시간을 재지는 않았습니다).

'고객을 대하는 가장 나쁜 방식은 일을 해 놓고 고객에게 알려 주지 않는 것입니다.' 테스터는 이것을 사용자 인터페이스 문제라고 부릅니다.

헤더의 미터는 컨텍스트 대비 사용한 토큰 수(예: '648 / 34.4k')와 초당 토큰 수(11.0 tok/s)를 보여 줍니다.

메모에는 '토큰 카운터 없음'이라고 적혀 있습니다. 스크린샷에는 컨텍스트 미터와 초당 토큰 수가 보입니다. 그가 말한 것은 메시지별 토큰 수일 수 있습니다(가정).

메모는 로컬 채팅 모델을 '인터넷을 조사하지 못하기' 때문에 '가장 멍청한 아이디어'라고 부릅니다. 같은 메모와 스크린샷에는 Search 기능, 웹 검색 승인 안내, 페이지를 읽는 도구 호출이 나옵니다.

그는 모델을 학습시키고 싶지 않고, 채팅 기능은 별로 쓸모가 없으며, 이미지와 영상 도구를 원하는데 '아직 보이지 않는다'고 말합니다. 학습과 'Train' 탭은 시도하지 않았습니다.

'어쩌면 제 쪽 문제일 수도 있지만, 아니요, 저에게는 아닙니다. 3개월이나 6개월 뒤에 다시 확인해 보겠지만, 지금은 M3 24 GB Pro MacBook에서는 아닙니다.'