AI가 소프트웨어 성능 최적화를 1000배 저렴하게 만들었다
There's no reason for software to be slow anymore
Dan Luu은 LLM이 성능 최적화 비용을 극적으로 낮추면서, 이전에는 대규모 프로젝트에서만 시도하던 최적화를 이제 누구나 쉽게 적용할 수 있다고 주장합니다. 그는 자신의 regex 엔진(FRE)과 Azul AI 개발 경험을 예로 들어, 에이전트가 몇 분 만에 JIT 컴파일러를 구현하거나 멀티스레딩 알고리즘을 재작성하는 등, 과거에는 사람이 며칠에서 몇 주가 걸리던 작업을 단 몇 분의 인간 시간으로 처리할 수 있게 되었다고 설명합니다. 이는 특정 워크로드에 맞춤화된 동적 소프트웨어의 가능성을 열며, 성능 최적화의 패러다임을 바꾸고 있습니다.
이제는 몇 분만에 인간이 타이핑한 몇 문장으로 에이전트가 작업을 수행하여, 이전에는 사람이 며칠에서 몇 주가 걸리던 까다로운 최적화를 단 몇 분의 인간 시간으로 처리할 수 있게 되었습니다.
HN 토론
489- ehnto
느린 소프트웨어의 가장 큰 원인 중 하나는 그냥 웹 요청을 기다리는 것이다. 많은 소프트웨어가 온라인 상태이거나, 온라인이 아니더라도 같은 스택으로 만들어져서, 사용하는 동안 계속 차단/대기 상태에 놓인다는 사실이 그렇다. 미국에 살지 않는 사람들은 온라인의 상당수가 미국에 호스팅되어 있어서 더 크게 느낀다. 사소한 상호작용 하나하나에 300ms씩 걸리면 금방 누적된다. 소프트웨어의 많은 UI 컨트롤에 대기 대화상자나 로딩 스피너가 있다면, 기본적으로 차단을 전제로 만든 것이다. 웹 기반으로 만들더라도, 그게 정말 필요한지, 아니면 UI 차단을 피하기 위해 다르게 만들 수는 없는지 스스로에게 물어봐라.
- eaftan
저는 SafeRE라는 비슷한 에이전트 기반 정규식 프로젝트를 진행 중입니다:
https://github.com/eaftan/safere
https://eaftan.github.io/safere-intro/
제 프로젝트는 Java용이고 프로덕션 등급을 목표로 합니다. 첫 번째 목표는 ReDoS 공격을 막기 위해 선형 시간 동작을 보장하는 것입니다. 저와 공동 연구자는 최근에 네이티브 RE2의 성능을 능가하기 위해 최적화를 진행하고 있습니다.
최적화는 에이전트 루프에 매우 잘 맞는다는 것이 밝혀졌습니다. 구체적인 수용 기준(벤치마크 케이스에서 의미 있는 개선을 보여야 하고, 테스트를 통과해야 함)이 있고, 에이전트는 프로파일러나 디스어셈블러 같은 도구를 사용하는 데 저보다 훨씬 뛰어납니다(제가 20년 동안 해왔음에도). 또한 Java의 인큐베이팅 중인 Vector(SIMD) API가 어떻게 작동하는지 같은 것들을 배우는 데 걸리는 시간을 단축해 줍니다. 개념은 이해하지만 Java 구현을 이해하는 데는 시간이 걸릴 텐데, 에이전트는 문서를 읽고 바로 실행할 수 있습니다.
핵심은 좋은 벤치마크 스위트를 만들고 에이전트가 벤치마크 케이스에 너무 좁거나 집중된 최적화를 내놓지 않도록 하는 것입니다. 또한 정확성 회귀가 없도록 강력한 테스트 스위트가 필요합니다. SafeRE는 수십억 개의 테스트가 있고, 그중 수백만 개가 CI에서 실행되며 나머지는 요청 시 실행됩니다.
- mccoyb
이 글을 요약하면 다음과 같습니다:
> 프로그램 공간 S에 대해 실행 가능한 최적화 목표를 가진 확률적 탐색 과정은 목표를 유지하거나 향상시킬 수 있다.
이것은 슈퍼최적화입니다. 80년대부터 알려져 왔습니다(Massalin, STOKE가 더 최근: https://github.com/StanfordPL/stoke). 유일한 새로운 점은 제안자가 이제 언어 모델로 훨씬 더 좋아졌다는 것입니다.
또한 에이전트가 작성한 소프트웨어가 느린 데는 여러 이유가 있습니다:
- 언어 모델은 여전히 데이터나 하드웨어 지향 설계를 기본적으로 잘 하지 못합니다. 따라서 매우 잘 이해된 프로그램을 매우 잘 이해된 워크로드로 포팅하는 것 이상의 진지한 새 작업을 한다면, 잘못된 할당 결정(종종 악의 근원)을 추적하는 데 몇 시간을 보내게 될 것입니다(그래서 TigerBeetle이 에이전트를 사용하지 않는지 보세요).
- 심각한 성능을 얻기 위해 필요한 조정은 언어 모델이 잘하는 언어에서는 거의 도달할 수 없습니다(심지어 Rust도 기본 언어가 강제하지 않는 훈련을 요구합니다). 더 낮은 수준으로 내려가면 소비 컨텍스트와 이러한 레버에 대한 접근을 교환하게 됩니다. 레버도 "소프트"합니다. 훈련을 강제하기 위해 많은 스킬과 도구를 작성하게 됩니다.
현실은 에이전트에서 (빠르게) 성능 좋은 코드를 얻으려면 성능 좋은 코드를 작성하는 방법을 알아야 하고(그리고 그러한 것에 대한 검증기를 만드는 데 사용할 정보를 표면화하는 방법을 알아야 합니다) ...
- hunterpayne
"LLM이 느리고 비대한 코드를 만들고 있는데, 그들이 모든 것을 슈퍼 최적화된 어셈블리로 다시 쓰면 파멸할 것이다."
이 사람은 효율적인 코드를 만드는 방법을 이해하지 못합니다. 저는 거의 모든 언어(몇 가지 예외 제외)로 "슈퍼 최적화된 어셈블리"보다 뛰어난 성능의 코드를 작성할 수 있습니다. 효율적인 코드 작성은 언어에 관한 것이 아니며, 종종 최고의 알고리즘에 관한 것도 아닙니다(때로는 그럴 때도 있지만). 메모리와 캐시 사용을 최적화하는 것입니다. 그리고 그것은 저자가 쓰는 어떤 것과도 직교합니다. 또한 LLM은 메모리 활용 최적화에 매우 서툽니다. 그렇게 잘하는 훈련 코드가 너무 적고, 그렇지 않은 코드가 너무 많습니다.
증거로, 저는 말 그대로 웹이 느려지는 것을 느낄 수 있고, 다른 많은 사람들도 그렇게 느낄 것이라고 확신합니다.
- chvid
ChatGPT macOS 버전은 제 컴퓨터에서 정기적으로 크래시를 일으키는 유일한 소프트웨어입니다. 메모리 사용량이 이유 없이 50GB까지 치솟을 때 말이죠.
그리고 그 소프트웨어는 세계에서 가장 높은 연봉을 받는 소프트웨어 엔지니어들이 만들었고, 세계의 모든 LLM 컴퓨팅에 접근할 수 있습니다.
- intrasight
저는 40년 동안 컴퓨터를 사용해 왔습니다. 그들은 전혀 빨라지지 않았습니다. 1989년에 우리가 만든 원자력 발전소 컴퓨터 시스템은 선택된 화면을 1초 안에 표시해야 했습니다. 오늘날 제가 사용하는 어떤 앱도 그렇게 할 수 없다고 생각합니다.
- rumisid
저에게 비교는 항상 3DsMax 대 Blender였습니다. 같은 종류의 소프트웨어, 같은 종류의 기능이지만 Blender가 훨씬 빠릅니다.
아키텍처 결정은 항상 중요했습니다.
- jjcm
이제 대부분의 소프트웨어가 느린 이유는 리소스를 제어해야 하는 공동 테넌시(co-tenancy) 때문이거나, 단순히 경쟁으로부터 안전하게 보호되기 때문이라는 것을 이해했습니다. 예를 들어 GitHub는 전자에 해당합니다. 소셜 기능을 사용하지 않을 것이므로 직접 더 높은 품질의 git 호스트와 CI/CD 시스템을 만들 수 있습니다. Apple의 다섯 손가락 안쪽 제스처 같은 것은 후자라고 생각합니다. 예전에는 그렇게 하고 바로 입력을 시작할 수 있었지만, 요즘은 키 입력이 등록되기 전에 애니메이션 등을 렌더링해야 합니다. 이 소프트웨어는 macOS에서 대체할 수 없기 때문에 느립니다.
하지만 이런 모든 것은 시간이 지나면 바뀔 것입니다. 지옥은 다른 사람들의 소프트웨어입니다.