지금 테크니컬 리그로 근무를 하고 있고 저희가 지금 엘에이 베이스 어플리케이션을 만든 지는 1년하고도 3개월이 지나가고 있는 것 같아요. 그래서 어떠한 주제를 가지고 오는 게 여러분들한테 가장 도움이 될까 사실 뭐 여러분들마다 당연히 이해 수준이라 그 원하고자 하는 정보가 낮을 테니까. 고민을 많이 했는데 약간 비기너보다 살짝 올라간 수준이라고 봐줘야 될 것 같구요. 그 저희가 사실 좀 의아하실 수도 있겠지만, 저희 여기 했을 때는 고온으로 작성이 돼 있어요. 그러면서 고온으로 작성돼 있는 상태에서 파이썬 생태계의 발전을 지켜보면서 야 그 고온으로 짜는 게 정말 천추의 한이다라는 생각을 많이 하게 되었고 그러면 제가 어떤 부분을 후회를 하고 있을까? 왜 파이썬 생태계로 다시 돌아가야 된다는 생각을 하고 있는지 그리고 저희도 지금 파이썬 포스닉 준비를 하고 있거든요. 그러한 배움 내지는 어느 정도는 이제 포뮬레이 되는 벤스프렉티스볼 에이전 애플리케이션을 좀 설명을 드리려고 합니다. 네 그래서 지난 1년간의 배운 그리고 성숙해진 개발 생태계라는 주제를 가지고 이제 발표를 할 예정이구요. 주제는 간단해요. 오케스트레이션을 첫 번째로, 소개해 드릴려고 하고 그다음에 포스트라프레션 그리고 마지막으로, 파이팅을 준비를 해봤는데 이 발표를 앞선 발표들을 쭉 듣다 보니까 아 됐다. 이번 행사가 어느 정도 발표 발제 주제를 가지고 좀 스토리 라인을 짜는 것 같다는 느낌이 들어가지고 아마 대관님 발표에 이어서 제 발표를 들으면 조금 더 애플리케이션 만드시는 분들은 어떤 고민하고 있는지 좀 얻어가실 수 있을 것 같아요. 네 첫 번째 섹션은 이제 오케스트레이션이고요. 아까 제만 님도 소개해 주시긴 하셨지만, 결국에는 지금 1년 3개월 1년 6개월 전에 오픈 AI가 챗GPT 내고 나서 챗GPT밖에 옵션이 우리가 존재하지 않았던 시절에서 많이 변화됐어요. 우리가 선택할 수 있는 모델에 이제 카탈로그가 굉장히 많아졌고 심지어는 저희가 직접 파이팅해서 모델을 올릴 수 있는 것들에 대한 그 어플 접근성도 굉장히 높았던 상태구요. 그러면은 모델을 그냥 우리가 오픈하기가 좋으니까 오프라인 씁시다 라고 결정하는 게 아니라 어떠한 이제 컨스트레이션을 가지고 어떠한 모델 결정을 해야 할지에 대해서 팩터를 나열해가지고 이 팩터간 비교를 할 수 있어야 되는데 저희는 일반적으로 6개의 형이 대표적인 것 같아요. 뭐 컨텍트 렌트를 얼마나 지원하는지가 첫 번째일 거고, 당연히 그리고 퍼포먼스는 어느 정도 나오고 있는지 뭐 주로 MMLU나 MML 프로스코어를 보겠죠. 그리고 레이턴시는 어느 정도 형성되고 있는지 우리가 이 퍼포먼스 달성하기 위해서 포스트를 어느 정도 소비를 해야 되는지 레이닝 및에 대한 이야기도 당연히 해야 되구요. 그리고 최근에는 뭐 라마도 항상 공개할 때 그 라마가드라든지 이런 뭐 퍼플 라마 같은 거 같이 공개하잖아요. 앞으로 세이프티 관련된 그 니즈가 계속해서 올라갈 건데 실제로 제품 중에서도 뭐 재미나이라든지. 에저 오픈 에이 같은 걸 보면은 세이프 디필터가 그냥 디폴트로 걸려 있어요. 그럼 세이프 디필터를 어떻게 우리가 고려해 가지고 제품을 설계해야 할지 이 6개소 팩터를 중심으로 그 모델을 선택하는 데 있어서 고민을 하게 됩니다. 혹은 그 폴백 로직이 아니더라도 그냥 제품 자체가 다양한 모델을 사용자에게 선택할 수 있는 선택권을 줌에 따라서 그 모델을 활용해야 되는 오케스트레이션 로직을 짜야 하는 비즈니스 리컬럼 같은 게 생길 수 있긴 해요. 그러면 이런 이런 이제 폴백 로직들이 대표적으로 우리가 고려해 봐야 되는 건데 첫 번째로는 콘텍트라이스죠 지나치게 긴 요청이 들어왔을 때 우리는 이거 어떻게 엔터링 할 수 있을까? 두 번째로는 그 우리가 어떠한 모델을 선택한다고 하더라도 주력으로 사용하게 되는 그 모델은 쓸 거예요. 뭐 프로백해서 에이모델서 프로백해서 비모델서 근데 폴백하기 전 이 베이스 모델은 무조건 쓸 거 아니에요. 그 베이스 모델이 레인에 비해서 걸렸을 때 우리 어떻게 이제 생명할 것인가? 그리고 이럴 때도 있어요. 꼭 성능이 좋은 모델만 써야 되는 게 아닐 수도 있어요. 뭐 예를 들어서 사람들 여기 들어와 가지고 어플릭스 들어가서 그냥 하이 이런 거 치고 있어요. 그런 거 실제대로 GPT45를 써야 할까요? 그렇지 않을 수 있겠죠. 그럴 때는 연속도나 비용이 더 중요합니다. 사용자한테 이제 사용자 경험을 늘리기 위해서 그리고 비즈니스 바지를 높이기 위해서 이러한 케이스에서는 어떻게 핸들링 할 것인가? 네 그 사용자 원하는 모델은 이런 그냥 시간들이 애초에 지정을 해버렸어요. 그럼 어차피 우리가 그 모델을 쓸 수 있도록 로직을 구현해 줘야 돼요. 그래서 마지막으로는 그 CYF 디 필터와 관련된 건데 우리가 원하지 않는 상황에서도 그 지나치게 CYF 디 필터를 강하게 걸어서 뭐 예를 들어서 음 폭탄이 유해한 이유에 대해서 알려줘라고 했을 때 어 옛날에 라마 투 같은 경우엔 어 폭탄에 대해서 얘기할 수 없습니다. 이런 것들을 사용자가 저해될 수 있죠. 이랬을 때에 대해서는 어떻게 우리가 포르멘버들이 셀 수 있을까에 대한 것들을 고민하는 것이 오케스트레이션이라고 저희는 그 정의를 하고 있어요. 일단 그 에세이즈 저희가 지금 고어노를 짰다 보니까 소스 코드 고어노이긴 한데 그 모델 타입에 대해서 지금 보시면은 뭐 GPT4로 라마트리 라인업 모델 그리고 아래 제미나잇 그리고 엔트로픽이 지금 스위치 케이스 문으로 다 분기가 되어 있어요. 이렇게 짤 수밖에 없어요. 사실 보험을 위해서 왜냐하면은 그 SDK마다 지금 다 다른 인터페이스를 지니고 있기 때문이에요. 오픈A의 전용 인터페이스가 있고 엔드로픽 전용 인터페이스가 있고 잭내의 좀 인터페이스가 있죠. 다들 경험을 많이 해보셨겠지만, 그리고 한 단계 더 내려가면은 그 하나의 STK 내에서도 에러 핸들링하는 로직이 다 달라요. 뭐 이거는 대표적으로 오픈 AI가 어떻게 레일러니깃이라든지. 콘텐츠 트랜스라든지 뭐 FILTER 링글랜드 에러 핸들링을 하고 있는지에 대한 대표적인 대표적인 가수도 저희 코드베이스에서의 이 로직이구요. 이런 게 굉장히 힘듭니다. 굉장히 힘들고 그 구현해야 되는 난이도도 상당하고 그리고 에지키스들에 대해서도 놓치기가 너무 쉬워요 그래서 제가 1년 전에 돌아간다면은 아 이건 저는 사실 라이네라랑 있었는지 모르겠어요. 그런데 다시 지금 구현을 해야 된다라는 상황이 발생하면은 저는 그냥 묻지도 따지진 않고 이제 라이델레르 쪽으로 갈 거 같애요. 보면은 단순해요. 뭐 헤이 하우스 보잉 뭐 이라는 포인트가 들어왔을 때 라이델엘엠이라는 러터가 앞에 있어 가지고 우리가 사용하고자 하는 모델에 대한 요청을 대신 해주는 거죠. 보시면은 뭐 라이델에는 다 컴플레이션 원래는 오픈에이다도 컴플레이션 엔트로피가 컴플레이션 이런 인터페이스였겠죠. 근데 라이델링 다 컴플레이션하고 모델은 엔자에다가 뭐 5분의 1 모델이든 엔트로픽 모델이든 제임의 모델이든 이런 여러 프로바이더들의 모델을 사용할 수 있게 됩니다. 질문해도 되나요? 그럼 준비하는 타임에 잠깐 질문 먼저 받도록 하겠습니다. 아직 내용이 안 끝났지만 라이베라를 쓰신다고 했는데 아직 안 쓰고 있습니다. 저희도 안 쓰실 거라고 했는데 비슷하게 VLM이나 완벽히 갖지는 않더라도 다른 대안들이 있는데, 어떤 것들을 검토 혹은 고려해 보시고 라이더레임을 주시겠다고 하는지 궁금합니다. 저희는 사실 라이델LM 관련 이런 유사 제품이 많다고 생각하지는 않고 있었어요. VLM도 라인 LLM 정도의 이제 인터페이스 통합성을 가지고 있진 않다고 생각을 했고 그래서 라인엘엘엠을 오히려 라인엘엠 말고 물 쓸까라기보다 라인엘엠 나오거나 나왔을 때 우리가 지금 구현했던 어플리케이션 레이어에서 어느 정도를 이제 이 프레임워크에 녹여낼 수 있을지를 훨씬 더 많이 고민했던 것 같고, 네 그래서 답변은 대안을 크게 리서치를 하지는 않았던 것 같아요. 요런 제품이 사실 지금 시장에 많이 없어가지고 답변해 주세요. 네 어떻게 하셨습니까? 혹시 또 추가 질문 있으실까요? 저한테 질문 잠시만 마이크 드릴게요. 죄송합니다. 본의 아니게 이런 시간이 예 안녕하세요. 그 오랜 한 거를 후회 하신다고 했는데 베프로나 운영 성능에 있어서 강점은 정말 없을까요? 혹시 고랭을 고민 중이신 건가요? 네 고랭을 저희 팀에서 많이 쓰고 있습니다. 사실 그쵸. 저희가 고랭을 처음에 썼던 이유도 결국에는 네 성능 때문이었고 사실 에이전트 에이전트를 고랭으로 짜자라는 그 니즈에서 시작한 건 아니었어요. 저희 저희 엠엘팀 코드베이스가 애초에 고랭으로 짜져 있어서 피오시를 진행할 때 고랭으로 시작을 하게 된 건데 사실 그동안은 그렇게 지난 뭐 6개월 정도까지는 이 정도로 진짜 활성 생태로 넘어가야 되냐라는 진지한 고민을 하지 않다가 그 이어서 라이데르름 이후에도 쭉쭉 나오겠긴 할 텐데 나오긴 했는데 그 거랭이 진행 이점보다 지금 개발 시장이 성숙해지는 속도를 따라가는 게 훨씬 더 우리에게 유리하다 왜냐하면은 그런 비즈니스 사이드에서 이런 결정들이 되게 쉽게 일어나는 것 같은데, 예를 들어서 뭐 여기 계신 다양한 분들이 엘엠 옵스 레지션 이벨레이션 관련해 가지고 요즘 이야기 진짜 많이 들으실 거잖아요. 그리고 관련돼서 파이썬 패키지도 엄청 많이 나오고 있죠. 랭스미스 랭키 유즈 뭐 에이전트 이벌 에이젠트 옵스 아젠타 뭐 기타 등등 엄청나게 많이 나오고 있는데, 고랭으로 구현하려면은 맛보기도 하지 못합니다. 그냥 그거를 따라갈려고 그냥 다 자치구가 돼 가지고 이제 그러다 보면 우리랑 함께 일하는 개발자들이 생각의 끈이 확장이 안 되더라고요. 활성 생태계에서 정권체가 워낙 좋다. 보니까 야 레코피처 나왔네 한번 써볼까 어 이러면 되네 고랭은 야 이 서울과 나왔다더라 어 끝났어요. 네 그래서 저희는 비즈니스 사이드에서 2점은 활성 상태로 넘어가는 게 좋다고 판단을 해 가지고 간 거지 고원호는 훌륭한 언어라고 생각합니다. 네 이제 정상적으로 돼서 다음 이어서 부탁드립니다. 잘 할 수 있을지 모르겠네요. 잘 해봤습니다. 네 그래서 RNA를 보면은 서로 다른 모델의 모델이나 인자 수준으로 내려가지고 쉽게 초상화해서 쓸 수 있다라는 게 이제 첫 번째 쟁점이구요. 제가 약간 전에 요거 SDK 별로도 에러 인셉션 헤드링이 너무 어렵다 라고 말씀드렸는데 그 라이델에 대해서는 굉장히 사랑스럽게도 그냥 저 APA 타임아웃 오픈 에이 하던 APA 타임아웃이지만 사실 모든 모델에 대한 타임아웃이 저 클래스에 걸리게 되었거든요. 그러니까 에너리셉션도 우리가 사용하는 모든 모델에 대해서 타임아웃이면 서로 에러로 그냥 우리가 던져버릴 수 있게 되는 거예요. 그래서 뭐 잘 안 보이시긴 하시겠지만, 익셉션 다운라인이 리트라이를 하는 저런 서비먼스도 짤 수 있게 되죠. 이게 어떻게 가능할까 하면은 이 엄청난 수작업을 라인하는 개발자분들이 맛라 있는 코드로 익셉션 핸드백만 해 놓으셨습니다. 엔트로픽 타임 아웃 뭐 에저 타임 어웃 타임 사랑하지 않을 수 없죠 네 그리고 우리가 RNLM 이후에 조금 더 욕심을 내본다면은 라우트 MLM 개념까지 적용을 해보려고 할 것 같아요. 락 LLM은 비교적 최근에 나온 개념이긴 한데 그 여기 LMCS 뭐 체포나 아레나 이런 거 많이 들어보셨죠 모델 나올 때마다 모델끼리 견주는 그런 플랫폼인데 그 CHATFORM RNA를 만드는 LMCS 연구진이 제안한 논문이고요. 저기 보면은 아이디어 라운터가 지금 이 코스트는 저렴한데 퍼포먼스는 GP45보다는 아니지만, 근사한 퍼포먼스 위치해 있는 겁니다. 그러면은 이 말이 즉슨 라마트리 에이필리언을 쉬운 컬에 대해서는 라마토리 에이필리언을 쓰고 좀 어려운 컬에 대해서는 지금 피지컬 올을 쓰는 트레이오프를 통해가지고 포스트도 저렴하고 퍼포먼스는 어느 정도 근사할 수 있는 시스템을 만들 수 있다라는 게 로아델럭 LED가 제안하는 프레마트고요. 아까 제가 말씀드렸던 성능보다 속도 비용이 더 중요한 비즈니스에 대해서는 라데레랑 같은 케이스를 적용을 해야 합니다. 사실 그래서 실제로 뭐 라우데리아 레포트 레퍼스토리의 리듬에 보시면은 이러한 예제가 있는데, 아까 제가 한 걸 공유롭게도 똑같네요. 사용자가 핸거우를 하면서 허리를 날렸죠 이때는 그냥 믹스트라를 뛰는 거예요. 믹스트라리 절여가고 충분히 그 고자를 하니까 근데 뭐 스피어노트 스피어노트 아 뭐 저 큰 수에 대한 스플레이터를 보여달래요. 하면은 조거는 믹스트리얼을 모른다라고 못 풀겠다. 지금 비포 브로 같은 틀린다 이러한 이제 라운팅을 하는 개념인 거죠. 이게 실제로 라디벨은 사실 그 패키지가 논문이어서 논문의 그 포스트 세이빙이 얼마나 되고 있는지에 대한 그 수치가 나와 있어요. 보시면은 코스트가 얘네가 제외하는 게 매트리스 메커레이션 기반의 라우터거든요. 그래서 두 번째 로우를 보시면 되는데 코스트가 1.42인데 리캐스트는 1초당 155배예요. 그 뭐 70배의 일케스트를 더 받을 수 있고 비용은 37배 저렴한 이런 걸 만들었다고 하는데 사실 LMM이 제시하는 게 중요한 건 아니에요. 그냥 앞에 라우터를 붙여가지고 모델을 라우칭하는 개념 자체가 중요한 거죠. 여기까지 오케스트레이션이고요. 저는 다시 개발한다면, 파이스 오너 로봇 가정 라이데레미가 라우터 개념을 도입하는 것에 첫 번째로, 고려를 하겠다라는 게 첫 번째 제안이었고요. 두 번째는 여기서부터 갑자기 어 개발자가 어디야 갑자기 이런 소리 하지라는 이야기들이 점철된 COSTROPRATION입니다. 그래요. LNN 같은 것들이 나오는 게 뭐 속도도 중요하지만 당연하게 또 비용이 중요하기 때문이에요. LNM 비용이 그 지피티커로 굉장히 나오고 나서 와 이거 진짜 저렴하다 저렴한 게 맞죠. 근데 그게 스케일 타면은 엄청 비싸죠 사실 그래서 많은 기업들이 그 그 스타킹 포인트에 대한 비용만 보고 쉽게 이제 어플리케이션 개발을 시작했다가 이제 트래픽 올라가면서 어 비용 관리가 안 되는 그런 어려움을 겪기 마련인데 결국 뭐 그거죠. 캐시 서킹 비즈니스를 만들었는데 근데 우리 모두가 여긴 여기는 모두가 아니지만, 영내 기업은 결국 제품을 통해 이윤을 만들어내야 되는 조직이에요. 그리고 원래는 서브 포스트 같은 것들을 일반적으로 소프트웨어 비즈니스 해서 보통은 이제 픽스토 코스트 고정비로 들어가는데 LLL 코스트가 너무 비싸다 보니까 요즘에는 그 LN 코스트를 변동비 성격으로 간주를 하는 비즈니스 굉장히 많아요. 저희도 그렇게 프로젝션을 하고 있구요. 그러면은 엔지니어로서 우리는 비즈니스 바질을 높이기 위해서 엘의 행진 최속화를 해야 합니다. 해내야 합니다. 그래야지 기업 이윤이 올라갈 수 있는 그 비즈니스 임팩트에 들근한 엔지니어가 될 수 있습니다. 갑자기 그래서 이렇게 일을 위해서 일단 첫 번째로는 그 에이저 시스템은 수많은 컴포넌트 LLM 브레이스트 컴포넌트로 이루어지잖아요. 보통 일반적으로 그러면 우리 시스템에서 어느 어느 녀석이 굉장히 돈을 많이 모으는 컴포넌트에 대한 이해인지에 대한 이해를 굉장히 높일 수 있어야 돼요. 그래서 미시적 관점에서 보면은 컴포넌트 단위 비용 비중이 우리 시스템에서 어떻게 구성되고 있는지 이런 것에 대한 프레차트로라도 세팅이 되어있어야 된다고 생각을 하구요. 그리고 각각의 컴포넌트에 대해서 이제 일자별로 어떻게 지금 프럭세이션이 발생하고 있는지까지 이제 우리가 트랙킹을 할 수 있어야 합니다. 당연하게도 이제 앞에가 미시적 관점이었다라고 하면은 전체적 관점에서는 우리가 지금 사용하고 있는 프로바이더들에 대해서 일간 비용지불이 어떻게 형성되고 있는지도 당연하게도 자동화 통해서 관측을 해야 합니다. 너무 그 원론적인 이야기인데 저는 LLBS 애플리케이션을 만드는 조직이 된다고 하면은 코스트 오플레이션을 아예 처음에 상정하지 않으면 안 되는 조직이라고 생각을 해요. 왜냐하면, 변동의 성격이 되었을 만큼 너무 비싼 기술이 되었기 때문이라고 생각을 하구요. GPT CHATCPT도 보시면은 그 CHATCPT가 뭐 한 2달 전에 무료로 풀렸죠 사실 리미티드 슬리버레전이긴 한데 보면은 플러스 유저한테는 3시간마다 80개의 메시지를 주고 베이징 유저는 40개를 준다고 해요. 이거 도대체 어떻게 저런 숫자가 나오는 거예요. 왜 80이고 왜 40인가 이러한 것들도 우리가 고려를 많이 해봐야 되는데 이럴 수 있죠. 그 우리도 LABS 애플리케이션을 만들었는데 모든 사용자한테 무제한으로 풀기는 부담이 있어 그래서 모든 사용자한테 몇 시간 제한을 걸어가지고 이 정도까지만 사용할 수 있게끔 그리고 이 리밋에 걸렸을 때는 뭐 서스트라이블 함께 유도한다던지 이러한 비즈니스를 만들어낸다고 할 때 저 숫자 84세는 도대체 어떻게 나온 걸까 요거를 우리가 계산을 할 수 있어야 되는데 계산을 할 건 아니에요. 그 이것도 원론적인 이야기긴 한데 결국에는 우리 비즈니스가 지금 1명의 사용자로부터 얼마를 벌어들일 수 있는지 큰 애들 LTV라고 얘기하죠. 이 LTV를 알고 있어야 돼요. 그리고 다시 라이델레엠으로 돌아오게 되는데 라이델앤엠에 그 버젯 매니저라는 개념이 있어요. 버젯 매니저라는 개념은 이제 뭐 특정 데이터베이스에다가 걸어 가지고 이 데이터의 이 데이터베이스의 사용자가 일간으로 지금 코스를 얼마나 배생시키고 있는지를 계속 트래킹을 하는 개념이에요. 그래서 보시면은 이제 버젯 매니저 어 이 유저 단위로 지금 소통을 하고 있죠. 만약에 사용자가 이 리스폰스를 컴플렛하면은 업데이트 포스트 해주고 이게 다 마감이 되면은 얘한테 이제 답변을 해줄 수 없다라는 이제 에러 헤슬링이 일어나게 됐는데 이런 식으로 그 사용자 단위로 평균 어느 정도의 그 사용량이 일어나고 있는지에 대한 측정이 이루어지게 되면은 이 적정 투자 가능 수치를 제품을 적용할 수 있게 돼요. 왜냐하면, 사용자가 평균으로 얼마 쓰고 있는지 계산됐죠 그리고 사용자가 평균적으로 얼마 벌어들일 사용자로부터 얼마나 벌어들일 수 있는지 계산이 됐죠 그러면은 이걸 역산하면은 어 한 사용자한테는 이 정도만 제공을 해야 돼라는 것을 우리가 어솜션을 늘릴 수 있죠. 그러니까 이 정도로 기반해 가지고 포스트 오퍼레이션을 할 수 있는 인지니어링 시스템을 만들어 놔야 한다라는 게 두 번째 제안 추천이었습니다. 그리고 그 LMM 여러 개 쓰다 보면은 아 그거 얼마였더라 하는 생각들 진짜 많이 하거든요. 근데 확인 페이스에 감사하게도 이런 발육비유 부분 다 올라와 있어요. 그래서 이 프로바이더별로 어떤 모델들이 지금 어떤 모델 대비해서 얼마나 저렴하고 비싼지까지 인제 그 모델링이 되어 있으니까 이런 것 잘 참고해서 그 포스트라프레이션 하는 데 대해 참조하시면 좋을 것 같습니다. 포스트로프레이션의 좀 내용이 중구난방에서 제가 정리를 한번 해보려고 했는데 그 LLM에 투자 가능한 수준에 대해서 비용적 감각을 처음에 지니고 있어야 된다. 그리고 비용적 감각이 생기면은 이에 기반해서 아까 라인 LLM에서 제시했던 BASETING 혹은 원인 그런 쓰레소리드 같은 것들을 적용을 할 수 있게 됩니다. 그리고 뭐 엔지니어들만 이 일을 하는 게 아니잖아요. 당연히 이제 파이켄스 분들도 계실 거고, 그 피해자들도 계실 테니까. 이 비용 감각을 우리가 가지고 있는 것들을 전사 차원에서 공유할 수 있게 모니터링이라든지. 시각화 같은 것들을 강화하는 작업이 엔지니어 사이드에서 굉장히 중요하고요. 그 LAM 담당하는 조직은 결국 성능 비용 습도 저삼위일체를 어떻게 만족시킬 수 있느냐에 대한 싸움을 계속 하는 조직이라고 생각해요. 그래서 저 새 항을 좀 그 민감하게 바라보는 게 중요하다 라는 게 제 생각이고요. 저 새 요인 중심으로 어 3큐에는 성능을 얼마나 끌어올리겠어 근데 그때 비용 거짓은 얼마야 이런 것들을 기반으로 목표 설정하고 최적화 위한 동력을 만들어 나가는 것을 추천드립니다. 네 마지막이고요. 마지막은 이제 너무 클리셰 같은 안전 프라이킹입니다. 그 이거는 정원은 아니고 저희가 그 어플리케이션 만들면서 파인튜닝을 위한 사이즈가 대충 이 정도로 구성이 되고 있구나라고 생각을 했던 부분이에요. 사이즈 1은 가능하겠지만, 오픈 AI의 엔트로피컬 제미네이 같은 메가 프로벤더들을 활용해서 어플리케이션 구현하는 개념이에요. 이때 근데 요즘 아시겠지만, 오픈 에이어는 엔트로픽이나 다 그 페프트 정도의 로런댑터 파이팅 다 지원을 하고 있어요. 그래서 여기서부터 사실 파인팅을 시도는 해볼 수 있구요. 그 페이즈 투가 투게더 AI나 파이너스 AI 같은 기업 혹시 들어보신 분이신가요? 투게더 AI 거 같은데, 쉽게 얘기해서 이런 비즈니스를 하는 모습들이에요. 어 라마토리 405빌리언 나왔대 그럼 써보고 싶잖아요. 근데 저걸 올릴 수가 없잖아요. 근데 405밀리언짜리 모델을 올려 가지고 오픈에 마치 오픈 에이아이 마냥 너네 그 405밀리언 모델 쓸려면은 1밀리언에 얼마 정도 1밀리언 토크네 얼마 정도 내야 돼 그래서 오픈 소스 가지고 페이 예술부 서비스를 하는 곳이자 그 서비스를 쓰다 보면은 어 405빌리언 파인팅도 해고 싶은데 어 파이팅 하고 싶지 여기서 파인터닝에 우리 405빌리언 떠 있으니까 여기다가 어댑터 붙여 가지고 파인팅 할 수 있게 도와줄게요 그런 서비스들을 하는 게 이제 플레이스 투 기업들이에요. 이 기업들은 들으시면 아시겠지만, 대신 해주는 거야. 대신 해주는 거예요. LNM 오픈 소스 LNM 서빙도 다시 해주고 오픈 소스 LLM에 기반한 어댑터 수준의 파이팅도 대신해주는 곳이고 그러다 보니까 엠엘 엔지니어가 임플루언스라든지 트레이닝 캠페빌리티가 그렇게 높지 않아도 돼요. 저 기업들을 활용을 하면 되니까. 이런 기업들도 당연하게 계속 트래프트 같은 것도 지원을 하고 있구요. 여기서 이제 넘어가면은 그 진짜 GPU 임대해 가지고 직접 하는 단계가 되는 거죠. 그러면 이제 뭐 자유도가 엄청 높아져요 팩트 할 수 있는 거고, 그다음에 풀퍼랜드 채널을 할 수도 있는 거고, 아니면 그냥 아예 우리는 이제 파격충이 아니다. 포스트레밍이라고 간주하고 길게 길게 본다라고 할 수도 있는 거고, 이때 되면 이제 GPU 클러스터도 확보를 해야 되고 GPU 클러스터 확보하면 되는 게 아니죠. 사실 엠엘 엔지니어 중에서도 트레이닝 할 수 있고 임플란스 할 수 있는 사람들이 있어야 된다더라구요. 그런 사람들이 많이 시장이 없으니까 페이즈 투 기업들이 나오는 거예요. 파이팅 잘 못하고 서빙 잘 못 하니까 그래서 저희는 한 이 정도에 지금 머물러 있어요. 지금 파인업스와 프라임 채닝은 아 저희 그 협력서에서 나온 겁니다. 파인억스 그 파인트닝을 5 스포 해가지고 하는 과정을 거쳐가지고 이제 GP 플루스터 기반으로 해서 자체 파인튜닝을 할 수 있는 인프라라든지 테마트를 구축하는 요 단계에 넘어가는 2.23단계에 위치해 있습니다. 네 아까 그 전 발표에서 재단도 되게 잘 얘기해 주셨는데 그 파이 튜닝 하기 전에 LNM 진짜 많이 써보고 진짜 필요한지 잘 판단해야 된다라는 말씀을 해주셨잖아요. 저는 이거 완전히 공감해요. FILITORING 사실 모델들 발전 속도가 너무 빨라 가지고 사실 파인 튜닝을 하지 말아야 될 이유를 찾는 게 더 빠르죠 그럼에도 불구하고, 우리 기업은 왜 파인트닝을 가야 하는가에 대해 찾는 게 그다음이고요. 저는 이 세 팩터 외에는 최근에는 파인트닝을 위한 메리트가 많이 없어지고 있다고 생각을 하는 편인데 첫 번째는 캐시예요. 결국에는 파인튜닝 해가지고 포스트 옵티메이션을 이뤄낼 수 있느냐 이거에 대한 프로젝션을 통해 가지고 그 결정을 하는 거죠. 그런데 이런 거 하다 보면은 갑자기 미니 같은 모델 나오는 프레이션이 다 깨지게 돼요. 사실 그럼에도 불구하고, 그 미니 나오고 나서 프렉션 계속하면서 우리가 그럼에도 불구하고, 옵티마이제이션을 캐시 사이즈에서 할 수 있는지를 점검하는 게 첫 번째 파인트닝을 위한 팩터라고 생각을 하고요. 두 번째는 이거는 좀 도전적이고 기술적인 이야기인데 그냥 아니야. 우리 기술적으로 무조건 파이트니가 좀 어떤 특정 컴포먼트에 대해서 잘 알 수 있어라고 할 수 있겠죠. 실제로 이런 플레이들을 지금 파이옥스 같은 기업들을 굉장히 많이 하고 있어요. 지금 시장 보시면은 파이옥스 투게더 그것도 마찬가지고 다 보면은 어 우리 기업들 펑션콜링 전용 모델 만들어서 제공할 겁니다. 이거 다 보셨나요? 파이어스랑 소개더랑 그룹이랑 다 펑션 컬링에 집중하고 있어요. 그냥 GPU 클러스터만 서빙하는 곳이 아니라 자체 모델까지 팔고 싶은 거죠. 근데 그 영역을 마치 프라이크 펑션 폴링이고 싶다. 왜냐 에이전트 시즌이 너무 코어 퍼포넌트거든요. 펑션 컬링이 그래서 이러한 결정도 실제로 할 수 있긴 해요. 세 번째가 가장 강력하죠. 우리가 레버리지 할 수 있는 그 우리만의 지적자산권들이 있는 경우예요. 가장 강력하죠. 그냥 다른 곳에서는 프라이큐닝을 통해가지고 낼 수 없는 성능을 낼 수 있으니까 이거는 아마 기업 담당자분들이 아실 거예요. 이거 우리밖에 없는 데이터인 걸 아셔야 되니까. 이 과정들이 지나면은 그 파인드라는 문제 정의가 진짜 필수적이라고 생각해요. 그냥 요즘에 합성 데이터 너무 잘 나오니까 합성 데이터 그냥 대충 만들어 가지고 넣으면 피니얼은 사실 성능 올라가긴 하는데 그리고 나서 그 BHBO 보면은 되게 알 수 없는 선택들이 굉장히 많거든요. 그래서 어떤 컴포넌트 하나하나를 정의할 때도 그 문제 정의와 컴포넌트 정의가 같이 이루어져야 돼요. 데이터 시스템에서 어떤 특정 LM 컴포넌트 있다고 했을 때 얘는 어떠한 결정들만 해야되는 애다 뭐 제약직 컨트라인도 있을 것이고. 그 선호되는 행동도 있을 것이고. 이런 것들에 대해서 정일 악단에서 시간이 많이 걸리더라도 좀 빡세게 하고 가는 것을 저희도 지향하는 편이구요. 당연하겠지만, 그 과정에서 어 이거 우리가 정의한 대로 잘 했어. 못했어를 판단하기 위해선 메트릭이 필요하죠. 제가 원래 EBILEATION을 가져오려다가 EBILEATION 얘기는 지금 바깥에 너무 많아서 제가 굳이 가져오진 않았고 학습과정에서 측정할 수 있는 MATRIC에 대한 정의가 필요합니다. 인식이 그래서 매트릭이 대충 어떤 식으로 설정이 되고 이 매트릭을 판단할 수 있는 근거가 될 수 있는 테스트셋은 이렇게 우리가 확보를 하자 근데 그 LM 컴포먼트부터는 굉장히 비정형의 레벨로 넘어갔잖아요. 전통적으로 우리가 분류 어떻게 잘했어. 랭킹 어떻게 잘했어를 넘어서서 얼마나 잘 썼어 얼마나 되게 컨덴스하게 요하게 잘했어. 이런 것까지 넘어가다 보니까 그 정량적 지표를 만드는 데 굉장히 어려움이 있는 건 사실이고 결국에는 이제 그러한 것들은 LMS 젖지로 빠지게 되는 거 같애요. 그 LMS 젖지 너무 유명하니까 여기 설명을 안 드리겠습니다. 이렇게 이루어지면은 결국에는 우리가 지금 그 견주고 싶은 모델이 이 태스크에 대해서 해당 테스트셋에 비하여 어느 정도 성능을 내리는지에 대한 레트릭싱이 이뤄져야 되겠죠. 이걸 이제 우리가 에세이지로 두는 거예요. 얘네를 이겨야 한다. 그리고 이제 학습을 통해가지고 최종적으로 우리가 설정한 문제가 있었고, 설정할 매트릭이 있었고, 인세이션이 있었을 때 그 투비가 되고 싶었던 우리 모델은 어느 정도의 매트릭을 기반으로 지금 성능이 되고 있는가를 측정을 하는 과정을 통해서 파인팅을 이뤄낼 수 있다고 보고 있습니다. 네 발표는 여기까지고요. 저희 에이션 시스템 진짜 재미있게 빡세게 만들고 있고 아직도 에밀리를 계속 체험하고 있고 급하게 된 지점을 많이 체험하고 있으니까 관심 있으신 분들 언제든지 연락 주시면 감사하겠습니다. 감사합니다. 중간에 질문을 받았기 때문에 이번 질문 넘어가도록 하겠습니다. 따로 질문이 있으신 분들은 손님께 세션이 끝난 후에 진행해 주시면 감사드리겠습니다.