Local LLM 서버 데몬


요약

https://crates.io/crates/llm-daemon

https://pypi.org/project/bihyung

LLM 서버를 데몬으로 띄워서, 실제로 LLM 생성이 필요할 때만 쓰고 쓰지 않을때는 자동으로 종료시키는 프로그램입니다.

주의사항

블로그 주인장이 월말까지 코파일럿 결제를 했기 때문에 한동안 몹시 친절한 코파일럿 말투로 글을 쓰게 될 것입니다.

왜 필요한가요?

LLM 서버는 메모리를 많이 먹는 편이라, 항상 켜놓고 있기에는 부담이 될 수 있습니다.

이를테면 제가 노트 작성 도우미 앱을 Language Server Protocol을 이용해서 만들고 있다고 합시다. 앱에서 LLM 기능이 필요한데 그걸 위해서 미리 LLM 서버를 띄워놓고 그 다음에서야 문서 편집기를 실행한다? 매우 비효율적이죠. 혹은 LSP 서버 내에서 LLM 서버를 실행할 수도 있겠지만, 그러면 또 LSP 서버가 엄청난 메모리를 차지하고, 경우에 따라 편집기를 여러 개 실행하는 경우 LLM 서버가 여러개 돌아가는 환장할 상황이 벌어질 수도 있습니다.

즉, LLM 서버는 “비싼 공유 자원”이라고 할 수 있습니다. 그리고 항상 쓰는게 아니라 필요할 때만 쓰는 상황입니다. 저는 왠지 이런 상황이 빌드 서버와 비슷해 보여서, 이미 널리 쓰이고 있는 buck, bazel 등의 빌드 시스템에서 채용하는 빌드 서버 개념을 적용해보고 싶었습니다.

구조

llm-daemon 라이브러리를 쓰는 앱을 만들고, 데몬을 구동하도록 하면 별도의 프로세스에서 LLM 서버가 돌아가게 됩니다. 앱이 실행되는 동안에는 LLM 서버가 계속 실행될 수 있도록 주기적으로 heartbeat를 보내게 되며, 앱이 종료되거나 크래시가 발생해서 heartbeat가 끊기면 잠시 후에 LLM 서버가 자동으로 종료됩니다.

여러 개의 앱이 동시에 실행되는 경우, LLM 서버는 하나만 실행되며, 모든 앱들은 이 하나의 LLM 서버를 공유하고 heartbeat를 전송하게 됩니다.

활용법

Rust에선 llm-daemon을 그대로 쓰면 되고, Python에선 bihyung(비형)이란 이름으로 같은 기능의 라이브러리를 제공합니다.

이걸 그대로 써도 되고, LLM 서버를 필요로 하는 langchain 등의 툴에 연결해서 사용해도 매우 유용할 것으로 예상됩니다. 다만 블로그 주인장이 langchain을 쓰지 않기 때문에 아직 연동을 구현하지는 않았습니다.

추후 개선하고 싶은 사항

  • 안정적인 데몬 실행환경 / 로그 설정
    현재 이런저런 문제로 tokio 런타임을 실행하기 전에 데몬을 실행해야 하는 등의 제한이 있는데, 유저가 이러한 제한들을 쉽게 이해할 수 있도록 만들어야 할 것입니다.
  • Langchain 등의 연동
    보아하니 langchain이 이미 뭔가 인터페이스를 정의해 놨을 것 같은데, 그걸 가져다 쓰면 내가 따로 구현할 필요가 없을 것 같습니다.