추론 엔진은 일회성(one-off) 시리즈가 될 것입니다

ninfer, dwarfstar, Splash, llamAmpere, gufo 등. 우리는 이들이 등장하는 것을 모두 보았습니다. 훌륭한 tok/s 성능에 사람들이 열광합니다. llama.cpp나 다른 엔진의 포크이거나, 아니면 처음부터 만들어진 것들입니다. 좋든 나쁘든, 목록은 계속해서 늘어날 것입니다. 이것들은 소프트웨어의 주요 어려움인 일반성(generality)을 회피하기 때문에 매우 잘 작동하며, 단지 하나의 모델/하드웨어 조합(또는 몇 가지)에 맞춰 구현하고, 그 특정 케이스를 위해 커널/컴퓨트 그래프를 최적화합니다. 성능이 좋은 대신 '과적합된(overfit)' 코드베이스들이며, well-known inference engines (llama.cpp, vLLM 등)을 능가하지만, 6개월 후에는 완전히 잊힐 것입니다. 하지만 새로운 것들이 그 자리를 차지할 것입니다... 테제: 일회성 엔진이 표준이 될 것입니다. llama.cpp, vllm 등은 대부분의 사람들에게 사용하기에 의미가 없을 것이며, 그 이유는 더 느리기 때문입니다.

당신이 아마도 받아들일 몇 가지 공리(axioms)들이 있습니다: 코드베이스가 일반적일수록 시간이 지남에 따라 새로운 기능을 깔끔하게 통합하기가 더 어렵습니다. 이는 혁신의 속도를 늦춥니다. AI 코딩은 점점 더 좋아지고 저렴해지면서, 작을수록 빠릅니다. 따라서 추론 엔진을 만드는 장벽이 낮아지고 있습니다. 많은 코딩 작업들이 완전히 AI(또는 인간)에게 맡기기 어려운 이유는 완전히 명세되지 않았기 때문입니다. 하지만 하나의 하드웨어/모델 조합에 대한 추론 엔진 포크에서 'tok/s를 높이는 것'은 완전히 명세되어 있으므로, 품질 면에서는 완벽하게 괜찮은 100% 자율 구현의 훌륭한 후보이며 (정확성 테스트만 포함된다면, 이는 사소합니다). 인간 병목 현상이 없습니다.

이 공리들을 연결하면, llama.cpp와 같은 일반 엔진들은 개발 속도, 그리고 따라서 토큰 속도 면에서 일회성 엔진들보다 영원히 뒤처질 것이고, 어느 쪽도 일반성과 개발 속도를 유지할 수 없을 것입니다. 일회성 추론 엔진들은 특정 하드웨어/모델 조합을 위해 계속해서 확산되고 사랑받을 것입니다.

제 TED 강연에 와주셔서 감사합니다. 함의:

이 테제는 흥미로운 질문을 제기합니다: 추론 엔진에서 무엇이 공통적으로 남아있을까요?

가장 명확한 예시: 모든 엔진마다 다른 사용 API를 갖는 것은 번거로울 것이기 때문에, 우리는 이미 오래전에 OpenAI API 호환성을 표준화했습니다. CLI 인자/설정에서도 그럴까요? 패키징된 GUI(llama-server)? 벤치마킹 도구(llama-bench)? 로깅, 모델 형식 등등은요? 추론 자체를 감싸는 모든 것을 복제하는 일회성 엔진들은 채택하기가 더 매끄러울 것입니다. 예를 들어, 제가 이 새로운 일회성 엔진들을 직접 사용해 보지 못한 주된 이유는 llama.cpp를 제대로 구동하는 방법을 알아내는 것 자체가 충분히 번거로웠기 때문입니다. 정말 가치가 있는 경우가 아니라면 다시 그렇게 하고 싶지 않습니다. 이 모든 것을 표준화하고 일회성 엔진들이 채택하기 쉽게 만드는 오픈 소스 프로젝트의 자리가 있을 것입니다. 어쩌면 특정 하드웨어 플랫폼만을 목표로 하는 '반(半)범용' 추론 엔진들을 더 많이 보게 될지도 모릅니다. 즉, 모델 차원에서는 여전히 일반적이지만, 하드웨어 측면에서는 그렇지 않은 경우입니다. Splash가 한 예일 수 있습니다. 아무도 자신의 모델/장비에 가장 적합한 추론 엔진을 찾기 위해 github/reddit/x를 지속적으로 스캔하고 싶어 하지 않습니다. 일부는 자체 에이전트를 만들어 맞춤형으로 만들 것입니다. 하지만 더 많은 사람들은 그렇게 하지 않을 것이라고 생각합니다. 따라서 하드웨어별 커뮤니티가 형성될 것입니다. r/appleM2Max32gbLLM이나 r/4090And64gbRamLLM처럼요 (실제로는 어떻게 조직될지는 과장해서 이름을 지은 것입니다.) 대안적인 미래 시나리오: 일회성 미래가 일어나지 않는 경우, 범용 추론 엔진이 모델/하드웨어별 커널과 계산 그래프를 '플러그인화(plugin-ify)'하여 런타임에 교체할 수 있는 방법을 찾아내는 것입니다. 따라서 단순히 .gguf 파일뿐만 아니라, 특정 하드웨어와 특정 모델을 위한 최적화를 포함하는 .inference_recipe도 다운로드하게 될 것입니다. 어쩌면 그러한 최적화들이 3개월 안에 llama.cpp 메인라인에 들어갈 수도 있지만, 포크(fork) 없이 오늘 바로 사용할 수 있습니다.

일반적인 추론 엔진들은 워크플로우를 AI화하는 방식을 찾아내어, 품질과 코드베이스의 일관성을 유지하면서도 개별 모델/하드웨어 플랫폼에 대해 독립형(one-off) 프로젝트와 동일한 개발 속도를 달성합니다. 저는 이것이 관련된 모든 사람들에게 가장 좋다고 생각합니다. MLIR나 Mojo 같은 것들의 전체적인 비전이 충분히 실현된 것입니다. 즉, 하드웨어 최적화 커널을 작성하는 것이 컴파일러에 의해 완벽하고 눈에 띄지 않게 처리되어, 더 이상 각 실리콘 플랫폼마다 하드웨어별로 손댈 필요가 없어집니다.) 그러면 모든 하드웨어/모델을 포괄하는 추론 엔진은 유지보수 및 기능 추가가 훨씬 수월할 것입니다. 참고로, 만약 정말 큰 영향을 미치고 싶다면 이것을 해결하세요. 미래의 수 세기 동안 세상이 당신에게 감사할 겁니다. 불행하게도 이 목표 자체를 개념화한 사람이 많지 않습니다. P.S. 단일 모델/하드웨어 엔진과는 별개의 차원에서 성장이 있습니다. 이는 '일반 추론 엔진의 기능들을 선점하는 것(frontrunning)'과 같은 것으로, PR을 통합하는 것이 느리기 때문에 발생합니다. Freetoken, BeeLlama 등이 예시입니다. 제가 제시한 다른 예시들만큼 모델이나 하드웨어에 특화되지는 않았습니다. 이 차원에 대해서는 깊이 생각해 본 적이 없습니다. submitted by /u/netherreddit to r/LocalLLaMA [link] [comments]