Command Palette
Search for a command to run...
천톈치: 에이전트 시대에 AI 컴파일러를 어떻게 재고해야 할까요?

8월 1일제9회 AI 컴파일러 기술 박람회가 베이징에서 성공적으로 마무리되었습니다.인공지능 컴파일러 분야의 여러 전문가와 학자들이 베이징 중관춘에 모여 기술 혁신과 실무 경험에 대한 통찰을 공유하고, 언어 표현, 연산자 계산, 추론 실행, 시나리오 응용 등 다양한 수준에 걸쳐 인공지능 컴파일러의 협력적 진화를 보여주는 자리를 마련했습니다.
톈치 첸은 카네기멜론 대학교 기계학습학과 및 컴퓨터과학과 조교수이자 NVIDIA 석좌 엔지니어이며, 세계적으로 유명한 오픈소스 프로젝트인 XGBoost, Apache TVM, MLC LLM의 핵심 개발자 겸 창립자입니다.그는 특별 게스트로 행사에 참석했습니다. AI 컴파일러 분야의 선구자인 그는 TVM 오픈 소스 커뮤니티의 현재 발전 방향을 공유하고 청중과 심도 있는 의견을 교환했습니다.
HyperAI는 천톈치 교수의 발표 내용을 원문의 의미를 변경하지 않고 종합 및 요약했습니다.
안녕하세요 여러분, 이 행사에 참여하여 제 생각을 공유하게 되어 매우 기쁩니다. 저는 천톈치입니다. 저희는 오랫동안 AI 컴파일러 분야를 연구해 왔으며, 올해는 특히 흥미로운 한 해였습니다. 올해 초부터 AI 에이전트 열풍이 빠르게 확산되면서 업계에 몇 가지 새로운 문제들이 대두되기 시작했습니다.
첫 번째 질문: AI 컴파일러는 여전히 가치가 있을까요? 에이전트를 직접 프로그래밍할 수 있다면 컴파일러가 더 이상 필요할까요?
두 번째 질문: 자동화를 통해 더 많은 일을 할 수 있습니다. 과거에는 소규모 팀의 가장 큰 병목 현상은 엔지니어링 리소스였습니다. 하지만 에이전트의 등장으로 더 적은 인원으로도 더 많은 성과를 낼 수 있게 되었습니다.
오늘 제가 여러분과 나누고 싶은 것은 다음과 같습니다.인공지능 에이전트 시대에 우리는 인공지능 컴파일러를 어떻게 재고해야 할까요? 미래의 인공지능 컴파일러는 어떤 방향으로 나아가야 할까요?

에이전트별 반복 속도 향상
핵심적인 특징은 에이전트가 제한된 컨텍스트를 가지고 있기 때문에 비교적 빠르고 집중적인 반복 개발이 필요하다는 점입니다. 과거에는 대규모 프로젝트 개발, 특히 대규모 단일 저장소 개발을 선호하는 경향이 있었지만, 이제는 에이전트에 대한 집중적인 반복 개발이 매우 중요한 방향으로 떠오르고 있습니다.
첫째, 에이전트별 반복 작업을 가속화하기 위해 프로젝트 경계의 안정성, 구성 가능성 및 모듈성이 매우 중요하다는 것을 알게 되었습니다.
저희 TVM FFI 프로젝트를 예로 들자면, 목표는 대규모 TVM 프레임워크 내의 핵심 구성 요소, 즉 함수들이 서로 호출하는 방식을 명확하게 정의하는 것입니다. 여기에는 프레임워크 DSL부터 cuteDSL, FlashInfer와 같은 백엔드에 이르기까지 다양한 구성 요소 간의 함수 경계를 정의하는 것이 포함됩니다. 과거에는 엔드투엔드 솔루션 구축에 더 집중했지만, 이제는 연산자나 모듈 간의 전환을 용이하게 하는 보다 유기적인 경계를 정의해야 할 필요성이 점점 커지고 있습니다. 따라서 경계 자체를 명확하게 정의하고 표준화하는 것이 매우 중요해졌습니다.
작년에 출시된 TVM FFI는 cuteDSL, FlashInfer, 그리고 최근에는 TensorRT를 포함한 다양한 기술과 통합되었습니다. TVM FFI의 목적은 경계 명세가 어떻게 구성되어야 하는지를 정의하는 것입니다. 경계가 명확하게 정의되면 중간 모듈을 더욱 유연하게 교체할 수 있습니다.
둘째로, 에이전트가 특정 작업을 신속하게 완료할 수 있도록 향후 더 많은 언어 지원 기능을 제공할 예정입니다.
에이전트의 피드백 시간이 한두 시간이라면 시행착오 시간이 점점 더 길어질 것입니다. 따라서 컴파일러 자체에서 더 많은 언어를 지원해야 하므로, 인프라 수준에서 더 많은 언어를 지원하도록 노력하겠습니다.
과거에는 사용자들이 주로 프로그램과 상호작용했는데, 그 프로그램 자체가 상호작용의 대상이었습니다. 하지만 인공지능이 더욱 지능화됨에 따라, 사람들은 모든 계산을 직접 수행하는 대신 도구를 만들어 사용할 가능성이 높아졌습니다. 예를 들어, 수학 계산을 할 때 반드시 암산으로만 할 필요는 없고, 도구를 활용할 수 있게 될 것입니다.마찬가지로, 컴파일러의 내부 분석 기능과 인프라가 점차 중요해질 것이라고 생각합니다. 컴파일러를 모듈화하여 AI가 현재의 요구 사항에 맞춰 자체적인 분석 및 반복 프로세스를 구축할 수 있도록 하는 것이 목표입니다.
이를 위해 최근 TIRx 개발에 힘쓰고 있으며, '모던 GPU 프로그래밍'이라는 튜토리얼도 공개했습니다. 물론 GPU에만 국한된 것은 아니며, 보다 일반적인 가속기 프로그래밍 개념을 소개하고자 합니다. 지난 6개월 동안 펑시위안에게 제 시간의 절반 정도를 코딩에 썼다고 말한 적이 있는데, 에이전트를 사용하면 프로젝트 전체 코드를 리팩토링할 수 있기 때문입니다. 작년에 TVM FFI 모듈을 비교적 독립적이고 안정적으로 만들었는데, 앞으로 TIRx의 독립성과 안정화를 더욱 추진할 계획입니다.
에이전트 시대에 컴파일러는 무엇을 할 수 있을까요?
기존 컴파일러에는 중요한 특징이 하나 있는데, 바로 두 가지 유형의 요소를 동일한 스택에 넣는다는 점입니다. 하나는 자동 스케줄링과 같은 고수준의 지능적인 부분이고, 다른 하나는 순전히 규칙 기반적인 요소와 같은 저수준의 덜 지능적인 부분입니다.하지만 앞으로는 이러한 추세가 바뀔 것이라고 생각합니다. 안정적인 부분과 빠른 반복이 필요한 부분을 분리하는 것이 점점 더 중요해질 것입니다. 다시 말해, 비교적 안정적인 핵심 모듈을 기반으로 에이전트 관련 기능을 더욱 유연하게 추가하여 에이전트가 필요에 따라 전용 컴파일러를 구축하고 프로세스를 최적화할 수 있게 될 것입니다.
본론으로 돌아가서, 에이전트 시대에 컴파일러는 무엇을 할 수 있을까요?
내년 이맘때쯤, 혹은 올해 말쯤이면 우리가 논의하는 AI 컴파일러는 올해 초에 논의했던 것과는 분명히 다를 것이라고 생각합니다. 이는 우리가 함께 이 문제를 다시 생각해 볼 수 있는 매우 흥미로운 기회입니다.
반대로, 도구를 가진 인간은 육체만 가진 인간보다 확실히 강합니다. AI 컴파일러 자체도 일종의 도구입니다. 따라서 컴파일러 관련 모듈의 설계 및 개발에 AI를 더욱 효과적으로 활용할 수 있는 능력이 있다면 앞으로도 흥미로운 기회는 많이 있을 것입니다.
제가 전하고 싶었던 말은 이게 전부입니다. 모두 감사합니다.
질의응답 시간
질문 1: 하드웨어가 점점 더 많이 등장함에 따라, 미래의 컴파일러는 범용 아키텍처 적응형을 채택해야 할까요, 아니면 하드웨어별 적응형을 채택해야 할까요?
첸 티안치:에이전트의 등장으로 많은 것이 바뀔 것입니다. 전통적으로 서로 다른 백엔드에서 코드를 공유할 수 있다면 누구나 자연스럽게 코드 공유를 선호했습니다. 이것이 바로 초기에 통합 개발을 위해 대규모 모노레포 시스템을 구축하는 경향이 있었던 이유입니다. 그러나 에이전트를 사용하면 코드 개발 비용이 절감되므로 앞으로는 더욱 전문화된 부분이 등장할 것입니다. 특히 공유 코드의 추상화 수준이 하드웨어 자체의 기능을 지원하기에 불충분할 때 이러한 현상이 두드러지는데, 이는 흔히 발생하는 일입니다. 예를 들어, GPU 환경에서도 Hopper용으로 설계된 컴파일러가 Blackwell 이후에는 완전히 사용할 수 없게 될 수 있습니다. 이러한 일이 자주 발생하기 때문에 미래에는 전문화가 필수적일 것입니다.
반대로, 무엇이 공통으로 남을 수 있을까라는 질문이 여전히 남아 있습니다. 에이전트가 하드웨어별 컴파일러를 구축할 수 있는 비교적 안정적인 기반이 여전히 필요합니다. 예를 들어, TIRx에 대한 최근 연구는 다양한 하드웨어가 자체 디스패치 규칙을 등록하고, 에이전트가 하드웨어 특성을 기반으로 관련 지식을 생성할 수 있도록 하는 것을 목표로 합니다.
앞으로는 특화된 컴파일러가 더욱 많이 등장할 것으로 예상됩니다. 이러한 컴파일러는 크게 두 부분으로 나뉘는데, 첫 번째는 ABI 요구사항, 핵심 정보 검색(IR) 데이터 구조, 언어 간 호환성 등 높은 안정성이 요구되는 안정적인 부분이고, 두 번째는 특정 시나리오에 특화된 부분으로, 미래에는 에이전트 기반 방식이 더욱 많이 사용될 가능성이 높습니다. 앞으로 이러한 컴파일러를 더욱 많이 보게 될 것이라고 생각합니다.
질문 2: 학습 과정에서 정보 검색(IR) 분야의 전통적인 추상적 경계들이 허물어지고 통합되는 것을 많이 목격했습니다. 이전에는 명확하게 정의되었던 것들이 점차 IR에 흡수되는 것처럼 보입니다. 이러한 관점에서 인공지능 컴파일러의 미래 발전 방향은 무엇이라고 생각하십니까?
첸 티안치:제 생각에는 이 문제는 두 부분으로 나눌 수 있을 것 같습니다. 첫째, 현재 다양한 정보 검색(IR) 모델들이 서로 다르게 보일지라도, 실제로는 여러 면에서 상당히 유사하며, 기본적으로 커널 레벨, 그래프 레벨, 그리고 이 둘 사이의 상호작용이라는 몇 가지 레벨로 나눌 수 있습니다. 몇 년 동안의 진화를 거치면 점차 몇 가지 더 안정적인 레벨로 수렴될 것입니다. 레이어가 너무 많으면 레이어 간 전환 과정에서 정보 손실이 발생하기 때문에 오히려 좋지 않습니다. 따라서 몇 가지 주요 레벨로 수렴하게 되면, 핵심 과제는 필요한 정보를 어떻게 인코딩할 것인가가 될 것입니다.
두 번째 부분에서는 강력한 컴파일러가 필요했던 여러 작업을 외부 인력이나 제어 담당자에게 위임할 수 있는지에 대한 질문을 다룹니다. 다시 말해, 컴파일러를 더 간소화하거나 계층화할 수 있는지에 대한 질문입니다. 계층화란 지속적인 유지 관리가 가능한 비교적 안정적인 계층과 빠른 반복이 가능한 또 다른 계층을 갖는 것을 의미하며, 적어도 미래에는 이 두 계층이 확실히 존재할 것입니다.
질문 3: AI 컴파일러의 관점에서 볼 때, 미래에 AI가 AI 컴파일러를 작성하는 모습을 볼 수 있을까요? 단기적으로 AI가 작성하기에 적합한 컴파일러 구성 요소는 무엇일까요? 주요 과제는 무엇일까요?
첸 티안치:우선, 여기 계신 많은 분들이 이미 AI를 활용하여 컴파일러를 작성하기 시작하셨을 거라고 생각합니다. 따라서 이는 미래의 가능성에 대한 질문이 아니라 현재 실제로 일어나고 있는 일입니다.
모듈화는 여기서 매우 중요합니다. AI가 대규모 프로젝트를 완벽하게 관리하는 것은 분명 어렵지만, 특정 모듈을 AI에 위임하여 신속한 반복과 시행착오를 거치는 것은 충분히 가능합니다. 핵심은 문제를 명확하게 정의된 하위 문제로 나누는 것입니다. 따라서 경계 정의가 필수적입니다. 저희 TVM FFI 접근 방식은 이러한 경계를 명확하게 정의하는 것을 목표로 합니다.
마찬가지로, 우수한 IR 인프라 또한 매우 중요합니다. 예를 들어, 현재 파이썬, 러스트, C++ 등의 언어를 지원하는 컴파일러 IR을 작성하려면 완벽하게 적합한 솔루션이 없습니다. 앞으로 이러한 인프라를 제공할 수 있게 된다면 개발 효율성이 크게 향상될 것입니다.
그렇다면 인프라 구축 외에 우리가 할 수 있는 일은 무엇일까요? 공통적인 요구사항을 추출할 수 있는지 여부에 달려 있다고 생각합니다. 예를 들어, 이전에 논의했던 문제처럼 컴파일러의 상당 부분은 호스트 측 비용 절감과 관련이 있습니다. 이 문제는 GPU 가속이나 하드웨어 가속과는 비교적 독립적이지만, 호스트 측 최적화 자체에는 여전히 자동화할 여지가 많습니다. 이러한 공통적인 요구사항을 추출할 수 있다면, 인공지능은 향후 컴파일러 개발에서 더욱 중요한 역할을 하게 될 것입니다.
질문 4: 저수준 DSL과 고수준 DSL과 같은 다양한 수준의 컴파일러는 향후 산업 및 개발 생태계에서 어떤 위치를 차지하게 될까요?
천톈치: 저는 각 레벨마다 요구 사항이 다를 것이라고 생각합니다. 일반적으로 로우 레벨을 노출하는 동시에 로우 레벨과 하이 레벨 모두를 표현하는 것이 좋습니다. 예를 들어, 저희가 최근 개발한 TIRx는 다양한 레벨에 대한 표현 방식과 네이티브 파트너 레벨에 대한 표현 방식을 모두 갖추고 있어 두 레벨 간의 유연한 전환이 가능합니다. 하지만 한 가지 원칙이 있습니다. 에이전트는 기능을 제한하지 않으면서 이러한 요소들을 표현하는 데 가능한 한 적은 토큰을 사용해야 합니다.
질문 5: 과거에 컴파일러에 대해 논의할 때 주로 커널 레벨에 초점을 맞췄지만, 실제로는 많은 것들을 IR(정보 검색)을 사용하여 표현할 수 있습니다. 그렇다면 앞으로는 커널 레벨 IR 외에도 마이크로 레벨 IR, 나아가 스케줄링 레벨 IR이 AI 컴파일러 연구의 새로운 방향이 될까요?
첸 티안치:사실 이는 아주 정상적인 현상입니다. 그래프 레벨 컴파일러는 항상 존재해 왔기 때문입니다. 다만 과거에는 커널 레벨 컴파일러와 그래프 레벨 컴파일러 간의 상호 작용이 상대적으로 미약했습니다. 그래프 레벨 컴파일러는 주로 그래프 레벨 문제를 해결하고, 커널 레벨 컴파일러는 주로 커널 레벨 문제를 해결해 왔기 때문입니다. 하지만 앞으로는 이 둘 간의 상호 작용이 점점 더 중요해질 것입니다.
최근 주요 연구 방향 중 하나는 커널 간 상호 작용이 필요한 메가커널(MegaKernel)입니다. 따라서 두 가지 유형의 정보를 단일 IR(통합 리소스 식별자) 내에 캡슐화하는 방법을 고민해 왔습니다. 만약 이것이 미래에 실현된다면 흥미로운 발전으로 이어질 것이라고 생각합니다. 예를 들어, 메가커널에 대한 이전 연구에서는 그래프 레벨과 커널 레벨 간의 상호 작용을 활용하여 최적화를 달성했습니다.
질문 6: 에이전트 친화적인 컴파일러는 참된 명제인가?
첸 티안치:미래에는 컴파일러가 필요 없는 시나리오가 등장할 수도 있습니다. 에이전트가 직접 어셈블리 코드를 생성할 수 있게 되는 것이죠. 차이점은 에이전트가 이 작업을 직접 수행하도록 할 수도 있고, 에이전트가 직접 컴파일러를 작성하여 도구를 만들 수도 있다는 점입니다. 개인적으로는 컴파일러가 여러 상황에서 개발 효율성을 향상시킬 수 있기 때문에 여전히 가치가 있다고 생각합니다.
그렇다면 "에이전트 친화적"이라는 말은 거짓일까요, 아니면 참일까요? 핵심은 소프트웨어가 처음부터 이러한 특성을 갖고 있는지 여부가 아니라, 그러한 특성을 목표로 설계하는지에 있다고 생각합니다. 에이전트가 도입되면 에이전트의 성능을 지속적으로 관찰하고, 어떤 부분에서 부족한지 파악한 후, 이러한 피드백을 바탕으로 개선해 나가야 합니다.
예를 들어, 언어 간 호환성 요구 사항은 매우 현실적인 문제입니다. 에이전트는 처음에는 Python을 사용하여 컴파일러 패스를 빠르게 개발할 수 있지만, 가속화가 필요할 때는 C++이나 Rust로 전환해야 할 수도 있습니다. 이러한 문제를 목표로 삼는다면, 이미 상당 부분의 코드가 에이전트에 의해 작성되고 있다는 점에서 이는 나쁜 일이 아니라고 생각합니다. 미래에는 컴파일러가 에이전트가 빌드 및 최적화를 지원하는 데 사용할 수 있는 도구가 될 것입니다.
위 내용은 Meet AI 컴파일러 기술 살롱에서 첸 톈치 교수가 발표한 통찰력 있는 프레젠테이션의 요약입니다. 이 행사에서 있었던 다른 흥미로운 발표 내용도 녹취록 형태로 곧 전해드릴 예정이니 기대해 주세요!











