▲

antirez/ds4 - Metal용 DeepSeek V4 Flash 로컬 추론 엔진

 (github.com/antirez)
1P by GN⁺ 7시간전 | ★ favorite | 댓글 1개
  • Apple Metal GPU에 최적화된 DeepSeek V4 Flash 전용 로컬 추론 엔진으로, 범용 GGUF 러너가 아닌 단일 모델에 집중한 네이티브 C 구현체
  • DeepSeek V4 Flash는 활성 파라미터 수가 적어 빠른 속도를 제공하며, thinking 모드에서 다른 모델 대비 1/5 수준의 짧은 사고 구간 생성
  • 100만 토큰 컨텍스트 윈도우와 극도로 압축된 KV 캐시를 통해 로컬 환경에서도 장문맥 추론이 가능하며, 디스크 KV 캐시 영속화 지원
  • OpenAI 및 Anthropic 호환 HTTP API 서버를 내장해 Claude Code, opencode, Pi 등 다양한 코딩 에이전트와 즉시 연동 가능
  • llama.cpp와 GGML 생태계의 기반 위에 구축되었으며, GPT 5.5의 강력한 코딩 지원을 받아 개발된 프로젝트

프로젝트 개요 및 설계 철학

  • ds4.c는 DeepSeek V4 Flash 전용 소형 네이티브 추론 엔진으로, 범용 GGUF 러너나 다른 런타임의 래퍼가 아님
  • 핵심 경로는 DeepSeek V4 Flash에 특화된 Metal 그래프 실행기이며, DS4 전용 로딩, 프롬프트 렌더링, KV 상태, 서버 API 접착 코드 포함
  • 로컬 추론 분야에 우수한 프로젝트가 많지만, 새 모델이 계속 등장하면서 관심이 분산되는 문제가 존재
    • 이 프로젝트는 한 번에 하나의 모델에 의도적으로 집중하며, 공식 벡터 검증(logits), 장문맥 테스트, 에이전트 통합까지 수행
  • 로컬 추론의 비전: A) HTTP API가 포함된 추론 엔진 + B) 특정 엔진에 최적화된 GGUF + C) 코딩 에이전트 구현체를 통한 테스트 및 검증, 이 세 가지가 함께 작동하는 것
  • Metal 전용이며, 향후 CUDA 지원 가능성은 있으나 확정되지 않음
    • CPU 경로는 정확성 검증용으로만 존재하며, 현재 macOS 버전의 가상 메모리 구현 버그로 인해 CPU 코드 실행 시 커널 크래시 발생
  • GPT 5.5의 강력한 지원을 받아 개발되었으며, 인간이 아이디어, 테스트, 디버깅을 주도

DeepSeek V4 Flash를 별도 엔진으로 만든 이유

  • 활성 파라미터가 적어 더 빠른 추론 속도 제공
  • thinking 모드에서 다른 모델 대비 1/5 수준의 짧은 사고 구간을 생성하며, 사고 구간 길이가 문제 복잡도에 비례
    • 다른 모델이 thinking 모드에서 실용적으로 사용 불가능한 상황에서도 DeepSeek V4 Flash는 사용 가능
  • 100만 토큰 컨텍스트 윈도우 지원
  • 284B 파라미터 규모로 27B, 35B 모델 대비 지식의 경계에서 더 많은 정보를 알고 있음
    • 이탈리아어 TV 프로그램, 정치 관련 질문 등에서 차이 확인 가능
  • 영어와 이탈리아어 작문 품질이 준프론티어 모델 수준
  • KV 캐시가 극도로 압축되어 로컬 컴퓨터에서 장문맥 추론이 가능하며, 디스크 KV 캐시 영속화 지원
  • 특수 방식으로 양자화할 경우 2비트 양자화에서도 잘 작동하여 128GB RAM MacBook에서 실행 가능
  • 향후 DeepSeek에서 V4 Flash 업데이트 버전 출시 예상

llama.cpp 및 GGML에 대한 감사

  • ds4.c는 GGML에 링크하지 않지만, llama.cpp 프로젝트가 개척한 경로 위에 존재
  • llama.cpp의 커널, 양자화 포맷, GGUF 생태계, 하드-원 엔지니어링 지식이 필수 참고 자료
  • 일부 소스 레벨 코드가 MIT 라이선스 하에 유지 또는 적용됨: GGUF quant 레이아웃 및 테이블, CPU quant/dot 로직, 특정 Metal 커널 등
  • LICENSE 파일에 GGML 저작자 저작권 표시 유지

모델 가중치

  • 이 프로젝트 전용으로 게시된 DeepSeek V4 Flash GGUF만 작동하며, 임의의 DeepSeek/GGUF 파일은 호환되지 않음
  • 2비트 양자화는 비대칭 양자화 방식 적용
    • MoE 전문가(expert)만 양자화: up/gate는 IQ2_XXS, down은 Q2_K
    • 공유 전문가, 프로젝션, 라우팅 등 나머지 컴포넌트는 양자화하지 않아 품질 보장
  • ./download_model.sh q2로 128GB RAM 머신용, ./download_model.sh q4로 256GB 이상 RAM 머신용 모델 다운로드
    • Hugging Face(antirez/deepseek-v4-gguf)에서 다운로드하며, curl -C -로 부분 다운로드 재개 지원
  • ./download_model.sh mtp로 선택적 투기적 디코딩(speculative decoding) 지원 GGUF 다운로드 가능
    • MTP/투기적 디코딩 경로는 아직 실험적이며, 현재 약간의 속도 향상만 제공

속도 벤치마크

  • --ctx 32768, --nothink, greedy 디코딩, -n 256 설정에서의 단일 실행 Metal CLI 수치
  • MacBook Pro M3 Max, 128GB (q2)
    • 짧은 프롬프트: prefill 58.52 t/s, 생성 26.68 t/s
    • 11709 토큰 프롬프트: prefill 250.11 t/s, 생성 21.47 t/s
    • q4는 메모리 부족으로 N/A
  • Mac Studio M3 Ultra, 512GB (q2)
    • 짧은 프롬프트: prefill 84.43 t/s, 생성 36.86 t/s
    • 11709 토큰 프롬프트: prefill 468.03 t/s, 생성 27.39 t/s
  • Mac Studio M3 Ultra, 512GB (q4)
    • 짧은 프롬프트: prefill 78.95 t/s, 생성 35.50 t/s
    • 12018 토큰 프롬프트: prefill 448.82 t/s, 생성 26.62 t/s

CLI 사용법

  • -p 옵션으로 원샷 프롬프트 실행, -p 없이 실행하면 인터랙티브 멀티턴 채팅 모드 진입
  • 인터랙티브 CLI는 렌더링된 채팅 트랜스크립트와 라이브 Metal KV 체크포인트를 유지하여, 각 턴이 이전 대화를 확장
  • 유용한 명령어: /help, /think, /think-max, /nothink, /ctx N, /read FILE, /quit
    • Ctrl+C로 현재 생성 중단 후 프롬프트로 복귀
  • 기본값은 thinking 모드이며, /nothink 또는 --nothink로 직접 응답 모드 전환
  • --mtp MTP.gguf --mtp-draft 2로 선택적 MTP 투기적 경로 활성화 가능
    • greedy 디코딩에서만 유용하며, confidence gate(--mtp-margin)를 사용해 느린 부분 수락 방지

서버

  • OpenAI/Anthropic 호환 로컬 HTTP 서버 실행 가능
  • Metal 전용이며, 하나의 변경 가능한 그래프/KV 체크포인트를 메모리에 유지
    • 상태 비저장 클라이언트가 동일 프롬프트의 더 긴 버전을 재전송하면 공유 접두사 재사용 가능
  • 요청 파싱과 소켓은 클라이언트 스레드에서 실행되지만, 추론 자체는 단일 Metal 워커를 통해 직렬화
    • 현재 서버는 여러 독립 요청을 일괄 처리하지 않으며, 동시 요청은 순서대로 대기

  • 지원 엔드포인트

    • GET /v1/models, GET /v1/models/deepseek-v4-flash
    • POST /v1/chat/completions, POST /v1/completions, POST /v1/messages

  • /v1/chat/completions (OpenAI 호환)

    • messages, max_tokens/max_completion_tokens, temperature, top_p, top_k, min_p, seed, stream, stream_options.include_usage, tools, tool_choice 지원
    • 도구 스키마는 DeepSeek의 DSML 도구 포맷으로 렌더링되며, 생성된 DSML 도구 호출은 OpenAI 도구 호출로 역변환

  • /v1/messages (Anthropic 호환)

    • Claude Code 스타일 클라이언트용 엔드포인트
    • system, messages, tools, tool_choice, max_tokens, temperature, top_p, top_k, stream, stop_sequences, thinking 제어 지원
    • 도구 사용은 Anthropic tool_use 블록으로 반환
  • 양쪽 API 모두 SSE 스트리밍 지원, thinking 모드에서 추론 과정은 네이티브 API 형태로 스트리밍

에이전트 클라이언트 연동

  • ds4-server는 OpenAI 호환 chat completions을 사용하는 로컬 코딩 에이전트와 연동 가능
  • 128GB RAM에서 2비트 quant(81GB)를 실행할 경우 100k~300k 토큰 컨텍스트 윈도우가 적절
    • 전체 1M 토큰 컨텍스트는 약 26GB 메모리(압축 인덱서만 약 22GB) 사용
  • 384000 출력 제한 설정으로 토큰 캡 방지 가능 (모델은 최대 384k 토큰까지 생성 가능)

  • opencode 연동

    • ~/.config/opencode/opencode.json에 provider와 agent 항목 추가로 설정
    • baseURL을 http://127.0.0.1:8000/v1로 지정

  • Pi 연동

    • ~/.pi/agent/models.json에 provider 설정 추가
    • DeepSeek의 thinking 포맷, reasoning effort 지원, 스트리밍 usage 지원 등 호환성 옵션 포함
    • ~/.pi/agent/settings.json에서 기본 모델로 설정 가능

  • Claude Code 연동

    • Anthropic 호환 엔드포인트 사용, ~/bin/claude-ds4 래퍼 스크립트로 환경 변수 설정
    • ANTHROPIC_BASE_URL을 로컬 서버로 지정하고 모든 모델 변수를 deepseek-v4-flash로 설정
    • Claude Code는 초기에 약 25k 토큰의 대형 프롬프트를 전송하므로, --kv-disk-dir 활성화 필수
      • 첫 번째 비싼 prefill 이후 디스크 KV 캐시가 저장된 접두사를 재사용하여 후속 세션에서 전체 프롬프트 재처리 불필요

Thinking 모드

  • DeepSeek V4 Flash는 non-thinking, thinking, Think Max 세 가지 모드 지원
  • 서버 기본값은 thinking 모드
  • reasoning_effort=max로 Think Max 요청 가능하나, 컨텍스트 크기가 모델 카드 권장 사항에 충분히 큰 경우에만 적용
    • 작은 컨텍스트에서는 일반 thinking으로 폴백
  • OpenAI reasoning_effort=xhigh는 일반 thinking에 매핑되며, Think Max가 아님
  • 직접 응답이 필요하면 thinking: {"type":"disabled"}, think:false, 또는 deepseek-chat 같은 non-thinking 모델 별칭 사용

디스크 KV 캐시

  • Chat/completion API는 상태 비저장이므로 에이전트 클라이언트는 매 요청마다 전체 대화를 재전송
  • ds4-server는 렌더링된 토큰 스트림을 캐시된 토큰 접두사와 비교하여 처리
    • 라이브 인메모리 체크포인트는 현재 세션 담당
    • 디스크 KV 캐시는 세션 전환 및 서버 재시작 후 유용한 접두사를 유지하는 메커니즘
  • 현재 메모리에는 하나의 라이브 KV 캐시만 존재하며, 새로운 비관련 세션이 이를 대체하면 이전 체크포인트는 디스크 KV 캐시에 기록된 경우에만 재처리 없이 재개 가능
  • --kv-disk-dir과 --kv-disk-space-mb로 활성화

  • 캐시 키 및 파일 구조

    • 캐시 키는 정확한 토큰 ID의 SHA1 해시이며, 원시 텍스트가 아님
    • 각 토큰 ID는 리틀엔디안 32비트 정수로 해싱되며, 파일명은 <sha1>.kv
    • 일반 read/write I/O로 기록하며 mmap 사용하지 않음 (이미 모델을 매핑하는 프로세스에 추가 VM 매핑 방지)

  • 디스크 캐시 파일 레이아웃

    • KVC 고정 헤더 48바이트: magic("KVC"), 버전, routed expert quant 비트, 저장 사유, 캐시된 토큰 수, 히트 카운트, 컨텍스트 크기, 생성/마지막 사용 Unix 타임, DS4 세션 페이로드 바이트 수
    • 렌더링된 텍스트: 캐시된 토큰 접두사의 토크나이저 디코딩 텍스트 (관찰 용도, 키로 사용되지 않음)
    • DS4 세션 페이로드: 13개의 리틀엔디안 u32 필드로 시작하며, magic("DSV4"), 페이로드 버전, 컨텍스트 크기, prefill 청크 크기, KV 링 용량 등 포함
      • 체크포인트 토큰 ID, 다음 토큰에 대한 float32 logits, 레이어별 압축 어텐션 행 수, 라이브 raw 슬라이딩 윈도우 KV 행, 압축 레이어의 KV 행 및 compressor frontier 텐서 등 저장

  • 체크포인트 저장 시점

    • cold: 긴 초기 프롬프트가 안정 접두사에 도달한 후, 생성 전
    • continued: prefill 또는 생성이 설정된 간격만큼 진행될 때
    • evict: 비관련 요청이 라이브 인메모리 세션을 대체하기 전
    • shutdown: 서버가 정상 종료될 때
  • cold 저장 시 작은 토큰 접미사를 트리밍하고 prefill 청크 경계에 정렬하여, 향후 요청에서 BPE 경계 재토큰화 미스 방지
    • 기본값: 최소 512 토큰 접두사, cold 저장 최대 30000 토큰, 꼬리 32 토큰 트리밍, 2048 토큰 청크 정렬
  • 기본적으로 2비트와 4비트 routed-expert 변형 간 토큰 접두사가 일치하면 체크포인트 재사용 가능
    • --kv-cache-reject-different-quant로 동일 양자화 전용 재사용 설정 가능

백엔드

  • 기본 백엔드는 Metal (--metal)
  • CPU 참조/디버그 경로도 존재 (--cpu)하나 프로덕션 대상이 아님
    • 서버는 Metal 전용이며, 최적화된 구현은 Metal 그래프 경로에 존재
  • MIT 라이선스, C/Objective-C/Metal 구현

함께 보면 좋은 글 β

▲
GN⁺ 7시간전  [-]
Hacker News 의견들

  • 기존 코드베이스에서 Claude Code와 함께 써봤는데, 2비트 양자화 모델임에도 제 역할은 하는 듯함
    프롬프트 처리는 몇 분 걸리지만 실제 편집은 20토큰/초 이상으로 꽤 빠름
    작은 작업에서는 코드 탐색, 수정 적용, 테스트 작성까지 성공했지만, 사소한 지적 하나는 고치지 못했음
    더 나쁜 점은 다른 문제를 풀던 중 동시에 나눈 “The Duck” 관련 대화를 환각으로 끌어왔다는 것임. 아마 Claude Code 초기 프롬프트 예시 중 하나인 듯함

  • 예전에 Qwen3 모델용으로 아주 비슷한 걸 만들었음. Qwen3만 실행하고, 일부 양자화만 지원하며, GGUF에서 로드하고, Claude가 반복적으로 최적화한 추론을 사용함
    전체가 파일 몇 개 수준으로 작고 이해하기 쉬워서, 학생들이 디코딩 전략 추가나 abliteration 같은 걸 실험하며 배우도록 만든 프로젝트였음. 유명 프레임워크는 크고 복잡해서 해킹하기 어렵고, 교육용 프로젝트는 GPT-2처럼 오래된 것에 머무는 경우가 많음
    교육용으로 시작했지만 계속 머릿속을 떠나지 않는 아이디어가 생겼음. 특정 GPU+모델 조합에 맞춘 초최적화 추론 엔진을 만들면 어떨까 싶음. GPU는 비싸고 점점 구하기 어려워지니, 추상화를 충분히 걷어내고 정확한 하드웨어/모델에 직접 맞추면 꽤 많이 최적화할 수 있을 것 같음
    다만 모델이 구식이 되면 전부 처음부터 다시 해야 하는 문제가 있음

    • 이미 사용 중인 추론 엔진들은 서로 다른 하드웨어에 맞춰 최적화된 백엔드 구성 요소들을 포함하고 있음
      덜 인기 있는 플랫폼에서는 아직 쉽게 얻을 수 있는 성능 개선 여지가 있지만, 특정 GPU 제품군용 초최적화 모델 실행기를 만들어 훨씬 더 나은 성능을 얻을 공간은 많지 않음. 핵심 계산은 이미 각 GPU에 맞춘 고도로 최적화된 커널이 처리하고 있음
      CPU 아키텍처에서 더 잘 돌도록 최적화한 llama.cpp 포크들도 있지만, 유지보수자 간 이견이 없다면 특정 모델+GPU 실행기를 따로 만드는 것보다 이런 개선을 upstream에 병합하는 편이 시간을 더 잘 쓰는 길임
    • 유명한 FizzBuzz 고성능 코드골프 답변이 떠오름. 그런 식의 최적화를 추론에 적용할 수 있다면 속도를 10배 이상 높일 수도 있을 것 같음
      https://codegolf.stackexchange.com/questions/215216/high-thr...
    • 여기에 더해, 칩을 모델에 맞춰 설계하면 어떨까 싶음. 디지털에서 아날로그로 옮겨서 벡터를 비트가 아니라 전압으로 표현하면 어떻게 될까?
      계산량이 큰 행렬 곱셈을 연산 증폭기로 처리할 수 있을까? 그리고 이런 아날로그 접근이 비트 표현의 한계보다 훨씬 효율적일 수 있을까?
    • Mojo가 목표로 하는 게 초최적화된 하드웨어 특화 엔진처럼 보이는데, 여기서는 거의 언급되지 않는 듯함
    • 비슷한 걸 만들어본 적 있음. 한 가지 문제는 LLM이 좋은 셰이더를 작성하는 데 정말 형편없다는 점임. 덜 엉망으로 만들게 하려고 너무 많은 시간을 썼음

  • 최신 AI가 커널 최적화까지 할 수 있게 된 만큼, 더 많은 사람이 자기 하드웨어에 맞는 더 나은 추론을 직접 만들어봐야 한다고 봄
    오래된 W7900(RDNA3)을 갖고 있는데, 48GB VRAM 외에도 123 FP16 TFLOPS/INT8 TOPS, 864GB/s 메모리 대역폭 같은 지표는 꽤 괜찮음. 하지만 AMD의 ROCm 지원도, llama.cpp 지원도 악명 높게 나빴음
    최근 이 카드를 전용 에이전트/코딩 엔드포인트로 쓰려고 W8A8-INT8 모델을 튜닝하기 시작함. 며칠 동안 자동 반복을 약 800회 돌렸고, 여러 frontier/SOTA 모델을 써봤는데 Kimi K2.6이 의외로 잘했음. 결과적으로 Qwen3.6 MoE 기준 최고의 llama.cpp 수치보다 prefill은 20%, decode는 50% 빨라졌음
    지금은 MTP와 DFlash 최적화를 계속 파고 있는데 결과가 꽤 만족스럽고, 다음에는 Gemma 4를 시도해볼 생각임

    • 7900xtx로 비슷한 상황임. 24GB VRAM에 서류상 성능은 괜찮지만 실제로는 대부분이 잘 안 돌아감
      그래도 llama.cpp는 최고 성능은 아닐 수 있어도 대부분의 모델을 일관되게 실행할 수 있음. MTP가 부족하고 하이브리드 모델의 캐시 무효화 문제가 있는 듯하지만, 적어도 무엇이 도는지는 알 수 있음
      Python 기반 추론기들은 uv/venv, 내 venv, 시스템 환경, Python, 라이브러리까지 뒤섞여 실제로 뭐가 돌아가는지 파악하려면 에이전트가 필요할 지경임. 실력 문제나 사용자 오류라는 건 알지만, 거기에 쓸 시간이 남아 있지 않음
      완벽하지 않더라도 GitHub나 Hugging Face에 올리면 다른 에이전트가 0부터가 아니라 거기서 시작할 수 있음. Ling-2.6-flash(107B-A7B4 MoE)도 그렇게 했고, 로컬 LLM용으로 가진 다른 하드웨어인 M2 Max에서 실용적으로 돌릴 수 있는 가장 큰 LLM임
      MTP가 잘 작동하지 않아도 현재 llama.cpp가 Ling-2.6-flash를 전혀 못 돌리는 것보다는 개선임. 관련 논의는 https://huggingface.co/inclusionAI/Ling-2.6-flash/discussion...에 있고, 4비트 양자화는 https://huggingface.co/ljupco/Ling-2.6-flash-GGUF, 브랜치는 https://github.com/ljubomirj/llama.cpp/tree/LJ-Ling-2.6-flas...에 있음
    • 지식과 결과를 공유해주면 좋겠음
      llama.cpp는 PC 지원을 훨씬 더 잘할 수 있었다고 봄. 일부는 벤더 지원이 나빠서 그렇겠지만, 사용자가 이렇게 많은데도 표준 PC에서 더 최적화된 추론이 많이 보이지 않는 건 놀라움

  • 정말 멋짐. 하나의 오픈소스 모델을 여러 달 동안 집중적으로 최적화하면 어떤 결과가 나올지 궁금함
    추론 서빙뿐 아니라 하네스 최적화와 맞춤 워크플로까지 포함해서, frontier 모델은 추론하고 도출할 수 있지만 오픈소스 모델은 크기나 학습 한계 때문에 기본적으로 부족한 부분의 간극을 얼마나 좁힐 수 있을지 보고 싶음

    • frontier 모델과 오픈소스 모델 사이에는 늘 큰 격차가 있을 것임. 아주 부자가 아니라면 더 그렇고, 이 산업 전체가 단위 경제성을 무시하고 있어서 말이 안 됨
      Kimi 2.6을 괜찮은 토큰/초 속도로 운영하는 데 월 2만 달러가 드는데, 그 토큰을 이익 내며 팔려면 하드웨어 비용이 월 1천 달러 미만이어야 함
      억만장자들이 원가의 1/10~1/20 가격으로 토큰을 팔아주는 관대함이나, 유능한 오픈소스 모델이 소비자용 하드웨어에 들어가는 망상 같은 미래에 역량을 걸고 있다면 이미 끝난 셈임

  • 재미있고 흥미로우며 많은 걸 말해주는 데이터 포인트가 있음. 내 MacBook M3 Max는 DS4가 최대 속도로 토큰을 생성할 때 전력 사용량이 50W까지 올라감

    • “LLM 데이터센터는 규모의 경제 덕분에 사용자당 에너지 효율이 셀프호스팅 LLM보다 기술적으로 더 좋다”는 데이터 포인트를 인터넷은 아직 받아들일 준비가 안 된 듯함
    • 이런 기계가 “생각”하는 데 얼마나 많은 전력이 드는지 생각해보면 흥미로움. 막연히 “많이” 든다고는 생각했지만 숫자로 보니 좋음
      DS4 Flash가 50W에서 피크를 찍고 280B 파라미터라면, 1.6T 파라미터인 DS4 Pro는 대략 300W쯤 될까? 최신 GPT 5와 Opus는 비슷하게 500W 정도로 느껴짐
      Claude Code를 쓰면서 모델이 혼자 장황하게 도는 동안, 어딘가 데이터센터에서 500W를 태우고 있다고 봐도 되는 걸까?
    • 모두가 알아차리지는 못할 수 있지만, 이건 정말 훌륭하고 인상적인 결과임. 내 M4 Max에서는 대부분 모델이 150W를 소비함
    • 그 수치가 진짜인지 궁금함. 하드웨어에 익숙하지 않은 사람은 이런 걸 어떻게 측정하면 되는지도 궁금함
    • 인간 뇌 2~3개 정도의 전력 사용량과 같음. 대단한 작업임

  • Mac Studio에서 96GB RAM보다 큰 옵션을 주문할 수가 없음. M3 Ultra나 M4 Max에서도 마찬가지임. 호주 한정인지 모르겠음
    반면 MacBook Pro는 M5 Mac으로 128GB를 지정할 수 있음
    https://www.apple.com/au/shop/buy-mac/mac-studio

    • 이 메모리가 unobtanium으로 만들어졌다고 믿기는 어려움
      Apple은 바가지 가격 논란이나 재고 부족 반발을 겪느니 아예 가격을 매기지 않는 편을 택했을 수도 있음
    • 호주만 그런 게 아님: https://9to5mac.com/2026/05/05/apples-most-powerful-mac-stud...
      96GB를 넘는 모든 Mac Studio 구성과 기본형 Mac mini를 없앴음. Neo 기본 구성도 시장에서 내리는 걸 검토 중이라는 소문이 있음
      팹 생산능력과 RAM 공급 제약을 이런 식으로 처리하는 듯함
    • Studio는 이제 꽤 오래된 제품임. 새 모델이 언젠가 나오면 더 많은 메모리 옵션이 붙을 가능성이 큼. 그래도 128GB M5 Max MBP는 훌륭함

  • 간단한 동기 부여용 벤치마크나 목표를 놓친 건지 모르겠음
    일반 도구 체인을 쓰는 것보다 더 빠르거나, 더 크고 똑똑한 모델을 돌릴 수 있게 해준다고 추정은 되지만, 그 기준선 대비 기존 개선폭이나 기대 개선폭이 어느 정도인지 명확히 적혀 있지 않은 듯함
    관련 비교값을 알고 있다면 제시된 숫자로 계산할 수는 있겠지만 말임

  • 매우 인상적임. 다만 큰 입력에서 응답을 시작하기까지 4분 정도 걸리는 듯한 점은 이상하게 보임
    Mac 하드웨어로 LLM을 쓰지는 않지만 꽤 놀랍고, 실사용에는 상당히 큰 걸림돌일 것 같음
    다만 일반 사용에서는 캐싱 설명을 보니 훨씬 납득됨. Claude Code가 유용한 작업을 시작하기 전에 보통 25k 토큰 정도의 큰 초기 프롬프트를 보낼 수 있고, --kv-disk-dir를 켜두면 첫 비싼 prefill 이후 디스크 KV 캐시가 저장된 prefix를 재사용해서 전체 프롬프트를 다시 처리하지 않아도 됨

    • 코딩 에이전트가 아주 큰 시스템 프롬프트를 보내면 그런 일이 생김. 이후 도구 호출이 큰 파일이나 diff를 넣을 때도 마찬가지임
      하지만 M3 Ultra에서는 prefill 속도가 거의 500토큰/초라서 충분히 실사용 가능한 영역임. M3 Max는 조금 더 인내가 필요하지만 잘 작동하고, pi agent를 쓰면 사고 과정을 출력하므로 기다리는 대신 검열되지 않은 chain of thought를 읽게 됨
      어제 X에 M3 Max로 쓰는 영상을 올렸는데, 꽤 괜찮은 속도로 토큰을 뱉어냄
    • M5에서는 prefill이 더 빠르고, 이전 세대는 조금 약함

  • MacBook에서 큰 LLM은 토큰 생성 속도는 받아들일 만하지만, 문제는 컨텍스트 읽기임
    채팅 세션처럼 KV 캐시를 쓰는 증분 읽기가 아니라, 큰 파일을 붙여넣을 때처럼 큰 입력을 읽는 경우가 문제임. 몇 분이 걸릴 수 있음

    • DS4는 프롬프트 토큰을 초당 460개 처리할 수 있음. 아주 뛰어나진 않지만 그렇게 느리진 않음. M3 Max 기준이고, README의 벤치마크를 보면 됨
    • 로컬 추론에서는 왜 이렇게 느린데 호스팅 모델을 쓰면 그렇게 빠른지 쉽게 설명해줄 수 있을까?
    • 내가 착각한 게 아니라면 이 저장소는 2비트 양자화로 실행하는 내용임
      클라우드 제공자가 제공하는 원래 지능과는 꽤 거리가 있을 가능성이 큼
      그래도 에이전트형 워크플로에서 로컬 LLM의 가능성을 더 잘 보여줌
    • 왜 이런 현상이 생기는 걸까?
      전체 대화 이력을 다시 넣는 방식에 의존하지 않는 아키텍처가 있을까? 순환형 LLM 같은 것 말임
답변달기