정말 멋짐. 지금 당장 클라우드 사업자보다 실용적이려는 프로젝트가 아니라, 가능성의 경계를 보여주는 프로젝트임
모델 효율 개선과 로컬 장비 성능 향상이 맞물리면 언젠가 고품질 로컬 모델도 경제적으로 운용 가능해질 수 있음

초당 0.5토큰은 긴 작업에도 쓸모없다고 봄. 차라리 돈을 들여 16GB 4060 Ti 2장에 텐서 병렬화를 적용하겠음
20년 뒤라면 태양광으로 작동하며 잔디를 깎거나 보도를 닦는 사이버펑크풍 저속 로봇, 혹은 정원에서 분재의 성장 속도만 간신히 따라가며 가지를 치는 로봇에 어울릴 듯함

지금은 거의 쓸 수 없지만, 이런 프로젝트가 계속 개선돼야 결국 실용적인 버전에 도달하므로 반가움

토큰 비용을 지불하고 추론 사업자가 전기료를 내는 게 낭비라는데, 오이를 사면 농부가 물과 비료 비용을 내는 것과 무엇이 다른지 모르겠음. LLM이 나중에 끼워 맞춘 논리이길 바람
아이디어 자체는 흥미로우며 더 작은 모델로 시험해 보고 싶음. 초당 0.5토큰을 생성하면서 SSD에서 매초 수 GB를 읽는다면, 일반 소비자 노트북에는 여전히 너무 크지만 250~500GiB 모델을 대상으로 할 때 오히려 실용적일 수도 있음

직접 토마토를 기르면 공짜 토마토를 얻을 수 있음. BLT를 만들기엔 부족해도 슈퍼마켓산이 아니니 세상을 조금 구한 셈임 /s

42W를 지속적으로 쓰고 전기료가 kWh당 20센트라고 가정하면 토큰 100만 개당 약 5달러이며, 하드웨어를 비롯한 다른 비용은 제외한 값임

한 달은 약 260만 초이고 초당 0.5토큰이면 월 130만 토큰을 생성함. 부대 비용까지 감안하면 월간 장비 운영비가 토큰 100만 개당 비용이라고 잡아도 대략 맞음

태양광 발전이 있다면 계산이 어떻게 달라지는지 궁금함

표준 llama.cpp도 GGUF를 mmap할 수 있어 메모리에 들어가지 않는 부분은 디스크에 남고, 커널 페이지 캐시가 자주 쓰는 부분인 상주 트렁크를 유지해 줌. 굳이 자체 구현할 이점이 무엇인지 궁금함

며칠 전 비슷한 프로젝트에서도 같은 질문이 나왔는데, 먼저 mmap을 시도한 뒤 직접 구현해 10배 빨라졌다고 했음
데이터베이스 엔진이 자체 캐시를 구현하는 이유와 같음. 커널 페이징은 범용·요청 기반이지만 실제 접근 패턴을 알면 필요한 데이터를 미리 읽고 파이프라인화할 수 있음

이 정도 규모에서 SSD를 스왑 공간으로 쓰면 불과 몇 달 만에 누적 쓰기 내구성을 소진하기 쉬움. 단기 시험 이상으로 돌렸을 때 SMART의 누적 쓰기량과 마모 통계를 보고 싶음
전부 RAM에 들어가는 모델이라면 llama-server는 --no-mmap으로 실행하는 편이 나았음. 물론 전체 Kimi K3와 100만 토큰 문맥을 올리려면 2TB 서버가 필요함

README가 LLM 작성물이라는 느낌을 강하게 주는데, 코드베이스도 LLM이 작성했는지 궁금함

피상적으로 깎아내리고 싶지는 않지만, 문서가 모델을 정말 원래 정밀도로 실행하는지 스스로 모순됨. 주장하는 3비트 양자화는 흥미로울 수 있으나, K3는 원래 정밀도의 밀집 매개변수만 약 115GB이고 토큰당 활성 희소 전문가가 약 25GB이며 KV 캐시도 추가되므로 RAM 29GB에서 토큰당 2초라는 주장은 이해하기 어려움

소프트웨어를 많이 직접 작성했고 프로그래밍 언어도 만들었음: https://github.com/marcobambini/gravity
이제는 LLM과 에이전트를 조율하는 데 내 기술을 활용해 더 나은 코드를 훨씬 빠르게 작성함. 개발자는 새 기술에 적응하거나 도태되는 길 중 하나를 택해야 함

작성자들이 최소한 LLM이 생성한 README를 직접 읽어보기라도 했으면 함. LLM은 독자 관점에 대한 이해가 부족해 외부 독자도 프로젝트의 전체 맥락과 의사결정 과정을 안다고 가정함
사용자에게는 중요하지만 완성품을 보는 독자에게는 무관한 내부 결정과 Claude 특유의 난해한 용어가 그대로 들어감. LLM을 자주 사용하고 복잡한 코드 작성에 매우 유용하다는 점은 인정하지만, 글의 초안 품질은 형편없음

기여자 목록에 claude가 있으니 추측할 필요도 없음. Claude에게 커밋까지 맡길 정도라면 코드를 직접 검토했을 가능성도 낮아 보임

README에서 Claude 특유의 문체가 가장 짙게 느껴짐. 사람별 글쓰기 방식을 인식하듯, 이제는 Claude가 기본으로 생성하는 짧고 단속적이며 운율만 과한 문체도 별도 유형으로 머릿속에 자리 잡는 느낌

작업에 맞는 모델을 정확히 고를 수 있을 만큼 기술이 발전하면 가치가 커질 수 있음. 자동 탐색 과정에서 하루 30분 정도만 큰 모델을 가동하고 나머지 시간에는 소형 모델을 사용하는 미래를 상상할 수 있음

그런 미래는 오지 않을 듯함. 백로그 항목조차 끝낸 뒤에야 소요 시간을 알 수 있는데, 실제로 수행하지 않고는 작업 복잡도를 미리 알 방법이 없음