📚 전체 지도 보기
오픈소스 LLM vs 클라우드 LLM — 손익분기는 어디인가
“오픈소스 LLM 써야 할까요, 그냥 Claude 쓸까요?”
이 질문에 대한 대답이 기술 블로그에서 이상하게 종교전쟁처럼 흐르는 걸 자주 봅니다. “오픈이 미래다” vs “클라우드가 현실이다” — 양쪽 다 틀린 말은 아닌데, 사실 이건 손익분기 문제예요. 월에 토큰을 얼마나 쓰는가, 데이터가 얼마나 민감한가, GPU를 24시간 돌릴 사이즈의 워크로드가 있는가. 숫자로 답이 나옵니다.
이 글에서는 종교를 빼고 수학만 올려 봅니다.
- “오픈소스”라는 단어부터 정확히 — 오픈 웨이트 vs 진짜 OSI 오픈소스
- 2026년 4월 현재, 라이선스가 어떻게 4분류로 갈리는가
- H100 시간당 × 720h 수학 vs API $/M tok 수학
- 모델 사이즈별 VRAM 요구치
- 손익분기 — 월 2억 토큰이라는 경계선
- 추론 서버 3종(vLLM / TensorRT-LLM / SGLang) — 무엇을 언제
- 하이브리드가 실무에서 가장 많이 보이는 이유
- 시나리오별 선택 표
순서대로 갑니다.
1. “오픈소스 LLM”이라는 말을 정확히 — 지금 대부분은 오픈 웨이트다
“오픈소스 LLM”이라는 말이 한국어 인터넷에서 거의 자동으로 Llama, Qwen, DeepSeek 같은 모델을 가리키게 됐습니다. 근데 이게 엄밀히 보면 틀린 용어예요.
OSI(Open Source Initiative)가 2024년 10월에 확정한 Open Source AI Definition v1.0 기준으로, 어떤 모델이 “오픈소스 AI”라고 불리려면 세 가지가 다 공개돼야 합니다.
- 훈련 데이터: 어떤 데이터로 학습했는지 전체 목록과 접근 방식
- 훈련 코드: 재현 가능한 학습 스크립트·하이퍼파라미터
- 가중치(weight): 최종 모델 파라미터
이 셋이 다 있어야 “오픈소스”입니다. 하나라도 빠지면 오픈소스가 아니에요.
문제는 Llama·Qwen·DeepSeek 모두 가중치만 공개하고 있다는 겁니다. 훈련 데이터의 구체 구성은 비공개거나 개략 설명만 있고, 훈련 코드도 공개 안 한 부분이 많습니다.
그래서 요즘 업계에서 정확하게 쓰려는 표현은 “오픈 웨이트(open-weight)” 예요. 가중치는 열었지만 훈련 데이터·코드는 닫혀 있다는 뜻입니다. Meta가 Llama 4를 발표할 때도 공식 블로그에서 “open weights”라는 표현을 썼습니다.
왜 이 구분이 중요하냐면, 재현 가능성 때문입니다. 훈련 데이터와 코드가 없으면:
– 같은 모델을 처음부터 다시 만들 수 없다
– 학습 데이터에 어떤 편향이 들어갔는지 검증할 수 없다
– 저작권·프라이버시 이슈를 추적할 수 없다
가중치만 공개된 모델은 “무료로 쓸 수 있는 블랙박스”에 가까워요. 당신이 Llama 4를 fine-tune해서 제품에 올렸을 때, 원래 Meta가 어떤 데이터로 학습시켰는지는 추측만 가능합니다.
이 글에서는 정확성을 위해 “오픈 웨이트 LLM” 이라고 쓰되, 독자 편의를 위해 제목과 검색 키워드에선 일반적 표현인 “오픈소스 LLM”을 유지합니다. 같은 걸 가리키고 있다고 이해하시면 됩니다.
ⓘ 이 구분을 처음 본다면 👉 F7. 파라미터 이해에서 “모델 안에 뭐가 있는가”를 먼저 보고 오세요. 가중치 = 파라미터의 최종 저장본입니다.
2. 라이선스 4분류 — 2026년 4월 기준
“오픈 웨이트”라고 해도 라이선스가 다 같은 게 아닙니다. 현재 주요 모델들을 상업 활용 관점에서 4분류로 나누면 이렇습니다.
Llama 4 Maverick
MAU 7억 미만 무료
DeepSeek V3.2
DeepSeek R1
| 구분 | 라이선스 | OSI 승인 | 상업 활용 |
| Llama 4 Scout/Maverick | Llama 4 Community | NO | MAU 7억 미만 무료 |
| Qwen 3, Gemma 4 | Apache 2.0 | YES | 자유 |
| DeepSeek V3/V3.2/R1 | MIT | YES | 자유 |
| GPT-5.4 / Opus 4.7 / Gemini 3.1 | 독점 | — | API만 |
핵심 포인트 몇 개.
(1) Llama 4는 엄밀히는 “오픈 웨이트”가 맞지만 OSI 오픈소스는 아니다.
Meta의 Llama 4 Community License에는 “월간 활성 사용자(MAU) 7억 명을 넘는 회사는 별도 상업 라이선스를 받아야 한다”는 조항이 있어요. 즉 Apple·Google·Amazon 같은 거대 플랫폼이 Meta의 경쟁 제품에 Llama를 쓰는 걸 막는 조항입니다. OSI 오픈소스 정의는 “모든 사용자·용도에 대해 차별하지 말 것”을 요구하기 때문에, 이 조항 하나로 OSI 승인을 못 받습니다.
(2) Qwen 3와 Gemma 4는 진짜 Apache 2.0.
차별 조항이 없어요. 상업 활용 자유, fine-tune 자유, 재배포 자유. OSI 승인된 표준 오픈소스 라이선스입니다. Google의 Gemma 4도 비슷한 방향이에요 — 원래 2024년 Gemma 1에는 “use policy”가 붙어 있었지만 현재 Gemma 4 기준으로는 Apache 계열로 더 열렸습니다.
(3) DeepSeek V3 계열은 MIT — 가장 자유로운 선택.
MIT는 “내 코드 갖다 쓰고 문제 생기면 나는 책임 안 짐”이 전부인 라이선스예요. 수정·재배포·상업화에 아무 제약이 없습니다. DeepSeek가 이 라이선스를 고른 건 의도적 시장 전략으로 읽힙니다 — 가장 제약 없는 조건으로 가장 빨리 생태계를 잡겠다는 거죠.
(4) 클로즈드 모델은 API로만 쓸 수 있다.
GPT-5.4, Opus 4.7, Gemini 3.1 Pro는 가중치 자체를 절대 다운로드 할 수 없어요. 당신이 쓰는 건 OpenAI/Anthropic/Google의 클라우드에서 돌아가는 API 엔드포인트 뿐입니다. 이게 “클라우드 LLM”이라고 부를 때의 현실적 정의예요.
라이선스 해석은 여기까지. 이제부터는 수학입니다.
3. 비용 수학 — API $/M tok vs H100 시간당
“직접 돌리는 게 싸다”는 이야기를 하려면 숫자가 있어야 해요. 두 축을 놓고 비교합니다.
A. API 쪽 가격 (2026-04 기준, per 1M tokens, 입력/출력)
– GPT-5.4: $2.50 / $15
– Opus 4.7: $5 / $25
– Sonnet 4.6: $3 / $15
B. H100 80GB GPU 임대료 (2026-04 기준, 시간당)
– RunPod Community Cloud: $1.49/h (가장 싼 구간)
– 일반 시장가: $2.50~$3.00/h
– 고가 스팟: $3.90/h까지
$1.49/h × 720h = 월 $1,073
중간 가격으로 돌리면 월 $1,800
고가 스팟 기준 월 $2,808
즉 H100 1장을 한 달 쉬지 않고 돌리는 데 들어가는 돈은 약 $1,073 ~ $2,808 (한화 약 148만 ~ 388만 원) 입니다. RunPod처럼 저렴한 커뮤니티 옵션 기준으로 $1,073이 floor고, 현실적으로는 보통 월 $1,500~$2,000 선이에요.
이 돈을 API에 쓴다고 생각해 볼게요. Opus 4.7 입력 기준으로 $1,073 / $5 per 1M = 2.1억 입력 토큰. Sonnet 4.6 입력 기준이면 $1,073 / $3 = 3.6억 토큰. GPT-5.4 입력 기준이면 4.3억 토큰.
당신의 워크로드가 월 2억 토큰 미만이라면, H100 한 장을 빌려서 직접 돌리는 것보다 API로 쓰는 게 무조건 싸다는 얘기예요. 이게 앞으로 반복해서 나올 손익분기 기준선의 출발점입니다.
단, 여기까진 “API 가격만 놓고 본 비교”예요. 실제로는 더 들어가는 비용들이 있습니다:
- 엔지니어링 인건비 (오픈 웨이트 모델 서빙은 사람 손이 많이 듭니다)
- 네트워크·스토리지·S3 egress
- 모니터링·로그 저장·알림 시스템
- 실패 시 대체 옵션 (API fallback이 대부분 필요합니다)
그래서 “순수 GPU 비용”이 API 예산보다 싸다고 해서 바로 손익이 나는 건 아니에요. 실무에서는 “API 비용의 2~3배 토큰을 24/7 쓸 워크로드“쯤 돼야 self-host가 진짜 이득을 본다고 보는 게 보수적 기준선입니다.
4. VRAM 수학 — 어떤 모델이 어느 GPU에 올라가는가
가격 다음은 모델이 GPU에 올라가느냐의 문제입니다. VRAM 용량이 부족하면 아예 못 올려요.
| 모델 사이즈 | 필요 VRAM | GPU 구성 | 예시 |
| 7~13B | 24GB | RTX 4090 1장 | Qwen 3 8B, Gemma 4 9B |
| 70B급 / MoE(17B active) | 80GB | H100 80GB 1장 또는 A100 × 2 | Llama 4 Scout |
| 235B~671B MoE | 320~640GB | H100 × 4~8 + NVLink | Qwen 3 대형, DeepSeek V3 671B |
| Llama 4 10M 컨텍스트 | KV cache 수백 GB | 다중 GPU 샤딩 필수 | Llama 4 Scout 10M context |
여기서 짚을 게 몇 가지 있어요.
(1) 7~13B 모델은 개인용 PC에서도 돈다.
RTX 4090 한 장이면 Qwen 3 8B나 Gemma 4 9B는 충분히 돌아요. 가정용 데스크톱에 AI 라우터를 꽂는 느낌입니다. 다만 한 번에 한 명 정도 처리하는 사이즈고, 동시에 여러 쿼리를 받으려면 배치 최적화가 필요합니다.
(2) 70B는 H100 1장이 기준선.
Llama 4 Scout는 17B active MoE 구조라 실제 파라미터 사용량은 17B 수준이지만, 전체 가중치를 메모리에 올려둬야 해서 VRAM은 70B급이 필요해요. H100 80GB 한 장 또는 A100 40GB 두 장이 현실적 최소치입니다.
(3) 235B~671B MoE는 멀티 GPU 세계.
DeepSeek V3 671B나 Qwen 3 상위 모델을 제대로 돌리려면 H100을 4~8장 NVLink로 묶은 구성이 필요합니다. 여기서부터는 기업 인프라 영역이에요. RAM 128GB 이상, NVMe SSD 2TB 이상도 기본으로 받쳐줘야 합니다. 개인 개발자가 취미로 돌릴 수 있는 사이즈는 아닙니다.
(4) 긴 컨텍스트는 별도의 메모리 폭탄.
Llama 4의 10M 컨텍스트 같은 극단적인 경우, 가중치 자체는 올라가도 KV cache가 수백 GB까지 부풀어요. 컨텍스트 길이 × 레이어 수 × 히든 차원 × 2(K, V) 공식으로 늘어납니다. 그래서 긴 컨텍스트를 self-host로 쓰려면 GPU 한두 장으로는 절대 안 되고, 샤딩 구성이 필수예요.
파라미터 수에 대한 감이 애매하시면 F7. 파라미터 이해를 한 번 보고 오세요. 여기서부터는 그 지식이 돈으로 환산되는 영역입니다.
5. 손익분기 그래프 — 월 2억 토큰이라는 경계선
이제 2장과 3장을 그래프 한 장으로 합칩니다.
이 그래프가 이 글의 한 줄 요약입니다.
월 2억 토큰 미만 = API 유리. 월 2억 토큰 이상 + 24/7 가동 = self-host 검토 가치.
단, 여기에 반드시 따라붙어야 하는 현실 조건들:
-
24/7 가동을 실제로 할 수 있는가. H100 한 장을 빌려놓고 평일 오전만 쓴다면, 빈 시간만큼 그냥 돈을 버리는 거예요. 피크 워크로드가 낮에만 있다면 스팟 인스턴스나 오토스케일링이 필요합니다. 그리고 그걸 설정하는 건 다시 엔지니어 시간이에요.
-
워크로드가 안정적인가. 이번 달엔 10억, 다음 달엔 1,000만 토큰이 나오는 변동 심한 워크로드라면 self-host는 낭비예요. API가 가진 가장 큰 장점은 사용한 만큼만 내는 탄력성입니다.
-
fine-tune한 특수 모델이 필요한가. 기성 모델만 쓸 거면 사실 API의 튜닝 옵션(OpenAI fine-tuning, Claude custom)을 쓰는 게 종합적으로 쌉니다. 오픈 웨이트 self-host가 진짜 필요한 건 “API에서 제공 안 하는 규모·구조의 fine-tune을 하고 싶을 때” 예요.
-
민감 데이터인가. 헬스케어·금융·법률 같은 영역에서는 “데이터를 밖으로 안 내보낸다”가 가격보다 우선입니다. 이 경우엔 손익분기 계산 자체가 무의미해요. self-host가 강제됩니다. (엔터프라이즈 zero-retention 옵션 이야기는 8장에서 다시.)
그래서 “self-host가 유리한 월 2억 토큰”이 실무에서 나오는 사이즈는 꽤 한정적이에요. 회사 단위의 프로덕션 트래픽, 또는 특수 목적 파인튠된 모델을 끊임없이 돌리는 AI 제품이 그 정도 사이즈가 됩니다.
6. 추론 엔진 3종 — vLLM, TensorRT-LLM, SGLang
self-host를 결정했다고 해도 다음 문제가 바로 옵니다. 어떤 추론 엔진을 쓸 것인가.
모델 가중치만 GPU에 올려서는 제대로 된 처리량이 안 나와요. 배치 관리, KV cache 재사용, tensor parallel, 메모리 페이징 같은 최적화가 필수인데 — 이걸 직접 짜지 않고 쓰는 게 추론 엔진입니다. 2026년 4월 현재 주도권을 잡고 있는 건 세 개예요.
가장 많은 모델 지원.
PagedAttention로 KV cache 효율화.
커뮤니티 가장 큼.
vLLM 대비 +15~30% 처리량.
NVIDIA 전용, 컴파일 필요.
모델 고정 시 유리.
RadixAttention로 TTFT 단축.
chatbot·RAG에 유리.
같은 system prompt 반복 시.
실무적 선택 기준을 정리하면 이렇습니다.
vLLM을 기본으로 깔고 시작하세요. 가장 많은 모델을 지원하고, 가장 빨리 새 모델이 올라오고, 문서와 커뮤니티가 가장 큽니다. 아직 self-host 경험이 적다면 일단 여기서 시작해서 기준점을 잡으세요. PagedAttention 덕분에 KV cache 메모리가 꽉 차서 뻗는 일이 거의 없어요.
TensorRT-LLM은 “한 모델을 H100에서 쥐어짜내야 할 때”만. 처리량 +15~30%가 공짜는 아니에요. 모델마다 엔진을 다시 컴파일해야 하고, NVIDIA GPU 외에서는 안 돌아갑니다. 즉 “모델을 자주 바꾸지 않는다” 는 전제가 있을 때만 가치가 있어요. 한 번 셋업하면 H100의 성능을 정말 끝까지 쓸 수 있습니다.
SGLang은 특정 패턴에서 갑자기 빛납니다. 같은 system prompt로 여러 요청이 오는 경우 — 예를 들어 챗봇, RAG 시스템, 프롬프트 템플릿을 고정하고 뒤에 user 메시지만 바꾸는 경우 — RadixAttention이 앞쪽 토큰을 캐시에 저장해둬서 TTFT(첫 토큰까지 걸리는 시간)가 크게 줄어요. 동일한 시스템 프롬프트가 반복되는 패턴에서 vLLM 대비 체감 차이가 나옵니다.
세 개 다 오픈소스고 무료입니다. 상업적 self-host 환경에서는 보통 “vLLM을 기본으로 두고, 특정 모델의 H100 최대 스루풋이 필요하면 그 모델만 TensorRT-LLM으로 뽑고, 채팅·RAG 영역은 SGLang으로 바꾼다“는 하이브리드가 많습니다.
7. 하이브리드 — 실무에서 가장 많이 보이는 진짜 답
여기까지 오면 눈치채셨을 거예요. “오픈 vs 클라우드”가 이분법 질문이 아니라는 걸.
실무에서 가장 많이 보이는 건 하이브리드 구성입니다. 한쪽만 쓰는 조직은 오히려 드물어요.
대표적인 세 가지 패턴을 봅시다.
패턴 1 — Fine-tune은 클라우드, 결과만 self-host
Together AI나 Fireworks 같은 서비스에서 오픈 웨이트 모델을 클라우드 GPU로 fine-tune한 다음, 훈련 끝난 가중치를 자기네 인프라로 가져와서 서빙합니다. 학습은 일회성·간헐적이라 클라우드 GPU로 쓰고(쓴 시간만큼만), 서빙은 상시니까 self-host로 고정비 구성. 이 조합이 현금흐름 관점에서 제일 깔끔해요.
패턴 2 — Router 구성: 민감 데이터는 self-host, 일반은 Claude
LiteLLM·OpenRouter 같은 라우터 레이어를 앞에 세우고, 데이터 민감도에 따라 뒤쪽 모델을 다르게 보냅니다. 개인정보가 들어간 쿼리 → self-host Llama 4. 일반 문서 요약·코드 도움 → Claude API. 같은 애플리케이션 안에서 두 경로가 자동으로 갈라지는 구조예요.
# 의사 코드 (LiteLLM 스타일)
if has_pii(user_query):
model = "self-host/llama-4-scout"
else:
model = "anthropic/claude-sonnet-4-6"
response = completion(model=model, messages=[...])
이렇게 짜면 규제 대응은 self-host로 하면서, 대부분의 쿼리는 품질 좋은 클라우드 모델에게 보내는 혜택을 동시에 가져갈 수 있어요.
패턴 3 — 엔터프라이즈 zero-retention 옵션
Anthropic·OpenAI 모두 엔터프라이즈 플랜에서 “프롬프트와 응답을 우리 서버에 0일 저장한다(zero-retention)”는 옵션을 제공합니다. 이걸 쓰면 로그가 남지 않아요. 민감 데이터 우려를 줄이면서도 API의 편의성을 그대로 가져갈 수 있는 선택지입니다. self-host로 안 가도 되는 경우가 이걸로 해결되는 상황이 꽤 많아요.
즉 “데이터가 민감해서 self-host가 필수”라고 덜컥 결론내기 전에, 우선 쓰고 있는 API의 엔터프라이즈 zero-retention 옵션을 검토해 보는 게 순서입니다.
8. 시나리오별 선택 — 언제 무엇을 써야 하는가
지금까지 얘기한 걸 한 표로 정리합니다.
| 시나리오 | 추천 |
| 개인 개발자·사이드 프로젝트 | 클라우드 API (월 2억 토큰 미만이 거의 확정) |
| 스타트업 MVP (월 1천만~1억 토큰) | 클라우드 API + fallback 라우터 |
| 프로덕션 AI 제품 (월 2~5억 토큰) | 하이브리드 — 코어는 self-host(Qwen 3/Llama 4), 피크는 API |
| 헬스케어·금융·법률 (데이터 민감) | self-host 우선 + 엔터프라이즈 zero-retention 검토 |
| 특수 fine-tune이 제품의 핵심 | self-host (API fine-tune으로 안 되는 경우) |
| 최상위 품질이 우선 (논문 작성·법률 분석·복잡 코드) | 클라우드 — Opus 4.7/GPT-5.4가 여전히 앞섬 |
| 한국어 특화 성능 필요 | Qwen 3 시리즈 self-host 또는 Claude/GPT API |
제 개인적 관찰인데, 한국 시장에서 스타트업이 실제로 self-host로 옮겨가는 시점은 대부분 시리즈 B 이후입니다. 그 전까지는 엔지니어링 리소스가 워낙 귀해서, 수백만 원 아끼려다 수천만 원어치 시간을 잃거든요. 월 2억 토큰 경계선은 “넘을 수 있느냐”가 문제가 아니라 “넘는 순간 self-host 엔지니어를 채용할 수 있느냐”가 문제입니다.
9. FAQ
Q1. Llama 4 Community License의 “MAU 7억 명” 조건이 중소기업에도 걸리나요?
걸리지 않습니다. 이 조항은 Apple·Google·Amazon·Meta 같은 거대 플랫폼을 타깃으로 한 조항이에요. 월간 활성 사용자 7억 명이라는 건 전 세계에서 손에 꼽는 규모입니다. 일반 기업·스타트업은 상업 활용에 아무 제약 없이 Llama 4를 쓸 수 있어요. 다만 “OSI 정의 오픈소스가 아니다“라는 점은 기억해 두세요.
Q2. RTX 4090 한 장으로 실무에 쓸 만한 모델을 돌릴 수 있나요?
개인 프로토타입 수준까진 충분합니다. Qwen 3 8B, Gemma 4 9B 같은 7~13B 모델이 24GB VRAM에 깔끔하게 올라가요. 다만 동시 요청 처리량은 낮습니다 — 한 번에 한두 명 정도. 회사 내부 도구라면 쓸 만하지만, 고객 대상 프로덕션으로 쓰려면 배치 최적화나 다중 GPU 구성이 필요해요.
Q3. DeepSeek V3가 MIT 라이선스라는데, 기업이 자기 제품에 그대로 써도 되나요?
법적으로는 됩니다. MIT는 수정·재배포·상업 활용 전부 허용해요. 다만 재현 가능성 문제가 남습니다 — 훈련 데이터 구성이 완전히 공개된 건 아니라서, 혹시 라이선스 분쟁 소재가 들어갔는지 검증할 수 없어요. 엔터프라이즈 법무팀이 까다로운 조직은 이 지점에서 걸립니다.
Q4. 오픈 웨이트 모델 성능이 이제 Claude나 GPT를 따라잡았다는 이야기가 있던데 사실인가요?
벤치마크(MMLU, HumanEval 같은 표준 테스트)에서는 상위 오픈 웨이트 모델들이 클라우드 프론티어와 비슷한 점수를 내고 있습니다. 그런데 실무 품질에서 체감되는 차이는 여전히 있어요 — 긴 컨텍스트 정확도, 툴 호출 안정성, 지시를 정확히 따르는 능력, adaptive thinking 같은 영역에서 클라우드 프론티어가 아직 앞섭니다. 벤치 점수와 실무 체감은 같지 않다는 걸 염두에 두세요.
Q5. vLLM·TensorRT-LLM·SGLang 중 처음 시작은 뭐가 좋나요?
vLLM이 맞습니다. 설치가 가장 쉽고, 모델 지원이 가장 넓고, 문서가 가장 잘 돼 있어요. 여기서 기준점을 잡은 다음, 처리량이 부족하면 TensorRT-LLM, 공유 프롬프트 패턴이 많으면 SGLang으로 갈아타는 게 정석입니다.
10. 다음 편 안내 — P4 클로즈드 4사
이번 글은 오픈 웨이트와 클라우드를 수학으로 비교했어요. P4에서는 클로즈드 쪽만 좁혀서 4사(OpenAI·Anthropic·Google·xAI)를 비교합니다.
- GPT-5.4 / Opus 4.7 / Gemini 3.1 Pro / Grok 각각의 기술 포지셔닝
- 가격 구조 이면의 사업 전략 차이
- adaptive thinking · extended thinking · reasoning models의 설계 철학 차이
- 기업이 4사 중 하나를 표준으로 고를 때 실제로 무엇을 봐야 하는가
P 시리즈가 점점 실무 의사결정에 가까워지고 있다는 게 보이실 거예요. “기술 공부”와 “기술 선택”은 다른 능력인데, P 시리즈는 후자를 키우는 게 목적입니다.
11. 소스
- Llama 4: Multimodal intelligence (Meta) — Llama 4 공식 발표·Community License
- Qwen 3 (QwenLM) — Qwen 3 공식 발표·Apache 2.0
- DeepSeek V3 (GitHub) — DeepSeek V3 저장소·MIT 라이선스
- Claude API pricing (Anthropic) — Opus 4.7·Sonnet 4.6 가격
- OpenAI API pricing — GPT-5.4 가격
- vLLM vs TensorRT-LLM vs SGLang benchmarks (Spheron) — 추론 엔진 벤치마크
- H100 rental prices cloud comparison (Intuition Labs) — H100 시간당 시장가
- Qwen 3 local hardware guide 2026 (Compute Market) — VRAM 요구치 가이드
- Open Source AI Definition v1.0 (OSI) — OSI 오픈소스 AI 정의
📬 매주 월요일, AI 공부 지도 신편과 이번 주 AI 이슈를 뉴스레터로 받아볼 수 있습니다. 구독은 shuntailor.net 우측 하단에서.
저자: VibeCoding Tailor (바이브코딩 태일러)
사이트: shuntailor.net
