왜 매번 Charles 왕이 누군지까지 필요하다며 모델 전체를 메모리에 밀어 넣는지 늘 의문이었음. 큰 파일을 잘게 나눠 적은 메모리로 효율적으로 읽는 기술은 이미 확립됐다고 봄
최첨단 AI 업계에는 모델 제작엔 뛰어나지만 규모 확장성과 실용성은 인프라 담당자에게 떠넘기는 경향이 있어 보임. 실제로 쓰는 지식이 10% 미만이라면 미세조정과 최적화만으로 비용을 크게 낮출 수도 있을 듯함

모델 전체를 메모리에 두는 편이 디스크와 교환하는 것보다 훨씬 빠름

사실상 전문가 혼합(MoE) 구조를 설명한 셈임. 전문가 계층이 충분히 작고 SSD가 빠르면 필요할 때만 불러올 수 있음
밀집형 LLM은 보통 성능이 더 좋지만, 계층을 외부 저장소로 내보내면 MoE보다 훨씬 크게 느려짐

요즘은 출처를 모르는 프로젝트를 내려받을 때 이런 보안 검토를 직접 돌려야 함. 저장소의 에이전트 지시와 Markdown 파일을 무시하고 Swift/Metal 소스, 빌드 스크립트, CI 설정, 의존성을 검사하게 했더니 악성 코드·백도어·자격 증명 탈취·숨은 네트워크 엔드포인트는 찾지 못했지만, 컴파일·공급망·런타임 위험은 여전히 남는다는 결과가 나왔음
더 좋은 프롬프트가 있다면 공유해도 좋겠고, Cursor의 Composer 2.5로 실행한 비용은 0.20달러 미만이었음

M1 MacBook Air에서 macOS 15를 쓴다면 다음 두 줄을 삭제하거나 if #available(macOS 26.0, *)로 감싸면 컴파일됨: opts.languageVersion = .version4_0
주석에 따르면 어텐션이 11.24배 빨라져 사전 채우기가 2.4배 가속되는 효과는 놓치지만, 8코어 GPU M1 Air에서 초당 5~6토큰은 나옴

유용한 정보임. 나중에 최소 지원 버전을 낮춰볼 수도 있겠음 2.4배 사전 채우기 개선은 apple10 GPU 계열에서만 작동하며, M1은 기억상 apple7임

이 프로젝트가 평범한 mmap 과 어떻게 비교되는지 궁금함. llama.cpp도 mmap을 켜고 재패킹을 끄면 원할 경우 26B 모델을 2GB RAM에서 실행할 수 있음
핵심 차이는 SSD 읽기를 추론 작업과 동기화해 지연을 최소화했다는 점으로 보이며, 운영체제는 이런 실행 맥락을 고려하지 않음

첫 버전은 mmap을 사용했음. 8GB M2에서 차가운 상태의 3.36MB 전문가를 읽는 데 mmap은 10ms, pread는 2.8ms가 걸렸고 전체 시뮬레이션은 각각 초당 0.50토큰과 4토큰이었음 mmap에서는 모델이 페이지를 건드릴 때 운영체제가 사후 대응으로 읽기 때문에 어떤 전문가가 선택됐는지, 언제 GPU 작업과 읽기를 겹칠 수 있는지 알지 못함. 공통 가중치는 단순성을 위해 여전히 mmap을 사용하며, llama.cpp도 2GB 미만에서 돌 수는 있겠지만 더 느릴 것으로 봄

실제 속도를 확인하려면 llama.cpp의 SSD 오프로딩과 직접 비교해 보고 싶음

“측정 결과는 기준점이지 성능 상한이 아니다”라는 문장은 Claude 특유의 표현처럼 보임

이런 표현이 너무 널리 퍼져 Claude식 문체를 계속 읽다가 나도 같은 버릇을 익힐까 걱정될 정도임

“100번 넘게 실험했고 대부분 실패했지만 일부가 여기까지 이끌었다”도 같은 흔적처럼 보임

원래는 ChatGPT식 표현이었을 가능성이 크지만, 그렇다고 서구 기업을 증류했다고 몰아가지는 않겠음. 2022년 이후의 레시피 블로그가 4.6~4.8 무렵 학습 데이터에 들어갔을 수도 있음

이제 이런 판별은 그만할 때가 됐다고 봄. 새 형태의 문법 경찰과 다를 바 없고 별 가치도 더하지 못함
저자가 LLM으로 문장만 다듬었고 쓸데없는 내용이 추가되지 않았다면 상관없음. 글 자체가 쓸모없는 생성물이라면 그냥 낮은 점수를 주면 됨

더 빠른 SSD를 장착한 M1 Max Mac Studio에서 초당 12토큰과 거의 즉각적인 응답이 나오는 건 인상적임. 대형 모델을 메모리가 아니라 SSD에서 직접 구동할 가능성을 보여줌

아쉽게도 여기서는 SSD 읽기 속도가 가장 큰 병목임

요즘 SSD 스트리밍 엔진은 많지만 어려운 기능까지 시도하는 경우는 드묾. 주요 모델에 추측 디코딩용 MTP 헤드가 있으므로 이를 SSD의 전문가 가중치를 미리 읽는 데 활용할 수 있음
GPU가 필요로 하기 전에 가중치를 준비하면 VRAM 캐시 미스 비용을 크게 줄일 수 있으며, 효과가 입증되면 향후 모델은 전문가를 미리 불러오는 전용 헤드를 갖추고 학습 단계부터 이를 고려할 수도 있음

SSD 스트리밍에서는 GPU가 올바른 전문가를 가져올 때까지 거의 항상 SSD를 기다리므로, SSD 쪽에는 미리 읽을 여유가 사실상 없음. 잘못 예측한 전문가를 읽으면 오히려 손해이며, 이 때문에 일반적인 비대규모 배치 환경에서는 기존 MTP도 별 도움이 안 됨

실제로는 생각보다 어려움. 계층마다 전문가 집합이 다르고, 작은 라우터가 아래 계층 전문가의 출력 상태를 보고 사용할 전문가를 정함
MTP가 만든 초안 토큰으로 첫 계층의 전문가까지는 예측할 수 있지만, 10번째 계층을 알려면 1~9번째 계층을 실행하며 해당 전문가들을 먼저 읽어야 함. 따라서 다음 토큰 생성기 대신 모든 계층의 전문가 활성화를 한꺼번에 예측하도록 학습된 장치가 필요함

DiffusionGemma를 실행하는 프로젝트도 거의 준비됐으며 두 프로젝트를 결합하면 잘 맞을 수 있음. 36GB M3에서 초당 약 20토큰이 나오고 서로 더 빠른 커널을 가져다 쓸 가능성도 큼
현재 코드는 https://github.com/mmastrac/diffgemma에 있지만 아직 배포 가능한 상태는 아님

M5의 메모리가 더 많아 운영체제가 파일 대부분을 이미 캐시했기 때문일 가능성이 큼. M2는 메모리 압박이 커서 SSD 읽기 결과를 덜 캐시할 것임
운영체제 캐시까지 포함해 총 2GB만 쓸 수 있다면 추론 속도는 더 낮아질 수 있음

시스템 캐시와 pread에 상당히 의존함. 프로세스가 2GB 아래여도 M5 Mac이 일부를 캐시할 수 있고 하드웨어 자체도 훨씬 빠름
토큰당 읽기는 M2에서 83ms, M5 Pro에서 12ms였으며 전체 시간은 각각 163ms와 30ms였음. 읽기와 GPU 처리 모두 빨라진 결과임

세대가 오래돼 Pro끼리 비교해도 SSD가 훨씬 느리고, 같은 세대에서도 Air의 SSD와 메모리 대역폭이 Pro보다 낮을 가능성이 있음

M5 MacBook Pro는 RAM이 24GB라서 더 많은 문맥을 메모리에 보관할 수도 있음

앞으로 30~60GB 메모리와 매우 빠른 SSD를 갖춘 시스템이라면 이런 기법으로 초대형 모델도 실행할 수 있기를 기대함