데이터가 이미 있는 곳에서돌 만큼 작습니다.
Megha는 0.6B 파라미터의 인과 언어 모델로, 에이전트형 작업과 코딩, 여러 언어의 지시 수행을 위해 만들었습니다. 크기가 곧 요점입니다. 로컬 처리는 모델이 실제로 당신의 기기에 들어갈 때에만 진짜 보장이 되니까요.
모델 카드 전체를 한 화면에.
- 파라미터
- 0.6B
- 전체
- 임베딩 제외
- 0.44B
- 파라미터
- 층
- 28
- 트랜스포머 블록
- 어텐션 헤드
- 16Q / 8KV
- 그룹 쿼리
- 컨텍스트 길이
- 32,768
- 토큰
- 아키텍처
- 인과 LM
- 디코더만
- 언어
- 100+
- 지시 수행
- 사고 모드
- 켜고 끄기
- 추론 시점에
28개 층, 그룹 쿼리 어텐션.
쿼리 헤드 16개가 키/값 헤드 8개를 나눠 쓰는 그룹 쿼리 어텐션이 KV 캐시를 작게 유지해, 일반 하드웨어에서도 32K 컨텍스트가 가능해집니다.
그룹 쿼리 어텐션 · 16Q / 8KV
키/값 헤드를 쿼리 헤드끼리 나눠 쓰면 완전한 멀티헤드 어텐션에 견주어 KV 캐시가 대략 절반으로 줄어듭니다. 그래서 32K 컨텍스트가 워크스테이션이 아니라 노트북에서도 성립하고, 로컬 처리라는 보장이 이론이 아니라 실무가 됩니다.
값을 할 때에만 켜는 추론.
사고 모드는 모델에 구워 넣은 것이 아니라 추론 시점에 켜고 끕니다. 일상적인 추출·분류·서식은 그것 없이 돌아 빠르게 유지되고, 여러 단계의 계획과 까다로운 리팩터링에는 추가 추론 예산이 붙습니다. 에이전트 스케줄러가 작업마다 고르고, 당신이 덮어쓸 수 있습니다.
- 배포 단위가 아니라 요청 단위로 전환
- 일상적인 일은 기본적으로 지연이 낮게 유지된다
- 에이전트 스케줄러가 정하고, 무엇을 정했는지 보여 준다
- 어느 쪽이든 예산은 적용된다. 사고 모드는 백지수표가 아니다
- 끔분류, 추출, 서식, 서식 틀 채우기
- 끔단순한 라우팅과 임베딩 생성
- 켬여러 파일에 걸친 리팩터링과 의존성을 살핀 수정
- 켬첫 수를 잘못 두면 비싼, 여러 단계의 계획
Megha는 선택지이지, 바꿀 수 없는 기본값이 아닙니다.
MeghaOS는 작은 모델을 함께 넣어, 수수한 하드웨어에서도 첫 실행이 오프라인으로 됩니다. Megha도, 더 마음에 드는 무엇이든, 설치 한 번 거리입니다.
작은 모델이 함께 들어 있습니다
지원하는 어떤 기기에서도, 메모리가 넉넉지 않은 오래된 Mac과 PC에서도 첫 실행이 오프라인으로 되도록. 라우팅, 추출, 분류, 도구 고르기는 잘합니다. 일부러 작게 만들었지, 일부러 강하게 만든 것이 아닙니다.
Megha 설치는 한 줄
Ollama로 받아 오거나 vLLM으로 띄운 다음, MeghaOS를 그 엔드포인트로 향하게 하세요. 위의 모델 카드가 설명하는 구성이 이것이고, 메모리에 여유가 있는 기기라면 이걸 권합니다.
아예 다른 모델을 가져와도 됩니다
Ollama나 vLLM으로 띄울 수 있는 것이면 무엇이든 됩니다. Qwen이든 DeepSeek이든 Kimi든, 이미 쓰시던 것이든. MeghaOS는 OpenAI 호환 엔드포인트와 이야기할 뿐, 그 뒤가 무엇인지는 신경 쓰지 않습니다.
호스팅 제공자를 써도 됩니다
자기 키로 클라우드 API를 향하게 하거나 MeghaOS Pro를 구독하세요. 이 길로 보낸 요청은 기기를 떠납니다. 그게 이 거래의 전부입니다. 얼마가 들고 무엇을 사는지는 가격 페이지를 보세요.
원하면 MeghaOS 밖에서도 돌리세요.
이 모델은 이미 쓰시는 런타임에 그대로 붙습니다. 운영체제에 묶인 부분은 없습니다.
ollama run meghavllm serve meghaos/megha-0.6bpython -m sglang.launch_server --model-path meghaos/megha-0.6bfrom transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("meghaos/megha-0.6b")모델 가중치와 토크나이저 설정은 hf.co/meghaos/megha-0.6b에서 Apache 2.0으로 제공합니다.
0.6B 모델이 아닌 것.
이 대목을 곧이곧대로 적는 것이, 이 페이지의 나머지를 믿을 만한 이유입니다.
프런티어 모델이 아닙니다
열린 추론, 긴 글쓰기, 어렵고 새로운 문제에서 0.6B 모델은 프런티어 시스템을 따라가지 못합니다. 따라가려 들지도 않습니다.
이 맞바꿈은 의도한 것입니다
분류, 추출, 라우팅, 서식, 도구 호출. 에이전트가 실제로 하는 일의 대부분이 이것이고, 거기서는 작은 로컬 모델이 더 빠르고, 호출마다 값이 들지 않으며, 요청 제한과도 무관합니다.
하이브리드는 되지만, 필수는 아닙니다
MeghaOS를 더 큰 로컬 모델로도, 호스팅 모델로도 향하게 할 수 있습니다. 호스팅 제공자로 보낸 것은 기기를 떠납니다. 그쪽으로 보낸다는 게 바로 그 뜻이고, 이는 당신이 고르는 설정이지 조용히 일어나는 일이 아닙니다.
로컬은 실패의 한 갈래를 통째로 없앱니다
운영 환경에서 LLM 오류의 큰 몫이 요청 제한입니다. 로컬 모델에는 제한이 걸릴 수 없으니, 호스팅 모델이라면 멈춰 섰을 시간대에도 에이전트는 계속 일합니다.