Ollaya, Jev 스타일 결정 모델을 로컬에서 밀리초 만에 실행하는 오픈소스 런타임 공개
- Ollaya가 Jev형 결정 모델을 로컬에서 돌리는 오픈소스 런타임을 공개함. ONNX 런타임으로 CPU와 NVIDIA GPU에서 실행하고 HTTP 서버는 기본적으로 127.0.0.1에 바인딩됨
- RTX 4090에서 Laya가 질문 5개 요청을 8~10ms에 처리해, TypeSafe Jev 호스티드 API 중앙값 236~276ms보다 크게 빠르고 모델별 지연은 laya:multilingual 8.1ms에서 decider:2b 190ms까지 퍼짐
- TypeSafe API와 드롭인 호환임. /v1/systemone과 /v1/models를 TypeSafe 요청·응답 형태로 서빙하고, 공식 TypeSafe Python SDK 0.7.1이 로컬 서버에 수정 없이 동작함
- 가중치는 저자의 Hugging Face 저장소에서 커밋 고정과 sha256 검증을 거쳐 내려받고, 런타임은 Apache-2.0임. 모델은 Convai Innovations의 Laya(322m·421m), Mapika의 decider, Moritz Laurer의 nli, Knowledgator의 gliclass가 있음
- HN 토론에서 Laya의 정확도가 Jev보다 크게 낮다는 지적이 이어짐. jevbench 순위표에서 Laya 421M는 30.25점으로 41위인데 Jev 1.13이 63.29점 2위, decider-4b v2가 64.13점 1위임. 논문 페이지는 Laya의 보정 오차(ECE)를 0.081로, Jev는 0.246으로 제시함
Hacker News opinions
- Jev랑 비교할 만한 범용 결정 모델이 많나? 평가 세트가 있으면 그냥 분류기 하나 학습시켜서 끝내는 게 낫다고 봄.
- Hugging Face에 비슷한 모델 모아둔 스페이스가 있더라. 최고 오픈 모델은 Perplexity CTO가 $3k에 학습시킨 건데 좀 멋짐.
- 그 스페이스가 개요로 괜찮음. 요즘 오픈 모델들은 Jev에 근접하긴 하는데 덩치가 크고, 고정 과제에 평가 세트가 있다면 학습시킨 분류기가 맞음.
- 근데 Ollama가 언제든 결정 모델을 지원하면 좀 위험하지 않나? 게다가 go-llama이고 Rust도 아니라서 'Ollama for X'라는 호칭도 이상하고.
- 뭐 그럴 수도 있지. 나는 Ollaya에 코드를 묶지도 않음. Jev랑 같은 API 쓰니까 어느 쪽이든 그대로 갈아타면 됨.
- Jev형 결정 모델이 눈에 띈다면 Ollama가 지원할 거라고 봄. 팀이 아직 안 한 게 좀 의외임.
- 반응 속도는 좋은데 실제 결정 품질은 Jev 대비 어때?
- 개발자인데 솔직히 말하면 Laya는 Jev보다 많이 약함. 어려운 쿼리에선 확실히 떨어지고, 작은 모델이라 빠른 게 다임. Jev에 근접하는 오픈 모델은 훨씬 커서 그걸 붙이는 게 다음 작업임.
- 나도 써봤는데 Laya가 복잡한 쿼리에서 확률도 낮고 결정도 자주 틀림.
- LLM 시대엔 데이터셋 생성이 겁나 싸고 빠름. Laya 파인튜닝 비용도 얼마 안 드는데 굳이 Jev 돈 낼 이유가 있을지 모르겠음.
- jevbench 하루에 두 번씩 보고 있는데 재밌더라. 지금 순위는 decider-4b v2가 64.13점 1위, Jev 1.13이 63.29점 2위, JevK5 v0.2가 62.04점 3위. Laya 421M는 30.25점으로 41위임.
- jev/laya용 시맨틱 그렙 도구를 각각 만들어 봤는데, '남자 이름이다' 같은 단순 쿼리는 처음엔 비슷해 보였거든. 그런데 쿼리가 조금만 복잡해지면 laya가 완전 무너지고, 쿼리 표현만 바꿔도 아예 아무것도 못 찾더라. 로컬로 빠르게 돌리고 싶었는데 아직은 안 됨.
- 'decision model'이 그냥 마케팅 용어 아닌가? 분류기 + 소형 비추론 LLM일 뿐이고 confidence는 확률의 함수인데.
- instruct 기반 리랭커랑 laya/jev가 뭐가 다른 건지 솔직히 모르겠음. 제로샷 다중 과제에서 캘리브레이션된 확률 낸다는 거 말고는 차이가 안 보여.
- 차이라면 laya/jev는 학습 없이 쓰는 제로샷 분류기라는 점. LLM으로 프롬프트 돌려가며 시작해서 실제 데이터 모으고, 루브릭으로 만들어 Jev에 넣고, 마지막에 그 평가 세트로 커스텀 분류기 파인튜닝하는 흐름이 현실적임.
- Jev 가치는 과제가 계속 움직일 때 드러남. 자동 모드 분류기 같은 거에서 진가가 나옴.
- LLM이랑 시스템 원을 하나의 도구에 넣으면 좋겠는데, 결국 Ollama가 했으면 함. vLLM 다음 릴리스에 게이트웨이로 붙는다는 얘기 있고, GoModel이 이미 S1 엔드포인트를 지원함.
- 티켓이랑 이메일이 로컬에 남는 건 끌림. 근데 CUDA 12를 지원해줬으면 좋겠음, GPU 갈아탈 생각은 없는데.
- CUDA 12는 vLLM 다음 릴리스 기다리면 된다던데, 그건 좀 아닌 것 같음.
- 참고로 FAQ에 독립 프로젝트이고 Ollama와 무관하다고 적혀 있음.