제퍼넷 로고

Nvidia 소프트웨어 임원인 Kari Briski와의 인터뷰

시간

인터뷰 Nvidia의 GPU 기술 컨퍼런스는 지난주에 마무리되었으며 회사의 Blackwell 칩과 AI의 놀라운 경이로움, 그리고 값비싼 GPU 하드웨어를 구입했다는 소식을 전했습니다.

머신러닝 모델이 지원하는 자동화를 통해 많은 창의적인 노력이 더 빨라지거나 더 빨라질 수 있다는 생각을 바탕으로 주가가 사상 최고치를 기록하고 있다는 소문이 회사 주변에 떠돌고 있습니다.

아직 시장에서는 테스트 중입니다.

조지 산타야나 한때 : “과거를 기억하지 못하는 자는 그것을 반복하게 되는 형벌을 받는다.” 자주 반복되는 문구입니다. 그러나 과거의 기억이 실제로 AI 모델을 차별화하는 것은 아닙니다. 그들은 과거를 기억할 수 있지만 여전히 요구에 따라 그것을 반복해야 하며 때로는 부정확하기도 합니다.

그럼에도 불구하고 많은 사람들, 특히 AI 하드웨어나 클라우드 서비스를 판매하는 사람들은 전능한 AI를 신뢰합니다. 특히 Nvidia는 이에 큰 투자를 하고 있습니다.. 그래서 등록 모든 소란이 무엇인지 알아보기 위해 GPU 컨퍼런스를 잠시 방문했습니다. 목요일에 전시장에서 제공되는 레몬 바에 관한 것은 확실히 아니었습니다. 그 중 다수는 전시장 쓰레기통에서 미완성으로 초기 공모를 마쳤습니다.

대화가 훨씬 더 흥미로웠어요 등록 Nvidia의 AI 및 HPC 소프트웨어 개발 키트 제품 관리 부사장인 Kari Briski와 함께했습니다. 그녀는 회사의 기반 모델, 라이브러리, SDK에 대한 소프트웨어 제품 관리를 총괄하고 있으며 현재는 새로 발표된 학습 및 추론을 처리하는 마이크로서비스를 담당하고 있습니다. NIM 마이크로서비스와 더 나은 확립 니모 배포 프레임워크.

등록: 기업은 클라우드나 온프레미스에서 이러한 마이크로서비스를 어떻게 소비하게 될까요?

브리스키: 사실 이것이 우리가 NIM을 만든 이유의 장점입니다. "NIM"이라고 말하는 것은 좀 웃기네요. 하지만 우리는 오래 전에 이 여행을 시작했습니다. 저희는 제가 시작할 때부터 추론 작업을 해왔습니다. 제가 1.0년에 시작했을 때는 TensorRT 2016이었던 것 같습니다.

수년에 걸쳐 우리는 컴퓨터 비전, 심층 추천 시스템 및 음성, 자동 음성 인식 및 음성 합성, 그리고 이제는 대규모 언어 모델을 시작으로 다양한 종류의 워크로드에 대해 자세히 알아보면서 추론 스택을 늘려 왔습니다. 이는 정말 개발자 중심의 스택이었습니다. 이제 기업은 OpenAI와 ChatGPT를 보았으므로 기업 데이터 옆이나 기업 애플리케이션에서 이러한 대규모 언어 모델을 실행해야 할 필요성을 이해하고 있습니다.

평균적인 클라우드 서비스 제공업체에서는 관리형 서비스를 위해 수백 명의 엔지니어가 추론, 최적화 기술을 연구하고 있습니다. 기업은 그렇게 할 수 없습니다. 가치 실현 시간을 즉시 확보해야 합니다. 이것이 바로 우리가 TensorRT, 대규모 언어 모델, Triton 추론 서버, 표준 API 및 상태 확인을 통해 수년 동안 배운 모든 것을 캡슐화한 이유입니다. [아이디어는] 모든 것을 캡슐화하여 5분 이내에 0에서 대규모 언어 모델 엔드포인트까지 도달할 수 있다는 것입니다.

[온프레미스 데이터센터와 클라우드 데이터센터 비교] 우리 고객 중 상당수가 하이브리드 클라우드입니다. 그들은 컴퓨팅을 선호합니다. 따라서 데이터를 관리형 서비스로 보내는 대신 데이터에 가까운 곳에서 마이크로서비스를 실행할 수 있으며 원하는 곳 어디에서나 실행할 수 있습니다.

등록: Nvidia의 AI용 소프트웨어 스택은 프로그래밍 언어 측면에서 어떤 모습인가요? 아직도 주로 CUDA, Python, C, C++인가요? 더 빠른 속도와 효율성을 위해 다른 곳을 찾고 계십니까?

브리스키: 우리는 개발자들이 사용하는 곳이라면 어디든지 항상 탐구하고 있습니다. 그것은 항상 우리의 열쇠였습니다. 그래서 저는 Nvidia에 입사한 이후로 가속 수학 라이브러리 관련 작업을 해왔습니다. 먼저, 병렬성을 얻으려면 CUDA로 프로그래밍해야 했습니다. 그리고 C API가 있었습니다. 그리고 우리에게는 Python API가 있었습니다. 따라서 개발자가 어디에 있든 플랫폼을 사용하는 것이 중요합니다. 현재 개발자들은 컬(curl) 명령이나 Python 명령 등을 사용하여 매우 간단한 API 엔드포인트를 사용하고 싶어합니다. 그래서 그것은 매우 간단해야 합니다. 왜냐하면 오늘 우리가 개발자들을 만나는 곳이기 때문입니다.

등록: CUDA는 분명히 GPU 계산을 효과적으로 만드는 데 큰 역할을 합니다. Nvidia는 CUDA를 발전시키기 위해 무엇을 하고 있나요?

브리스키: CUDA는 모든 GPU의 기반입니다. CUDA를 지원하고 CUDA 프로그래밍이 가능한 GPU입니다. 몇 년 전에는 이러한 도메인별 언어가 있었기 때문에 CUDA-X라고 불렀습니다. 따라서 의료 영상 [신청]이 있는 경우 cuCIM. 자동 음성 인식 기능이 있으면 그 끝에 CUDA 가속 빔 검색 디코더가 있습니다. 따라서 CUDA로 가속화된 다양한 유형의 워크로드에 대한 이러한 모든 특정 사항이 있습니다. 우리는 수년에 걸쳐 이러한 모든 전문 라이브러리를 구축했습니다. cuDFcumML, 그리고 이것저것. 이 모든 CUDA 라이브러리는 우리가 수년에 걸쳐 구축한 것의 기초이며 이제 우리는 그 위에 구축하고 있습니다.

등록: Nvidia는 소프트웨어와 하드웨어를 설계하는 방식 측면에서 비용 고려 사항을 어떻게 봅니까? Nvidia AI Enterprise와 같은 경우 GPU당 매년 4,500달러가 소요되는데 이는 상당한 금액입니다.

브리스키: 첫째, 소규모 기업의 경우 항상 처음 프로그램. 우리는 항상 고객과 협력하고 있습니다. 90일 무료 평가판이 귀하에게 정말 가치가 있습니까? 정말 그만한 가치가 있나요? 그런 다음 구매 시 비용을 줄이기 위해 우리는 항상 소프트웨어를 최적화하고 있습니다. 따라서 라이선스당 연간 CPU당 4,500달러를 구입하고 A100에서 실행하고 내일 H100에서 실행하는 경우 가격은 동일합니다. 비용은 [처리량에 비해] 낮아졌습니다. 따라서 우리는 항상 이러한 최적화와 총 소유 비용 및 성능을 소프트웨어에 다시 구축하고 있습니다.

훈련과 추론 모두에 대해 생각할 때 훈련에는 약간의 시간이 더 걸리지만 이러한 자동 구성기를 사용하면 "데이터가 얼마나 되나요?"라고 말할 수 있습니다. 얼마나 많은 컴퓨팅이 필요합니까? 얼마나 걸릴까요?” 따라서 컴퓨팅 공간은 더 적게 가질 수 있지만 모델을 훈련하는 데 시간이 더 오래 걸릴 수 있습니다. 일주일 안에 훈련하시겠습니까? 아니면 하루만에 훈련시키시겠습니까? 그래서 당신은 그러한 절충안을 만들 수 있습니다.

등록: 현재의 문제 중 특별히 해결하고 싶은 부분이나 극복하고 싶은 기술적 과제가 있나요?

브리스키: 지금은 이벤트 중심입니다. 누더기 [외부 소스에서 가져온 데이터로 AI 모델을 강화하는 방법입니다]. 많은 기업에서는 답변을 생성하기 위한 고전적인 프롬프트만 생각하고 있습니다. 하지만 실제로 우리가 원하는 것은 이러한 모든 검색 증강 생성 시스템을 모두 함께 [연결]하는 것입니다. 당신이 당신과 당신이 끝내고 싶은 작업에 대해 생각한다면, “아, 데이터베이스 팀에 가서 얘기해야 해요. 그리고 해당 데이터베이스 팀은 Tableau 팀에 가서 이야기해야 합니다. 대시보드를 만들어야 해요.” 실제로 작업을 완료하기 전에 이 모든 일이 일어나야 합니다. 그래서 그것은 일종의 이벤트 중심 RAG입니다. RAG가 RAG와 대화한다고는 말할 수 없지만 본질적으로 에이전트는 나가서 많은 작업을 수행하고 다시 돌아옵니다. 그리고 우리는 그 직전에 있습니다. 그래서 저는 그것이 2024년에 볼 수 있어서 정말 기대되는 일이라고 생각합니다.

등록: Nvidia가 자체 AI를 dogfood하고 있나요? AI가 내부적으로 유용하다고 생각하시나요?

브리스키: 사실, 우리는 시작했고 작년에 2023년이 탐색의 해였기 때문에 제가 발견한 Nvidia 내에는 150개 팀이 있었습니다. 더 많았을 수도 있었습니다. 그리고 우리는 우리 도구를 어떻게 사용하고 있는지, 어떤 종류의 팀이 있는지 말하려고 했습니다. 사용 사례를 정리하고 수천 송이의 꽃이 피어나는 과정에서 얻은 모든 학습 내용을 모범 사례로 결합하여 하나의 저장소로 만들기 시작했습니다. 그것이 실제로 우리가 출시한 제품입니다. 생성적 AI 예시 GitHub에서 모든 모범 사례를 한 곳에 모아두고 싶었기 때문입니다.

그것이 우리가 구조적으로 한 일입니다. 하지만 명확한 예로서 우리는 다음과 같은 정말 훌륭한 논문을 썼다고 생각합니다. 칩네모, 그리고 그것은 실제로 우리 EDA, VLSI 설계 팀에 관한 것이며 그들이 기초 모델을 채택하고 우리의 독점 데이터에 대해 교육한 방법에 관한 것입니다. 우리는 VLSI를 위한 자체 코딩 언어를 가지고 있습니다. 그래서 그들은 독점 언어를 생성하고 VLSI 설계 칩 작성 코드를 잘 모르는 새로운 엔지니어의 생산성을 돕기 위해 부조종사(오픈 소스 코드 생성 모델)를 코딩하고 있었습니다.

그리고 그것은 모든 고객의 공감을 얻었습니다. 따라서 SAP에 문의하면 데이터베이스에 대한 독점 SQL과 같은 BOP(이월 주문 처리)가 있습니다. 그리고 저는 서로 다른 독점 언어를 사용하는 세 명의 다른 고객과 이야기를 나눴습니다. 심지어 SQL에도 수백 가지 방언이 있습니다. 따라서 코드 생성을 수행할 수 있는 것은 RAG로 즉시 해결할 수 있는 사용 사례가 아닙니다. 예, RAG는 문서와 일부 코드 조각을 검색하는 데 도움이 되지만 해당 언어로 토큰을 생성하도록 훈련되지 않으면 코드만 만들 수는 없습니다.

등록: 대규모 언어 모델과 해당 모델이 애플리케이션과 함께 연결되는 방식을 볼 때 발생할 수 있는 대기 시간과 이를 처리하는 방법에 대해 생각하고 있습니까? 단순히 의사결정 트리를 하드코딩하는 것이 더 합리적일 것 같은 경우가 있습니까?

브리스키: 맞습니다. 특정 질문이나 프롬프트를 요청하면 단 하나의 질문이라도 이미 5~7개의 모델이 시작되어 프롬프트 재작성과 가드레일, 검색기 및 순위 재지정을 받을 수 있습니다. 그리고 발전기. 이것이 NIM이 중요한 이유입니다. 왜냐하면 우리는 대기 시간에 최적화되어 있기 때문입니다.

이것이 바로 우리가 다양한 버전의 기초 모델을 제공하는 이유이기도 합니다. 특정 작업 세트에 좀 더 적합한 작은 언어 모델인 SLM이 있고 최종적으로는 더 높은 정확성을 위해 더 큰 모델을 원할 수 있기 때문입니다. 그러나 대기 시간 창에 맞게 모든 것을 연결하는 것은 많은 하이퍼스케일 또는 관리형 서비스에 대해 수년 동안 해결해 온 문제입니다. 그들은 이러한 대기 시간 창이 있고 질문을 하거나 검색을 할 때 실제로 여러 번 질문을 떠나서 질문을 작성하는 경우가 많습니다. 그래서 그들은 "전체 응답의 각 작은 부분에 대한 대기 시간 창은 얼마나 됩니까?"라는 많은 경쟁 조건을 갖게 되었습니다. 네, 우리는 항상 그것을 보고 있습니다.

하드코딩에 대한 귀하의 주장에 대해 오늘 고객과 이야기를 나눴습니다. 우리는 하드코딩 그 이상입니다. 대화 관리자를 사용하여 if-then-else를 사용할 수 있습니다. [하지만] 수천 개의 규칙을 관리하는 것은 정말, 정말 불가능합니다. 이것이 바로 우리가 가드레일과 같은 것을 좋아하는 이유입니다. 가드레일은 고전적인 대화 관리자를 일종의 대체물로 나타내기 때문입니다. “야구, 소프트볼, 축구에 대해 말하지 마세요”라고 말하고 그것들을 나열하는 대신 “스포츠에 대해 말하지 마세요”라고 말할 수 있습니다. 그리고 LLM은 스포츠가 무엇인지 알고 있습니다. 시간을 절약하고 나중에 해당 코드를 관리할 수 있다는 점은 훨씬 더 좋습니다. ®

spot_img

최신 인텔리전스

spot_img