인터넷에 연결된 전 세계 인구의 95%에 대해 50ms 이내에 추론을 실행하면 GPU 메모리 성능이 무자비하게 효율적입니다. 작년에 저희는 Infire(Rust 기반 추론 엔진)로 메모리 사용률을 개선했고, Omni(모델 예약 플랫폼)로 콜드 스타트를 없앴습니다. 이제 저희는 추론 플랫폼의 다음 큰 병목 현상인 모델 가중치를 해결하고 있습니다.
LLM에서 단일 토큰을 생성하려면 GPU 메모리에서 모든 모델 가중치를 읽어야 합니다. 여러 데이터 센터에서 사용 중인 NVIDIA H100 GPU 에서는 텐서 코어가 메모리가 제공할 수 있는 것보다 거의 600배 빠르게 데이터를 처리할 수 있으므로, 컴퓨팅이 아니라 메모리 대역폭에 병목 현상이 발생합니다. 메모리 버스를 통과하는 모든 바이트는 가중치가 더 작았으면 피할 수 있었을 바이트입니다.
이 문제를 해결하기 위해 저희는 Unweight(Unweight)를 구축했습니다. 여기서 핵심 혁신은 빠른 온칩 메모리에서 가중치를 압축 해제하고 텐서 코어에 직접 공급하면 느린 주 메모리를 통한 추가 왕복을 방지한다는 것입니다. Unweight 런타임은 워크로드에 따라 여러 실행 전략 중에서 선택합니다. 즉, 단순성이 우선이고, 메모리 트래픽을 최소화하는 실행 전략이 있으며, 오토튜너는 가중치 행렬과 배치 크기에 따라 최상의 실행 전략을 선택합니다.
이 게시물에서는 Unweight의 작동 방식을 자세히 설명합니다. 하지만 투명성을 높이고 빠르게 발전하는 이 분야에서 혁신을 장려하기 위해 기술 문서 를 게시하고 GPU 커널을 오픈 소싱합니다.
Llama-3.1-8B에 대한 초기 결과 다중 계층 퍼셉트론(MLP) 가중치만 비교했을 때 30%까지 압축된 것으로 나타났습니다. 가중치 해제는 디코딩을 위해 매개변수를 선택적으로 작동하므로 모델 크기를 15~22% 줄이고 최대 3GB의 VRAM을 절약할 수 있습니다. 아래 그래픽에 나와 있는 것처럼, Cloudflare의 네트워크를 통해 더 많은 것을 끌어낼 수 있고, 더 많은 위치에서 더 많은 모델을 실행할 수 있으므로, Cloudflare의 네트워크에서 더 저렴하고 빠르게 추론할 수 있습니다.
Unweight 덕분에 단일 GPU에 더 많은 모델을 맞출 수 있습니다
창의적인 방식으로 모델 가중치를 압축하여 추론 속도를 높이거나 더 작은 GPU에서 실행되는 방법을 모색하는 연구가 늘어나고 있습니다. 가장 일반적인 것은 양자화로, 32비트 또는 16비트 부동 소수점 숫자를 작은 8비트 또는 4비트 정수로 변환하여 모델 가중치 및 활성화의 크기를 줄이는 기술입니다. 이는 손실 압축의 한 형태로, 다양한 16비트 부동 소수점 값을 동일한 4비트 정수로 변환할 수 있습니다. 이러한 정확도의 저하는 예측할 수 없는 방식으로 응답의 품질에 영향을 미칩니다. 다양한 사용 사례에 제공되는 프로덕션 추론을 위해, 우리는 정확한 모델 동작을 유지하는 무손실을 원한다는 것을 알았습니다.
최근 몇 가지 시스템(Huff-LLM, ZipNN, ZipServ)에서는 LLM 가중치를 크게 압축할 수 있음이 나타났지만, 이러한 접근 방식은 우리의 접근 방식과는 다른 문제를 대상으로 합니다. ZipNN은 배포 및 저장을 위해 가중치를 압축하며 CPU에서 압축 해제가 수행됩니다. HUff-LLM은 디코딩을 위한 맞춤형 FGPA 하드웨어를 제안합니다. 또한 ZipServ는 압축 해제와 GPU 추론을 융합하지만, 소비자용 등급의 GPU를 대상으로 하므로 Cloudflare의 H100 GPU에서는 사용할 수 없습니다. 그 어떤 것도 우리에게 필요한 것을 제공하지 못했습니다. Rust 기반 추론 엔진과 통합할 수 있는 Hopper GPU의 무손실 추론-시간 압축 해제.
그 핵심 문제는 일반적인 압축이 아닙니다. BF16 웨이트의 지수 바이트는 매우 중복되어 있으므로 엔트로피 코딩이 이러한 바이트에 대해 잘 작동합니다. 문제는 추론 속도가 느려지지 않을 만큼 빠르게 압축을 푸는 것입니다. H100에서 텐서 코어는 대부분의 시간 동안 유휴 상태로 메모리를 기다리지만, 이러한 유휴 용량을 단순히 압축 해제 용도로 재사용할 수는 없습니다. 각 GPU 컴퓨팅 장치는 공유 메모리 제약으로 인해 압축 해제 커널 또는 행렬 곱셈 커널 중 하나를 실행할 수 있으며, 두 커널을 동시에 실행할 수는 없습니다. 행렬 곱셈과 완벽하게 겹치지 않는 디코딩 대기 시간은 토큰 대기 시간에 직접적으로 누적됩니다. Unweight의 해답은 빠른 온칩 공유 메모리에서 가중치를 압축 해제하고 그 결과를 텐서 코어에 직접 제공하는 것이지만, 다양한 배치 크기와 가중치 형태에서 효율적으로 작업을 수행하는 것이야말로 진정한 엔지니어링 팀의 역할입니다.
AI 모델의 모든 숫자는 16비트 "brain 실수"(BF16)로 저장됩니다. 각 BF16 값은 세 부분으로 구성됩니다.
이러한 가중치 중 하나를 분해하는 방법은 다음과 같습니다.
가중치에 따라 기호와 무용수가 예측할 수 없을 정도로 변합니다. 즉, 무작위 데이터처럼 보이고 의미를 압축할 수 없습니다. 하지만 지수의 경우는 이야기가 다릅니다.
이전 연구에 따르면 학습된 LLM에서는 256개의 가능한 지수 값 중 소수만이 대부분을 차지합니다. 일반적으로, 가장 일반적인 상위 16개의 지수가 레이어의 모든 가중치의 99% 이상을 차지합니다. 정보 이론에 따르면 이 분포를 나타내는 데는 약 2.6비트만 필요하며, 이는 할당된 8비트보다 훨씬 적은 양입니다. 일반적인 LLM 계층의 지수 값 분포를 살펴보면 상위 16개 지수가 전체 모델 가중치의 99%를 차지한다는 것을 알 수 있습니다.
일반적인 LLM 계층의 지수 값 분포
이것이 Unweight가 활용되는 이중화입니다. 부호와 가수부는 그대로 두고 지수 바이트만 허프만 코딩 을 사용하여 압축합니다. — 일반적인 값에는 짧은 코드를, 드문 값에는 더 긴 코드를 할당하는 고전적인 기법입니다. 지수 분포가 크게 왜곡되어 있기 때문에 지수 스트림에서 약 30%의 압축을 달성합니다. 당사에서는 모델 매개변수의 약 3분의 2를 구성하고 토큰 생성 중 메모리 트래픽을 지배하는 MLP 가중치 행렬(게이트, 업, 다운 예측)에 이를 선택적으로 적용합니다. 어텐션 가중치, 임베딩, 레이어 규범은 압축되지 않습니다. 최적화로 해석하면 Cloudflare 기술 보고서에 자세히 설명되어 있듯이, MLP(멀티레이어 퍼셉트론)의 가중치 크기는 약 20% 감소했습니다.
희귀한 지수가 있는 소수의 가중치는 별도로 처리됩니다. 64 행에 있는 가중치에 상위 16개 색상표 외부의 지수가 있는 경우 전체 행이 그대로 저장됩니다. 이 접근 방식을 사용하면 핫 경로에서 요소별 분기가 제거됩니다. 모든 단일 가중치를 검사하여 엣지 케이스를 확인하는 대신, 미리 행당 하나의 결정을 내립니다.
NVIDIA H100 GPU에는 두 가지 관련 메모리가 있습니다.
추론 중 각 토큰을 생성하려면 HBM에서 전체 가중치 행렬을 읽어야 합니다. HBM과 SMEM 간의 메모리 버스가 성능 병목 현상이며, 수학 자체는 아닙니다. 버스를 통과하는 바이트 수가 적을수록 = 토큰 생성 속도가 빨라집니다.
추론하는 동안 각 토큰을 생성하려면 메모리 버스를 통해 HBM의 전체 가중치 행렬을 읽어야 하며, 이것이 병목 현상입니다. H100의 텐서 코어는 HBM이 데이터를 제공하는 것보다 훨씬 빠르게 숫자를 분석할 수 있습니다. 압축은 버스를 통과하는 데 필요한 바이트 수가 줄어들기 때문에 도움이 됩니다. 하지만 함정이 있습니다. GPU가 압축 데이터에 대한 연산을 수행할 수 없다는 것입니다. 먼저 가중치를 압축 해제해야 합니다.
대부분의 이전 작업은 전체 가중치 행렬을 HBM으로 압축 해제한 다음 표준 행렬 곱셈을 실행했습니다. 이는 저장 용량에는 도움이 되지만, 모든 토큰에 대해 HBM에서 여전히 전체 비압축 매트릭스를 읽기 때문에 대역폭에는 도움이 되지 않습니다.
추론하는 동안 압축된 가중치를 사용하는 가장 좋은 방법은 없습니다. 올바른 접근 방식은 배치 크기, 가중치 행렬의 모양, 압축 해제에 사용할 수 있는 GPU 시간 등 워크로드에 따라 달라집니다. Unweight는 네 가지 압축 실행 파이프라인을 제공하며, 각 실행 파이프라인은 압축 해제 노력과 계산 복잡성 사이에서 서로 다른 균형을 유지합니다. 하나는 전체 허프만 디코딩, 지수 전용 디코딩, 색상표 트랜스코딩 또는 전처리 완전히 건너뛰기입니다.
네 가지 실행 파이프라인
4개의 파이프라인이 스펙트럼을 형성합니다. 한쪽 끝에서 전체 디코딩은 원래 BF16 가중치를 완전히 재구성하고 NVIDIA의 cuBLAS 라이브러리로 전달하여 표준 행렬 곱셈을 수행합니다. 이는 cuBLAS가 일반 데이터에서 최고 속도로 실행되는 가장 간단한 경로이지만, 전처리 단계에서 메인 메모리에 가장 많은 바이트의 바이트를 다시 씁니다. 이 알고리즘은 행렬 곱셈이 작고 사용자 지정 커널 오버헤드가 주로 발생하는 소규모 배치 크기에서 잘 작동합니다. 반면 직접 색상표는 전처리를 완전히 건너뛰며, 가중치는 모델 로드 시 간단한 4비트 형식으로 미리 코드 변환되며, 행렬 곱셈 커널은 이러한 인덱스로부터 즉석에서 BF16 값을 재구성합니다. 전처리 비용은 없지만 커널은 요소당 더 많은 작업을 수행합니다.
그 사이에는 두 개의 독립적인 경로가 있습니다. 하나는 지수 바이트만 디코딩하고(트래픽 전처리를 절반으로 줄임), 다른 하나는 런타임에 4비트 색상표 인덱스로 트랜스코딩(4분의 1)합니다. 둘 다 압축된 데이터를 로드하고, 빠른 공유 메모리에서 BF16을 재구성하며, 주 메모리를 왕복하지 않고 텐서 코어에 직접 입력하는 맞춤형 커널을 사용합니다.
전처리가 적다는 것은 HBM에 쓰는 데이터가 적다는 것을 의미하며, 따라서 메모리 버스가 더 빨리 해제됩니다. 하지만 이로 인해 더 많은 재구성 작업이 mat물 커널로 이동하게 되었습니다. 이러한 절충이 효과가 있는지 여부는 상황에 따라 다릅니다.
소규모 배치 크기(즉, 1~64 토큰)과 비교할 때 mat물은 크기가 작기 때문에 중복되는 계산이 많지 않고 사용자 지정 커널의 고정 비용이 지배적입니다. 전체 디코딩 + cuBLAS가 cuBLAS가 오버헤드가 낮기 때문에 단순히 승리하는 경우가 많습니다. 배치 크기가 큰 경우(즉, 256개 이상 토큰)을 실행하는 경우, 마트물은 추가 재구성 작업을 흡수할 수 있을 만큼 충분히 오래 실행됩니다. 전처리 과정이 가벼워지면 작업이 더 빨리 완료되며 확보된 버스 대역폭과 컴퓨팅 중복이 효과를 발휘합니다. 색상표 또는 지수 파이프라인이 앞으로 나아갑니다. 동일한 계층 내에서 가중치 행렬이 다르면 파이프라인별로 유리할 수 있습니다. "게이트" 및 "위쪽" 프로젝션은 "아래쪽" 프로젝션과 차원이 다르므로 마트물 내에서 수행되는 작업 순서를 변경하려면 다른 성능 절충이 필요합니다.
처리량과 파이프라인 전략의 비교
Unweight가 단일 전략을 하드코딩하지 않는 이유입니다. 런타임은 대상 하드웨어의 실제 엔드투엔드 처리량을 측정하는 자동 튜닝 프로세스를 통해 정보가 전달되며 각 배치 크기에서 각 가중치 행렬에 가장 적합한 파이프라인을 선택합니다(자세한 내용은 아래 참조).
4개의 파이프라인 중 3개의 파이프라인은 압축 해제와 계산을 융합한 사용자 지정 행렬 곱셈 커널을 사용합니다. 이 커널은 HBM에서 압축된 데이터를 로드하고, 공유 메모리에 원래 BF16 값을 재구성하며, 텐서 코어에 직접 입력하는 작업을 한 번의 작업으로 처리합니다. 재구성된 가중치는 주 메모리에 절대 존재하지 않습니다.
기존의 압축 해제와 가중치 해제 비교
가중치 해제를 사용하면 MLP 가중치 행렬을 위해 메모리 버스를 통과하는 바이트가 최대 30% 감소합니다
이 커널 내에서 GPU의 스레드 그룹은 두 가지 역할로 나뉩니다.
프로듀서 그룹이 전용 메모리 복사 하드웨어(TMA)를 사용하여 HBM에서 공유 메모리로 압축된 입력을 로드합니다. 기호+가수 바이트, 지수 데이터(또는 색상표 인덱스), 희귀한 지수가 있는 행의 경우 그대로 지수 행을 단계적으로 구성합니다. 소비자보다 앞서 실행하여 순환 버퍼를 채워 데이터가 필요하기 전에 준비할 수 있도록 합니다.
소비자 그룹은 기호+가수 바이트가 있는 지수를 결합하여 BF16 값을 재구성한 다음, 그 결과를 호퍼의 WGMMA 텐서 코어 명령어에 즉시 공급합니다. 재구성된 가중치는 공유 메모리를 벗어나지 않고 조립에서 계산으로 바로 이동합니다.
재구성 마트물은 각 컴퓨팅 장치가 처리하는 출력 타일의 수와 순환 버퍼의 실행 깊이에 따라 여러 가지 변형으로 제공됩니다. 출력 타일이 넓어짐에 따라 대규모 배치 크기에서 데이터 재사용이 향상됩니다. 버퍼가 깊으면 작은 배치 크기에서 메모리 대기 시간이 줄어듭니다. 오토튜너가 작업 부하에 따라 최상의 변형을 선택합니다.
두 개의 융합된 파이프라인에서는 별도의 전처리 커널(허프만 복호화기 또는 색상표 트랜스코더)이 재구성적 마트물과 동시에 실행됩니다. 하지만 이러한 커널은 GPU 리소스를 두고 경쟁합니다.
호퍼에서 각 컴퓨팅 장치(SM)에는 228KB의 공유 메모리가 있습니다. 재구성 마트물은 파이프라인 버퍼 및 누산기 타일에 약 227KB가 필요합니다. 디코드 커널은 허프만 조회 테이블에 약 16KB가 필요합니다. 227 + 16 > 228이므로 이 두 커널은 동일한 계산 단위를 공유할 수 없습니다. 디코딩에 할당된 모든 SM은 마트물에 사용할 수 있는 SM이 하나 줄어듭니다.
디코드 SM이 많을수록 전처리는 더 빨라지지만 행렬 곱셈은 느려지며 그 반대의 경우도 마찬가지입니다. 최적의 분할은 조정 가능한 또 다른 매개변수이며, 오토튜너가 휴리스틱에 의존하지 않고 실제 처리량을 측정하는 또 다른 이유입니다.
SM 파티셔닝 제약이 있음에도 불구하고 Unweight는 트랜스포머 모델의 구조를 활용하여 압축 해제 비용의 많은 부분을 숨깁니다.
모든 계층이 런타임에 허프만 디코딩을 필요로 하는 것은 아닙니다. 가중치 해제는 레이어를 "하드"(허프만 전처리가 필요함) 또는 "쉬움"(매트물이 직접 사용할 수 있는 사전 트랜스코딩된 색상표 데이터 사용)으로 분류합니다. 런타임은 둘 사이를 번갈아 가며 실행합니다.
디코드는 부트스트랩, 어텐션, 간편 MLP 계산 중에 별도의 CUDA 스트림에서 실행됩니다. 하드 계층의 MLP가 실행될 때쯤, 전처리된 가중치는 이미 대기 중입니다.
GPU가 전처리가 필요 없는 쉬운 계층을 계산하는 동안 별도의 CUDA 스트림 세트가 백그라운드에서 다음 하드 계층의 가중치를 디코딩합니다. 쉬운 계층이 마무리되고 어려운 계층의 차례가 오면 전처리된 데이터가 이미 대기하고 있습니다. 이중 버퍼링된 전처리 슬롯은 하나의 하드 계층에서 디코딩 출력이 소비되는 동안 덮어쓰기되지 않도록 보장합니다.
다운 프로젝션은 이러한 중복의 혜택을 가장 많이 받습니다.
4개의 파이프라인, 여러 matmut 커널 변형, 디코딩과 계산 간에 분할된 조정 가능한 SM 덕분에 구성 공간이 넓어집니다. Unweight는 단일 전략을 하드코딩하는 대신, 오토튜너를 사용하여 대상 하드웨어에서 실제 엔드투엔드 추론 처리량을 측정합니다. 고정 상태를 위아래로 누른 상태에서 게이트 프로젝션의 후보 구성을 쓸어담은 다음, 더 이상 개선이 발견되지 않을 때까지 위아래로 반복합니다. 그 결과, 각 배치 규모에서 각 프로젝션에 정확히 어떤 파이프라인, 마트물 변형, SM 할당을 사용할지 런타임에 알려주는 모델별 구성 파일이 생성되며, 이는 모두 휴리스틱이 아닌 측정된 성능에 따라 결정됩니다.
인코딩 형식, 실행 파이프라인, 일정 예약은 독립적으로 선택할 수 있습니다. 동일한 허프만 압축 모델 번들이 분포와 추론을 모두 지원할 수 있습니다.
배포의 경우, 허프만 인코딩은 압축(최대 22% 전체 모델 크기 축소)을 극대화하여 네트워크를 통해 모델을 전송할 때 전송 시간을 줄입니다.
추론의 경우, 허프만이 인코딩한 프로젝션은 모델 로드 시 추론 색상표 중간 형식으로 트랜스코딩할 수 있으므로 배포 형식을 제한하지 않고 가장 효율적인 런타임 실행이 가능합니다.
단일 모델 번들은 패키징 시 하나의 전략을 실행할 필요가 없습니다. 런타임에서는 각 프로젝션 및 배치 크기당 최상의 실행 경로를 즉시 선택합니다.
Llama 3.1 8B(우리의 주요 테스트베드)에서 Unweight는 다음을 달성합니다.
추론 번들의 경우 13% 이하(게이트/업 MLP 프로젝션만 압축)의 모델 풋프린트 감소, 또는 배포 번들의 경우(다운을 포함한 모든 MLP 프로젝션 압축) 22% 이하의 모델 풋프린트 감소. 모든 압축은 100% 비트 단위까지의 무손실입니다. Llama 70B까지 추정하면 구성에 따라 약 18~28GB를 절약할 수 있습니다.
30~40%의 처리량 오버헤드, 현재 최적화 수준에서 엔드투엔드 방식으로 H100 SXM5에서 측정. 오버헤드는 배치 크기 1(~41%)에서 가장 크고 배치 1024(~30%)에서 줄어듭니다. 작은 배치 고정 비용, 중복 가중치 타일 재구성, 다운 프로젝션 제외 등 세 가지 알려진 소스는 활성 최적화 중입니다.
단일 모델에 대한 중간 결과입니다. 압축 비율은 다른 SwiGLU 아키텍처로 일반화되어야 하지만(지표 통계는 모델 규모에 따라 일관됨), 처리량 수치는 현재 커널 구현에 따라 다르며 최적화가 계속 진행됨에 따라 변경됩니다. 저희는 아직 전반적인 감소 효과를 약화시키는 어텐션 가중치, 임베딩, 레이어 노름 등을 압축하지 않았습니다.
GPU는 카드 자체의 비용, 요구되는 고대역폭 메모리, 상당한 전력 소모 등 여러 측면에서 비용이 많이 듭니다.
이를 방지하기 위해 여러 연구자들은 전체 모델에서 최대 30%의 압축률을 보이는 시스템을 보여주었지만, 이는 프로덕션 규모에서 작동하지 않는 소비자 GPU와 연구 프레임워크를 대상으로 합니다. Unweight의 개발에서 얻은 핵심 인사이트는 멀티레이어 퍼셉트론(MLP)이 모델 가중치의 대부분을 구성하며 추론 워크로드 중 컴퓨팅 비용의 상당 부분을 차지한다는 점입니다. 이 플랫폼은 MLP 가중치만 압축하고(압축 이점이 적은 계층에서 오버헤드 방지), 컴퓨팅 및 메모리가 긴밀하게 균형을 이룬 데이터센터 H100 GPU를 위해 특별히 설계되었으며, 단일 접근 방식을 사용하지 않고 배치 크기에 적응하는 4개의 실행 파이프라인이 제공됩니다 .
하지만, 저희는 분명히 하고자 합니다. Unweight는 결코 공짜가 아닙니다. 온칩 재구성으로 압축되지 않은 가중치에는 존재하지 않았을 계산 작업이 늘어납니다. Llama 3.1 8B에서 추론 구성은 일반적인 제공 배치 크기에서 약 30%의 처리량 비용으로 전체 모델 메모리의 약 13%를 절약합니다. 이 격차는 배치 크기가 커질수록 (전처리 중복이 개선됨에 따라) 좁아지며, 최적화를 진행함에 따라 더욱 좁아질 것으로 예상됩니다. 특히, 각 MLP 레이어의 다운 프로젝션(압축 가능한 가중치의 약 3분의 1)은 아직 압축하지 않았으며, 여러 커널 개선 사항이 활발히 개발 중입니다.
Cloudflare 네트워크의 경우 Unweight를 이용하면 용량이 더 커집니다. 인스턴스당 더 적은 GPU 메모리로 최첨단 모델을 제공할 수 있으므로 비용이 절감되고 더 많은 장소에서 더 많은 모델을 배포할 수 있습니다. 모델 배포의 경우, 절감액이 더 큽니다. 허프만 압축 번들은 크기가 약 22% 작으므로 모델을 전 세계 에지 위치로 보낼 때 전송 시간이 줄어듭니다.
향후에는 효율성 향상과 더불어 개선될 것으로 생각되는 세 가지의 구체적인 연구 방향이 있습니다.
다운 프로젝션 압축. 현재 가중치 해제는 게이트 및 업 MLP 프로젝션을 압축하지만, 프로젝션 다운은 압축 가능 가중치의 약 1/3을 차지합니다. 이는 전치된 차원으로 인해 다른 커널 변형이 필요하며, 이로 인해 전체 모델 크기가 22% 이상 줄어들 것으로 예상됩니다.
커널 최적화. 현재 30~40%의 처리량 오버헤드는 재구성 가능한 마트물에서의 소규모 고정 비용, 대규모 배치 크기에서의 중복 가중치 재구성, 다운 프로젝션 누락의 세 가지 원인에서 비롯됩니다. 각각에는 알려진 완화 경로가 있으며, 이는 당사의 기술 백서에 설명되어 있습니다.
더 많은 모델. 결과는 Llama 3.1 8B에 대한 결과이지만, 기본 지수 통계는 모든 규모에서 SwiGLU 아키텍처 전반에서 일관되게 나타났습니다. Cloudflare에서는 Workers AI를 통해 더 큰 규모의 모델에 Unweight를 도입하기 위해 노력하고 있습니다.
장기적으로, 저희는 수요에 따라 콜드 전문가를 가져와야 하며 스토리지를 줄이면 비용이 추가로 절감되는 혼합형 모델에 Unweight의 아키텍처가 의미하는 바를 조사하고 있습니다.
이 분야는 빠르게 발전하고 있는 분야이기 때문에, 이곳에서 우리의 작업을 오픈 소스로 삼고 압축 및 GPU 효율성에 대한 늘어나는 연구에 기여하게 되어 매우 기쁩니다. 가중치 해제는 퍼즐의 한 조각이지만 다른 연구자들이 이를 기반으로 구축할 수 있는 유용한 패러다임을 찾을 수 있기를 바랍니다!