openllm leaderboard도 누가 자꾸 experiment-xx 이렇게 올리길래 안본 지 꽤 됐는데

정말 리더보드 꼭 필요한 것인데...감사합니다

여기서 1등이 대한민국 1등이다.

선생님 늅늅이 질문하나 드려도 될까요? 이전 리더보드에 있던 모델들을 우바부가에서 로드하려하니 대부분 로드가 불가하더라구요... 4080 사용중인데 찾아본 바로는 VRAM이 부족해서 그런걸로 보이긴 해서, 양자화된 한국어 LLM 모델을 찾아보려하니 정보가 영 없더라구요.... 혹시 추천해주실만할 모델이 있을까요?

orion모델은 만들어주신 평가지표로 몇점 나오는지 궁금하군요.

멋지십니다.. gpt4랑 하이퍼클로바x가 상위권인건 역시 자본의 힘이 대단하긴 하네요. 그와중에서도 오픈소스로 거기에 필적할만한 모델을 만든분들도 대단하구요

고생하셨습니다.. 선생님.. 솔라 미니도 api 제공되던데 성능이 궁금합니다..

한국어 모델 리더보드는 돈이 크게 걸려있는거 같네요. (투자금)
점점 어떤 데이터가 좋게 나오더라는 식으로 가서 점수가 잘 나오는 방향으로  
검증 데이터에 가까운 dataset 이 구성되지 않을까 조심스레 생각해봅니다.

좋은 평가기준 제시해 주셔셔 감사합니다.

llm 리더보드 먹고있는 solar 시리즈들 써보면 너무 형편없었는데 속이 시원하군요.

와 깜놀! 끝내 줍니다!

리더보드 측정 시 동작하는 모델들은 양자화를 사용해서 로드 하지는 않죠?

저도 사람이 하는 평가를 GPT4로 대체하여 여러가지 성능 평가를 해봤습니다
근데, GPT4가 GPT3.5나 4가 생성한 답변을 더 좋다고 평가하는 경향이 있는거 같습니다
예를들어 사람이 보기에는 GPT4보다 믹스트랄이 생성한 답변이 더 좋다고 보는데 GPT4한테 평가를 시키니 GPT4 답변이 더 좋다고 하더군요

이런 경향에 대해 어떻게 생각하시는지 궁금합니다!

솔직히 리더보드 의지해서 파인튜닝해도 뭔가 몬가였는데..... 저만 그런건 아니었나보네요 ㅎㅎ

개인적인 체감으로는 gpt-4보다 오히려 mixtral과 더 유쾌한 대화를 하고 있는데 돌이켜보면 이건,
검열에 대한 반감때문일수도 있다는 생각입니다.
가장 답답해 죽을 거 같았던건 클로바x였는데요. 도무지 어떤 대화도 할수가 없다는 느낌이었어요. 뭐만하려고 하면 벽을 만났거든요.
그러니까 세련된 태도로 어떠한 질문이든 하라고 하면서
막상 질문을 하면 그 안에 어떠한 의견도 없는 상투적인 대답을 아주 세련되게 하는 사람같았습니다.
한국말을 문제없이 하긴하는데, 진짜 AI처럼 정이 가지 않는 사람.
대화를 계속하고 싶은 마음을 차단해버리는 사람같은.

리더보드 최상위권 모델들 대부분은 진짜 성능 심각합니다. 신뢰도 바닥이 아니라 그냥 신뢰도가 이제 없음 ㅋ

아이디를 안보다가 다시보니 여기에서 활동하셨군요! 저도 몇몇회사들은 오픈도 안되서 검증이 안되는 (페이퍼 런칭이 의심되는) 기사를 내거나, 아니면 점수로도 거의 차이가 안나는데 몇등했다 기사 올라오는걸 보고 많은 분들과 마찬가지로 피로도가 높은 상황이였을것 같습니다.
정부 주도가 아닌 오픈계열로 대안이 나와서 여러모로 실 사용자 입장에서 도움이 되는 역할을 해 주셔서 감사합니다 ㅁㅁ!

영어권에서도 비슷한 문제가 심해서 이러한 (풍자) 논문도 나왔지요.
Pretraining on the Test Set is All You Need (유일하게 필요한 것은 테스트 데이터에 학습을 시키는 것이다.)

이렇게 좋은 리더보드를 만들어주셔서 우선 감사드립니다. 저도 기존의 리더보드의 솔라 모델을 사용하여도 성능이 좋지 않길래 무슨 이유인지 궁금했는데, 드디어 궁금증이 풀렸네요 ㅎㅎ

이번에 제가 파인튜닝을 한 모델을 평가해보려고 깃허브를 참고해서 모델 평가를 실행했는데, cuda out_of memory가 뜨는 이유가 무엇일까요? 일단 지금 자원 상태는 a100-80gb 8장인데, 메모리 부족이 뜨는 이유를 잘 모르겠습니다. 혹시라도 이유를 알려주신다면 감사드립니다.

아래는 오류 문장입니다.
torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 1.18 GiB. GPU 0 has a total capacty of 79.15 GiB of which 843.75 MiB is free. Process 474753 has 4.70 GiB memory in use. Including non-PyTorch memory, this process has 73.61 GiB memory in use. Of the allocated memory 72.88 GiB is allocated by PyTorch, and 80.17 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF