모여보세요: 커뮤니티 모델 구축 스레드

크라우드소싱 컴퓨팅 (crowdsourced compute)을 통해 커뮤니티 모델을 만드는 것은 분명히 가능하며, 적어도 두 가지 방법이 있습니다. 이 스레드는 (풀링 방식이 불가능한 이유를 설명하는 가짜 전문가들로 변질되고 있는) 기존 스레드를 다시 집중시키려는 시도입니다: https://old.reddit.com/r/LocalLLaMA/comments/1u77xo3/joing_all_gpus_to_train_a_community_model/ 모든 사람의 장비(rigs)를 네트워크로 연결하여 컴퓨팅 클러스터 (compute cluster)를 구축하려고 시도하는 것은 합리적이지 않다는 점은 사실이지만, 그것은 일종의 허수아비 공격 (straw man)입니다. 왜냐하면 실제로 그렇게 할 필요가 없기 때문입니다. 일반적으로 주요 전략은 'Branch-Train-Stitch'의 변형을 통해 MoE (Mixture of Experts)를 만드는 것을 포함합니다. 간단히 말해, 참여를 원하는 모든 사람에게 (나중에 특정 형태와 아키텍처를 갖게 될) '프로토타입 (prototype)' 밀집 모델 (dense model)을 배포하면, 사람들이 각자의 하드웨어에서 독립적으로 이 프로토타입 모델을 학습시키고, 그 후 좁은 도메인 (narrow-domain)에서 학습된 서브모델 (submodels)을 주최자에게 다시 제출하면 주최자가 이 서브모델들을 하나의 거대한 MoE로 결합(stitch)하는 방식입니다. 여기에는 몇 가지 주의 사항과 참여하는 모든 사람이 결정해야 할 사항들이 있습니다.

프로토타입의 목표 크기 (또는, 누가 참여할 것인가)
이 결정은 얼마나 많은 사람이 기여할 수 있는지에 영향을 미치며, 근본적으로 참여도에 관한 문제이므로 투표를 통해 처리하는 것이 좋을 것입니다. 저는 이전 서브포럼 하드웨어 투표 (https://old.reddit.com/r/LocalLLaMA/comments/1op0j6j/recent_vram_poll_results/)를 살펴보았습니다. 우리 중 12GB 이상의 VRAM을 가진 사람이 수천 명이나 된다는 점을 고려하면, 프로토타입 크기를 2B 정도로 쉽게 결정할 수 있으며, 결과적으로 최종 모델에 합리적으로 포함할 수 있는 것보다 훨씬 더 많은 참여자가 생길 수 있습니다.
만약 한 단계 높인다면 (32GB VRAM으로), 7B 프로토타입을 배포할 수 있는데, 여기에는 다른 고려 사항들이 있습니다 (예:

최종적인 MoE (Mixture of Experts)는 아마도 500B-1T 규모의 클래스에 도달할 가능성이 높으며, 이는 포럼의 압도적인 대다수에게 말 그대로 실행 불가능한 수준일 것입니다. 라우터 (router)를 위한 학습과 병합 후 치유 (heal post merge) 과정은 터무니없이 비용이 많이 들 것이며, 멤버들이 서브모델 (submodels)을 학습하여 제출할 수 있는 시간적 창구 또한 (1-2B 프로토타입의 경우 약 2주인 것에 비해) 약 8주 정도로 연장되어야 할 것입니다.

따라서 이것이 가장 큰 첫 번째 질문이라고 생각합니다: 이것은 누구를 위한 것인가요? 포럼 멤버들이 직접 사용하기 위한 것인가요? 아니면 세계적인 수준의 프런티어 모델 (frontier model)을 목표로 하는 것인가요?

몇 가지 고려 사항, 상황을 개선하기 위한 아이디어, 그리고 기타 사항들

완성된 기여자 모델 (donors)들은 좁고 잘 정의된 범위를 가져야 합니다. 주최측은 아마도 등록 포털을 '바이브 코딩 (vibe-code)' 해야 할 것입니다. 여기서 참여하는 모든 사람은 의도한 서브 범위(예: 대학원 수준의 신호 처리 / 1900년대 이전의 도서 등)를 선언해야 하며, 포털은 내부적으로 다른 선언된 범위와의 중복 여부를 확인하여 (기본적으로 직교성 (orthogonality)을 강제함) 하위 단계의 라우터 학습 시 문제를 일으키지 않도록 모두가 맡은 바를 지키겠다는 약속을 해야 합니다.

프로토타입을 기여자 모델로 학습시키는 과정은 잘 구조화되어야 하며, 구조, 수치 데이터 타입 (numerical data types), 토크나이저 (tokenizer), 그리고 채팅 템플릿 (chat template)이 모두 일치하도록 보장하면서 데이터의 최소 길이를 강제하는 (이 또한 사전에 합의되어야 함) 스크립트를 배포하여 '바이브'를 맞추는 것이 가치가 있을 수 있습니다.

실제로 우리는 반드시 '여기에 데이터를 입력하세요'라는 스크립트를 제공해야 합니다. 이 서브 포럼의 많은 사람들이 추론 (inference) 경험은 있을지 모르지만, 이곳의 스레드들을 읽어보면 학습 (training) 경험이 있는 사람은 매우 적다는 것을 알 수 있습니다. 이 스크립트가 사용자의 하드웨어를 자동 감지하고 '그냥 작동하게' 만드는 것 자체가 하나의 골칫거리가 될 가능성이 높습니다. 아마도 CUDA와 Vulkan 백엔드로만 제한해야 할까요? 제가 가진 기여자 스크립트 중에는 배치 크기 (batch size)를 자동 감지하고 (기본적으로 점점 더 큰 배치로 채우기 -> 순전파 (forward) 실행 -> 역전파 (backward) 실행 -> OOM(Out of Memory)이 발생할 때까지 스텝 (step) 진행 -> 그 후 규모 축소), 메모리를 사전 할당하거나 엄격하게 관리하는 등의 기능을 갖추고 있어 이를 이 용도에 맞게 조정할 수 있습니다.

주최측이 모든 제출물을 수집하고 나면, 처음과 마지막 몇 개의 레이어(layer)를 제거하고, 기여자(donor)들을 메타 모델(meta-model)로 조립합니다. 전통적으로는 기여자의 어텐션 가중치(attention weights)를 평균 내지만, 특히 우리가 집단적으로 게이트형 델타 네트워크(gated delta nets)나 유사한 기술을 시도해 보기로 결정한다면 더 나은 기술이 있을 수 있습니다. 다른 분들이 원치 않으신다면 제가 조금 더 조사해 볼 수 있습니다.

그 다음으로, 기여자 모델들을 모두 동결(frozen)한 상태에서 라우터 레이어(router layers)를 학습시킵니다 (어텐션/임베딩(attention/embeds)도 초기에는 동결됩니다). 우리는 기여자 모델의 품질이나 출처를 확신할 수 없기 때문에, 실제로 균등한 활용(uniform utilization)을 엄격하게 강제해서는 안 됩니다. 왜냐하면 의도적으로 학습이 덜 되었거나 악의적인 기여자를 제출하도록 기여자 학습 스크립트를 수정하는 것은 매우 쉽기 때문입니다. 다행히 문헌에는 이를 위한 최소 4가지의 고유한 해결책이 있으며, 그중 두 가지는 제가 경험해 본 것이라 더 자격 있는 분이 나타나지 않는다면 제가 설명해 드릴 수 있습니다.

이 마지막 치유(healing) -> 강화학습 (RL) 학습 단계에서는 모델 전체가 VRAM에 유지되어야 합니다. 우리 중에는 풀 H200 리그를 갖춘 멤버가 몇 명 있지만, 그들이 참여를 선택하지 않는다면 이를 대여해야 할 것입니다. 수정: 사실 제가 알고 있는 H200을 보유한 두 멤버 모두 Vast에서 리그를 운영하고 있습니다. 우리가 자금을 모아 우리 멤버들에게 비용을 지불함으로써, 이 프로젝트 전체를 LocalLLama 패밀리 내에서 유지할 수도 있을 것 같네요. ㅎㅎ

시간이 다 되었고 분명히 무언가 잊어버린 것 같습니다. 나중에 수정할 수도 있습니다.
요약하자면, 우리가 집단적으로 원하기로 결정한다면 우리는 이것을 반드시 해낼 수 있습니다.
———
수정: 사실 Branch-Train-Stitch가 이를 완수할 수 있는 유일한 방법입니다. 이 에세이 시작 부분에서 제안하려 했던 다른 접근 방식은 NVIDIA가 여기서 설명하는 것과 같은 '업사이클링 (upcycling)'이었습니다: https://arxiv.org/abs/2410.07524
하지만 그들은 전문가(experts)를 온라인 방식으로 생성하기 때문에 우리는 그렇게 할 수 없습니다. 여기서는 분산 컴퓨팅 (distributed compute)을 위한 오프라인 방식이 요구사항이기 때문입니다. :P
/u/Party-Special-5177 에 의해 r/LocalLLaMA 에 제출됨
[link] [comments]