모든 무료 LLM 리스트는 과거의 스크린샷일 뿐입니다. 저는 모든 엔드포인트(endpoint)를 다시 호출하는 리스트를 만들었습니다.
요약
무료 LLM 엔드포인트의 실시간 작동 여부를 추적하는 오픈소스 프로젝트 'stillworks'를 소개합니다. 단순히 모델 목록을 나열하는 대신, 실제 채팅 요청을 정기적으로 보내 성공률과 지연 시간을 측정하여 신뢰할 수 있는 API 상태를 제공합니다.
핵심 포인트
- 정적인 LLM 리스트 대신 실시간 API 호출을 통한 상태 검증
- 성공률과 지연 시간을 기준으로 최적의 엔드포인트 순위 제공
- MIT 라이선스의 오픈소스 프로젝트 (bon5co/stillworks)
- API를 통한 자동화된 폴백(fallback) 구현 지원
제가 지금까지 사용해 본 모든 무료 LLM 엔드포인트(endpoint) 리스트는 정확했던 적이 딱 한 번뿐이었습니다. 바로 누군가가 그 리스트를 작성한 바로 그날입니다. 그 이후로는 스크린샷에 불과합니다. 엔드포인트가 조용히 새로운 요구 사항을 추가하거나, 모델 ID가 변경되거나, 제공업체가 익명 트래픽에 대해 402 에러를 반환하기 시작해도, 아무도 리스트를 다시 실행하지 않기 때문에 리스트에는 여전히 "무료, 키(key) 불필요"라고 적혀 있습니다.
그래서 저는 지루한 버전을 만들었습니다. stillworks는 추적 중인 모든 엔드포인트에 정해진 일정에 따라 실제 채팅 완성(chat completion) 요청을 보내고, 성공 사례 옆에 실패 사례를 포함하여 무엇이 돌아왔는지 게시합니다.
사전에 밝힙니다: 제가 이것을 만들었습니다. 제작된 지 이틀 되었으며, MIT 라이선스를 따르고, 저장소(repo)는 bon5co/stillworks입니다. 제가 이것을 게시하는 이유는 프로젝트가 완성되었기 때문이 아니라, 측정(measurement) 부분이 흥미롭기 때문입니다.
"우리가 확인하는 것"의 실제 의미
HEAD 요청이 아닙니다. /v1/models 목록 조회도 아닙니다. {"role":"user","content":"hello"}를 포함한 실제 POST /chat/completions 요청이며, 키가 필요 없는 항목의 경우 Authorization 헤더를 전혀 포함하지 않습니다. 만약 응답(completion)이 돌아오면 해당 행은 녹색으로 표시되고 시간이 기록됩니다. 만약 402 에러가 발생하면 그 또한 게시됩니다.
2026-08-05 01:30 UTC 기준 상태는 다음과 같습니다:
- 75개의 모델 추적 중.
- 최근 점검에서 20개가
Authorization헤더 없이 응답함. 나머지 55개는 무료 티어 키(free-tier key)가 필요하며 동일한 표에 그렇게 표시되어 있습니다. - 지난 일주일간의 키리스(keyless) 조사 결과: 194번의 시도 중 146번 성공.
- 20개 중 단 5개만이 우리가 수행한 모든 확인에 응답했습니다.
- 20개 중 6개는 절반 미만의 성공률을 보였습니다. llm7의
gpt-oss:20b는 최근 19번 중 9번 응답했습니다. 디렉토리(directory)라면 이를 "사용 가능"이라고 나열했을 것입니다.
마지막 숫자가 제 논점의 핵심입니다. "사용 가능(Available)"은 불리언(boolean) 값이 아니며, 이를 불리언으로 표현하는 리스트는 여러분에게 약간의 거짓말을 하고 있는 것입니다.
API가 곧 제품입니다
페이지는 표 형식입니다. 제가 실제로 사용하는 것은 다음과 같습니다:
curl -s https://stillworks.supercapybara.com/api/llm/up
이 명령은 응답한 키리스 엔드포인트(keyless endpoints)를 순위별로 반환합니다. 우선 지난 한 주 동안 얼마나 많이 응답했는지에 따라 정렬하고, 그다음으로 지연 시간(latency)에 따라 정렬합니다. 즉, models[0]이 최적의 선택이며 나머지는 폴백(fallback)으로 사용하면 됩니다. 각 항목은 다음 호출에 필요한 모든 정보를 포함하고 있습니다:
{
"model": "minimax-m2.7",
"provider": "llm7",
...
이 리스트를 순회하는 것은 편법이 아니라 의도된 사용 방식입니다:
import json, urllib.request
from openai import OpenAI
...
다음 섹션에서 설명할 제한 사항 때문에 이 루프(loop)를 사용하게 될 것입니다.
만약 프로젝트에 세 줄 정도만 붙여넣고 싶다면 ?format=env 옵션도 사용할 수 있습니다:
# stillworks: verified keyless 22 min ago
OPENAI_BASE_URL=https://text.pollinations.ai/openai
OPENAI_API_KEY=not-needed
...
proved / claimed_unproved / failed / absent
기능 플래그(Capability flags)는 제가 가장 주관적인 의견을 갖는 부분입니다. 왜냐하면 제가 읽어본 모든 레지스트리(registry)가 이 부분을 대충 얼버무리고 넘어가기 때문입니다. 네 가지 상태가 존재하며, 이는 두 가지로 축약될 수 없습니다:
| 필드 | 의미 |
|---|---|
proved | 우리가 직접 호출했고 작동했습니다. 우리가 보낼 수 있었던 도구 호출(tool call). 우리가 보낸 스키마(schema)를 파싱하고 일치시킨 응답. 우리가 보낸 이미지에 대한 답변. |
| ... |
두 가지 실제 사례를 통해 왜 이러한 구분이 가치가 있는지 알 수 있습니다:
pollinations / openai-fast — 39개의 일반 채팅 완성(chat completions) 중 39개가 성공했으며, 지연 시간은 295ms로, 보드에서 가장 신뢰할 수 있는 키리스(keyless) 행입니다. 제공업체는 도구 호출(tool calling) 기능을 주장합니다. 하지만 우리의 도구 프로브(tools probe) 결과는 402 Payment Required로 돌아왔습니다. 따라서 tools는 proved도 아니고 failed도 아닌, claimed_unproved에 위치합니다. 즉, 해당 기능을 부정할 수는 없었지만, 실제로 확인하지도 못했다는 뜻입니다.
ovh-anonymous / Qwen3Guard-Gen-8B — 6개의 채팅 완성 중 6개가 성공했으며, 지연 시간은 464ms입니다. 네 가지 기능 프로브(capability probes)는 모두 즉시 실패했습니다: feature 'response_format with provided format' is not currently supported. 이들은 failed에 해당합니다. 하나의 행은 완벽하게 정상적인 채팅 엔드포인트이면서 동시에 구조화된 출력(structured output)에 대해서는 막다른 길(dead end)일 수 있습니다.
20개의 키리스(keyless) 모델 중 8개는 tools가 실제로 작동함을 입증했습니다. 만약 ?feature=tools,vision으로 필터링하면 실제 호출을 통해 증명된 모델만 얻게 됩니다. 즉, 미검증된 모델은 낙관적으로 포함되기보다는 제외되며, 이는 보수적인 접근 방식이며 때로는 성가실 수 있습니다.
이것이 알려줄 수 없는 것들
이 섹션은 제가 덧붙인 면책 조항이 아닙니다. 이 프로젝트가 가치가 있다고 생각하는 이유입니다.
- 키리스 할당량(Keyless quotas)은 일반적으로 IP별로 책정됩니다. 저희 주소에서 검증된 것이 사용자님의 주소에서 검증되었다는 의미는 아닙니다. 저희 서버에 응답할 수 있는 엔드포인트라도 첫 호출 시 사용자님께 402 또는 429 오류를 반환할 수 있습니다. 저희는 사용자님의 할당량을 측정할 수 없으며, 그렇게 주장하지도 않습니다. 이것이 API가 단일 승자 대신 순위와 목록을 제공하는 이유입니다. 즉, 폴백(fallbacks) 자체가 핵심입니다.
- **`auth:
엔드포인트(endpoint)를 추가하려면 apps/audit/seed.go에 기본 URL(base URL), 채팅 경로(chat path), 그리고 키(key)가 필요한지 여부를 포함하여 PR(Pull Request)을 보내면 됩니다. 프로버(prober)는 다음 사이클에서 이를 검증하며, 아무것도 발견되지 않는 경우를 포함하여 실제로 발생하는 모든 상황을 게시합니다.
이 시스템은 JavaScript 프레임워크 없이 Go, Postgres, 그리고 templ로 구성되어 있습니다. 테이블 필터링과 정렬은 서버 사이드(server-side)에서 이루어지며, 클라이언트 스크립트는 이를 보완하는 역할만 수행합니다. 제공자 키(Provider keys)는 환경 변수(environment)에 저장되며 프로브(probes) 시에만 사용됩니다. 이 키들은 절대 렌더링되거나, 로그에 남거나, 데이터베이스에 기록되거나, API를 통해 반환되지 않습니다. 또한, 응답에 키가 나타날 경우 실패하는 테스트가 존재합니다.
제가 놓친 엔드포인트가 있거나, 여러분의 IP에서 제 수치를 재현할 수 없는 부분이 있다면 기꺼이 알려주시기 바랍니다. 후자가 더 유용할 것입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기