맥 스튜디오 M5 Ultra, SSD가 빨라지면 로컬 AI도 빨라질까?

대화 앱에서 모델을 선택했다고 곧바로 답변이 나오는 것은 아닙니다. 먼저 저장 장치에 있는 모델 파일을 사용할 준비를 해야 하고, 그다음 질문과 첨부 문서를 읽고, 마지막으로 답변을 한 토큰²씩 만듭니다. 화면에서는 모두 기다리는 시간으로 보이지만 컴퓨터가 하는 일은 다릅니다.

SSD 성능 향상이 가장 직접적으로 도움이 되는 곳은 첫 번째입니다. 코딩 모델을 열었다가 이미지 모델로 바꾸고, 다시 대화 모델로 돌아오는 사람이라면 이 구간을 하루에도 여러 번 거칩니다. 반대로 같은 모델 하나를 계속 켜 두고 쓰는 사람은 처음 한 번의 대기가 줄어도 그 뒤 대화에서는 차이를 작게 느낄 수 있습니다.

Tom’s Guide의 M5 Ultra 리뷰에서는 4TB SSD 구성의 Blackmagic 읽기 13,902MB/s, 쓰기 14,283MB/s를 기록했습니다. 다만 이것은 해당 리뷰 장비의 디스크 측정값입니다. 모든 SSD 용량에서 같은 수치가 나온다는 뜻도, LLM³의 답변 속도가 그 비율로 오른다는 뜻도 아닙니다.

예를 들어 70GB를 읽는다고 가정해 봅시다. 데이터를 일정하게 초당 7GB 읽으면 전송에 10초, 초당 14GB 읽으면 5초가 걸립니다. 이 계산은 디스크에서 옮기는 시간만 떼어 낸 설명용 예시입니다. 실제 모델 로딩에는 파일 처리, 메모리 할당, 실행 준비가 더해지므로 앱의 대기 시간이 그대로 절반이 되지는 않습니다.

두 번째로 모델을 열었더니 빨라졌다면 SSD 덕분인지도 나눠 봐야 합니다. 운영체제가 직전에 읽은 파일을 메모리에 보관하는 파일 캐시가 작동했을 수 있기 때문입니다. 같은 프롬프트의 계산을 재사용하는 프롬프트 캐시와는 별개입니다. ‘첫 실행’이라는 표현 하나로 이 둘을 묶으면 SSD와 LLM 양쪽의 성능을 잘못 해석하기 쉽습니다.

모델이 통합 메모리⁴에 올라가 있고 스왑이나 오프로드 없이 실행된다면, 답변을 만드는 동안 주로 오가는 곳은 SSD가 아니라 메모리와 연산 장치입니다. 빠른 창고에서 책을 꺼냈더라도 책상 위에 펼친 뒤 읽는 속도까지 창고가 결정하지는 않는 것과 비슷합니다. SSD 읽기 속도만 보고 초당 토큰 수를 계산할 수 없는 이유입니다.

질문을 보낸 뒤 한참 조용하다가 답변은 빠르게 쏟아진다면, 입력이 긴지부터 보세요. 문서와 대화 기록을 읽는 프리필⁵이 오래 걸리는 상황일 수 있습니다. 반대로 첫 답은 금방 나오는데 문장이 천천히 이어진다면 모델 크기, 양자화⁶, 실행 엔진과 디코드⁷ 가속 설정을 살펴볼 차례입니다. 두 상황에 같은 SSD 업그레이드를 권할 수는 없습니다.

이 사이트의 속도 체감 화면도 프리필과 디코드를 나눠 보여 줍니다. 여기서 나오는 대기 시간을 SSD에서 모델 파일을 처음 불러오는 시간으로 읽으면 안 됩니다. 모델을 실행할 준비가 된 다음, 내 입력 길이에서 답변이 어떻게 나오는지 비교하는 용도로 쓰면 됩니다.

메모리에 모델이 전부 들어가는 상황만 있는 것은 아닙니다. 지원되는 모델과 엔진에서는 큰 조회 테이블을 SSD에 남겨 두고, 그때 필요한 항목만 읽어 오는 PLE⁸ 오프로드를 사용할 수 있습니다. 책을 통째로 매번 옮기기보다 색인에서 필요한 카드만 꺼내 보는 방식에 가깝습니다. 이때는 답변 중에도 저장 장치를 읽으므로 SSD 성능이 다시 중요해집니다.

실제 사례로 MacStories는 M5 Ultra 256GB·80코어 GPU⁹에서 Qwen3.8-Flash-Next oQ8e의 PLE 테이블을 SSD에 두고 실행했습니다. oMLX 0.7.0.dev2, MTP¹⁰ 깊이 3 조건에서 문장 생성 중앙값은 86.8 tok/s, 답변 중 측정된 프로세스 메모리는 약 187GB였습니다. 메모리는 가중치만의 크기가 아닙니다.

이 기록은 실행 가능한 구성을 보여 주지만 SSD만 바꾼 비교 실험은 아닙니다.

여기서 MTP와 PLE 오프로드는 역할이 다릅니다. MTP는 다음 토큰 후보를 미리 제안해 생성 반복을 줄이는 쪽이고, PLE 오프로드는 일부 데이터의 저장 위치를 바꾸는 쪽입니다. 엔진이 그 조합을 지원하면 함께 쓸 수 있습니다. 다만 모든 모델에 같은 옵션을 켜거나, 일반적인 n-gram¹¹ 추측 디코딩¹²과 같은 기능으로 생각하면 안 됩니다.

또한 큰 파일을 순서대로 읽는 속도와 여기저기 흩어진 작은 항목을 읽는 속도는 다릅니다. 한 번 읽은 항목이 파일 캐시에 남는 정도도 영향을 줍니다. 그래서 SSD 벤치마크가 두 배라고 오프로드 디코드도 두 배로 잡는 계산은 하지 않습니다.

특정 모델 하나라면 선택지가 될 수 있습니다. 하지만 이를 모든 모델에 적용되는 공식으로 삼기는 어렵습니다. 선택적 오프로드를 지원하지 않는 모델도 있고, 긴 문맥의 KV 캐시¹³나 동시에 켠 다른 모델은 또 메모리를 차지합니다. 256GB라는 숫자와 모델 파일 크기만 비교해서 ‘들어간다’고 끝낼 문제가 아닙니다.

운영체제가 부족한 메모리를 SSD로 밀어내는 스왑도 따로 봐야 합니다. 어떤 데이터를 옮길지 엔진이 정한 PLE 오프로드와 달리, 메모리 압박 때문에 필요한 데이터를 계속 내보내고 다시 읽으면 대화가 끊기거나 대기가 길어질 수 있습니다. 빠른 SSD가 손해를 줄여 줄 수는 있어도, 메모리가 넉넉한 상태와 같아지는 것은 아닙니다.

반대로 모델과 문맥이 이미 충분히 들어간다면 512GB로 올린다고 답변이 자동으로 두 배 빨라지지도 않습니다. 큰 메모리의 가치는 더 큰 모델, 긴 문맥, 여러 모델을 함께 쓰는 여유에 있습니다. 256GB와 512GB 사이에서 고민한다면 ‘언젠가 쓸지도 모르는 가장 큰 모델’보다 매일 켜 둘 모델과 다른 앱을 먼저 적어 보는 편이 낫습니다.

매일 쓰려는 모델이 빠듯하다면 메모리 쪽이 우선입니다. 모델이 안정적으로 실행되지 않는데 로딩만 빨라져도 해결되는 것은 적습니다. 메모리, KV 캐시, 다른 앱이 사용할 공간을 먼저 확보한 뒤, 자주 쓰는 모델 파일과 작업 자료가 들어갈 SSD 용량을 정하는 순서가 무난합니다.

이미 메모리가 충분하고 여러 대형 모델을 번갈아 쓴다면 이야기가 달라집니다. 모델을 갈아 끼울 때마다 기다리는 사람이므로 빠른 저장 장치의 이점을 자주 받습니다. 이미지 생성까지 병행해 체크포인트¹⁴를 자주 바꾸거나, 모델을 내렸다 올리는 작업이 많은 경우도 여기에 가깝습니다. 그렇더라도 용량이 더 큰 SSD가 반드시 더 빠르다는 가정은 빼고, 구매할 용량의 측정 결과를 확인해야 합니다.

가끔 시험할 모델을 많이 보관하려는 목적이라면 외장 SSD도 방법입니다. 자주 쓰는 파일은 내부에, 당장 켜지 않을 모델은 외부에 두면 됩니다. 다만 외장 SSD는 드라이브뿐 아니라 케이스, 연결 규격, 케이블과 발열의 영향을 함께 받습니다. Thunderbolt 5라는 이름만으로 내장 SSD와 같은 속도라고 계산해서는 안 됩니다.

평소 쓰는 모델과 질문 하나를 정하고, 모델을 여는 시간과 답변이 시작되는 시간, 그 뒤 문장이 이어지는 속도를 따로 봅니다. 활동 모니터에서는 메모리 압력과 스왑 사용량을 함께 확인하세요. 스왑은 누적된 수치 하나만 보지 말고 해당 작업을 시작했을 때 늘어나는지, 응답 지연과 함께 나타나는지를 봐야 합니다.

속도를 나란히 비교할 때는 같은 모델 파일과 양자화, 입력 길이, 엔진 버전, MTP 설정을 맞춥니다. 파일 캐시와 프롬프트 캐시의 상태도 기록합니다. 모델 교체가 불편한 것인지, 긴 문서가 느린 것인지, 메모리가 모자란 것인지가 갈리면 무엇을 바꿀지도 훨씬 선명해집니다.

더 좋은 장비를 사면 지금의 답답함이 사라질 것이라는 기대는 자연스럽습니다. 중요한 것은 그 답답함이 어디에서 생겼는지입니다. 매일 같은 모델로 오래 대화하는 사람에게는 모델이 들어가는 메모리와 답변 속도가, 여러 모델을 오가는 사람에게는 파일을 여는 시간까지 중요해집니다. 같은 M5 Ultra라도 잘 맞는 구성은 달라질 수 있습니다.

먼저 실제로 쓸 모델을 골라 프리필과 디코드를 체감해 보세요. 그 속도가 충분하고 메모리에도 여유가 있다면 SSD는 필요한 저장 공간과 교체 편의에 맞춰 결정하면 됩니다. 더 큰 숫자를 사는 것보다, 내가 기다리던 구간을 줄이는 쪽에 돈을 쓰는 편이 만족스럽습니다.