기존 코드베이스에서 Claude Code와 함께 써봤는데, 2비트 양자화 모델임에도 제 역할은 하는 듯함
프롬프트 처리는 몇 분 걸리지만 실제 편집은 20토큰/초 이상으로 꽤 빠름
작은 작업에서는 코드 탐색, 수정 적용, 테스트 작성까지 성공했지만, 사소한 지적 하나는 고치지 못했음
더 나쁜 점은 다른 문제를 풀던 중 동시에 나눈 “The Duck” 관련 대화를 환각으로 끌어왔다는 것임. 아마 Claude Code 초기 프롬프트 예시 중 하나인 듯함
예전에 Qwen3 모델용으로 아주 비슷한 걸 만들었음. Qwen3만 실행하고, 일부 양자화만 지원하며, GGUF에서 로드하고, Claude가 반복적으로 최적화한 추론을 사용함
전체가 파일 몇 개 수준으로 작고 이해하기 쉬워서, 학생들이 디코딩 전략 추가나 abliteration 같은 걸 실험하며 배우도록 만든 프로젝트였음. 유명 프레임워크는 크고 복잡해서 해킹하기 어렵고, 교육용 프로젝트는 GPT-2처럼 오래된 것에 머무는 경우가 많음
교육용으로 시작했지만 계속 머릿속을 떠나지 않는 아이디어가 생겼음. 특정 GPU+모델 조합에 맞춘 초최적화 추론 엔진을 만들면 어떨까 싶음. GPU는 비싸고 점점 구하기 어려워지니, 추상화를 충분히 걷어내고 정확한 하드웨어/모델에 직접 맞추면 꽤 많이 최적화할 수 있을 것 같음
다만 모델이 구식이 되면 전부 처음부터 다시 해야 하는 문제가 있음
이미 사용 중인 추론 엔진들은 서로 다른 하드웨어에 맞춰 최적화된 백엔드 구성 요소들을 포함하고 있음
덜 인기 있는 플랫폼에서는 아직 쉽게 얻을 수 있는 성능 개선 여지가 있지만, 특정 GPU 제품군용 초최적화 모델 실행기를 만들어 훨씬 더 나은 성능을 얻을 공간은 많지 않음. 핵심 계산은 이미 각 GPU에 맞춘 고도로 최적화된 커널이 처리하고 있음
CPU 아키텍처에서 더 잘 돌도록 최적화한 llama.cpp 포크들도 있지만, 유지보수자 간 이견이 없다면 특정 모델+GPU 실행기를 따로 만드는 것보다 이런 개선을 upstream에 병합하는 편이 시간을 더 잘 쓰는 길임
여기에 더해, 칩을 모델에 맞춰 설계하면 어떨까 싶음. 디지털에서 아날로그로 옮겨서 벡터를 비트가 아니라 전압으로 표현하면 어떻게 될까?
계산량이 큰 행렬 곱셈을 연산 증폭기로 처리할 수 있을까? 그리고 이런 아날로그 접근이 비트 표현의 한계보다 훨씬 효율적일 수 있을까?
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를 소비함
그 수치가 진짜인지 궁금함. 하드웨어에 익숙하지 않은 사람은 이런 걸 어떻게 측정하면 되는지도 궁금함
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 같은 것 말임
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에 병합하는 편이 시간을 더 잘 쓰는 길임
https://codegolf.stackexchange.com/questions/215216/high-thr...
계산량이 큰 행렬 곱셈을 연산 증폭기로 처리할 수 있을까? 그리고 이런 아날로그 접근이 비트 표현의 한계보다 훨씬 효율적일 수 있을까?
최신 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를 시도해볼 생각임
그래도 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 모델은 추론하고 도출할 수 있지만 오픈소스 모델은 크기나 학습 한계 때문에 기본적으로 부족한 부분의 간극을 얼마나 좁힐 수 있을지 보고 싶음
Kimi 2.6을 괜찮은 토큰/초 속도로 운영하는 데 월 2만 달러가 드는데, 그 토큰을 이익 내며 팔려면 하드웨어 비용이 월 1천 달러 미만이어야 함
억만장자들이 원가의 1/10~1/20 가격으로 토큰을 팔아주는 관대함이나, 유능한 오픈소스 모델이 소비자용 하드웨어에 들어가는 망상 같은 미래에 역량을 걸고 있다면 이미 끝난 셈임
재미있고 흥미로우며 많은 걸 말해주는 데이터 포인트가 있음. 내 MacBook M3 Max는 DS4가 최대 속도로 토큰을 생성할 때 전력 사용량이 50W까지 올라감
DS4 Flash가 50W에서 피크를 찍고 280B 파라미터라면, 1.6T 파라미터인 DS4 Pro는 대략 300W쯤 될까? 최신 GPT 5와 Opus는 비슷하게 500W 정도로 느껴짐
Claude Code를 쓰면서 모델이 혼자 장황하게 도는 동안, 어딘가 데이터센터에서 500W를 태우고 있다고 봐도 되는 걸까?
Mac Studio에서 96GB RAM보다 큰 옵션을 주문할 수가 없음. M3 Ultra나 M4 Max에서도 마찬가지임. 호주 한정인지 모르겠음
반면 MacBook Pro는 M5 Mac으로 128GB를 지정할 수 있음
https://www.apple.com/au/shop/buy-mac/mac-studio
Apple은 바가지 가격 논란이나 재고 부족 반발을 겪느니 아예 가격을 매기지 않는 편을 택했을 수도 있음
96GB를 넘는 모든 Mac Studio 구성과 기본형 Mac mini를 없앴음. Neo 기본 구성도 시장에서 내리는 걸 검토 중이라는 소문이 있음
팹 생산능력과 RAM 공급 제약을 이런 식으로 처리하는 듯함
간단한 동기 부여용 벤치마크나 목표를 놓친 건지 모르겠음
일반 도구 체인을 쓰는 것보다 더 빠르거나, 더 크고 똑똑한 모델을 돌릴 수 있게 해준다고 추정은 되지만, 그 기준선 대비 기존 개선폭이나 기대 개선폭이 어느 정도인지 명확히 적혀 있지 않은 듯함
관련 비교값을 알고 있다면 제시된 숫자로 계산할 수는 있겠지만 말임
매우 인상적임. 다만 큰 입력에서 응답을 시작하기까지 4분 정도 걸리는 듯한 점은 이상하게 보임
Mac 하드웨어로 LLM을 쓰지는 않지만 꽤 놀랍고, 실사용에는 상당히 큰 걸림돌일 것 같음
다만 일반 사용에서는 캐싱 설명을 보니 훨씬 납득됨. Claude Code가 유용한 작업을 시작하기 전에 보통 25k 토큰 정도의 큰 초기 프롬프트를 보낼 수 있고,
--kv-disk-dir를 켜두면 첫 비싼 prefill 이후 디스크 KV 캐시가 저장된 prefix를 재사용해서 전체 프롬프트를 다시 처리하지 않아도 됨하지만 M3 Ultra에서는 prefill 속도가 거의 500토큰/초라서 충분히 실사용 가능한 영역임. M3 Max는 조금 더 인내가 필요하지만 잘 작동하고, pi agent를 쓰면 사고 과정을 출력하므로 기다리는 대신 검열되지 않은 chain of thought를 읽게 됨
어제 X에 M3 Max로 쓰는 영상을 올렸는데, 꽤 괜찮은 속도로 토큰을 뱉어냄
MacBook에서 큰 LLM은 토큰 생성 속도는 받아들일 만하지만, 문제는 컨텍스트 읽기임
채팅 세션처럼 KV 캐시를 쓰는 증분 읽기가 아니라, 큰 파일을 붙여넣을 때처럼 큰 입력을 읽는 경우가 문제임. 몇 분이 걸릴 수 있음
클라우드 제공자가 제공하는 원래 지능과는 꽤 거리가 있을 가능성이 큼
그래도 에이전트형 워크플로에서 로컬 LLM의 가능성을 더 잘 보여줌
전체 대화 이력을 다시 넣는 방식에 의존하지 않는 아키텍처가 있을까? 순환형 LLM 같은 것 말임