top of page

정확도를 희생하면서 파라미터를 줄인 GAP Transformer 실험

8분 전
9분 분량
Generic compute infrastructure for a small language-model architecture experiment, not GAP-20 hardware, a model diagram or a benchmark result. Credit: panumas nikhomkhai. Source: https://www.pexels.com/photo/close-up-of-computer-hardware-17489157/. Pexels License.
Generic compute infrastructure for a small language-model architecture experiment, not GAP-20 hardware, a model diagram or a benchmark result. Credit: panumas nikhomkhai. Source: https://www.pexels.com/photo/close-up-of-computer-hardware-17489157/. Pexels License.

Gated Attention Projection의 약자인 GAP은 어텐션과 피드포워드 처리를 결합하며, 표준 Transformer 기준 모델보다 파라미터가 19.91% 적은 대신 정확도도 더 낮다고 보고한다. GAP Transformer 실험은 다른 블록 구조가 모델 크기와 예측 품질 사이에서 유용한 절충안을 제공할 수 있는지 검증한다.

저자는 언어 모델 평가에 사용되는 Wikipedia 텍스트 모음인 WikiText-103의 점수가 매겨진 타깃 1억 개로 두 모델을 학습했다고 설명한다. 더 작은 모델은 기준 시스템을 능가하지 못했다. 이 결과의 의미는 파라미터 절감이 품질 저하를 정당화하는지, 그리고 통제된 실험이 그 상충 관계를 설명할 수 있는지에 달려 있다.

기준점은 어텐션과 피드포워드 구성 요소가 별도의 연산을 수행하는 익숙한 Transformer 아키텍처다. GAP은 이러한 구성을 재검토하지만, 공개된 근거는 대체를 주장하기보다는 탐색적 비교를 뒷받침한다. 소형 모델을 평가하는 개발자에게 이 차이는 추가 테스트가 필요한 요소와 배포 판단에 아직 적합하지 않은 요소를 가른다.

GAP Transformer 실험이 실제로 보고한 내용

GAP은 보고된 비교에서 더 작은 모델을 제공하지만, 예측 품질은 측정 가능한 수준으로 떨어진다.

프로젝트의 공개 모델 결과에는 표준 Transformer의 학습 가능한 파라미터가 337,280개, 확장된 GAP20 구성의 파라미터가 270,128개로 제시돼 있다. 파라미터는 모델의 동작을 결정하는 학습된 수치 값이다. 그 수를 줄이면 모델의 저장 요구량은 바뀌지만, 동등한 성능을 입증하는 것은 아니다.

보고된 테스트 퍼플렉서티는 표준 모델의 40.05에서 GAP20의 45.62로 상승한다. 퍼플렉서티는 보지 못한 텍스트에 대한 예측 불확실성을 측정하며, 값이 낮을수록 예측이 더 우수함을 뜻한다. 보고된 다음 토큰 정확도 역시 30.34%에서 28.61%로 하락한다.

저장소는 4개 레이어, 4개 어텐션 헤드, 96토큰 컨텍스트, 하나의 학습 시드를 사용한 비교를 설명한다. 시드는 초기화 같은 무작위 선택을 제어한다. 이러한 경계 조건은 이 실험이 특정 학습 설정 아래의 소형 언어 모델에 관한 것임을 보여주므로 중요하다.

저자는 또한 계산상 34.31%의 파라미터 감소를 보이는 소형 버전과 확장 구성을 구분한다. 저장소는 이 소형 구성이 공개된 1억 타깃 실험에서 학습되지 않았다고 명시한다. 따라서 해당 파라미터 수는 비교 가능한 품질 결과로 제시해서는 안 된다.

공개 릴리스에는 아키텍처 코드, 연구 PDF, 별도의 속도 벤치마크가 포함돼 있다. 그러나 사전 학습 체크포인트, 토크나이저, 전체 평가 로그 및 보고된 결과를 독립적으로 재현하는 데 필요한 기타 학습 자료는 빠져 있다.

이러한 공개 범위는 원래의 헤드라인만으로는 알기 어려운 뉴스의 성격을 더 정확히 규정한다. 한 연구자가 초기 측정치를 갖춘 검토 가능한 아키텍처 제안을 공개했다. 측정치는 여전히 저자 보고 결과이며, 공개 패키지가 뒷받침하는 검증 범위는 완전한 학습 릴리스가 제공할 수 있는 수준보다 좁다.

독자에게 당장의 질문은 이 특정 절충안이 또 다른 실험을 할 가치가 있는지다. 모든 지표에서 이길 필요는 없더라도, 아키텍처가 연구 가치를 얻으려면 장점의 출처와 수반되는 단점을 보여주는 비교가 필요하다.

예측력이 더 약한 소형 모델도 엄격한 저장 공간 제한 아래에서는 유용해질 수 있다. 반대로 같은 예산에 맞춰 크기를 조정한 기존 모델은 그 장점을 없앨 수도 있다. 보고된 비교만으로는 이 선택을 해결할 수 없다.

따라서 GAP Transformer 실험은 통제된 평가의 출발점이다. 이는 별도의 어텐션 및 피드포워드 레이어가 불필요해졌다는 근거가 아니라, 테스트할 수 있는 구체적인 후보를 제공한다.

크기 예산을 선택하는 모델 설계자에게 압력이 쏠린다

핵심 경쟁은 동일한 자원 제한 안에서 유용한 품질을 제공하는 아키텍처들 사이에서 이뤄진다.

파라미터 감소는 누군가 제약된 결정을 내려야 할 때 의미를 갖는다. 메모리가 제한된 기기용 로컬 텍스트 완성 모델을 선택하는 가상의 개발자를 생각해 보자. 이 개발자에게 필요한 것은 출력 품질과 무관하게 가장 작은 모델이 아니라, 기기 한도 안에서 수용 가능한 제안을 제공하는 모델이다.

이런 환경에서 아키텍처 변경은 선택 가능한 대안을 개선할 때 가치를 얻는다. 더 작은 설계가 충분히 유용한 예측을 제공한다면, 저장 공간 절감은 품질 저하를 정당화할 수 있다. 사용자가 제안을 더 자주 거부한다면, 명목상의 효율 이점은 실질적 가치가 거의 없을 수 있다.

GAP은 어느 결과도 입증하지 못했다. 보고된 측정치는 배포된 애플리케이션의 수용률이 아니라 벤치마크에서의 언어 예측에 관한 것이다. 가상의 배포 사례를 입증된 활용 사례로 다루면 근거를 과장하게 된다.

따라서 직접적인 대상은 비교 실험을 실행할 수 있는 연구자와 개발자다. 기업 구매자와 일반 AI 사용자가 계획을 바꿀 이유는 더 적다. 여기에는 더 나은 어시스턴트나 문서 작업 흐름으로 곧바로 이어지는 검증된 제품 수준의 이점이 없다.

모델 설계자에게 요구되는 것은 방법론적 엄격성이다. 기존 아키텍처라고 해서 익숙하다는 이유만으로 비교 대상에서 영구적으로 제외돼서는 안 된다. 제안된 대안 역시 파라미터 절감이 구매 논거가 되기 전에 동등하게 엄격한 검토를 받아야 한다.

원래 Transformer 아키텍처는 어텐션 서브레이어와 위치별 피드포워드 네트워크를 갖춘 설계를 확립했다. 어텐션은 시퀀스 위치 전반의 정보를 결합한다. 피드포워드 네트워크는 각 위치의 표현을 변환한다.

이 구분은 GAP의 주장을 이해할 기준을 제공한다. 제안된 실험은 이러한 연산을 재배치해 더 적은 학습 값으로도 가치 있는 모델을 만들 수 있는지 묻는다. 어느 계산 방식도 더는 중요하지 않다는 점을 보여주는 것은 아니다.

공정한 제품 결정을 위해 설계자는 실제로 마주한 제약 조건 아래에서 모델을 비교해야 한다. 저장 공간 제약이라면 유사한 파라미터 예산에서 품질을 비교해야 한다. 응답 시간 제약이라면 의도한 하드웨어와 작업 부하에서 측정해야 한다.

이 비교들은 서로 다른 질문에 답한다. 작은 다운로드를 위해 선택된 모델은 낮은 응답 지연을 위해 선택된 모델과 다를 수 있다. 학습 실험은 파라미터 수가 더 적다는 사실만 보고해서 두 문제를 모두 해결할 수 없다.

이 차이는 팀이 평가를 문서화하는 방식에도 영향을 준다. 구성 세부 정보, 결과, 한계를 검색 가능한 지식 베이스에 보관하면 엔지니어가 원래의 가정을 잃지 않고 실험을 비교하는 데 도움이 될 수 있다.

실질적 함의는 크지 않지만 분명하다. 모델 크기가 중요한 경우 GAP은 연구 비교 목록에 포함될 만하다. 기존 애플리케이션에서 기존 모델을 대체할 만큼의 근거는 아직 제시하지 못했다.

공유 게이트 블록은 이름만이 아니라 비교 자체를 바꾼다

아키텍처의 핵심 질문은 게이트의 존재 여부만이 아니라 변환과 정보 경로의 배치에 관한 것이다.

게이트는 다른 표현을 조절하는 학습된 연산이다. 이 일반적 개념만으로 GAP을 고유하게 식별할 수는 없다. 과학적 질문은 게이트가 어떤 정보를 입력으로 받는지, 어떤 값을 변경하는지, 주변 블록이 정보를 어떻게 앞으로 전달하는지다.

공개된 GAP 블록 구현은 제안을 검토 가능하게 한다. 먼저 입력을 정규화하고 어텐션을 적용한 뒤 그 결과를 입력과 결합한다. 정규화는 안정적인 계산을 지원하기 위해 중간 표현의 크기를 조정한다.

그다음 블록은 결합된 표현을 정규화하고, 그 자체의 학습된 비선형 변환 결과를 곱한다. 출력 프로젝션은 원래 입력을 더하기 전에 이 곱셈 결과를 매핑한다. 프로젝션은 특징 표현 사이의 학습된 매핑이다.

반면 기준 구현은 어텐션 출력 프로젝션 뒤에 별도의 확장 및 축소 피드포워드 네트워크를 적용한다. 또한 덧셈과 정규화의 배치도 다르다. 이전 표현을 이후 계산에 더하는 잔차 연결은 정보가 변환을 우회할 수 있는 위치를 바꾼다.

따라서 GAP을 단순히 피드포워드 네트워크를 제거한 구조로 설명하면 남아 있는 학습된 변환을 놓치게 된다. 게이트를 추가한 기존 블록으로 설명해도 변경된 정보 경로를 간과하게 된다. 이 구현은 특정한 아키텍처 결정들의 조합을 제시한다.

이 조합은 완전한 설계로서 평가받을 가치가 있다. 그러나 완전한 설계 비교만으로 관찰된 결과를 일으킨 개별 결정이 무엇인지 자동으로 설명할 수는 없다. 파라미터 감소, 품질 변화, 다른 실행 패턴에는 서로 다른 원인이 있을 수 있다.

여기서 헤드라인의 겉보기 단순함은 연구 문제가 된다. 여러 구조적 선택이 함께 바뀌면 모델은 더 작아질 수 있지만, 블록 융합 자체가 최선의 절충안을 만들었다는 점까지 입증되지는 않는다. 게이트, 차원, 정규화, 정보 경로는 각각 별도로 조사해야 한다.

관련 선행 연구도 있다. 연구자들은 게이트 어텐션 연구에서 게이트 어텐션 유닛을 소개했으며, 이 연구는 “Transformer Quality in Linear Time”이라는 제목으로 출판됐다. 해당 연구는 다른 레이어 설계 안에서 게이팅과 어텐션을 결합하는 방식을 탐색했다.

그 존재는 직접적인 순위가 아니라 역사적 맥락을 제공한다. 공통된 용어가 동일한 방정식, 실험 조건, 성능을 의미하지는 않는다. GAP은 “gated”라는 단어만으로가 아니라 명시적인 구조 분석을 통해 해당 연구와 비교돼야 한다.

선행 연구는 새로움에 관한 질문도 더 구체적으로 만든다. 유용한 기여는 특정한 배열, 재현 가능한 자원 이점, 또는 유익한 실험 결과에서 나올 수 있다. 이전에 아무도 어텐션과 게이팅을 결합하지 않았다는 주장에 의존할 필요는 없다.

GAP Transformer 실험에서 가장 생산적인 다음 비교는 이러한 가능성을 분리하는 것이다. 연구자들은 차원과 학습 조건을 통제한 뒤 제안된 배열이 자원-품질 관계를 개선하는지 물어야 한다.

이러한 틀은 광범위한 개념에 선례가 있더라도 가치 있는 결과가 나올 여지를 남긴다. 또한 익숙한 구성 요소가 새로운 약어 아래 등장했다는 이유만으로 근거 없는 중요성을 얻는 것을 막는다.

컴파일러 결과는 별개의 성능 질문에 답한다

GAP을 컴파일해 얻은 속도 향상은 컴파일된 표준 Transformer보다 빠르다는 점을 입증하지 않는다.

저자의 게시물은 CPU 벤치마크에서 GAP20을 컴파일했을 때 학습 처리량이 약 19.9% 높아졌다고 보고한다. 처리량은 시스템이 일정 시간 안에 완료하는 작업량을 측정한다. 이 비교는 GAP20 자체의 컴파일 버전과 비컴파일 버전에 관한 것이다.

그 분모가 핵심이다. 독자는 매개변수 감소와 처리량 수치를 쉽게 결합해 GAP가 기준 모델보다 더 작고 빠르다는 주장으로 받아들일 수 있다. 하지만 보고된 컴파일러 비교는 그러한 결론을 뒷받침하지 않는다.

PyTorch의 컴파일러 문서는 PyTorch 프로그램의 실행을 최적화하는 시스템인 torch.compile을 설명한다. 성능은 워크로드에 따라 달라지며 컴파일 오버헤드도 포함된다. 따라서 최적화된 실행 경로를 측정하는 일은 아키텍처 질문과 함께 시스템 측면의 질문에도 답하는 것이다.

아키텍처 제안과 컴파일러는 생산적으로 상호작용할 수 있다. 특정 연산은 최적화 후 효율적으로 실행될 수 있다. 그렇더라도 이 가능성은 비슷한 수준의 최적화가 적용된 대안들과 비교해 검증해야 한다.

공정한 비교라면 동일한 하드웨어에서 동등한 컴파일러 설정으로 두 아키텍처를 실행해야 한다. 또한 워크로드를 맞추고 구성 차이가 있다면 그 이유를 설명해야 한다. 그렇지 않으면 결과에 아키텍처 효과와 실행 선택의 영향이 뒤섞인다.

이 구분은 학습 관련 의사결정에 중요하다. 연구자는 모델이 특정 품질 기준에 도달하는 데 걸리는 시간을 알고 싶을 수 있다. 모델이 처리한 각 타깃으로부터 덜 효과적으로 학습한다면, 높은 처리량만으로는 그 질문에 답할 수 없다.

배포에서는 또 다른 측정 기준이 필요하다. 학습 처리량은 사용자가 생성된 텍스트를 받기까지의 지연 시간을 보여주지 않는다. 또한 생성 중 메모리 사용량이나 동시 요청 상황에서의 성능도 입증하지 못한다.

또 다른 가상의 로컬 자동완성 애플리케이션을 생각해 보자. 한 모델은 학습 배치를 효율적으로 처리할 수 있지만 짧은 대화형 응답에는 거의 이점을 제공하지 못할 수 있다. 개발자는 개선된 경험을 주장하기 전에 실제 상호작용을 측정해야 한다.

컴파일 오버헤드 역시 의사결정을 바꾼다. 장시간 실행되는 워크로드는 시작 작업을 많은 연산에 걸쳐 분산할 수 있다. 자주 시작되는 애플리케이션은 이 비용을 다르게 겪을 수 있다. 벤치마크 보고는 이를 평균값 속에 숨기기보다 그 차이를 드러내야 한다.

반복 측정은 지속적인 이점과 일반적인 변동을 구분하는 데 도움이 된다. 중요한 질문은 문서화된 조건에서 같은 패턴이 여러 실행에 걸쳐 나타나는지다. 한 번의 유리한 측정만으로 사용자가 그 이점을 얼마나 신뢰성 있게 기대할 수 있는지는 입증할 수 없다.

그렇다고 컴파일러 결과가 무의미한 것은 아니다. 이는 확인할 가치가 있는 잠재적으로 유용한 실행 특성을 보여준다. 오류는 실험이 측정하지 않은 더 광범위한 주장으로 그 특성을 확대하는 데 있다.

현재로서는 매개변수 수, 예측 품질, 컴파일 처리량을 각각 별도의 문장으로 다뤄야 한다. 이를 하나의 효율성 점수로 결합하려면, 공개된 비교가 해소하지 못한 워크로드 우선순위에 관한 가정이 필요하다.

검증의 공백은 귀속과 재현에 관한 문제다

가장 강력한 비판은 어떤 설계 선택이 결과를 만들었는지, 그리고 다른 연구자가 그 측정을 반복할 수 있는지를 묻는다.

공개 연구 토론에서 저자는 GAP를 실험적이라고 명시적으로 설명한다. 게시물은 표준 Transformer가 더 우수한 성능을 보였다고 말하며, 전반적인 우월성을 주장하지 않는다. 이러한 신중한 표현은 이후 보도에도 유지되어야 한다.

thexylophone이라는 핸들을 쓰는 한 댓글 작성자는 모델 폭과 어텐션 차원의 변화가 아키텍처 주장을 복잡하게 만든다고 지적한다. 이 작성자는 정규화와 잔차 연결의 배치에도 의문을 제기한다. 권고는 각각의 변화를 분리해 검증하라는 것이다.

이는 공개 토론에서 나온 기술적 비판이지, 독립적으로 검증된 실험 결과는 아니다. GAP 설계에 가치가 없다는 점을 입증하는 것도 아니다. 다음 결과를 더 유익하게 만들 방법을 제시할 뿐이다.

개별 구성 요소를 바꾸거나 제거하는 어블레이션 연구가 이 우려를 해소할 수 있다. 연구자들은 주변 설정은 유지하면서 게이트, 정보 경로 또는 정규화 위치를 변경할 수 있다. 각 비교는 더 좁은 범위의 설명을 검증하게 된다.

목표는 인과적 귀속이다. 관련 차원을 맞춘 뒤에도 매개변수 이점이 유지된다면 아키텍처 해석은 더 강해진다. 더 단순한 기존 조정이 같은 절충안을 만들어 낸다면 설명은 달라진다.

두 번째 우려는 품질 비교 자체다. 더 작은 모델의 정확도 하락은 용량 감소에 따른 예상 가능한 결과일 수 있다. 새로운 배치를 정당화하려면 연구자들은 다른 크기 축소 방법과 비교했을 때 품질 손실이 유리한지 보여줘야 한다.

이는 단일 기준 모델을 결정적인 것으로 다루기보다 여러 기존 구성을 비교해야 함을 시사한다. 그러한 비교는 가능한 선택지를 지도처럼 보여줄 것이다. 그러면 GAP는 단지 다른 지점을 차지하는 것이 아니라 그 지도의 일부를 개선함으로써 주목받게 된다.

무작위성은 또 다른 불확실성을 만든다. 서로 다른 초기 조건에서 학습을 반복하면 관측된 관계가 지속되는지 알 수 있다. 그전까지 독자는 품질 차이의 정확한 크기에 얼마나 신뢰를 둬야 할지 판단할 수 없다.

재현의 경계도 마찬가지로 중요하다. 살펴볼 수 있는 아키텍처 코드는 다른 이들이 모델이 수행하는 연산을 검토할 수 있게 한다. 보고된 학습 결과를 반복하려면 그에 더해 데이터 처리, 학습 절차, 평가 설정 및 기록된 출력이 필요하다.

이는 서로 관련된 투명성의 형태이지만, 서로 다른 질문에 답한다. 독자는 벤치마크를 확인하지 않고도 방정식을 이해할 수 있다. 실행 가능한 모델은 원래 실험을 재현하지 않더라도 새로운 실험을 뒷받침할 수 있다.

텍스트 예측이 입증할 수 있는 범위에도 한계가 있다. 더 강력한 벤치마크 예측이 신뢰할 수 있는 지시 이행, 사실 회상 또는 특화된 애플리케이션에서의 유용한 행동을 자동으로 증명하지는 않는다. 이러한 역량에는 실제 요구사항에 맞는 평가가 필요하다.

따라서 회의적인 해석 역시 정확해야 한다. GAP에는 조사할 가치가 있는 초기 자원-품질 절충안이 있지만, 그 절충안의 원인과 재현 가능성은 아직 해결되지 않았다. 이 연구를 검증된 대체안이나 무의미한 실패라고 부르는 것은 모두 현재 증거를 넘어선다.

다음 업데이트를 더 유익하게 만들 세 가지 결과

다음으로 유용한 이정표는 더 큰 헤드라인 비율이 아니라 더 강력한 비교 증거다.

첫 번째로 살펴볼 신호는 독립적으로 반복 가능한 학습 및 평가 패키지다. 데이터 준비, 토크나이저, 구성, 학습 절차, 평가 출력을 연결한 공개 자료가 있다면 다른 이들이 보고된 비교를 점검할 수 있다. 독립적인 일치 결과는 초기 결과에 대한 신뢰를 높일 것이다.

연구자들이 원인을 추적할 수 있다면 불일치 역시 유익한 정보가 된다. 서로 다른 전처리나 평가 설정은 벤치마크가 측정하는 대상을 바꿀 수 있다. 이러한 차이를 해소하면 더 유리한 점수를 내지 못하더라도 연구 기록이 개선된다.

이 신호는 확장보다 먼저 검증에 관한 것이다. 기반을 점검 가능하게 만들지 않은 채 실험을 확장하면 불확실성이 커질 수 있다. 규모는 작더라도 재현 가능한 결과가 어떤 대규모 실험에 자원을 투입할지 결정하는 더 단단한 기반을 제공한다.

두 번째 신호는 크기를 조정한 기존 모델과의 통제된 비교이며, 구성 요소 어블레이션이 함께 이루어져야 한다. 중요한 질문은 제안된 블록이 비교 가능한 예산 안에서 더 유용한 예측 품질을 보존하는지다. 이 비교는 핵심 아키텍처 주장을 직접 검증한다.

GAP가 이러한 통제 조건 전반에서 유리한 성능을 보인다면 그 배치에 대한 근거는 더 강해진다. 기존 모델의 크기 조정이 이를 따라잡는다면 초기 결과는 대신 구성 선택에 관한 증거가 된다. 어느 결과든 불확실성을 줄인다.

이 단계에서는 겉으로 보이는 절충안이 반복 학습 실행에서도 유지되는지도 다뤄야 한다. 안정적인 패턴은 고립된 결과보다 더 높은 신뢰를 정당화한다. 순위가 불안정하다면 더 폭넓은 결론에 앞서 실험에 더 강력한 측정이 필요하다는 뜻이다.

세 번째 신호는 실행 속도를 정의된 애플리케이션 요구사항과 연결하는 성능 연구다. 동등한 최적화 조건에서 두 아키텍처를 비교하고, 시간 측정과 함께 관련 품질을 보고해야 한다. 그러면 컴파일러 관찰 결과가 누군가 실제로 내려야 하는 의사결정과 연결된다.

학습 워크로드에서는 지정된 품질 수준에 도달하는 일이 관련 결과일 수 있다. 대화형 애플리케이션에서는 응답 지연과 메모리 사용량이 더 중요할 수 있다. 벤치마크는 승자를 제시하기 전에 그 선택을 명시해야 한다.

이러한 조건에서 일관된 이점이 확인된다면 실용적 근거는 더 강해진다. 기준 모델에 동등한 최적화가 적용된 뒤 이점이 사라진다면 주장은 원래의 실행 설정으로 제한된다. 어느 발견이든 기존 비율을 반복하는 것보다 더 유용하다.

이러한 발전에 대한 검증된 일정은 없다. 향후 몇 달간 독자는 확장이나 재현이 이미 진행 중이라고 가정하기보다 구체적인 공개 자료와 독립적으로 보고된 측정 결과를 찾아야 한다.

GAP Transformer 실험을 지켜보는 이라면 원래 주장을 실험 조건과 함께 유지해야 한다. 어떤 절충안이 자신의 워크로드에 중요한지 결정하기 전에 예측 품질, 모델 크기, 측정된 실행 시간을 각각 따로 비교하라. 향후 업데이트에서는 빠진 통제 요소, 즉 반복 가능한 학습, 크기를 조정한 기준 모델과의 비교, 동등한 컴파일러 처리를 확인하라. 아키텍처 평가 기록을 관리한다면 각 결과가 무엇을 측정하고 어떤 질문이 여전히 열려 있는지 기록하라. 이 습관은 유망한 소규모 실험을 근거 없는 배포 권고로 바꾸지 않으면서 더 쉽게 평가하게 해 준다. 어떤 결과가 가장 먼저 당신의 결정을 바꿀까? 반복 가능한 품질, 더 나은 크기 비교, 아니면 실제로 사용하는 하드웨어에서 측정한 성능일까?

 
 

무료로 시작하세요

개인 지식 관리 기능을 갖춘 로컬 우선 AI 어시스턴트

더 나은 AI 경험을 위해

현재 remio는 Windows 10+ (x64) 및 M-Chip Macs만 지원합니다.

업무를 위한 AI 파트너
remio와 더 많은 일을 해내세요

계획하고, 만들고, 완성하세요
모든 일을 한곳에서

bottom of page