6회차 받아쓰기

Attendees 1 00:01 안녕하세요. 혹시 다들 들리시나요?

Attendees 1 00:08 네 오프라인에 계신 분들은 마이크와 스티커 우리 다 꺼주시면 될 것 같고 네 다들 연휴 잘 지내셨는지 모르겠습니다. 저는 지난주에는 독감에 걸려서 좀 고생을 많이 했는데 다행히 좀 쉬고 또 연휴가 있어가지고 몸은 이제는 다 나은 것 같아요. 날씨가 굉장히 추운데 다들 건강 조심하시고 오늘 강의 시작하도록 하겠습니다. 일단 저희가 지금까지 어떤 계획으로 어디까지 왔는지에 대해서 잠깐만 다시 한 번 리캡을 하고 또 오늘 내용으로 들어가도록 하겠습니다. 이번이 여섯 번째 주고요. 그리고 지난 주까지 해서 제가 지난번까지 해서 다섯 차례에 걸쳐서 저희가 파이토치 내부에 대해서는 특정 카피틀에 대해서는 꽤 상세하게 다뤄 봤고요. 그래서 저희가 이 파일 조치에 대해서 상세하게 보는 것은 지난주 지난번으로 마지막 으로 랩업을 하고 그리고 이번 주에는 파이토치만 그럼 가지고 되는가 파이토치 외에 또 어떤 것들이 필요한가라고 하는 부분들에 대해서 간략하게 이 오버뷰를 하려고 하고요.

Attendees 1 01:28 그리고 이렇게 해서 이제 소프트웨어에 대한 이야기는 마무리를 하고 다음 번에는 이 CPU와 GP와 MPU 비교를 하면서 그리 MPU라고 하는 게 왜 탄생을 했는지 아키텍처적으로 어떤 특성을 가지고 있는지에 대해서 좀 이야기를 나눠볼 생각이고 그리고 이제 리벨리온의 MP와 저희가 파이토치를 어떻게 붙이고 있나라고 하는 걸 마지막으로 해서 원래 이제 생각을 했던 강의는 마무리를 하려고 생각을 하고 있습니다. 그 이후에 어떻게 할지는 제가 요즘에 업무가 바빠가지고 고민을 많이 못 했는데 다음 주나 아니면 그다음 주에 다시 공유를 드리도록 하겠습니다.

Attendees 1 02:09 오늘 제가 제목을 비온디 파이토치라고 말씀을 드렸는데요. 당연히 뭔가 파이토치보다는 뭔가를 준비를 하고 해야 되기 때문에 그런 제목을 아마 달았겠죠 오늘 이제 가지고 있는 코스는 뭐냐 하면은 특히 이제 리벨리온이나 아니면은 또 여기 지금 강의에 참여하고 계신 다른 분들께서 다니시는 이런 AI 반도체 회사들 관점에서는 이런 개발 환경으로 파이토치만 그러면 지원하면 되는 건가? 라고 하는 질문을 한번 드려보고 싶고요. 특히 이제 저희처럼 출원에 특화된 AI 반도체 회사가 어떤 것들을 준비를 더 해야 되는지 라고 하는 그런 측면에 대해서 고민하는 그런 내용들을 오늘 공유를 해 보려고 합니다. 일단은 성능이 가장 중요한 이슈라고 생각을 하면 그러면 이제 어떤 성능 측면에서 어떤 문제들이 있는지에 대해서 먼저 저희가 좀 고민을 해야 되고 그런 이슈들을 어떻게 해결할 수 있냐라고 하는 것들에 대해서도 이야기를 좀 나눠봐야 될 것 같고요.

Attendees 1 03:07 그러면 그런 이슈들을 개발자들이 잘 해결하기 위해서는 그런 파이토치만 가지고 충분히 해결을 할 수가 있는가 아니면 이 외에 보조적인 다른 개발 환경이 필요할까 이런 질문들에 대해서 답을 하면 다행스럽게 오늘 저희가 하려고 하는 주제들을 다 다루게 될 것 같습니다. 일단은 답부터 좀 말씀을 드리면 이건 일단 제 개인적인 생각이기도 하지만 제 생각에는 크게 틀릴 것 같지는 않고 다만 많은 분들이 다 비슷비슷하게 생각하실 것 같은데 LM 출원 관점에서만 본다 하더라도 이 파이토치는 전체 큰 그림의 사실 일부라고 볼 수가 있고요. 매우 중요한 일부긴 하죠. 그러니까 이런 전체적인 생태계의 구심점이 파이토치 이고 또 저도 그렇게 생각을 하긴 하지만 파이토치만 가지고 모든 게 내는 건 아니고 일단 저희가 오픈 소스로 잘 활용을 하고 있는 남마라든지 또 최근에

Attendees 1 04:03 크게 이슈가 된 그런 딕스이라든지 하는 공개되어 있는 이런 프리트레이드 램이라고 하는 것도 전체 증상에서 보면 굉장히 중요한 그런 환경 중에 하나라고 생각을 할 수가 있고 이것들이 배포가 되는 허딩 페이스 중심의 이런 배포에 관련되어 있는 기술들도 굉장히 중요하고요. 파이토치는 물론 또 중요하고 하지만 성능이라고 하는 것에 초점을 맞춰 봤을 때에도 파이토치만으로는 해결되지 않는 그런 굉장한 부분들이 있어서 포널 프로그래밍도 필요하고 그다음에 더 하이 레벨의 이런 서빙 최적화도 같이 필요합니다. 이런 모든 것들을 다 갖추고 있어야지 개발자들이 LM 추론을 성능을 잘 낼 수가 있기 때문에 그런 의미에서는 파이토치 외에 다른 것들도 다 잘 갖추고 있어야 하겠죠

Attendees 1 04:58 이런 관점에서 오늘 이제 아젠다를 제가 좀 정리를 해 봤는데요. 일단 처음에는 ll 인플루언스가 가지고 있는 성능 문제들에 대해서 조금 저희가 고민을 해 보고 그 그런 문제들을 해결하기 위해서 사람들이 어떤 기술들을 개발을 해 왔는지라고 하는 것들을 좀 커버를 한 다음에 이런 것들을 해결하기 위한 그런 실제적으로 사람들이 사용하는 기술로 커널 프로그래밍 그다음에 서빙 최적화를 위한 그런 프레임워크들 이 두 가지 타픽을 좀 다뤄보려고 하고 있습니다. 오늘은 코널 프로그래밍을 어떻게 하는가 그다음에 쿠다는 어떻게 생겼나라고 하는 것보다는 왜 이런 것들이 이제 필요한가라고 하는 것들에 대한 모티베이션 관점에서 좀 더 이야기를 많이 드리게 될 것 같아요. 실제 코다나 이런 것들에 대한 기술은 저보다도 아마 더 잘 알고 계신 분들이 많이 계실 거라고 생각하고 또 인터넷에 보면 또 좋은 자료들이 굉장히 많기 때문에 그런 자료들을 참고를 하시면 될 것 같습니다.

Attendees 1 06:01 일단 LM을 하니까 일단 가장 기본적인 내용부터 먼저 시작을 해보면 좋을 것 같은데요. 일단 LM 자체가 가지고 있는 어떻게 보면 가장 중요한 것 중에 하나가 어텐션 어텐션 중에서도 실퍼 어텐션이라고 할 수도 있고요 슬퍼 어텐션이 어떤 건지라고 하는 것들에 대해서는 자세히 말씀드리지 않고 됐지만은 실제 이거를 이제 계산을 한다라고 하는 측면에서 봤을 때에는 이제 스케일이 다 프로덕트라고 하는 것들이 이제 셀퍼 텐션에 가장 중요한 연산이라고 생각을 할 수가 있는데 왼쪽 그림에 있는 것처럼 이렇게 문장이 주어졌을 때 그 문장들 사이에 있는 관계에 의해서 어떤 단어들이 어떤 의미를 가지고 있는지라고 하는 것들을 이 문장 내에서 더 명확하게 추출을 해 나가는 과정이 스 어텐션이라고 생각을 할 수가 있고요. 그거는 뭐 다들 아시는 것처럼 KBQ라고 하는 세 가지의 값을 가지고 조작을 해가지고 그런 과정들을 하게 되는데 어텐션이라고 하는 것은 각 단어들 사이에 있는 그런 연관성에

Attendees 1 07:01 얻는 의 크기라고 생각을 하면 되고 그 크기를 KVQ 값을 곱해 가지고 누적을 해서 더하면 스크립트uct 계산을 하게 되면 그럼 특정 단어에 실리퍼 디렉션이 반영이 된 그런 새로운 그런 표현이 만들어지게 됩니다. 제가 깊게 이야기를 하지는 않겠지만 실제 오른쪽 그림에서 몇 가지 저희가 계산 측면에서 재미있는 포인트들이 있는데 하나는 실제 KQV가 원래 맨 처음에 주어진 단어들의 임베딩으로부터 계산이 되는데 이 과정 자체는 병렬적으로 저희가 뽑아낼 수 있는 과정이고요. 그렇게 된 후에는 특정 단어에 대해서 이제 가중치가 더해져 있는 새로운 임베딩 값을 찾기 위해서 곱한 다음에 그러니까 kv 값을 곱한 다음에 거기에 이제 v를 적용을 하게 되는데 그 중간 과정에 이 소프트맥스가 들어가고 그 소프트맥스를 통해서 전체적인 그런 분포들을 다시 한 번 노멀라이즈를 하게 된 다음에 그걸 이제 다시 합쳐서 새로운 그런 프레젠테이션을 만들게 됩니다.

Attendees 1 08:07 여기에서 보면 저희가 지금 새로운 프레젠테이션을 만들고자 하는 그 단어의 쿼리가 다른 모든 케이드와 곱해지는 과정이 있고 그 곱해진 qk 값을 소프트맥스를 거친 다음에 이제 VR 곱해서 모든 단어를 거기에 더하게 되면 새로운 임베딩을 찾을 수가 있게 되죠. 맨 밑에 있는 부분들은 각각 단어별로 다 병렬로 처리가 가능하지만 이제 그 위에 있는 부분은 서메이션도 해야 되고 그다음에 소프트 엑스 같은 경우에는 실제 전체 분포를 다 보고 이제 처리를 해야 되기 때문에 명렬로 처리하기가 좀 까다로운 그런 부분들이 있습니다. 네 이런 계산적인 특징을 가지고 있고요 또 다른 하나의 특징은 커설이냐 그다음에 커설이 아니냐라고 하는 이런 특징들이 있는데 지금 제가 여기서 왼쪽 그래프 이전 슬라이드에서 사용했던 슬라이드 같은 경우에는 넌 코자이고요. 그러니까 it 이라고 하는 단어는 보면 어텐션을 이 단어 앞에 있는 그런 단어들 그다음에 그 이후에 있는 단어들을 가지고 모두

Attendees 1 09:12 구하도록 되어 있죠. 하지만 이제 오른쪽에 있는 그림에서는 이제 커절이라고 왼쪽에 그러니까 먼저 나온 단어들로부터만 어텐션을 받도록 되어 있고요. 넌 커절이냐 퍼절이냐에 따라서 실제 이제 계산을 한 패턴 같은 경우에는 굉장히 크게 달라지는데 그러니까 뉴럴 네트워크 자체의 구조 자체가 굉장히 많이 달라지는데 GPT가 나온 이후로는 네 커드 어텐션만으로도 충분히 성능을 잘 낼 수 있다라고 사람들이 생각을 해서 아마 지금 나오는 거의 대부분의 에덴은 다 오토로 이그레시브 커다 어텐션을 쓰고 있는 것으로 알고 있습니다. 디코드오니 LMM 같은 경우에는 결국에 이제 하는 일이 주어진 단어들로부터 그다음 단어를 예측을 하는 일을 계속 반복을 하는 건데요.

Attendees 1 10:02 네 그래서 일단은 그걸 먼저 트레이닝을 하는 프리 트레이닝 과정이 있고요. 그 프리트레이닝에서 하는 거는 정말 말 그대로 n개의 단어가 주어졌을 때 그 다음 단어가 무엇인지라고 하는 것들을 굉장히 많이 반복을 해서 제 계산을 하게 되죠. 그렇게 해서 실제 트레된 웨이트를 구하면 그걸 디코드하는 과정에서는 프럼트가 주어지면 그 프럼트에 대한 답을 쭉 뱉어내는 그런 과정으로 저희가 모델을 설계를 하고 그 프롬트가 주어졌을 때 그 프롬트를 처리를 하는 크리스셀이라고 하는 과정도 그 프리필을 가지고 코드를 시작을 해서 문장이 끝날 때까지 계속 반복해서 단어를 생성을 해내는 그런 디코드라고 하는 그런 과정으로 나누게 됩니다. 플렉실과 디코드는 한 큰 모델의 일부라고도 생각도 할 수 있긴 하지만 또 어떤 관점에서 봤을 때에는 웨이트를 셰어하고 있는 두 개의 다른 모델로도 생각을 할 수가 있거든요. 실제 계산이 일어나는 특성이라든지 하는 것들이 프리필과 리코드가 다르기 때문에

Attendees 1 10:59 저는 개인적으로는 그냥 웨이트가 피어가 되는 그냥 별도의 두 개의 모델이라고 생각을 합니다. 각 회사마다 접근법이 다르긴 하겠지만 이 리벨 내용 같은 경우에도 이 트리플과 디코드는 실제 두 번 컴파일을 해서 별도의 바이어를 만들어가지고 사용을 하고 있습니다. 물론 이제 웨이트는 시도를 하지만요 혹시 제가 너무 빠르게 이야기를 했을까요? 다들 잘 알고 계시는 것 같아 가지고 제가 좀 빠르게 진행을 했는데 혹시 질문이 있을까요? 지금 단계에서

Attendees 1 11:40 네 제가 이제 계속 이야기를 하고 그다음에 프리스필리가 디코드 이야기를 하는 이유는 실제 이런 것들이 어떻게 동작하는지라고 하는 것보다는 이런 프리페이가 디코드가 가지고 있는 계산적인 특징이 어떻게 다르냐라고 하는 것들을 이야기를 하기 위해서 쭉 이야기를 했는데요. 이 실제 저희 프리필을 하고 그다음에 기코드를 하는 과정을 시간치로 놓고 쭉 펼쳐보면 이렇게 생겨 있어요. 맨 처음에 모델을 로딩을 하고요. 그런데 이제 모델은 계속해서 로딩을 하지 않기 때문에 일단 처음에만 로딩을 하게 되겠죠. 그리고 첫 번째 토큰을 만들어내는 과정까지가 이제 프리필이라고 생각을 하면 되고 이 과정에 많은 부분들은 실제 그 프로필을 이해를 하는 과정이라고 저는 입성 쪽으로는 생각을 하고 있고요. 그래서 이제 이제 프론트를 이해를 하고

Attendees 1 12:31 첫 번째 단어를 만들어내면 그다음부터는 계속해서 하나 하나 단어씩 만들어서 만들어내서 이제 문장이 끝날 때까지 반복을 하게 되죠. 이 과정이 실제 답을 만들어내는 과정입니다. 실제로 LM LM 추론의 성능을 이야기를 하는 여러 가지 지표들이 있는데 그중에 중요한 것 중에 하나가 타임트 퍼스트 토큰이라고 하는 그런 용어가 있는데 이 타임트 퍼스트 토큰은 이 프리스이 얼마큼 빠르게 되는가를 나타내는 그런 용어라고 생각을 하시면 되고 그다음에 TPS라고 하는 표현이 있는데 그러니까 토큰 퍼 세컨드라고 하는 표현이 있는데 이 토큰 퍼 세컨드는 그 이후에 디코드 과정에서 생성되는 이 한 스텝들마다 얼마큼 시간이 걸리는가라고 하는 것을 TPS라고 표현을 하죠. 이 TPS 매 토클마다 새로운 토큰을 만들어내긴 하지만 그 과정은 정말 똑같거든요. 같은 모델을 그냥 쭉 돌리는 과정 이죠. 하지만 달라지는 것들은 그 슬퍼 텐션을 반영을 해야 되는 그 전에 있는 문장들이 사실은 다르기 때문에

Attendees 1 13:35 그렇다는 이야기는 이론적으로는 인플런스를 한 번 하면 할 때마다 더 많은 예산을 처리를 해야 돼서 TPS 자체는 두 번째 제너레이션 할 때보다는 세 번째 네 번째로 넘어갈수록 시간이 더 자연스럽게 많이 걸리게 되어 있습니다. 네

Attendees 1 13:55 이거 저희가 약간 계산적인 측면에서 조금 더 자세히 한 번 더 한번 보고 싶은데요. 일단 프리핀하고 디코드하고 실제 약간 줌 아웃을 해가지고 기제 내부에서 일어나는 일을 보게 되면 일단 디코드가 좀 더 이해하기 쉬울 것 같아서 디코드를 먼저 하면 디코드는 그 전에 있는 모든 단어들에 대해서는 이미 생성이든 이해든이라고 하는 게 끝나 있는 거고 이제 새로 지금 막 만들어놓은 단어를 가지고 그다음에 그다음 단어를 이제 예측을 하는 과정을 하면 되는데 그 과정에서는 일단 그 마지막 그 맨 마지막 단어로 모여 있는 이제 맨 마지막 단어에 모여 있는 모든 어텐션을 다시 다 계산을 하게 되죠. 예 그래서 이제 셀퍼 어텐션을 계산을 하게 되고 그다음에 이제 리니어 필터를 거쳐서 이제 클래스피케이션을 하게 되면은 그럼 실제 저희가 선택하는 단어가 모이게 됩니다.

Attendees 1 14:56 이 과정이 매 단어마다 반복이 되는 거고 그 단어마다 반복이 될 때 아까 말씀드린 것처럼 이미 철회한 혼이 늘어나니까 점점 더 많은 단어들을 계속해서 철회를 해야겠죠. 네 이게 이제 디코드에서 일어나는 과정이고요. 그다음에 프리필에서 일하는 과정은 개념적으로는 상당히 비슷할 수 있어요. 어쨌든 간에 아까 말씀드린 것처럼 디코드 우리 LM 같은 경우에는 딱 할 수 있는 일이 단어들이 주어지면 그 단어들의 다음 단어를 예측을 할 수 있는 것 밖에 없거든요. 그래서 그거는 플레핀이나 디코드나 원천적으로는 똑같은 과정을 하게 되는데 프르필에서는 다만 뭐가 다르냐면 이미 엔게의 단어가 주어져 있고 그 엔게의 단어들에 대해서는 MG의 단어들을 처리하는 과정에서는 그 단어들이 어떤 단어들인지 예상을 할 필요는 없는 셈인 거죠. 그러니까 예를 들어서 두 번째 단어인 아라고 하는 단어를 처리를 하는 데 있어서

Attendees 1 15:55 거기서 처리를 하는 데 있어서 유라고 하는 단어로부터 어떤 단어가 실제 만들어지는지 라고 하는 프리스 과정에서의 아라고 하는 두 번째 단어를 처리를 하는데 인풋이 되지는 않습니다. 말이 잘 전달이 됐는지 잘 모르겠습니다. 디코드는 좀 달라요. 디코드는 지금 이 그림에서는 한 토큰을 만들어내는 과정만 그려져 있는데 예를 들어서 그 그다음 단어를 또 한 번 제너레이션을 해야 된다라고 한다면은 그다음 단어는 첫 번째 단어가 생성이 끝나야지만 사실 시작을 할 수가 있겠죠. 왜냐하면 새로운 토큰이 만들어지면 그 만들어진 새로운 토큰까지 반영을 해서 그다음 토큰을 예측을 해야 되니까 첫 번째 토큰이 뭔지를 알아야지 그다음 토큰을 예측을 할 수가 있죠. 그래서 디코딩 과정에서 매 토큰마다 그 전 토큰이 처리가 다 끝나야지만이 그다음 토큰을 처리를 해야 되는 거고 결국에 이제 시퀀셜하게 토큰들을 처리를 할 수밖에 없는데 플리핑 하는 과정에서는 여기 있는 이라고 하는 단어들이 들어왔을

Attendees 1 17:05 a라고 하는 단어를 처리를 할 때 you라고 하는 단어에 next 토큰을 뭐라고 프로젝트를 할 건지 이미 그 다음 단어는 사실 아로 정해져 있기 때문에 그것과 상관없이 저희가 프리트 과정을 처리를 할 수가 있거든요. 네 그래서 UI 풀 채봇이라고 하는 모든 단어를 다 동시에 처리를 해도 무가능하죠. 네 동시에 처리를 하는 게 무방하다고 하는 거는 그 전 단어들이 그다음 단어에 영향을 전혀 준다고 하는 건 아니고요. 토큰을 처리하는 것들이 오른쪽으로 계속 이제 영향을 주기는 하지만 유라고 하는 단어가 실제 모든 레이어들을 다 타고 끝나서 만들어진 최종 아웃풋 자체가 그다음 토큰을 처리하는 데 있어서 이렇게 되지 않기 때문에 모든 단어들을 다 병렬로 맨 첫 레이어부터 차근차근 시작을 할 수가 있습니다. 네 질문이 있어서 일단은 질문이 꽤 많이 셨네요 제가 네 일단은 그럼 여기서 잠깐 멈추고 질문을 좀 답을 해보도록 하겠습니다.

Attendees 1 18:10 네 트랜스포머의 디코드와는 다른 아키텍처인가요? 트랜스포머의 디코드만으로 그러니까 트랜스포머 자체가 디코드만으로 되어 있다라고 생각을 하면 될 것 같습니다. 그리고 프로필과 디코드를 두 개의 모델로 만든다면 트랜스포머랑 유사한 것 같습니다. 네 제 생각에는 그렇지 않은 것 같아요. 네 그렇지는 않고 프리필드랑 디코드가 다른 거는 제가 지금 말씀드린 것처럼 콘드를 처리하는 데 있어서 그전에 있는 단어들을 병렬로 한꺼번에 처리를 할 수 있느냐 없느냐의 차이가 있어서 저희가 사실 그거의 그 특성에 따라서 개념적으로 두 개의 모델로 만드는 것처럼 생각을 하는 거지 이게 인코더랑 디코드로 구성이 돼 있는 거와는 저는 좀 다른 것 같다고 생각이 듭니다. 동석님이 네 동석님이 설명을 잘 해 주신 것 같고요. 그다음에 양 님께서 플플이나 디코드가 웨이트는 싫어하지만 구조가 다르다고 했는데 네 지금 제가 설명하고 있는 부분이 바로 이런 부분인데요.

Attendees 1 19:17 이제 조금 더 뒤에서 이야기를 하긴 하겠지만 프로필과 디코드가 방금 말씀하신 것처럼 여러 개의 토큰들을 처리를 하는 그런 과정에서 나타나는 병렬 가능성의 양상이 다르기 때문에 실제 처리를 하는 그 연산 자체를 다른 구조를 가지고 갈 수가 있죠. 리벨 이용에서 각각 두 번 컴파일을 한다고 했는데 컴파일러에 다른 옵션을 줘서 컴파일이 다르게 동작하도록 유도한다는 말씀이신가요? 컴파일러에 다른 옵션을 주는 게 아니라 실제 프리필과 디코드에 생성되는 계산 자체가 다를 수가 있죠. 예를 들어서 배치 사이즈가 다르다든지 나는 지금 말씀드린 것처럼 각각의 토큰을 벽렬로 처리를 할 때 각 토큰의 스프레이필드에서는 한 토큰의 행성 그러니까 첫 번째 토큰에 의해서 생성되는 토큰이 두 번째 토큰에 전달될 필요가 없기 때문에 그런 실제적인 계산의 모양 자체가 다르게 되는 셈인 거죠. 프리핀에서 화살표는 어텐션을 의미를 하는 건가요? 네 여기서 이 화살표에서는 어텐션을 의미를 한다고 생각하시면 됩니다.

Attendees 1 20:19 네 좋은 질문 드리셨고요. 네 아무튼 다시 강조를 드리지만 프래필과 디코드에서는 이런 여러 개의 토핑들이 주어졌을 때 이것들을 어떻게 처리를 하느냐라고 하는 방식 자체가 다르다라고 하는 것들을 말씀을 다시 한 번 들었습니다. 그래서 이제 이 그림으로 제가 다시 한 번 설명을 해보려고 하는데요. 왼쪽이 프리필리고 오른쪽이 이제 디코드라고 한다면은 i like my tip alot이라고 하는 단어에서 i like my c이 예를 들어서 실제 프럼트로 들어왔고 이 프롬트에서 alot 두 단어가 생성이 된다라고 생각을 하면 일단 왼쪽에 있는 프리필을 하는 부분에서는 i이와 라이크와 마이와 패스를 모두 다 처리를 하긴 하는데 이 그림에서 보면은 i에 의해서 만들어진 최종 아웃풋이 라이크로 들어가지 않아요. 왜냐하면 아까 말씀드린 것처럼 이미 라이크라고 한 단어는

Attendees 1 21:17 이미 정해져 있는 단어이기 때문에 그전에 만든 토큰이랑 연관을 굳이 시킬 필요가 없겠죠. 라이크와 마이 사이에서도 똑같은 그런 관계가 있겠죠. 하지만 팩과 a 관계에서는 순차적인 그런 디널스가 있겠죠. 왜냐면 캡으로부터 결국에는 얘를 제너레이션을 해야 되는 거고요. 그다음에 이 a라고 하는 단어를 반영을 해서 그다음 단어를 만들어야 되기 때문에 실제 저희가 디코드라고 하는 그 부분에서 첫 번째로 만들어내는 토큰을 처리를 하는 과정은 프로젝트이 완전히 끝나야지만 시작을 할 수가 있겠죠. 그다음에 디코드의 두 번째 토큰을 만들어내는 과정도 첫 번째 토큰을 만들어낸 이후에만 시작을 할 수가 있습니다.

Attendees 1 22:05 네 프리스트에서 화살표가 전부 연결되지 않았는데 전부 연결되어야 하지 않을까요? 어떤 부분을 말씀하시는 건지 잘 모르겠는데 네 화살표가 다 연결이 되어야 한다. 다 연결을 제가 시켜놓은 것 같은데요.

Attendees 1 22:25 라이크라는 아이 아이요. 그니까 연결이 안 돼도 되죠. 근데 연결이 어떻게 하면 되냐면 i i 값이 이제 라이크를 하는 첫 번째 맨 밑에 있는 레이어에 KB 값으로는 이제 표시가 돼야 되기 때문에 그런 디펜던스는 있죠. 하지만 아이가 처리가 된 레이어의 아웃풋이 첫 번째 두 번째 레이어에 인풋으로 들어갈 필요는 없겠죠 니 보면은 이 그림 상에서 보면 이제 실제 영향을 주는 방향이 위로 그러니까 환 토큰을 처리를 하는 과정에서 첫 번째 레이어가 두 번째 레이어에 영향을 주고 두 번째가 세 번째 영향을 주고 하는 거는 원래 LM 자체가 이렇게 스테이킹을 해서 만들어져 있기 때문에 당연히 일어나는 전파 과정인 거고요. 그다음에 우상향 방향으로는 영향을 주게 돼 있고요. 왜냐하면 셀퍼 텐션을 확인해야 되잖아요. 그러니까 맨 밑에 있는 문장들이 이제 셀퍼 텐션을 확인해야 되니까

Attendees 1 23:24 우 방향으로는 우상향 방향으로는 자기가 가지고 있는 케이블 값을 쿼리를 하기 위해서 계속 이제 전파를 시키는 그런 과정은 필요하고요. 네 그런 것들이 스태킹이 돼서 각 레이어마다 이제 반복이 되기는 하지만 네 하지만 각 레이어별로 봤을 때에는 병렬로 처리를 해도 상관이 없죠. 옆으로 전파가 되는 패스는 없기 때문에 팬적으로는 다 동시에 동시에 처리를 할 수가 있겠죠. 그래서 마치 그냥 여러 개의 리퀘스트를 한 번에 묶어가지고 락스텝 네 그냥 동시에 똑같은 레이어들을 반복해서 수행을 한다라고 생각을 해도 무가능하죠. 그런 측면에서는 패럴 하고 그냥 배치 사이즈가 타임 계산을 하는 거랑 똑같은 그런 효과를 가지게 됐습니다.

Attendees 1 24:18 차 선생님께서 비코 도이 트랜스포라도 프린트 단계에서는 넌 커절 어텐션을 하는 것이 아닌가요? 네 그렇게 하지 않습니다. 지금 딱 여기서 보면 이제 커절이라고 한다면은 화살표가 반대 방향으로 가는 화살표가 있어야 되거든요. 근데 지금 제가 그려놓은 거에서는 반대 방향으로 가는 할 필요가 없잖아요. 어텐션은 항상 이제 왼쪽에서 오른쪽으로만 가도록 되어 있기 때문에 네 커절이라고 할 수가 있죠.

Attendees 1 24:52 네 선어님 매토콘을 디코드 할 때마다 이전까지 프리필된 정보를 사용하는 것처럼 이해됩니다. 그럼 디코드 커널은 종료 시까지 프리필 커널을 반복하는 형태로 실연이 되나요?

Attendees 1 25:12 이게 무슨 말인지 제가 잘 이해가 되지 않긴 하는데요. 네 선호 님 질문을 조금만 더 자세히 해 주실 수 있으실까요? 여기서 시간이 좀 많이 내면 안 될 것 같긴 한데 네 제가 질문이 잘 아직 소화가 안 돼서 답을 해드리기가 지금은 어렵습니다. 다음에 저한테 혹시 메일로 해주시거나 아니면 코멘트 남겨서 답을 해드리면 어떨까 싶습니다. 일단은 넘어가도록 할게요. 네 하지만 어쨌든 간에 넌 커절이가 아니라 지금 제가 그려놓은 그림은 커절이고요. 왼쪽에서 오른쪽으로만 영향을 주게 돼 있고 프로필 과정에서 왼쪽에서 오른쪽으로 영향을 주긴 하지만은 위로만 주게 되어 있잖아요. 그래서 팬 쪽으로는 똑같이 계산을 할 수가 있고 그런 이유가 왜 그러냐 하면은 실제 라이크라고 하는 단어는 이미 정해져 있기 때문에 왼쪽에 있는 거를 처리를 한 다음에 그 인풋을 받아가지고 라이크를 처리를 할 필요가 없기 때문에 네 이제 무상향으로만 지금 디펜던시가 일어나는 그런 상황입니다.

Attendees 1 26:23 이게 지금 이제 이 그래프를 설명을 하기 위해서 사실 계속 이제 빌드업을 지금까지 한 거예요. 그래서 이제 슬퍼 텐션 이야기를 하고 그다음에 커저 런커절 이야기를 했고 그다음에 LM이 이제 인퍼런스 과정에서 어떻게 프리 디코드로 나뉘게 되고 거기에서 프리필과 디코드가 어떤 대상적인 특성을 갖고 있는지라고 하는 거를 사실 이 그래프를 설명을 하기 위해서 계속 이제 빌러을 했다고 생각을 하시면 되고요. 이거는 이제 아키텍처나 아니면은 퍼포먼스 분석을 하시는 분들은 보면 딱 다 아시는 그런 그래프인데 이거를 이제 루프라인 어날리시스라고 하거든요 로플라인 언날리스라고 하는 거는 여기 보면은 맨 이제 디코드라고 하는 메모리 바운드라고 하는 부분에 있는 선과 그다음에 터닝 포인트라고 해서 쭉 표면화가 되어 있는 이런 선이 약간 지붕처럼 보인다라고 해서 이제 루플라인이라고 표현을 하고요. 이 그림이 이제 뭘 보여주냐면 과연 이 컴퓨터 그러니까 실제 이 그림에서는 굉장히 컴퓨터를 단순하게

Attendees 1 27:25 메모리에 의한 메모리를 읽고 쓰는 데 있는 영향 그다음에 실제 그 메모리를 컴퓨터 안으로 들고 와서 계산을 하는 데에서 들어가는 오버헤드 이렇게 크게 그냥 두 개로만 딱 나눠서 생각을 하는 거고 그랬을 경우에 내가 지금 메모리에 의해서 바운드가 된 상황인지 아니면은 컴퓨터에 의해서 바운드가 되는 상황인지라고 하는 걸 이제 판별을 하는 그런 그래프라고 생각을 하시면 되고요. 이 왼쪽에 있는 그런 그래프는 실제 메모리가 바운드가 되지 않은 메모리에 바운드가 된 상황이에요. 그러니까 아직 계산을 할 수 있는 그런 커페스티 연산기들은 남아 있는 그런 상황인데 데이터를 들고 오고 아니면 데이터를 레베틀하는 속도가 충분히 빠르지 않아서 그 칩이 자기가 가지고 있는 풀 코페스로 연산을 못하는 그런 상황이고요. 이제 오른쪽은 계산 자체가 이미 꽉 차 있는 그런 상황인 거죠.

Attendees 1 28:21 그래서 실제 이제 더 이상 계산을 계산 모든 연산들이 다 연산기들이 다 계산을 하고 있는 그런 상황이면 당연히 더 이상 계산을 할 수가 없잖아요. 그래서 아무리 더 많은 더 높은 아스메드 인턴스를 갖는다 하더라도 더 이상 속도가 빨라지지 않는 그런 상황입니다. 여기 밑에 그 x축에 나오는 이 안메ic intensity라고 하는 거는 특정 알고리즘이 가지고 있는 그런 특성이라고 생각을 하면 되는 거고 디코드라고 하는 프리필이라고 하는 부분은 병별로 계산을 굉장히 많이 할 수 있기 때문에 여기서 보면은 아스멜 인텐스티가 굉장히 높아요. 네 그거를 또 다르게 설명을 하면 아까 그림에서 보면 제가 횡쪽으로 모든 연산을 다 처리를 할 수 있다고 했잖아요 그러면 횡쪽으로는 사실 i like my 켓이라고 하는 네 부분에서 똑같은 레이어가 동시에 수행이 되기 때문에 이 똑같은 레이어에 들어가는 웨이트들은 한 번만 올라오면 네 번 계산을 하는 셈이죠.

Attendees 1 29:22 네 그래서 아르테메릭 인텐스티가 높죠. 그러니까 들어오는 웨이트에 대비해서 할 수 있는 연산 자체가 높은 그런 상황이고요. 그런데 이제 그 오른쪽에 있는 디코드에서 예를 들어서 이라고 하는 단어를 만들어내는 과정을 생각을 하면 이때는 한 번에 한 레이어만 돌잖아요 그러니까 프릭슬에서와 마찬가지로 한 레이어에 필요한 모든 weight는 다 들고 오는데 계산을 한 번밖에 못 하는 거예요. 프리슬 같은 경우에서는 그걸 네 번 할 수 있고 그러니까 아르베이비 인텐스티가 프리슬이 고들보다 4배가 더 높은 상황이겠죠 그래서 빅코드는 알트mic 인텐스티가 낮고 그렇기 때문에 메모에 바운드 돼 있고 그 이야기는 원하는 만큼 계산을 다 못하는 그런 상황인 거고요. 프리필 같은 경우에는 아이스멜 인텐스티가 높고 좋기 때문에 저희가 일단은 연산기 자체들이 다 항상 비지하기 때문에 더 이상 속도를 높일 수 없는 그런 상황

Attendees 1 30:17 인 셈인 거죠. 그래서 연산계 이플라이제이션 측면에서만 본다면 프리필이 훨씬 더 아이디얼한 상황이고 그다음에 디코드가 그렇지 못한 상황이라고 생각을 할 수가 있습니다. 네 응주님께서 스파스티 매트릭스를 연산하는 경우 의미가 없는 계산을 많이 하는데 이러한 경우에 아이스바디 인텐스티는 의미가 있을까요? 제가 이제 용주님께서 하신 말씀을 어떻게 이해를 했냐면 스파스한 계산을 한다라고 한다면 그 때 곱하고 더하고 하는 그런 실제 유용한 계산을 하기 전에 예를 들어서 파싱을 하고 다시 데이터를 배칭을 다 다시 재배치를 하고 하는 그런 이제 과정들이 포함이 돼 있어서 그런 것들을 의미가 없는 계산이라고 표현을 하신 것 같은데 이런 경우에는 이제 머신러닝에서는 어떤 표현이 있냐면 제가 단어를 까먹었는데 그 유효 뭐 곱샘 뭐 이런 표현이 있거든요 그 유효 곱셈인가 라고 하는 그런 표현이 있어요. 그러니까 실제 이 모델을 어떻게 힘대로 터리를 하는지 떠나서 원래 모델이 가지고 있는

Attendees 1 31:27 실제 곱해야 되는 그런 연산이 인트린직하게 있잖아요 그렇죠? 그게 얼마냐 얼마냐 그다음에 이 프로세서가 그거 측면에서 얼마나 빠르게 처리를 하는가라고 하는 거를 측정을 하는 그런 용어가 또 따로 있습니다. 그래서 방금 말씀하신 거에 다시 이제 돌아오게 되면은 알스베드 인텐스티가 그런 의미에서는 의미가 없기는 하죠. 의미가 없다기보다는 약간 희석이 되기는 하죠. 하지만 충분히 뭐 예를 들어서 댄스한 계산이고 그런 의미가 없는 계산의 웨이쇼가 사실 굉장히 적다라고 한다면 그러면 아스메 인텐스티라고 하는 게 의미가 있는 그런 아니라고 생각을 할 수가 있습니다.

Attendees 1 32:16 다음 페이지로 넘어가도록 하겠습니다. 제가 이제 이 그림을 그린 이유가 다시 한 번 이 그림에 대해서 다시 한 번 말씀을 드리려고 하는 게 뭐냐면은 보통 이런 경우에 프리필리 실제 연산을 꽉꽉 채워서 하기 때문에 프리필리 자체는 이제 문제가 있다고 보지는 않는 거고요. 그러니까 이게 실제 보면 어 그러면은 메모리 밴디스를 더 늘려줘야 되는 게 아니야라고 이야기를 할 수 있긴 하지만 실제로 사람들이 이런 그래프를 보게 되면 프 3 자체는 이미 충분히 효율을 다 내고 있다라고 생각을 하고 오히려 이제 왼쪽에 있는 디코드가 이 프로세서의 성능을 다 내고 있지 못하다라고 사람들이 보통 생각을 하게 돼요. 그 이유 중에 하나이기는 한데 보통 이제 요즘에 이 프로세서를 디자인을 하게 되면은 메모리가 가장 다틀랙이 되는 경우가 많거든요.

Attendees 1 33:01 메모리 퍼포먼스가 전체적인 성능의 퍼포먼스를 굉장히 많이 좌우를 한다라고 사람들이 생각을 하고 있고 이거는 지금 최근 몇 년 동안에만 이렇게 생각을 하는 게 아니라 제가 지금 여기에 긁어놓은 논문이 1994년 논문이고 이 논문이 이제 메모리월이라고 하는 표현을 처음 썼던지 아니면은 사람들이 널리 알게 된 그런 계기가 됐던지 하는 그런 논문인데 그때부터 이런 이야기가 나왔어요. 그때부터 그 프로세서들의 성능은 연산을 얼마큼 빠르게 처리를 하느냐가 아니라 얼마나 데이터를 빨리 들고 오고 내보낼 수 있는가에 의해서 결정이 된다라고 하는 이 현상은 아주 옛날부터 알려져 있던 그런 현상입니다. 실제 메모리 인터페이스가 발전하고 있지 않은 건 아니거든요. 요즘에 이제 모든 분들이 알고 있는 HBM이라든지 하는 이런 기술들이 새로 나오긴 하면서 메모리 인터페이스가

Attendees 1 33:51 그다음에 밴드 위스가 점점 더 향상이 되고 있긴 하지만 그런데 문제는 그거에 비해서 실제 하드웨어가 가지고 있는 연산 덴스티가 훨씬 더 빨라지고 있다라고 하는 게 문제인 셈인거죠. 그래서 실제 시간이 지나가면 지나갈수록 계속 이제 프로세서에서는 이런 메모리 성능 문제가 점점 더 악화가 되어 가는 이런 상황이라고 생각을 하시면 됩니다. 네 그런 의미에서 메모리 밴드리스를 굉장히 잘 쓰는 게 굉장히 중요하고 그런 의미에서는 아까 말씀드린 것처럼 디코드 같은 경우에는 이미 연산을 얼마 하지도 않았는데 메모리가 바운드가 됐잖아요. 그 이야기는 메모리 벤닉스를 그만큼 비효율적으로 사용하고 있다는 이야기와 똑같은 이야기죠. 그런 측면에서 엘레이 특히나 프리필이 아니라 빅코드 과정에서 발생하는 이런 메모리 비효율을 줄이기 위한 그런 기술들이 많이 지금 제안들이 되고 있는 그런 상황이라고 생각하시면 될 것 같아요. 용주 님 질문에는 제가 그 툴은 잘 모르겠는데 그 툴이 실제

Attendees 1 34:58 모델도 다 이해를 하고 하지 않고서는 제 생각에 이 뉴욕 옵션을 따지는 건 쉽지 않을 것 같긴 하거든요. 그래서 뉴욕 옵션 아까 말씀드린 것처럼 실제 그런 계산에서 얼마큼 곱셈이 있냐라고 하는 걸 가지고 할 수 있는 게 아니라 원래 그게 가지고 있는 추상적인 모델에서의 곱셈이 얼마큼인데 그게 구현되었을 그걸 얼마큼 빠르게 처리를 하느냐라고 하는 거기 때문에 아마 이런 툴로 자동으로 뽑아낼 수가 있는 건지 저는 잘 모르겠습니다. 시간이 얼마 없어서 조금 더 빨리 빨리 지나가도록 하겠습니다. 네 이건 이제 메모리를 메모리 효율을 두 과정에서 향상시킬 수 있는 여러 가지 방법들을 하나하나 짧게 설명을 드리려고 하거든요 이제 그중에 하나가 이제 저희가 프리플에서 했던 것처럼 여러 개의 토큰을 로 이제 병멸로 처리를 할 수 있도록 만들면 되겠죠. 근데 그게 같은 토큰을 처리를 하는 과정에서는

Attendees 1 36:01 함 토꾼과 그다음 토군 사이에서는 디펜던스가 있기 때문에 어려우니까 이제 여러 개 리퀘스트를 묶어서 처리를 하면 병렬로 처리를 할 수 있는 가능성도 있겠죠. 그게 이제 첫 번째 인디비디얼 리퀘스트에서 예를 들어서 뭐 다이나이트 베칭 아니면 스텝트 대칭이라고 하는 걸 하게 되면은 여러 개의 리퀘스트를 묶어서 처리를 하게 되고 걔네들의 이제 모든 레이어를 다 이렇게 맞춰가지고 락스텝으로 이제 처리를 하게 하면 그러면은 이제 저희가 여러 개의 쿼리를 병물로 처리를 하면서 메모리의 효율성을 높일 수가 있긴 하겠지만 여기서 이제 문제는 뭐냐 하면 실제 디코드 가정이 얼마나 빠를지 느릴지를 저희가 판단을 할 수가 없기 때문에 한 배치에 들어 있는 모든 애들이 다 똑같은 랩스텝으로 진행을 해야 된다라고 한다면은 가장 시간이 오래 걸리는 애가 끝날 때까지는 모두 다 기다려야 되는 이런 문제가 발생을 하게 되죠.

Attendees 1 36:55 그래서 빈 공간들이 많아지게 되고 그냥 인디디얼 리퀘스트를 처리를 하는 것보다는 효율이 올라갈 수 있긴 하겠지만 저희가 원하는 만큼은 성능을 낼 수가 없습니다. 이거에 이런 문제를 해결하기 위해서 컨티뉴어스 배칭이라고 하는 그런 기술을 새로 만들었는데 이 컨티뉴어스 배칭이라고 하는 거는 이제 이런 거를 이제 그렇게 생각을 하는 게 아니라 실제 각 레이어들마다 이제 중간 중간에 다이나믹하게 끼어들어서 이제 같은 순서가 있는 애들을 병렬적으로 처리를 할 수 있도록 만들어주는 그런 기술이라고 생각을 하시면 되거든요. 컨티니스 배칭 자체가 어떻게 동작하는지에 대해서는 제가 시간이 없어서 자세히 말씀을 못 드릴 텐데 그 이 서울대학교에 계신 정명권 교수님께서 오라고 하는 굉장히 널리 알려진 그 논문에서 이제 대표적으로 이런 방법을 제안을 했고 그런 방법을 기반으로 해서 프랜드 AI라고 하는 회사도 만들어서 지금

Attendees 1 37:53 열심히 활동을 하고 계십니다. 컨티니스 매칭이라고 하는 거는 지금 LM 서빙에서는 거의 안 쓰면 안 되는 그런 굉장히 그런 중요한 핵심 기술로 자리가 잘 잡혀 있습니다. 어쨌든 컨테니어 배칭이라고 하는 걸 쓰게 되면 실제로 리캐스트마다 시퀀스 렌스가 다르다 하더라도 그것들을 잘 육수를 해가지고 빡빡하게 계산을 다 묶혀서 할 수가 있다라고 생각을 하시면 됩니다. 또 다른 방법은 이제 스펙틀러티브 디코딩이라고 하는 방법이 있는데요 제가 아까 말씀드리면서 실제 디코드 과정에서는 한 토큰이 다 끝나야지만이 그다음 토큰을 처리를 할 수 있다 격렬로 처리하는 것은 불가능하다라고 말씀을 드렸는데 이거를 해결할 수 있는 그런 제 방법이 스페큘레이션을 하는 거거든요. 여기에 제 인사이트는 뭐냐 하면 큰 모델이 있다라고 생각하면 그 큰 모델과 작은 모델이 있다라고 생각을 하면 큰 모델이 작은 모델보다 더 정확하긴 하지만

Attendees 1 38:52 그래도 작은 모델이 큰 모델의 성능에 그렇게 크게 뒤쳐지지 않는다라고 한다면은 일단 드래프트를 작은 모델로 만든 다음에 그 만든 드래프트가 맞는지 틀린지 검증을 하는 방식으로 큰 모델을 돌리게 되면 검증을 한 단계에서는 모든 토근들을 한꺼번에 검증을 할 수가 있거든요. 왜냐하면 prefid 아까 제가 말씀을 드렸는데 prefill이라고 하는 단어를 저희가 벽면으로 처리할 수 있게 되는 이유는 어떤 단어들이 처리가 될지라고 하는 것들이 정해져 있는 상태에서 동시에 처리를 할 수 있다라고 말씀드렸고 마찬가지로 이 df라고 하는 것들도 pref가 비슷하게 어떤 단어들을 검증할지는 다 정해져 있는 상태예요. 그래서 그 단어들을 검증을 하는 단계는 병렬로 프리스를 처리하는 거랑 사실 거의 똑같게 처리를 할 수가 있어요. 네 그래서 이제 만약에 드래프트가 정말로 그러니까 작은 모델이 만들어낸 드래프트가 실제 큰 모델이 만들어낸 그런 토큰들과 동일하다라고 한다면 병렬로 그것들을 검증을 하게 되면

Attendees 1 39:57 오류가 하나도 발생을 하지 않을 거고 그러면 거기에 나와 있는 모든 근들을 다 억셉트를 하면 되고요. 중간에 만약에 오류가 생겼다라고 한다면 오류가 생기기 전까지 가정을 하는 거고 우리가 생긴 그 밑부분을 사실 버려야 되는 거죠. 그래서 그 부분부터 다시 데스트를 만들어서 마찬가지로 또 검증하는 과정을 반복을 하게 됩니다. 저는 스펙틀러트 디코딩이라고 하는 거를 처음 이제 알게 됐을 때 굉장히 라고 스마트하게 만들었다라고 생각을 했고요. 실제로 실제로 이제 통계적으로 봤을 때에는 작은 모델들이 충분히 의미 있게 속도가 의미 있게 정확도가 높기 때문에 꽤 효율이 높다라고 사람들이 생각을 하고 있습니다.

Attendees 1 40:46 팩틀렉티브 티처 스튜던트 모델이 생각나네요. 이게 스튜던트 티처랑은 좀 다른 것 같기는 합니다. 제 생각에는 이런 스페큘러티브 어텐션이라고 스페큘러티브 디코딩이라고 하는 게 이제 아까 말씀드린 그 백신과는 그런 다른 방법으로 한 리퀘스트를 처리하는 과정에서 이제 그 검증이라고 하는 과정으로 문제를 전환을 시켜 가지고 마치 풀필을 하는 것처럼 여러 개의 토큰을 동시에 처리를 할 수 있도록 만들어주는 그런 기술이라고 생각을 하시면 됩니다. 이렇게 해서 제가 지금까지 이제 말씀드린 거는 저희가 어떻게 프리필처럼 디코드로 병렬 처리를 할 수 있냐라고 하는 부분들에 대해서 말씀 드렸고요. 네 지금 이제 말씀드릴 거는 뭐 그렇게 격렬이 된다 하더라도 실제 어텐션 자체가 꽤 비싼 가정이거든요. 근데 이제 어텐션 자체가 실제 시퀀스가 길어지면 길어질수록 굉장히 비싸죠. 왜냐하면 하나의 토큰을 그러니까 맨 마지막 토큰을 처리하기 위해서는 그전까지 제너레이션 되어 있는

Attendees 1 41:52 모든 토크들로부터 인풋을 들고 와서 KP 값을 계산을 해서 어텐션을 구해야 되는데 그런 것들이 또 마찬가지로 맨 번 반복이 되다 보면 그러면 엔 스퀘어 엔에 이제 자승만큼의 그런 컨텍스트가 생기게 되고 그러면은 이제 시퀀스 n스가 그려지면 그려질수록 이 어텐션이라고 하는 데 들어가는 계산에 필요한 메모리라든지 아니면은 시간이 엄청나게 많이 쓰일 수밖에 없거든요. 그 어텐션이 실제 시퀀스 x스가 길어지면 굉장히 크게 문제가 되고요. 이걸 해결하기 위한 그런 방법 중에 하나가 플래시 어텐션이라고 하는 제안이 있었어요. 이제 뒤에서 좀 더 자세히 말씀드릴 텐데 이 플래시 어텐션은 실제로 어텐션이 가지고 있는 이 자승의 콤플렉스티를 해결할 수 있는 방법은 없습니다. 네 그거는 이제 없고요. 하지만은 그거를 더 효율적으로 처리를 할 수 있는 방법이 있기는 한데 그게 이제 타일링과 피전이라고 하는 기술을 쓰게 되면 가능하거든요.

Attendees 1 42:47 여기 나와 있는 자세한 건 지금은 말씀드리지 않겠지만 이 왼쪽에서의 문제는 뭐냐 하면 이런 어텐션을 계산을 할 때 반복적으로 계속해서 밖에 있는 메모리로부터 계산을 그 데이터들을 반복적으로 들고 오고 또 다 내보내고 또 들고 오고 내보내고 하는 과정을 이제 반복적으로 하는 어텐션의 큰 문제 중에 하나인데 이 플래시 어텐션이라고 하는 거는 이 계산을 이제 타일링을 하고 한 타임을 처리하는 데 있어서는 이런 데이터를 주고받을 필요가 없이 한 번 올린 다음에 계산이 끝난 다음에만 외래 보넷으로 필션을 시켜놓으면 그 훨씬 더 효율적으로 처리를 할 수가 있겠죠. 네 이런 제 클래시 어텐션이라고 하는 이런 기술이 있습니다. 페이지 어텐션이라고 하는 거는 또 마찬가지로 굉장히 큰 그런 시퀀스가 있다라고 했을 때 이런 큰 시퀀스를 위해서 예를 들어서 케이비 캐시 블랙을 다 잡아놓고 있게 되면은

Attendees 1 43:42 케이블 캐치를 쓴다라고 했을 때 시퀀스 렌스 맥스 시퀀스 렌스에 맞춰서 저희가 케이블 캐치를 오노케이션을 해야 되는데 실제로 그걸 다 얼로케이션 해 놓고 잡아놓고 있게 되면은 그 맥스 시퀀스를 쓰지 않는 여러 가지 리퀘스트들 같은 경우에는 이제 놀고 있는 공간들이 많아지게 되건데 그렇게 되면 실제 예를 들어서 온신 매물이다라고 한다면은 넣을 수 있는 리퀘스트 한 번에 처리할 수 있는 리퀘스트가 바운드가 되겠죠 왜냐하면 피스 센스가 길어지게 되면 이런 문제를 해결하기 위해서 실제 로지컬한 캐시 블록이랑 실제 피지컬 한 캐시 블락은 디컴플리 시키고 로지컬한 캐시 블락은 굉장히 많은 리퀘스트를 그다음에 굉장히 긴 시퀀스에 대해서 처리를 할 수 있도록 만들어 놓기는 하지만 실제 필요한 부분만 롤로케이션을 해서 방금 말씀드린 이런 문제를 처리하는 방법이 페이스 어텐션이라고 하는 이런 방법이 있습니다.

Attendees 1 44:34 이런 것들이 이제 굉장히 긴 시퀀스의 어텐션을 더 효율적으로 처리를 하기 위한 대표적인 기술이라고 생각을 할 수 있습니다. 이런 것뿐만이 아니라 또 다른 여러 가지 수석타 기법들이 있는데 오늘 이제 익숙하게 다루지는 않겠지만은 여러분들이 잘 아시는 콘탈라이제이션이라든지 스파티 같은 때 문제를 컴플렉스 하는 이런 기술들도 굉장히 효과적으로 잘 활용을 할 수가 있습니다. 지금까지 이제 제가 소개해드린 이런 기술들이 메모리 오버드를 줄이기 위해서 사람들이 만들어낸 굉장히 재미있는 여러 가지 그런 장치들이고요. 네 그 장치들의 그런데 특성들이 뭐냐 하면은 하드웨어의 특성들을 잘 이용을 해서 계산을 하는 셈인 거고 이런 하드웨어적인 특성을 잘 계산을 활용을 해서 계산을 하는 하는 데에는 실제 파이토치가 제공하는 오베 엑스트랙션은 거기에는 맞지가 않아요. 그 파이토치가 하는 저희한테 제공하는 오베 엑스트랙션은

Attendees 1 45:28 실제 안에 있는 계산을 컨트롤 할 수가 있는 게 아니라 이미 정해져 있는 계산을 이 빌딩 블록으로 해가지고 계산을 만들 수가 있는 거고 그 옷 자체가 하나하나 가지고 있는 엑셀 자체는 특히나 이제 푸자 같은 걸로 하나 하나의 옷이 커널로 매핑이 되면은 그 커널 자체가 디램에 있는 인풋을 처리해서 디램에 다시 적어놓는 게 그 커널들이 가지고 있는 이학 모델이기 때문에 아까 말씀드린 플래시 업 텐션처럼 반복해서 메모리에서 DM에서 읽고 쓰 하는 과정을 반복을 할 수밖에 없거든요. 그런 한계를 극복을 하기 위해서는 그거를 파이터치 로그로 작성을 하는 게 아니라 그것보다 더 저 수준의 API를 써서 작성을 한 다음에 그것들을 이제 커스텀 업으로 웹을 해가지고 8조치 수준으로 이제 노출을 시켜야지만이 모델에서 쓸 수 있는 그런 그런 점들이 있습니다. 네 이제 코너 프로그램이라고 하는 것들에 대해서 조금 더 말씀을 드리려고 합니다.

Attendees 1 46:22 이게 이제 플래시 어텐션이 가정을 하고 있는 굉장히 간단한 GPU의 모델인데 그리드라고 하는 것들은 이제 굉장히 대규모로 벽을 벽력적으로 처리를 할 수 있는 연산기들이라고 생각을 하면 되는 거고 이 그리드가 연결되어 있는 게 하나는 밖에 있는 d램 그게 이제 오른쪽에 있는 거고요 그다음에 블록별로 할당이 되어 있는 음치 메모리인 퀴어드 메모리 이렇게 되어 있어요. 여기서 보면은 쉬어드 메모리가 실제 훨씬 더 벤더스가 높고요. 그래서 블록들은 쉬어드 메모리를 접근을 하는 게 쉬어드 메모리에 일단 올려놓은 다음에 계산을 하는 밖에 있는 디램에 따가 올려놓고 계산하는 것보다는 훨씬 더 빠르겠죠 그래서 실제 플래시 업텐션 같은 경우에는 어떻게 하냐면 원래 이제 인풋 데이터 그다음에 실제 메인테인을 해야 되는 데이터는 d램에 있다 하더라도

Attendees 1 47:12 그걸 쪼개서 셰어드 브에 올려놓고 그리고 실제 그리 같은 경우에는 셰어드 브에 올려져 있는 데이터를 가지고 훨씬 더 높은 밴닉스를 가지고 계산을 하게 됩니다. 이거는 아키텍처인 특징을 어떻게 그러면은 알고리즘 적으로 반영을 해가지고 저희가 코딩을 할 수 있느냐라고 하는 문제들이기는 하다. 이게 이제 어텐션 네 시간이 얼마 안 남아서 제가 원래는 8시에 끝내고 싶었는데 아마 끝내기 어려울 것 같은데 지금 제가 약간 플래시 어텐션이라고 하는 게 실제 어떤 알고리즘이라고 하는 거는 조금 더 자세히 설명을 드리면서 이게 왜 그러면 커널 프로그래밍 그리고 커널 프로그래밍도 차별하지 않은 코널 프로그래밍을 해야 되는가라고 하는 걸 좀 설명을 해 드리고 싶어서 제가 조금 다 이제 설명을 드리기 시작을 할 텐데요. 이게 이제 어텐션 이제 휴식을 저희가 쭉 펼쳐서 놓는 거거든요 그 아까도 말씀드렸지만 어텐션은

Attendees 1 48:03 그케라고 하는 키라고 하는 거를 에 쿼리에 넣어 가지고 그 넣는 게 제 두 개가 하는 과정이고요. 그래서 실제 어떤 저희가 어텐션을 하고자 하는 그 코리 자체가 실제 저희가 어텐션을 구해야 되는 그런 토큰이라고 생각을 하고 그다음에 거기에서 다른 거기에서 얼마만큼 어텐션을 줘야 되는가라고 하는 다른 단어의 키가 있으면 그걸로부터 실제 저희가 그래서 그 단어가 얼마만큼의 어텐션을 줘야 되는가라고 하는 1차 어텐션을 어텐션 값을 이제 얻게 되고요. 여기에서 이제 커절이라고 한다면은 실제 이제 뒤에 있는 단어들의 영향을 받지 않게 하기 위해서 매스킹을 쭉 해서 실제 커절 어텐션들만 쭉 필터를 하게 되고 거기에 이제 소프트맥스를 해서 전체 모든 토큰들에 대해서 어떤 밸런싱을 하게 된 다음에 거기에 실제 이제 그 토큰에 해당하는 v 값을 곱하게 되면 곱해서 더하게 되면은 저희가 원하는 어 소스 데어 있는데 이 값을 구할 수가 있죠.

Attendees 1 49:06 이게 이제 어텐션이 일어나는 과정인데 아까 말씀드린 것처럼 계산량과 메모리 모두 다 자승에 이걸 반복해서 하게 되면은 컴플렉스를 갖게 되는 거예요. 이게 이제 시퀀스 엑스가 느껴지면 점점 더 크게 문제가 되는 거고요. 플래시 어텐션이라고 하는 알고리즘은 이것들을 더 효율적으로 처리를 하기 위해서 굉장히 중요한 두 가지 기법을 적용을 하는데 하나는 타일링이라고 하는 거고요. 이제 타일링은 큰 계산을 낮게 쪼개가지고 필요한 부분만 들고 와서 계산을 할 수 있도록 해 주는 그런 알고리즘이라고 그런 방법이라고 생각을 하시면 되고요. 이 퓨션이라고 하는 거는 계산을 할 때 내가 이 계산에 필요한 모든 것들을 다 메모리에 들고 온 다음에 실제 메모리에 접근을 하지 않은 상태에서 최대한 많은 계산을 한 다음에 그 계산이 끝나면 한 번에 데이터를 눌려 내보내는 이런 거 필요하드라고

Attendees 1 49:59 표현을 하게 됩니다. 그래서 타일링과 네티션을 합쳐서 저희가 만약에 어텐션을 계산을 할 수 있게 되면은 훨씬 더 메모리를 효율적으로 사용할 수가 있겠죠. 이런 타일링과 퓨전이라고 하는 거는 제가 아까 말씀드린 이유로 파이토치 수준에서는 어떻게 저희가 해볼 수 있는 방법이 있지는 않고요. 이런 것들을 잘 활용을 하기 위해서는 현업 프로그램을 해서 이런 것들이 잘 반영된 알고리즘을 구현을 한 다음에 그것들을 이제 파이토치 오으로 랩을 해 가지고 노출을 시켜야 합니다. 그럼 이제 제가 이제 말씀드린 이 어텐션이라고 하는 알고리즘을 어떻게 그러면 타일링을 적용하고 그다음에 그 퓨전을 할 수 있을까라고 하는 게 있는데 여기서 그러면 곱셈 같은 경우에는 타일링이라고 하는 게 굉장히 보편적으로 잘 적용이 되고 있는 그런 과정이고 매스킹이라고 하는 것들도 마찬가지로 타일링이 잘 적용이 되는 부분이기 때문에 앞 뒤에 있는 이런 부분들은 사실

Attendees 1 50:52 타일링을 하고 퓨전을 하고 하는데 이거 있어서 크게 그렇게 부담이 되는 부분은 아니에요. 문제는 이제 중간에 들어가 있는 소프트 백스라고 하는 어떻게 처리를 할까라고 하는 그런 부분인데 소프트맥스라고 하는 건 그 계산 자체가 예를 들어서 n 값이 주어져 있으면은 그 n 값이 전체를 보고 그다음에 그걸 다시 리밸런싱을 하는 그런 과정이기 때문에 이걸 어떻게 이제 나눠서 쪼개서 계산을 할 건가라고 하는 것들이 기술적인 트렌드라고 분석을 할 수 있죠. 일단 소프트맥스라고 하는 게 왼쪽에 있는 이런 수식인데 그러니까 x라는 값들이 쭉 주어져 있으면 그 x들을 이렇게 익스퍼멘트로 다 바꿔가지고 이제 값들을 변화시킨 다음에 그 값들을 다 더해서 그걸 다시 나눠 가지고 어떻게 보면은 다 더했을 때 일이 되도록 다시 값을 노멀라이제이션을 해 주는 과정이 소프트맥스라고 생각을 하시면 됩니다. 여기에서 실제 이제 이거를 굉장히 간단하게 계산을 한다라고 한다면 모든 값들에 대해서

Attendees 1 51:54 이제 썸으로 나눠줘야 되는 부분도 있으니까 일단 그 썸을 먼저 구한 다음에 다시 돌아가서 하나하나의 값들을 대해서 다 나눠주게 되면 이제 이게 2패스가 되는 셈인 거죠. 이투패스라고 하는 이야기는 원래 이제 x 값이 맨 처음에 메모에 있는데 그것도 한번 다 읽어서 XI를 구하면서 이제 구하면서 구하고 구하면서 이제 썸을 이제 구하고 그다음에 다시 한 이 값이 썸을 알고 있으니까 다시 한 번 또 x 값을 다시 한 번 다 읽어들여가지고 나눠 가지고 최종 y i 값을 구하게 되면 이제 실제 메모리에 읽어서 계산을 한 다음에 다시 한 번 또 메모리에 다시 읽어가지고 계산하는 이런 두 개의 패스로 나눠져 있어서 메모리에 대한 접근을 이제 두 번씩 해야 되는 그런 알고리즘이 가장 간단한 알고리즘이라고 생각을 할 수가 있습니다.

Attendees 1 52:45 그것뿐만이 아니라 저희가 이 소프트맥스가 가지고 있는 또 다른 재미있는 문제는 이 뉴메니카 스테빌리티라고 하는 게 있는데 여기 보면 이제 익스퍼멘트가 들어가있기 때문에 값이 굉장히 커질 수가 있잖아요. 이제 플러시라고 하는 표현 자체가 문제가 뭐냐 하면은 값이 커지기는 커질수록 더 이상 표현을 할 수 없는 구간이라고 하는 게 생기게 되고 이제 그거에 도달을 하게 되면 레졸루션을 잃어버리거든요. 값이 굉장히 커졌다 작아졌다 하는 이런 과정이 예를 들어서 반복이 된다 아니면 값이 계속 작아지는 과정이 반복이 된다라고 한다면은 언젠가 다시 그게 복귀가 된다라고 하더라도 중간에 한 번 그 유닛을 닫게 되면 그 과정에서 에러스를 잃어버리게 되는 그런 현상이 발생하게 되고 이런 것들을 이제 리메리카 스테빌리티라고 표현을 하게 됩니다. 이런 누메리컬 스테빌리티를 저희가 이제 해결할 수 있는 방법 중의 하나는 그 값이

Attendees 1 53:38 커지는 걸 일단 회피를 할 수 있는 방법이 있으면은 아니면 작아지는 걸 회피할 수 있는 방법이 있으면은 네 가장 좋기는 하거든요. 이 경우에는 예를 들어서 전체 중에서 가장 큰 맥스 값을 알고 있고 그거에 대해서는 일단은 그것만큼 일단 빼 가지고 계산들을 다 반영을 하게 되면 분모와 분자에 분주다라고 하게 되면은 실제 그 반만큼은 위 아래에 어쨌든 나중에 이제 3세가 될 부분이기 때문에 그거를 일단은 다 반영을 한 다음에 나중에 3세를 하는 게 아니라 처음부터 상세가 된 값들을 가지고 시작을 하게 되면 그 밑으로 아니면 위로 떨어지면 이 경우는 이제 위로 올라가는 거죠. 위로 가는 거를 방지를 하면서 저희가 액트어스를 유지할 수 있는 구간 내에서만 계산을 할 수 있는 이런 장점을 가지고 있습니다.

Attendees 1 54:22 이렇게 또 이제 계산을 하기 위해서는 이제 맥스 값을 또 알아야 되니까 아까 제가 패스가 두 번 필요하다고 했는데 맥스 값을 또 알아내는 그런 과정을 또 한 번 칠해야 되니까 패스가 세 번이 되게 되죠. 이제 일반적인 스프트 맥스에 대해서 이제 셀프 스프트맥스라고 하는 거는 뉴메니컬 스텝을 는 조금 더 보장이 되는 장점이 있긴 하지만은 메모리에서 세 번 늘어야 되는 그런 부분들을 가지고 있어요. 플레시 어텐션이라고 하는 거는 일반적인 소프트맥스가 아니라 이런 세이프한 소프트맥스와 거의 비슷한 그런 효과를 가지고 있는 그런 알고리즘을 어떻게 싱크패스로 타일링과 풀시 되어 있는 형태로 우리가 구할 수 있을까라고 하는 그런 알고리즘이라고 생각을 하시면 되고요. 이 알고리즘은 여기서는 그냥 실제 타일링이 직접 된 건 아니고 그냥 모든 엘리먼트들로 계산을 했을 때 어떻게 이거를 실제 이제 퓨즈가 되어 있는 형태로 볼 수가 있냐라고 하는 것들을 쭉 이제 계산을 한 건데

Attendees 1 55:17 기본적인 아이디어는 뭐냐 하면은 저희가 맥스 값을 실제로 구하는 게 아니라 지금까지 나온 것 중에 가장 큰 값만 알고 있으면 그걸로만 저희가 스케일을 해도 아까 세이프티를 어느 정도 보장을 할 수가 있거든요. 그 대신에 그런 경우에는 그 맥스 값이 계속해서 이제 업데이트가 되니까 그 업데이트가 된 맥스 값에 반영을 해서 지금까지 더한 값을 다시 보정을 해가지고 유지를 하는 그런 과정들이 들어가면 그러면 계산을 할 수가 있습니다. 제가 이 알고리즘 하나하나 뜯어가지고 설명을 드리지는 않을 텐데 제가 아까 이제 세이프 소프트맥스라고 하는 걸 설명을 드렸지만은 세 소프트맥스의 온라인 버전이 있어요. 이제 온라인 알고리즘이라고 하는 거는 이런 미리 뭔가 다 계산을 한 다음에 그걸 다시 한 번 처리를 하는 과정 없이

Attendees 1 56:09 이제 그냥 실제 그때그때 있는 답만 가지고 뭔가 보정을 해 나가면서 하는 그런 알고리즘들이 보통 온라인 알고리즘이라고 표현을 하는데 그런 이제 이 소프트맥스의 온라인 버전이라고 하는 게 있는 거고 그 아이디어를 이제 실제 어텐션으로 확장을 해가지고 어텐션을 한 번에 한 번의 패스로 이렇게 맥스 값을 계속해서 업데이트하는 과정을 통해서 보정을 중간중간에 이렇게 해나가면서 타일과 휴지가 되어 있는 원패스 알고리즘을 구현을 해 놓는 게 플래스 어텐션이라고 생각을 하시면 됩니다. 어쨌든 그런 과정을 통해서 이렇게 플래시 어텐션 자체를 다시 리스트럭처링을 하면 그러면 읽고 쓰는 과정을 굉장히 많이 줄이면서 훨씬 더 효율적인 그런 알고리즘을 만들 수가 있게 되죠. 네 그래서 이제 이거를 이제 그때 그 당시에는 스탠포드에 있는 페이스트 학생이었던 우라고 하시는 분께서 만들었는데 일단 그 실제 스탠다드 어텐션 자체는 그런 이런 모든 과정들을 다 그냥 파이토치 온만으로 계산을 하게 되고

Attendees 1 57:13 파이 터치 이 파나 하나는 이제 가능하면 그 안에 이제 쿠플러스 같은 그런 가속 라이브러리를 써가지고 구현을 하도록 되어 있어요. 하지만 아까 말씀드린 것처럼 파이토치 옷만으로 표현을 해서는 스타일과 그다음에 퓨전 같은 것들을 할 수가 없기 때문에 전체적인 DP 유틸라이제이션은 굉장히 낮고요. 그것들을 해결을 해서 이 속도를 향상을 시킨 게 이제 플래시 어텐션 버전 원 알고리즘이고 이런 것들이 플래시 어텐션 버전원 자체는 엠비디아의 쿠다를 써서 구현을 했습니다. 하지만 플래시 어텐션을 써도 스탠다드 어텐션보다는 훨씬 더 빨라지긴 했지만 GP 유틸라이제이션은 약 25% 정도밖에 낼 수가 없었다라고 해요. 그래서 그 다오라고 하는 그 분이 주목을 한 게 커틀라스라고 하는 그런 다른 가상 라이벌에 주목을 했는데요. 커틀라스는 쿠다와는 달리 그 쿠다 그 위에 아마 제 생각에 올려진 템플릿 라이브러리라고 생각을 할 수가 있을 것 같긴 한데

Attendees 1 58:12 와는 달리 그 하드웨어의 디테일들을 모델링을 템플릿 형태로 해가지고 그 코드 자체를 그 엠비디아의 GPU에 하라는 그런 구조에 맞춰서 짤 수가 있거든요 그런 것들을 활용을 해서 웹을 훨씬 더 잘 설계를 해가지고 위슬라이제이션을 상당히 많이 올렸다고 합니다. 그래서 이제 플래시 버전 2 플레시 어텐션 버전 2부터는 그냥 생짝 후다로 짠 게 아니라 그런 하드웨어적인 옵티마이제이션을 훨씬 더 잘 할 수 있는 커트레스라고 하는 태블릿을 쓰기 시작을 했고요. 래셔 어텐션 버전 3가 되면서는 그 당시에 이제 하퍼라고 하는 새로운 아키텍처가 나왔는데 이 아키텍처가 나오면서 예를 들어서 저밀도 연산도 더 훨씬 더 잘 지원이 되고 그리고 에이 싱크로너스 카피 텐셀 코어에 대한 에이 싱크로너스 카피가 또 마찬가지로 추가가 되면서 이런 기능들을 다시 한 번 더 잘 활용해야 될 필요가 있어서 이제 플래스터

Attendees 1 59:05 플래시 어텐션을 다시 한 번 만들었고 그러면서 이제 하퍼에 대해서 유틸라이제이션을 75% 정도까지 눌렸다라고 합니다. 그전에 있던 프레시 어텐션 버전 2는 그런 화포에 있는 새로운 그런 기능들을 활용을 못 했기 때문에 그대로 돌리게 되면 유틸라이제이션이 한 30% 정도로 다시 낮아진다고 해요. 그걸 다시 이제 끌어올린 게 클러시 텐션 버전 풀이라고 생각을 할 수가 있습니다. 그래서 저는 이제 보통 사람들이 엠비디아가 제공하는 저수준 API다라고 하면은 이제 쿠다를 생각을 하긴 하지만 실제로 지금 MBD아 아키텍처는 옛날에 알던 그런 간단한 지표 기표가 아니기 때문에 이 쿠다를 직접 사용을 해가지고 성능을 내는 거는 굉장히 어려운 일이고 이런 쿠틀라스 같은 그런 하드웨어에 더 어웨어 한 그런 템플릿트를 써서 프로그램을 해야지만이 성능을 끌어올 수 있는 그런 상황입니다. 네 이 부분은 빠르게 넘어가도록 하겠습니다.

Attendees 1 1:00:00 네 이제 말씀드린 것처럼 이제 다 그니까 쿠다 커널을 이제 효율적으로 잘 짜는 거는 이제 사실 그렇게 쉬운 일은 아니고요. 그래서 이거를 그냥 일반적인 프로그래머가 그 프로그래밍 가이드에 나와 있는 대로만 짜게 되면 대충 한 10% 정도의 유틸라이제이션 밖에 뽑아낼 수가 없고 거기에 아까 제가 말씀드린 쿠틀러스라고 하는 이런 가속화 템플릿을 굉장히 잘 쓰게 되면 한 80%에서 90% 정도의 이제 피크 퍼포먼스를 낼 수가 있기는 한데 그러니까 쿠블러스 대비해서 이론적인 그런 피크에 굉장히 가깝게 올라갈 수가 있기는 한데 실제 거기에도 쿠틀라스로 표현되지 않는 그런 디테일한 것들이 있고 이런 것들은 엠비디아가 가지고 있는 스크립트 소스가 반영되어 있는 쿠플라스에서는 다 활용을 할 수가 있나 봐요. 그래서 이제 나머지 10%는 쿠블라스 같은 엠비디아만이 쓸 수 있는 그런 해큐 소스를 가지고 해야지만이

Attendees 1 1:00:56 최대 효과를 낼 수가 있고 어쨌든 간에 GPU 후자가 굉장히 간단해 보이지만 실제로는 성능을 내기 위해서는 굉장히 복잡한 과정을 거쳐야 된다 라고 알려져 있습니다. 그래서 이제 아마 트리톤이라고 하는 기술도 아마 많이 들어보셨을 수도 있을 것 같긴 한데 트리톤은 특히 이제 파이토치 20이 나오면서 파이토치 2 0이 중간에 특히나 이제 그래프 모드에서 최적화를 하는 중간 인터미디어 프젠테이션으로 활용을 하고 있어서 더욱더 이제 널리 쓰이기 시작을 했는데 이제 하버드 PhD 학생이던 제가 이름이 프렌치 이름이어가지고 잘 기억이 나진 않지만 네 틸렛이라고 하는 분께서 박사 논문 과정 중에서 만든 그런 기술이고 오프나이로 가면서 오프라인의 지원을 받아서 더 강력하게 지금 이제 오픈 소스로 지금 밀고 있는 그런 프로젝트라고 생각을 하시면 되고요. 이게 이제 많은 사람들이 쿠다의 대안이라고 생각을 하고 있는데 아까 말씀드린 그런 쿠다가 가지고 있는 복잡성을 감추면서

Attendees 1 1:01:57 하지만 이런 아까 말씀드린 타일링과 퓨전 같은 것들은 충분히 잘 표현을 할 수 있도록 어떻게 보면 중요한 것들은 취하고 그다음에 필요한 것들은 컴파일러를 통해서 해결을 하고 그래서 이제 개발자들이 손쉽게 이런 커너를 짤 수 있도록 만들어준 기술이 크리톤이라고 하는 그런 기술이 있고 이 트리톤이라고 하는 기술이 파토 지0에 대대적으로 적용이 되면서 많은 회사들이 많이 관심을 가지고 있고요. 이 리뷰도 마찬가지로 트리톤에 굉장히 많은 관심을 가지고 있습니다. 트리톤에 대한 자세한 내용은 오늘은 다루지 않으긴 할 텐데 트리톤이 이런 푸다 같은 이런 프리프라이토리한 그런 커널 프로그래밍이 모델의 대안으로 오픈 소스 대안으로 지금 잘 떠오르고 있는 것 같습니다. 이렇게 해서 이제 코널 프로그래밍에 대한 거는 아까 말씀드렸지만은 코다가 진짜 어떻게 생겼는지 쿠틀러스가 어떻게 생겼는지라기보다는

Attendees 1 1:02:50 코널 프로그램이라고 하는 게 이제 왜 필요하며 어떤 최적화들을 해야 했기 때문에 필요한가라고 하는 걸 위주로 해서 간단하게 좀 말씀을 드렸고요. 또 이제 다른 하나의 측면은 아까 말씀드린 저희가 봤던 이런 컨티뉴어스 배칭이라든지 스페큘러티브 디코딩 같은 이런 하이 레벨 옵티마이제이션들이 있는데 이 서빙을 하는 관점에서는 이런 옵티마이제이션들이 커널 프로그램을 하는 것 만큼이나 굉장히 중요합니다. 그런 것들을 이런 서빙 프레임워크 안에 점점점 녹아들어가기 시작했는데 그런 대표적인 프레임워이 VLM이라고 하는 프레임웍이 있습니다. VLM이라고 하는 프레임워은 아마 많은 분들이 아시겠지만 페이지 어텐션이라고 하는 그런 PhD 학생들이 만든 프로젝트부터 시작을 했는데 이게 굉장히 오픈 소스로 자리를 잘 잡으면서 거의 약간 업계 이제 스탠다드처럼 지금 자리를 잘 잡아가고 있는 것 같아요.

Attendees 1 1:03:42 그래서 이제 모델들도 그들이 올리는 게 아니라 이제 오프스 커뮤니티에 있는 개발자들이 새로운 모델이 나오면 빨리빨리 이제 여기에 이제 붙여보는 작업들도 해 주고 있고 그리고 원래 이제 페이지 어텐션으로 시작을 했지만 여러 대부분의 중요한 그런 알고리즘들은 나올 때마다 사람들이 VLM에 붙이고 있는 그런 상황입니다. 한 가지 재미있는 점은 VLM이 파이토치에 기반을 하고 있는데 아예 여러 가지 하드웨어들이 어떻게 VLM에 붙는가라고 하는 것들은 본인들이 해결을 하는 게 아니라 파이토치에 일단 잘 붙여가지고 오면은 그냥 VLM에서 잘 쓸 수 있도록 만들어 주겠다라고 선언을 했어요. 그래서 어떻게 보면은 파이토치가 있고 그 위에 상위에 이제 VRM이 있고 VM 입장에서는 밑에 있는 하드웨어에 대한 디폰던스들은 이제 파이토치 레이어를 통해서 이제 해결을 하려고 하는 것 같습니다.

Attendees 1 1:04:37 그래서 이제 저희 같은 그런 이제 인퍼런스 추론에 최적화되어 있는 하디오를 만드는 그런 입장에서는 화이트 토치도 잘 지원을 하고 그다음에 VM 같은 것들도 잘 활용할 수 있는 게 굉장히 중요하겠죠. 오픈 소스 세계에서는 요 이제 아까 제가 말씀드린 그런 이제 VLM 같은 기술이 굉장히 보편적으로 쓰이고 있고요. 그것뿐만이 아니라 파이웍스 AI나 그다음에 트게더 AI나 아까 제가 잠깐 말씀드렸던 플랜드 AI처럼 프리프라이토리한 이런 최적화 기술을 가지고 있는 서빙 프레임워크도 있고요. 이들도 굉장히 잘 펀딩을 받아가지고 열심히 사업을 하고 있는 걸로 알고 있습니다. 여기까지 제가 오늘 준비한 그런 내용이고요. 저희가 이제 제가 프리필과 디코드가 어떻게 계산 측면에서 다른가 그래서 내 프리필은 유틸라이제이션이 높은데 디코드는 유틸라이제이션이 낫고 그것들을 해결을 하기 위해서 어떻게 사람들이 최적화 기술들을 해왔는가 그래서 뭐 이제 배칭 여러 개의 리퀘스트를 묶어서 처리를 하는 방법

Attendees 1 1:05:42 그런데 다양한 그런 고정되지 않은 다양한 그런 시퀀스 맨스에도 굉장히 큰 유틸라이제이션을 성취하기 위해서 컨티너 배칭이라고 하는 그런 알고리즘이 나왔고 시스가 길어지면서 로보에드가 도미넌트하게 보이기 시작하는 이 어텐션이라고 하는 것들을 세석하는 몇 가지 방법들에 대해서 좀 말씀을 드렸고 스패큘러티브 디코딩이라고 하는 방법이 실제 한 리퀘스트를 처리하는 과정에서 디코딩 과정에서 발생하는 그런 피콘셜 ependy를 어떻게 끌어내는지라고 하는 것들에 대해서 이제 제가 좀 간단히 설명을 드렸고요. 이제 플래시 어텐션이 실제로 어떻게 생긴 알고리즘인지를 제가 이제 설명을 드리면서 이 왜 그런 알고리즘을 파이토치라는 표현을 할 수가 없고 코널 프로그래밍을 해야 되는지 그리고 요즘 이제 보편적으로 많이 쓰이고 있는 이런 서빙 프레임워크이라고 하는 주제를 오늘은 굳게 들어가지는 않고 일단 브로드하게 좀 말씀을 드렸습니다. 네 결론적으로는 이런 지금 특히나 LM이라고 하는 게 나오면서

Attendees 1 1:06:46 모델에 대한 최적화에 대한 니즈가 점점 더 커지게 됐고 그런 최적화의 니즈를 파이토치는 꼭 있어야 되긴 하지만 파이토치만으로는 해결을 할 수 없어서 이제 파이토치를 보완을 하는 커널 프로그래밍 그다음에 하이 레벨 서비 프레임워크 이렇게 두 가지도 함께 개발자들이 지금 보편적으로 쓰고 있는 이런 상황이다라고 하는 것도 오늘 강조를 하고 싶었습니다. 네 오늘 준비한 내용은 여기까지고요. 중간중간에 제가 나온 질문들은 거의 다 말씀을 드렸던 것 같고 그리고 여기에 나왔던 질문들 중에서 세님께서 하셨던 시프 플러스를 활용해서 수동으로 할당을 해야 한다면 VM 크기에 맞춰서 배분하는 수학 공식 같은 게 있을까요? 공식이라기보다는 그거는 이제 그 알고리즘을 만든 사람이 잘 계산을 해서 배분을 해야겠죠 그러니까 결국에는 타일 크기 파티션 크기 같은 것들을

Attendees 1 1:07:39 정하고 그랬을 때 그러면 거기에 다 어떻게 파티션 크기를 잘 정하고 그다음에 거기에 어떻게 그러면 잘 꾸겨 넣을까라고 하는 것들은 개발자들이 충분히 고려를 해서 아마 프로그램을 해야 될 것 같고요. 타일링이면 텐서를 디컴포지션 하는 것도 일종의 타일링 과정이라고 이해를 할 수가 있을 거예요. 네 이것도 일종의 타일링 과정이라고 생각을 할 수가 있고 드컴 훈련을 어떻게 하냐에 따라서 데 타일링이 잘 되기도 하고 잘 되지도 않기도 하고 그래서 메모리 유틸라이제이션을 저희가 잘 할 수도 있고 못할 수도 있고 달라지게 됩니다. 지난번 시간에 NVC가 디스트리뷰트를 고려하는 하는지 질문을 했었는데 그렇다면 mlir이나 LLVMR은 디스트비티를 고려할까요? 이거는 그니까 MLR이나 LVM IR 자체는 그냥 인티미 레프리젠테이션일 뿐이고요.

Attendees 1 1:08:39 예를 들어서 mr을 활용하는 컴파일러가 있다라고 한다면은 그 컴파일러가 이런 오토매틱 디스트리뷰션을 하는 컴파일러일 수도 있고 안 할 수도 있고 만약에 한다면 그 쪼개지기 전과 쪼개진 이후를 모두 다 mr로 어쨌든 표현을 해내야겠죠 그래서 NVCC는 컴파일러잖아요 그래서 컴파일러가 디스트리뷰티드를 하는지 못하는지 를 결정을 하듯이 mr이나 LVMR은 콤파일러가 아니라 콤파일러가 사용하는 인터뷰에 대한 프레젠테이션이어서 그 수준에서 디스트리뷰티가 고려가 되는 게 아니라 그거를 활용해서 만든 컴파일러가 마찬가지로 그런 것들을 고려할 거냐 고려를 하지 않을 거냐 그렇게 제 생각에는 질문을 바꿔서 해야 되는 것 같습니다. 그다음에 동희 님께서 페이지 어텐션 터널은 내부적으로 스케터 되어 있는 테이블 캐시를 모아서 컨티뉴어스가 맞는지 계산하는지 궁금합니다.

Attendees 1 1:09:42 그거는 컨트리거 하게 계산을 할 필요는 없고요. 그 대신에 맨 처음에 그니까 그럼 제 생각에는 실제 알고리즘을 만드는 사람마다 좀 다를 수도 있을 것 같긴 하거든요 예를 들어서 스케터한 되어 있는 거를 개더을 한 다음에 처리를 하는 게 더 효율적인 그런 하드웨어 같은 경우에는 그런 과정을 거칠 수도 있긴 하지만 그게 이제 아니다라고 한다면은 그러면은 이런 어쨌든 테이블 캐시 자체가 어떤 블록들로 나눠져 있을 텐데 그 블록 하나하나에 대해서 충분히 효율적으로 하드웨 유틸라이제이션을 쓸 수 있다라고 한다면 그 블락의 위치들만 인다이렉트하게 계속해서 읽어가지고 계산을 하면 되니까 제 생각에 그런 경우에는 굳이 개들을 하지 않고도 가능할 수도 있지 않을까 생각이 들긴 하거든요. 네 제 생각에 엠비디아 GPU에서는 굳이 익스프리스트하게 개더를 하지 않을 것 같다는 생각이 좀 들기는 해요.

Attendees 1 1:10:44 그렇긴 한데 만약에 디램이 얼 로케이션이 되어 있다 그러니까 디램이 있고 그다음에 온친 메모리가 있고 로지컬한 그런 테이블 자체가 d램도 디램에 매핑을 해놨을 수도 있고 아니면 온틴 메모리에 매핑을 해놨을 수도 있다라고 했을 때에는 일단 디램에서 온 메모리로 옮기는 그런 과정이 있을 수가 있을 것 같습니다. 그 디테일은 제가 정확하게는 잘 모르겠는데 그냥 제 상상으로는 약간 인플멘테이션 하시는 분들이 여러 가지 다양한 그런 시도들을 다른 하드웨어들마다 아마 해야 될 필요가 있을 것처럼 생각이 듭니다. 네 이렇게 해서 했던 질문들도 다 했고 오늘 내용도 다 커버를 해서 제가 예상했던 것보다는 13분 정도 더 늦게 했지만 오늘 내용들은 잘 커버를 했습니다.

Attendees 1 1:11:30 제가 오늘은 저도 날씨가 추워서 좀 빨리 가야 될 것 같기도 하고 여기 오신 분들도 집에 빨리 귀가를 하시는 게 좋을 것 같아서 오늘은 여기서 마치도록 하겠습니다. 네 다음 주에 뵙도록 할게요. 건강 조심하시고 또 다음 주에 뵙도록 하겠습니다.