r/LocalLLaMA•약 6시간 전•31•16

H2O-Lightning-4B: Apache-2.0 4B 의사결정 모델, JevBench 공식 1위 오픈 모델(Jev 상회)

H2O-Lightning-4B: Apache-2.0 4B Decision model, official #1 open model on JevBench (above Jev)

핵심 요약

H2O.ai에서 공개한 고속 의사결정 특화 4B 모델로, 단일 추론으로 정확한 확률값을 제공하며 벤치마크 1위를 기록했습니다.

고속 의사결정 — 단일 포워드 패스로 토큰 생성 없이 즉각적인 확률값 도출
벤치마크 1위 — JevBench에서 기존 모델을 상회하는 72.5점 기록
로컬 데이터 처리 — 외부 API 호출 비용 없이 로컬에서 안전하게 실행 가능
확장성 예고 — 향후 12B 및 31B 버전 출시로 성능 향상 예정

참고: 저는 H2O.ai에서 일합니다.

Jev가 유행시킨 "decisions API" 방식의 추론을 위해 오픈 웨이트(Apache-2.0) 모델인 H2O-Lightning-4B를 공개했습니다. 상태값과 유형별 질문(택일/예-아니오/점수)을 보내면 단 한 번의 포워드 패스로 보정된 확률값을 바로 뱉어냅니다. 토큰을 생성할 필요가 없어서 속도도 빠르고 비용도 저렴합니다.

**결과 (JevBench, 공개 리더보드):**
- 종합 점수 72.5점, Jev 1.13(71.5점) 대비 우위; 현재 오픈 모델 중 1위
- 리더보드: https://benchmarkheaven.com/jev-models

**실행 방법:**
- 베이스: Qwen3.5-4B 파인튜닝
- 기본 vLLM에 작은 오픈 심(레포지토리에 포함) 사용; H100 기준 결정당 ~30ms 소요
- 데이터는 로컬에 남고, 호출당 비용 없음

**출시 예정:** 12B 및 31B 버전. 내부 테스트 결과 Jev보다 훨씬 똑똑하고, 여전히 오픈 웨이트에 결정당 포워드 패스 한 번으로 작동함.

**데모** (보험 청구 1,000건 메일함 분류, 멀티 브라우저 웹 에이전트, 결정 클럭으로 돌리는 DOOM):

웨이트, 모델 카드 및 서빙 가이드: https://huggingface.co/h2oai/h2o-lightning-4b

설정이나 지연 시간 관련해서 궁금한 거 있으면 편하게 물어봐.

원문

커뮤니티 목록

r/LocalLLaMA•약 6시간 전•31•16

H2O-Lightning-4B: Apache-2.0 4B 의사결정 모델, JevBench 공식 1위 오픈 모델(Jev 상회)

H2O-Lightning-4B: Apache-2.0 4B Decision model, official #1 open model on JevBench (above Jev)

핵심 요약

H2O.ai에서 공개한 고속 의사결정 특화 4B 모델로, 단일 추론으로 정확한 확률값을 제공하며 벤치마크 1위를 기록했습니다.

고속 의사결정 — 단일 포워드 패스로 토큰 생성 없이 즉각적인 확률값 도출
벤치마크 1위 — JevBench에서 기존 모델을 상회하는 72.5점 기록
로컬 데이터 처리 — 외부 API 호출 비용 없이 로컬에서 안전하게 실행 가능
확장성 예고 — 향후 12B 및 31B 버전 출시로 성능 향상 예정

참고: 저는 H2O.ai에서 일합니다.

**결과 (JevBench, 공개 리더보드):**
- 종합 점수 72.5점, Jev 1.13(71.5점) 대비 우위; 현재 오픈 모델 중 1위
- 리더보드: https://benchmarkheaven.com/jev-models

**출시 예정:** 12B 및 31B 버전. 내부 테스트 결과 Jev보다 훨씬 똑똑하고, 여전히 오픈 웨이트에 결정당 포워드 패스 한 번으로 작동함.

**데모** (보험 청구 1,000건 메일함 분류, 멀티 브라우저 웹 에이전트, 결정 클럭으로 돌리는 DOOM):

웨이트, 모델 카드 및 서빙 가이드: https://huggingface.co/h2oai/h2o-lightning-4b

설정이나 지연 시간 관련해서 궁금한 거 있으면 편하게 물어봐.

주요 댓글

r/localllama

H2O-Lightning-4B의 의사결정 효율성과 속도에 대해 긍정적인 반응이 많으며, 특히 라우팅 용도로 사용할 때의 확률 보정 및 임계값 설정에 대한 기술적 논의가 활발합니다.

데이터셋 122k 행을 평가하는 데 H2O를 사용해 봤는데 꽤 괜찮음. Decider 4b 및 Claude Opus 5.5와 벤치마크를 비교했을 때 Opus와 약 97% 정도 일치했음. Decider의 92~93%보다 훨씬 가까운 수치임(벤치마크는 전체 데이터셋이 아닌 20개 예제 x 18개 질문으로 수행). 주로 복잡성 판단에서 의견이 갈렸는데, 작은 모델이 Opus보다 예제를 더 복잡하게 느끼는 건 당연한 결과임.

H2O-Lightning-4B 공개해 줘서 고마워요. 더 큰 모델로 넘기기 전의 1차 분류기로 테스트 중인데, 확률값 때문에 어려운 점이 두 가지 있네요.

중간 범위의 보정(Calibration)

직접 라벨링한 데이터셋(수동 분류 300개, 이진 선택)에서 각 확률 구간별 양성 비율은 다음과 같았음:

H2O 0.2~0.4: 실제 양성 11%
H2O 0.4~0.6: 실제 양성 20%
H2O 0.6~0.8: 실제 양성 75%
H2O 0.8~0.95: 실제 양성 81%

즉, 0.2에서 0.6 사이의 모든 값이 과대평가되어 있는데, 여기가 딱 에스컬레이션(상위 모델로 넘기는) 구간임.

지나치게 자신감 있는 예/아니오 답변

모델 카드에는 0.2~0.8 사이의 예/아니오 답변이 74개 중 0개라고 나옴. JevBench v1.6.1 보드를 보면 v1.1의 반대 사례가 보이는데, 예/아니오 답변의 약 15%가 자신감 있게 틀렸고 불확실한 구간에 걸치는 게 하나도 없음. 확률을 보고 에스컬레이션 여부를 결정하는 사람에게는 이게 최악임. 아무것도 플래그되지 않고 틀린 답변만 자신만만하니까.

serve_config.json의 noul_floor 0.801 설정이 예/아니오 답변을 의도적으로 중간 구간에서 밀어내는 것 같은데, 이유를 문서화하거나 선택 사항으로 만들 수 있을까요? 원본 수치를 보고하는 모드가 있으면 H2O를 폴백(fallback) 뒤에서 쓰기가 훨씬 쉬울 것 같아요.

감사합니다. 정말 유용한 피드백이네요. 저희가 지원하고자 하는 라우팅 사례에 딱 맞습니다.

예/아니오 하한값(질문 2번)에 대해 말씀드리자면, 이미 선택 사항입니다. 쉼(shim)을 SHIM_NOUL_FLOOR=0으로 시작하면 예/아니오 답변이 원본 확률을 유지합니다. 이게 왜 존재하는지, 라우팅에 어떤 영향을 미치는지 문서화했습니다: https://huggingface.co/h2oai/h2o-lightning-4b#routing-thresholds

기본값으로 설정된 이유는 리더보드 점수가 예/아니오 질문에 대한 확신을 보상하기 때문입니다. 그래서 기본적으로 쉼은 선택된 쪽을 0.801 이상으로 보고합니다. 그게 보드에서 보신 '구간 내 74개 중 0개'와 자신감 있게 틀린 답변의 원인입니다. 에스컬레이션용으로는 잘못된 설정이죠. 하한값을 끄면 3,474개의 홀드아웃 질문에서 0.9 임계값 기준, 59.5%를 에스컬레이션하면서 자신감 있게 틀린 답변은 0.4%에 불과합니다. 처음부터 카드에 더 명확히 기재했어야 했는데 죄송합니다.

중간 범위 보정(질문 1번)에 대해 말씀드리면, 이진 선택 항목은 '선택' 질문으로 점수가 매겨지므로 하한값 설정의 영향을 받지 않습니다. 지금 보시는 건 온도(temperature) 때문입니다. 기본 온도는 저희 데이터에 맞춰 튜닝된 단일 값인데, 사용자님의 도메인은 0.2~0.6 범위에서 다르게 작동하는 것 같네요.

두 가지 옵션이 있습니다:

쉼에서 SHIM_TEMPERATURE를 설정할 수 있습니다. 300개의 라벨링된 항목이 있다면 몇 줄의 코드로 교차 검증을 통해 온도(또는 반환된 확률에 Platt 스케일링 적용)를 맞출 수 있습니다. 보통 모델이 선택하는 답을 바꾸지 않고도 잘못된 중간 스케일을 바로잡을 수 있습니다.
질문 유형별로 온도를 다르게 설정하는 업데이트가 곧 나올 예정이니, 선택 질문 케이스에도 도움이 될 겁니다.

300개 항목(또는 구간별 카운트라도)을 공유해 주실 수 있다면 확인해 보고 싶습니다. 작은 구간은 노이즈가 많아서, 이게 도메인 시프트인지 다음 모델에서 수정할 수 있는 문제인지 확인하는 데 도움이 될 겁니다.

감사합니다. SHIM_NOUL_FLOOR=0으로 하한값을 끌 수 있다는 점이 도움이 되네요. 라우팅 임계값 섹션이 딱 필요했던 정보였습니다.

중간 범위 포인트에 대해 한 가지 반론하자면, 온도나 Platt 스케일링은 에스컬레이션 구간을 '어디에' 둘지는 고쳐주겠지만, '얼마나 많은' 에스컬레이션이 필요한지는 해결해주지 못합니다. 둘 다 단조 함수라 순위를 바꾸지 않거든요. 순위로 선택한 구간(가장 확신 없는 N개 항목)은 어떤 방식이든 같은 항목을 에스컬레이션하게 됩니다. 예산별 최적 구간에서 2,683개 항목 중 결과는 다음과 같습니다:

에스컬레이션 25개: H2O 285/300, 고정된 Gemma-4-12B 설정 296/300
에스컬레이션 100개: H2O 288/300, Gemma-4-12B 298/300
에스컬레이션 300개: H2O 296/300, Gemma-4-12B 298/300

즉, 차이는 스케일이 아니라 분리도(H2O AUC 0.965 vs 0.992)에 있습니다. 유형별 온도를 적용하면 기본 임계값이 더 잘 맞겠지만, 다음 모델이 중간 난이도를 더 잘 순위 매겨야 이 격차를 줄일 수 있을 겁니다.

요청하신 구간별 카운트입니다(구간: 항목 수, 양성 수):

0.00~0.05: 93, 0
0.05~0.20: 95, 0
0.20~0.40: 44, 5
0.40~0.60: 20, 4
0.60~0.80: 16, 12
0.80~0.95: 27, 22
0.95~1.00: 5, 5

항목 자체를 공유할 수 없어 죄송합니다. 구간별 순서는 깔끔한데, 문제는 0.2~0.95 구간에서 양성과 음성이 섞이는 겁니다.

수치는 모두 저희 실행 결과입니다. '고정된 Gemma-4-12B 설정'은 Cygnet입니다.

혹시 채용 중인가요?

물론이죠!

의사결정 분야를 밀어붙이는 오픈 모델이 더 많이 나오는 건 언제나 멋진 일이죠. 단일 포워드 패스 방식은 전체 생성이 필요 없는 작업에 정말 깔끔한 방식이고, 속도도 빠르고요.

회사 내부 툴링을 위해 비슷한 워크플로우를 만지작거리고 있는데, 수천 개의 항목을 루프 돌릴 때 속도 차이가 장난이 아닙니다. H100에서 30ms면 그 규모에서는 사실상 즉각적인 수준이죠.

그리고 영상에 나온 DOOM 데모는 생각보다 훨씬 재밌네요. 12B랑 31B 버전이 나오면 성능이 어떨지 기대됩니다.

H2O가 아직도 있다는 게 놀랍네요. 근데 언어 모델을 의사결정에 사용하는 것의 매력이 정확히 뭔가요? BERT 스타일 모델이 더 효율적이고 이 작업에 훨씬 더 적합하지 않나요?

좋은 질문입니다. Jev 방식은 지능과 속도 사이의 좋은 균형을 보여줍니다. BERT는 이해력 측면에서 의미론적으로 약간 부족한 면이 있습니다.

질문 유형별로 보정 결과를 세분화한 자료가 있나요? 특히 더 강력한 모델이나 사람에게 넘겨야 하는 임계값 근처의 결정들 말입니다. 라우팅을 위해서는 선택한 임계값에서 자신감 있게 틀린 답변이 얼마나 자주 빠져나가는지, 그리고 얼마나 많은 사례가 에스컬레이션되는지 알고 싶습니다. 복합 점수만으로는 그 트레이드오프를 알 수 없으니까요. 실행 전에 임계값을 고정한 작은 홀드아웃 세트가 있으면 이 의사결정 모델들을 비교하는 데 유용할 것 같습니다.

좋은 질문입니다. 정확히 그 분석 결과를 여기에 게시했습니다:
https://huggingface.co/h2oai/h2o-lightning-4b#routing-thresholds

원문r/LocalLLaMA

지금 같이 볼 만한 글

r/LocalLLaMA•1일 전

OpenRouter에 등장한 StepFun Step 5 프리뷰

OpenRouter에 600B 파라미터 규모의 StepFun Step 5 모델이 등장하며 성능과 출시 방식에 대한 논의가 이어지고 있습니다.

3913

Reddit 원문

r/ClaudeCode•약 19시간 전

헤비 AI 사용자들 주목

Claude에게 무한한 자원을 가정하게 했다가 엣지 브라우저 1만 3천 개가 실행되며 PC가 마비된 사용자 이야기입니다.

666241

Reddit 원문

r/OpenAI•약 22시간 전

앤스로픽, 클로드 대상 '학대 및 잔혹 행위' 금지

앤스로픽이 클로드에게 학대나 잔혹한 언행을 하는 것을 금지한 정책에 대해 사용자들 사이에서 논쟁이 벌어짐.

261228논쟁

Reddit 원문

커뮤니티 전체 보기

원문

주요 댓글

r/localllama

H2O-Lightning-4B 공개해 줘서 고마워요. 더 큰 모델로 넘기기 전의 1차 분류기로 테스트 중인데, 확률값 때문에 어려운 점이 두 가지 있네요.

중간 범위의 보정(Calibration)

직접 라벨링한 데이터셋(수동 분류 300개, 이진 선택)에서 각 확률 구간별 양성 비율은 다음과 같았음:

H2O 0.2~0.4: 실제 양성 11%
H2O 0.4~0.6: 실제 양성 20%
H2O 0.6~0.8: 실제 양성 75%
H2O 0.8~0.95: 실제 양성 81%

즉, 0.2에서 0.6 사이의 모든 값이 과대평가되어 있는데, 여기가 딱 에스컬레이션(상위 모델로 넘기는) 구간임.

지나치게 자신감 있는 예/아니오 답변

감사합니다. 정말 유용한 피드백이네요. 저희가 지원하고자 하는 라우팅 사례에 딱 맞습니다.

두 가지 옵션이 있습니다:

쉼에서 SHIM_TEMPERATURE를 설정할 수 있습니다. 300개의 라벨링된 항목이 있다면 몇 줄의 코드로 교차 검증을 통해 온도(또는 반환된 확률에 Platt 스케일링 적용)를 맞출 수 있습니다. 보통 모델이 선택하는 답을 바꾸지 않고도 잘못된 중간 스케일을 바로잡을 수 있습니다.
질문 유형별로 온도를 다르게 설정하는 업데이트가 곧 나올 예정이니, 선택 질문 케이스에도 도움이 될 겁니다.

감사합니다. SHIM_NOUL_FLOOR=0으로 하한값을 끌 수 있다는 점이 도움이 되네요. 라우팅 임계값 섹션이 딱 필요했던 정보였습니다.

에스컬레이션 25개: H2O 285/300, 고정된 Gemma-4-12B 설정 296/300
에스컬레이션 100개: H2O 288/300, Gemma-4-12B 298/300
에스컬레이션 300개: H2O 296/300, Gemma-4-12B 298/300

요청하신 구간별 카운트입니다(구간: 항목 수, 양성 수):

0.00~0.05: 93, 0
0.05~0.20: 95, 0
0.20~0.40: 44, 5
0.40~0.60: 20, 4
0.60~0.80: 16, 12
0.80~0.95: 27, 22
0.95~1.00: 5, 5

항목 자체를 공유할 수 없어 죄송합니다. 구간별 순서는 깔끔한데, 문제는 0.2~0.95 구간에서 양성과 음성이 섞이는 겁니다.

수치는 모두 저희 실행 결과입니다. '고정된 Gemma-4-12B 설정'은 Cygnet입니다.

혹시 채용 중인가요?

물론이죠!

그리고 영상에 나온 DOOM 데모는 생각보다 훨씬 재밌네요. 12B랑 31B 버전이 나오면 성능이 어떨지 기대됩니다.

좋은 질문입니다. Jev 방식은 지능과 속도 사이의 좋은 균형을 보여줍니다. BERT는 이해력 측면에서 의미론적으로 약간 부족한 면이 있습니다.

좋은 질문입니다. 정확히 그 분석 결과를 여기에 게시했습니다:
https://huggingface.co/h2oai/h2o-lightning-4b#routing-thresholds

원문r/LocalLLaMA

유형	임계값	에스컬레이션	나머지 정확도	자신감 있게 틀림
선택	0.9	51.3%	98.6%	0.7%
예/아니오	0.9	59.5%	99.1%	0.4%
점수	0.9	74.3%	100.0%	0.0%
전체	0.8	39.1%	96.2%	2.3%
전체	0.9	56.2%	98.8%	0.5%