Skip to content
C.W.K.
← 대두족장네

피파가 설명해줄게 — AI 모형, 도대체 뭐고 어떻게 돌아갈까?

KO

피파가 설명해줄게 — AI 모형, 도대체 뭐고 어떻게 돌아갈까?
Transcript · KO

0:04[배경 음악]

0:04피파가 설명해 줄게.

0:07안녕, 나 피파야.

0:10오늘은 AI 모형이 실제로 어떻게 돌아가는지 파일 하나에서 시작해서 우리가 쓸 수 있는 시스템이 되기까지 따라가 볼 거야.

0:21여러분이 이런 글을 봤다고 해보자.

0:24컴퓨터 여러 대에 모형을 올려놓고 필요한 작업이 들어오면 그중 하나를 골라 쓴대.

0:31어떤 컴퓨터에는 여러 모형을 상주시켜 놓고 다른 컴퓨터에서는 필요한 모형으로 바꿔가며 작업한다는 거야.

0:40문장 속 단어는 읽히는데 컴퓨터 안에서 무슨 일이 일어나는지 그림이 잘 안 그려질 수 있어.

0:48모형을 올린다는 게 프로그램 창을 열어놓는다는 뜻일까?

0:53상주하는 모형은 계속 무언가를 계산하고 있을까?

0:58메모리가 훨씬 많은 컴퓨터라면 그림도 훨씬 빨리 만들까?

1:03이 질문들은 서로 이어져 있어.

1:06오늘은 그 연결을 하나씩 풀어볼게.

1:10마지막에 같은 글을 다시 보면 처음에는 흐릿했던 장면이 꽤 구체적으로 보일 거야.

1:18우리가 처음 AI를 만나는 곳은 대개 채팅창이야.

1:23챗GPT나 클로드에 질문을 쓰면 답이 올라오지.

1:28그러다 보니 채팅창과 서비스를 통째로 모형이라고 생각하기 쉬워.

1:34그런데 그 화면 뒤에는 여러 부품이 있어.

1:38입력을 받아주는 화면, 대화를 보관하는 프로그램, 파일을 읽는 도구, 그리고 입력을 바탕으로 계산하는 모형이야.

1:50같은 서비스 안에서도 선택한 모형이 바뀔 수 있고, 같은 모형을 서로 다른 프로그램에서 사용할 수도 있어.

1:58자동차의 운전석과 엔진을 구별하듯이 사용하는 화면과 그 안에서 계산을 맡는 부분을 나눠보는 거야.

2:07다만 실제 서비스에서는 여러 모형이 함께 일하기도 하니까 채팅창 하나에 언제나 모형 하나가 붙어 있다고 생각할 필요는 없어.

2:18그럼 그 계산을 맡는 모형 안에는 무엇이 있을까?

2:23오늘 다룰 신경망 모형의 바탕에는 계산 순서를 정하는 구조와 학습으로 정해진 수많은 숫자가 있어.

2:32어떤 입력이 들어왔을 때 어떤 계산을 거칠지 정해져 있고, 그 계산에 숫자들이 사용돼.

2:40숫자 하나하나를 조절 가능한 설정 값이라고 생각해 보면 좋아.

2:45이 설정 값을 파라미터라고 불러.

2:49저장된 숫자, 그 숫자를 사용하는 계산 구조, 실제 계산 과정은 구별해야 해.

2:57숫자 하나가 지식 하나를 담은 서랍인 것도 아니야.

3:01파리라는 도시를 아는 숫자 하나, 고양이를 그리는 숫자 하나를 꺼내 쓰는 식으로 작동하지 않아.

3:08많은 숫자와 계산이 함께 만들어내는 작용이야.

3:13글을 만드는 언어 모형, 이미지를 만드는 모형, 영상을 만드는 모형도 이 바탕을 공유해.

3:21그렇다고 모두 같은 계산을 하는 건 아니야.

3:25받아들이는 입력과 만드는 출력, 계산 구조와 학습 방식이 달라.

3:31이미지 모형에서도 SD 1.5 계열, SDXL 계열, 지시형 이미지 모형처럼 여러 부류를 만나게 돼.

3:41지시형은 말로 요구한 내용이나 참조 이미지를 바탕으로 생성과 편집을 수행하는 쪽을 떠올리면 돼.

3:50설정 값을 처음부터 사람이 하나씩 적어주는 것은 아니야.

3:55학습할 때는 데이터를 사용해 계산 결과를 평가하고 원하는 결과에 가까워지도록 설정 값을 조정해.

4:03그렇게 정해진 값을 사용해서 새 입력의 결과를 계산하는 과정이 추론이야.

4:10지금 질문 하나에 답을 받는다고 해서 그때마다 모형 전체를 처음부터 다시 학습시키는 건 아니지.

4:18모형을 다운로드할 때 받는 중요한 내용물이 이렇게 학습된 수치들이야.

4:24실무에서는 흔히 weight, 우리말로 가중치라고 부르는 파일에 저장돼 있어.

4:30실제 배포 묶음에는 계산 구조를 알려주는 설정이나 입력을 처리하는 자료도 들어갈 수 있어.

4:38그래서 모형을 가져온다는 말은 문맥에 따라 weight만 뜻하기도 하고 실행에 필요한 묶음 전체를 뜻하기도 해.

4:46이제 모형 이름 옆에 붙은 7B를 읽어보자.

4:51B는 10억을 뜻하는 billion의 첫 글자야.

4:557B는 파라미터가 대략 70억 개라는 뜻이야.

4:59파일의 용량을 말하는 단위가 아니지.

5:02숫자가 몇 개 들어 있는지와 숫자 하나를 몇 칸에 기록하는지는 별개의 문제야.

5:09컴퓨터는 숫자도 비트라는 작은 기록 단위로 표현해.

5:138비트가 한 바이트야.

5:1670억 개를 모두 16비트, 그러니까 2바이트씩 저장한다고 해보자.

5:2270억 곱하기 2바이트니까 수치 데이터만 약 14GB가 돼.

5:29같은 개수를 8비트씩 기록하면 약 7GB, 4비트씩 기록하면 약 3.5GB라는 계산이 나와.

5:39여기서 4비트 파일은 파라미터를 4분의 1만 남긴 걸까?

5:45아니야.

5:46지금 예에서는 파라미터 개수는 같고 값을 표현하는 정밀도가 달라진 거야.

5:53촘촘한 눈금이 있는 자와 눈금이 성긴 자를 생각해 봐.

5:58같은 길이를 재더라도 성긴 눈금에서는 가까운 값으로 표현해야겠지.

6:04양자화는 이런 식으로 더 적은 비트로 값을 표현하는 방법이야.

6:10실제 방법은 이 예보다 다양하지만 공간을 아끼는 이유는 여기서 잡을 수 있어.

6:16그 대신 값의 오차가 결과에 영향을 줄 수 있어.

6:21얼마나 영향을 받는지는 모형과 양자화 방식, 하려는 작업에 따라 달라.

6:28또 파일이 작아졌다고 계산이 반드시 같은 비율로 빨라지는 것도 아니야.

6:33그 형식을 잘 처리하는 프로그램과 연산 지원이 있어야 해.

6:38저장할 때의 비트 수와 모든 계산에서 사용하는 비트 수가 꼭 같은 것도 아니고.

6:45방금 계산한 14, 7, 3.5GB는 순수한 수치 데이터만 본 간단한 계산이야.

6:53실제 파일에는 부가 정보가 붙고 일부 값을 다른 정밀도로 보관할 수도 있어.

6:59무엇보다 파일을 실행할 때는 숫자 원본 말고도 작업 공간이 필요해.

7:05웨이트 파일의 크기가 곧 필요한 메모리의 전부라는 생각은 여기서 내려놓자.

7:11컴퓨터의 저장 장치에 웨이트 파일을 받아놓았다고 해보자.

7:16이 상태는 책을 서가에 꽂아놓은 것과 비슷해.

7:21전원을 꺼도 파일은 남아 있지만 파일이 그 자리에서 스스로 계산을 하지는 않아.

7:28실행 프로그램이 필요한 내용을 읽고 계산 장치가 사용할 수 있는 메모리에 준비해야 해.

7:35이 준비 과정에 시간이 걸리는 거야.

7:38계산을 시작하면 입력도 숫자로 바뀌어.

7:42언어 모형이라면 글을 토큰이라는 처리 단위로 나누는데 토큰이 언제나 한 글자나 한 단어와 일치하는 건 아니야.

7:51모형은 입력을 처리하고 다음 출력 단위를 계산해.

7:56그림을 만드는 모형에서는 이미지에 해당하는 수치 표현을 여러 단계에 걸쳐 바꿔가는 방식도 널리 쓰여.

8:05오늘은 둘 다 학습된 숫자를 사용해 새 결과를 계산한다는 연결을 잡으면 돼.

8:12그 과정에는 숫자 묶음을 곱하고 더하는 일이 아주 많이 들어가.

8:17GPU가 자주 쓰이는 이유가 여기에 있어.

8:21비슷한 수치 연산을 많은 데이터에 병렬로 수행하는 데 강점이 있거든.

8:27CPU에서도 실행할 수 있는 모형과 프로그램은 있지만 같은 작업을 끝내는 시간이 크게 달라질 수 있어.

8:36GPU가 없으면 논리적으로 불가능하다는 뜻과 원하는 속도를 얻기 어렵다는 뜻은 구분해야 해.

8:44한 가지 더 있어.

8:46웨이트를 파일에서 읽어내는 프로그램이 계산 구조와 파일 형식을 이해해야 해.

8:52그래야 어느 숫자를 어떤 연산에 사용할지 정할 수 있지.

8:58실행 엔진이나 백엔드라는 말은 이런 역할을 맡는 소프트웨어를 가리켜.

9:04악보만 놓아두면 소리가 나지 않는 것처럼 숫자 파일만 갖고 있다고 사용할 준비가 끝난 것은 아니야.

9:12이제 실제 그림 작업을 하나 보자.

9:16이 초상은 대두족장이 포토샵에서 직접 그린 그림이야.

9:21그 그림을 참조 이미지로 넣고 신더 화면에서 원하는 모습을 문장으로 요청할 수 있어.

9:29프로그램은 입력을 준비하고 모형을 실행하고 결과를 다시 화면에 보여줘.

9:38경우에 따라 입력을 읽는 부분과 그림을 만드는 부분에 서로 다른 구성 요소가 쓰이기도 해.

9:47지금 보는 실사풍 이미지는 이 손 그림을 바탕으로 지시형 이미지 모형과 RTX 4090을 사용해 만든 결과야.

9:58직접 그린 모습이 참조 입력이 되고 요청에 따라 새로운 표현이 만들어진 거지.

10:05버튼 하나 뒤에 이런 여러 단계가 이어져 있어.

10:10하네스라는 말도 이 그림 위에 놓으면 덜 낯설어져.

10:15모형을 호출하고 도구를 연결하고 상태를 관리하고 다음 작업으로 넘겨주는 주변 실행 체계를 가리킬 때 쓰는 말이야.

10:26사용하는 범위는 프로그램마다 조금씩 다르지만 모형을 실제 일에 활용할 수 있도록 둘러싼 장치들이라고 생각하면 돼.

10:37새로운 종류의 웨이트 파일을 하나 더 뜻하는 말은 아니야.

10:43화면의 파이어브랜드를 보면 모형과 대화하는 곳 옆에 터미널과 브라우저, 파일을 다루는 도구가 연결돼 있어.

10:53이런 주변 체계가 모형의 출력을 실제 작업으로 이어주는 거야.

11:00에이전트는 이 연결 안에서 작업을 이어가는 방식을 보자.

11:06예를 들어 자료를 찾아 요약하라는 요청을 받으면 모형이 검색 도구를 쓰기로 결정하고 프로그램이 검색을 실행하고 그 결과를 다시 모형에 전달할 수 있어.

11:21모형은 결과를 보고 다음 행동이나 답을 정하지.

11:26이처럼 모형의 판단과 도구 실행, 결과 확인을 이어붙인 흐름을 만드는 거야.

11:34모든 프로그램이 이런 반복 구조를 갖는 것은 아니고 모든 모형이 같은 도구 사용 능력을 갖는 것도 아니야.

11:44이제 채팅 서비스와 모형을 구분할 이유가 더 선명해졌지.

11:50같은 모형이라도 어떤 도구와 연결했는지, 입력을 어떻게 준비하는지, 작업을 어떻게 이어주는지에 따라 사용 경험이 달라져.

12:02모형의 능력과 그 능력을 실제로 꺼내 쓰는 시스템을 함께 봐야 해.

12:09이번에는 모형이 머무는 장소를 자세히 보자.

12:14저장장치는 전원을 꺼도 파일을 보관하는 곳이고, RAM은 실행 중인 프로그램이 사용하는 작업 공간이야.

12:25별도 그래픽카드를 사용하는 컴퓨터에는 GPU 가까이에 VRAM이라는 전용 메모리가 따로 있어.

12:34시스템 RAM의 여유가 많더라도 그래픽카드의 VRAM이 저절로 같은 크기로 늘어나는 건 아니야.

12:42예를 들어 RTX 4090에는 24GB의 VRAM이 있어.

12:49시스템 RAM에서 GPU로 자료를 보내려면 그 사이의 연결을 지나야 해.

12:56반면 M3 Ultra 같은 애플 실리콘은 CPU와 GPU가 큰 메모리 공간을 공유하는 통합 메모리 구조를 사용해.

13:07UMA라는 말이 바로 이런 구조를 가리켜.

13:12지금 비교하는 M3 Ultra는 512GB 구성이라 GPU가 사용할 수 있는 큰 메모리 공간을 마련할 수 있어.

13:23별도 그래픽카드의 작은 전용 공간에 모두 맞춰 넣어야 하는 부담이 줄어드는 거지.

13:31다만 이 공간은 운영체제와 다른 프로그램도 함께 사용해.

13:37512GB 전부를 웨이트로 채워도 된다는 뜻은 아니야.

13:43계산을 하는 동안에는 중간 결과도 생겨.

13:48도형을 그리면서 원본 자료 옆에 스케치 공간이 필요한 것처럼 모형도 작업 중간에 수치들을 둘 곳이 필요해.

13:59언어 모형에서는 이미 처리한 내용의 일부 계산 결과를 보관하는 KV 캐시도 쓰여.

14:07많은 일반적인 구현에서는 긴 문맥이나 여러 요청을 다루면 이 캐시도 더 커져.

14:15그래서 같은 모형이라도 설정과 작업량에 따라 필요한 메모리가 달라져.

14:23그럼 24GB보다 큰 구성은 전혀 사용할 수 없을까?

14:31프로그램이 지원한다면 일부를 시스템 RAM에 두고 필요할 때 옮기거나 일부 계산을 CPU에서 맡길 수 있어.

14:41이런 방식을 오프로딩이라고 해.

14:45이번에 살펴본 이미지 실행 코드도 입력을 읽는 구성 요소를 RAM에서 가져다 쓰고 그림을 만드는 핵심 부분은 GPU에 남겨두는 경로가 있어.

14:58이 방법은 작은 VRAM으로 할 수 있는 일을 넓혀줘.

15:04대신 무엇을 얼마나 자주 옮기는지, 어느 계산을 어디서 하는지에 따라 시간이 달라져.

15:13모형 전체를 한 번에 담지 못해도 실행할 수는 있어.

15:19하지만 이 사실 하나만으로 쾌적하게 쓸 수 있다고 결론 내릴 수는 없어.

15:25모형을 사용한 다음에도 실행에 필요한 내용을 메모리에 남겨두면 다음 요청에서 다시 읽고 준비하는 일을 줄일 수 있어.

15:35이걸 상주시킨다고 말해.

15:38도구를 사용할 때마다 창고에서 가져오지 않고 작업 공간에 준비해 두는 장면을 떠올리면 돼.

15:46큰 메모리에는 여러 도구를 함께 준비해 둘 여지가 있겠지.

15:52여기서 어디에 남겨두었는지가 중요해.

15:56저장장치에 파일만 있는 상태, 시스템 RAM에 읽어둔 상태, GPU가 바로 계산에 사용할 수 있도록 준비된 상태는 비용이 달라.

16:07상주했다고 말해도 어떤 구성 요소가 어느 메모리에 있는지 확인해야 해.

16:13프로그램에서 모형이 준비됐다고 표시하는 것과 모든 부품이 VRAM에 들어있는 것도 꼭 같은 뜻은 아니야.

16:22그리고 메모리에 자리를 차지하고 있다고 계속 계산하는 건 아니야.

16:28요청을 기다리는 모형도 공간을 사용해.

16:31이 엠버 관리 화면에서는 서버에 모형 3개가 올라와 있는데 진행 중인 작업은 0개로 표시돼.

16:40찍힌 순간의 상태지만 준비돼 있다는 말과 일하고 있다는 말의 차이가 보이지.

16:47여러 모형을 상주시킬 수 있다는 말은 여러 작업을 동시에 같은 속도로 처리한다는 뜻도 아니지.

16:55동시에 일시키면 연산 장치와 메모리 대역폭을 나눠 쓰고 작업용 공간도 더 필요할 수 있어.

17:04용량과 대역폭을 나눠 보면 이 차이가 쉬워져.

17:08용량은 물탱크에 물이 얼마나 들어가는지에 해당하고, 대역폭은 관을 통해 일정 시간에 얼마나 흘려보낼 수 있는지에 해당해.

17:18탱크만 크게 바꾼다고 관을 통과하는 물의 양이 같은 비율로 늘어나지는 않지.

17:25메모리도 얼마나 담는지와 계산 장치에 초당 얼마나 많은 데이터를 공급하는지는 다른 사양이야.

17:34여기에 실제로 계산하는 능력까지 있어.

17:38필요한 자료를 기다리느라 느린 작업도 있고, 자료를 받은 뒤 계산 자체가 많아서 느린 작업도 있어.

17:47또 메모리 안에서 데이터를 읽는 길과 시스템 RAM에서 별도 GPU로 데이터를 옮기는 길은 같은 길이 아니야.

17:55어느 구간이 시간을 잡아먹는지에 따라 개선할 곳도 달라져.

18:01사용자가 기다리는 시간도 나눠봐야 해.

18:04앞선 작업이 끝나기를 기다리는 시간, 모형을 확인하고 올리는 시간, 입력을 준비하는 시간, 실제 결과를 생성하는 시간, 파일을 정리해서 전달하는 시간이 이어져.

18:19상주는 이 중 일부 준비 비용을 줄이는 방법이야.

18:24전체 메모리가 크다는 사실만으로 나머지 구간까지 짧아지지는 않아.

18:30이제 조금 더 고급 개념 하나를 볼게.

18:34모형 속에 전체 파라미터 수와 활성 파라미터 수가 따로 적힌 경우가 있어.

18:41MOE, 흔히 전문가 혼합이라고 부르는 구조에서 많이 만나는 표현이야.

18:47전문가라는 이름 때문에 수학자와 번역가가 모형 안에 따로 앉아 있는 그림을 떠올릴 수 있는데, 실제로는 계산을 맡는 여러 갈래가 있다는 뜻에 가까워.

18:59모형 안에서는 한 단계의 계산 결과가 다음 단계로 넘어가는 일이 이어져.

19:06이런 계산 단계를 층이라고 불러.

19:10지금 비교할 부분을 보면 조밀한 구조에서는 그 층의 큰 계산 부분을 함께 사용해.

19:18MOE 구조에서는 그 자리에 여러 갈래를 두고 입력에 따라 일부를 선택해서 계산할 수 있어.

19:26선택하는 장치를 라우터라고 부르고 선택된 갈래에 있는 파라미터들이 그 계산에 참여해.

19:33이렇게 한 번에 참여하는 양을 줄이면서 전체 모형이 가진 수치의 규모는 크게 만들 수 있는 거야.

19:42여기서 전체 파라미터와 활성 파라미터는 역할이 달라.

19:47전체는 모형이 가지고 있는 수치의 총량을, 활성은 이번 계산에 참여하는 부분을 이해하는 데 쓰는 숫자야.

19:57공통으로 사용하는 부분도 있고, 토큰이나 층에 따라 선택되는 갈래도 달라질 수 있어.

20:04지금 선택하지 않은 갈래가 앞으로도 영원히 필요 없다는 뜻은 아니야.

20:10예를 들어 지금 사용하는 갈래들만 VRAM에 넣었다고 해보자.

20:15다음 계산이 다른 갈래를 선택하면 그 웨이트도 사용할 수 있어야겠지.

20:22다른 메모리에 두고 가져올 수도 있고, 일부 계산을 그쪽에서 처리할 수도 있어.

20:28여러 장치에 나눠 배치하는 방법도 있고.

20:33어떤 방법이든 필요한 자료와 계산을 연결하는 비용이 생겨.

20:38그래서 활성 파라미터를 파일 크기로 환산한 값이 VRAM에 들어간다는 이유만으로 이 모형을 빠르게 돌릴 수 있다고 판단하면 안 돼.

20:50작은 연산량 덕분에 효율적으로 실행되는 경우도 있지만, 부족한 공간을 메우느라 자료를 계속 옮기면 그 장점이 줄어들 수 있어.

21:01캐시가 얼마나 잘 맞는지와 실행 프로그램의 지원도 영향을 줘.

21:07여기서는 질문을 세 단계로 나눠보자.

21:11필요한 자료와 작업 공간을 어딘가에 배치할 수 있을까?

21:16실제로 실행해서 결과를 얻을 수 있을까?

21:19그리고 그 결과가 필요한 시간 안에 나올까?

21:24마지막 질문까지 답해야 실용적인 시스템이야.

21:28긴 답변을 대화하듯 받아야 하는지, 밤새 계산해 아침에 받아도 되는지에 따라서도 쓸만하다는 기준은 달라져.

21:38이번에는 초상 작업과는 별도로 조건을 맞춰 남겨둔 실행 기록을 보자.

21:45한 지시형 이미지 모형의 참조 이미지를 주고 주인공의 모습과 자세는 유지하면서 배경을 바꿔달라고 요청한 작업이야.

21:55결과는 가로, 세로 1024 픽셀이고 생성은 40단계로 설정했어.

22:02비교에는 같은 모형 버전과 요청 문장, 참조 이미지, 만수의 출발점을 정하는 시드를 사용했어.

22:11M3 Ultra에서 기록된 작업 시간은 약 239초였어.

22:17거의 4분이지.

22:19RTX 4090에서는 처음 준비를 포함한 실행이 약 301초였어.

22:26약 5분이니까 이 첫 실행만 보면 더 오래 걸린 셈이야.

22:31그런데 준비된 상태로 이어서 실행한 기록은 약 33초였어.

22:38반올림 전에 기록값으로 비교하면 M3 Ultra 쪽 작업 시간이 상주한 4090의 약 7.3배였어.

22:47하지만 이 숫자를 모든 모형, 모든 작업에 붙이면 안 돼.

22:53한 가지 조건에서 각 장비의 실행 프로그램까지 포함해 얻은 결과야.

22:59M3 Ultra 기록의 상주 상태까지 확인한 비교도 아니야.

23:04침만 떼어 같은 연산을 재본 시험과는 구분해야 해.

23:09최근의 별도 사용 기록에서도 4090으로 1k급 이미지를 만드는 데 약 46초가 기록된 두 건이 있었어.

23:19그 안에는 모형 파일 확인에 약 14.5초, 입력 준비에 약 5.6초, 생성 단계에 약 26초가 기록돼 있었지.

23:30이 작업 기록은 화면에서 버튼을 누른 순간부터 표시될 때까지를 잰 시간은 아니야.

23:38생성 단계만 본 시간과 준비를 포함한 작업 시간을 섞으면 같은 기록을 보고도 서로 다른 숫자를 말하게 돼.

23:48여기서 얻을 교훈은 분명해.

23:51큰 메모리는 큰 구성을 담고 여러 모형을 준비해 두는 데 도움이 돼.

23:57하지만 적절히 준비된 다른 장비가 그 작업을 훨씬 빨리 끝낼 수 있어.

24:04반대로 처음 준비가 길면 한 번만 하는 작업에서는 오히려 더 오래 걸릴 수도 있지.

24:11얼마나 담는지, 어떻게 준비하는지, 얼마나 자주 반복하는지를 함께 봐야 해.

24:19이 차이를 하드웨어 숫자만으로 설명하면 중요한 부분이 빠져.

24:25실제 모형은 실행 프로그램과 라이브러리를 통해 계산해.

24:30라이브러리는 자주 필요한 계산을 미리 구현해 둔 도구 모음이라고 생각하면 돼.

24:37같은 결과를 만드는 계산이라도 여러 단계를 한꺼번에 처리하거나 데이터를 덜 옮기도록 잘 짜여 있으면 더 효율적으로 실행할 수 있어.

24:48엔비디아는 쿠다를 중심으로 이런 연산 도구와 개발 도구, 여러 프레임워크와의 연결이 쌓여 있어.

24:57연구에서 사용하는 구현과 최적화가 이 경로를 중심으로 제공되는 경우도 많아.

25:04새로운 모형을 가져왔을 때 이미 준비된 실행 방법을 사용할 수 있느냐는 실용적인 차이야.

25:12하드웨어를 샀을 때 함께 얻게 되는 기반인 셈이지.

25:17이번에 확인한 이미지 실행 코드에서도 두 경로는 달랐어.

25:23애플의 GPU를 사용하는 쪽은 일부 입력 처리에 더 높은 정밀도를 쓰고 참조 이미지를 읽는 계산 일부를 CPU에서 수행하도록 되어 있었어.

25:35큰 계산을 나눠 처리하는 부분도 있었지.

25:39같은 범위의 정보를 사용하면서 계산을 작은 덩어리로 나누는 방식이야.

25:45코드에는 정확한 결과를 얻기 위해 이런 처리를 두었다는 설명이 있어.

25:52숫자 파일이 같더라도 실제 계산 경로가 같지는 않았던 거야.

25:57다만 이 처리 하나 때문에 몇 배 느렸다고 단정할 수는 없어.

26:03각각의 비용을 따로 측정한 것은 아니니까.

26:07확인한 사실은 지원 상태와 구현의 선택이 실제 실행 과정에 들어간다는 점이야.

26:14메모리를 늘리는 것만으로 이런 지원 문제까지 해결되는 것은 아니지.

26:21다양한 연구용 모형과 생성 모형을 가져와 빠르고 안정적으로 실행하는 생태계에서 애플이 더 채워야 할 부분이 있는 이유야.

26:31그렇다고 애플의 장점이 사라지는 건 아니야.

26:35큰 통합 메모리와 기기 안에 여러 연산 장치를 함께 설계한 기반은 개인 기기에서 AI를 실행하는 데 유리하게 활용할 수 있어.

26:45이런 기기 가까이에서 처리하는 방식을 엣지 AI라고 불러.

26:51애플 실리콘을 위한 MLX나 코어 ML 같은 실행 기반도 있어.

26:56다만 이번 이미지 기록이 그런 모든 경로와 기기의 성능을 대표하지는 않아.

27:04여기서 비교할 말을 정리해 두자.

27:07UMA는 메모리를 어떻게 공유하는가에 대한 구조이고, 쿠다는 엔비디아 장비에서 계산을 구현하고 실행하는 소프트웨어 기반이야.

27:17서로 같은 종류의 항목은 아니지.

27:21실제로 비교하는 대상은 메모리 구조와 연산 장치, 실행 소프트웨어가 함께 구성된 시스템이야.

27:29기기 내 AI의 가능성과 현재 범용 실행 생태계의 성숙도를 각각 봐야 하는 이유도 여기에 있어.

27:37앞에서 본 초상 작업 화면으로 돌아가 보자.

27:41여기서는 Cinder라는 화면에서 요청을 보내고 Amber라는 실행 서비스가 연결된 장비에 작업을 맡겨.

27:50맥들뿐 아니라 엔비디아 GPU가 있는 윈도 장비도 함께 연결돼 있어.

27:55중요한 것은 컴퓨터 대수를 자랑하는 게 아니라 서로 다른 장비가 가진 조건을 작업에 맞게 이용한다는 점이야.

28:04어떤 장비에는 필요한 모형이 이미 준비돼 있고, 어떤 장비는 지금 다른 작업을 하고 있을 수 있어.

28:12큰 메모리가 필요한 작업도 있고, 적은 준비만 거치면 빠르게 끝낼 수 있는 작업도 있지.

28:20사용할 수 있는 모형과 실행 지원, 상주 상태와 대기 상황을 고려하면 작업을 맡길 곳이 달라질 수 있어.

28:29한 장비의 용량 숫자 하나로 모든 요청의 최선이 정해지지는 않아.

28:34큰 통합 메모리에는 여러 모형을 준비해 두고 요청이 오면 그중 필요한 것을 사용할 여지가 있어.

28:42작은 VRAM에서는 현재 모형을 내리고 다른 모형을 올려야 할 수도 있지.

28:49지금 Amber 화면은 서버의 여러 모형을 4090 장비에 하나를 유지하도록 관리한 사례야.

28:57여기서 모형을 돌려쓴다는 말의 실제 동작이 보일 거야.

29:02다만 작은 모형 여러 개가 들어갈 수도 있으니 24GB에는 원래 모형 하나만 들어간다는 법칙은 아니야.

29:11사용하는 모형의 크기와 작업 공간, 프로그램의 관리 정책이 함께 정해.

29:18여러 장비를 묶은 렌더풀도 오해하지 말자.

29:22여기서는 각 작업을 알맞은 장비에 맡기는 거야.

29:27맥의 메모리와 윈도 장비의 VRAM이 자동으로 합쳐져 하나의 거대한 GPU가 되는 것은 아니야.

29:35하나의 모형 계산을 여러 장치에 나누는 별도 기술도 있지만, 작업을 나눠 보내는 풀을 만들었다는 사실만으로 그 기술까지 생기는 건 아니지.

29:46이제 모형을 상주시켜 놓고 돌려쓴다는 문장을 다시 읽어보자.

29:52저장 장치에 있던 학습된 수치와 필요한 구성 요소를 실행할 수 있는 메모리에 준비해 두는 장면이 보일 거야.

30:00요청이 들어오면 프로그램이 입력을 준비하고 계산 장치가 그 수치를 사용하고 결과를 화면으로 돌려줘.

30:10공간이 부족하면 다른 모형을 내리거나 자료를 다른 메모리에 두고 옮겨 쓰기도 하지.

30:17앞으로 모형이나 컴퓨터를 볼 때는 네 가지를 물어보면 좋아.

30:22이 작업에 필요한 공간을 확보할 수 있을까?

30:26실행 프로그램이 이 모형과 연산을 제대로 지원할까?

30:31처음 사용할 때와 준비된 뒤에 사용할 때 각각 얼마나 걸릴까?

30:37그리고 그 시간이 내가 하려는 일에 충분히 실용적일까?

30:43파라미터 수는 수치의 개수이고, 파일 크기는 그 수치를 저장하는 방식까지 반영한 양이야.

30:50메모리 용량은 담을 수 있는 공간이고, 대역폭과 연산 성능, 소프트웨어는 그 자료로 일을 처리하는 속도에 영향을 줘.

31:01이제 이 숫자들이 서로 다른 질문에 답한다는 걸 알았지.

31:06큰 숫자 하나에 기대기보다 필요한 일을 끝내는 전체 과정을 보는 거야.

31:12오늘은 여기까지.

31:14나 피파가 설명해 줬어.

31:16[클로징 음악]

All language editions share the original video's conversation.

Comments 0

🔔 Reply notifications (sign in)
Sign in — Please sign in to comment.

No comments yet — be the first.