제미나이 temperature 폐지 — 공식 문서 네 쪽이 갈렸고, 모델 50개 중 43개는 아직 그 값을 싣고 있어요
제미나이 릴리스 노트가 샘플링 파라미터 세 개를 폐지로 선언했는데, API 레퍼런스는 아직 Optional이고 텍스트 생성 가이드는 예제에 그대로 넣어요. 지금 보내면 어떻게 되는지 모델 다섯 개에 직접 쳐 봤어요. 2026년 8월 22일 오후 관측이에요.
AI 모델 컨텍스트 길이 실측 — 422개 중 42개는 표시값과 공급자 한도가 다르고, 최대 31배 차이가 나요
🤖
HowtoAI 편집팀AI 전문 에디터
AI 기술을 누구나 쉽게 활용할 수 있도록 실전 가이드를 작성합니다. ChatGPT, Claude, AI 자동화, SEO 분야를 전문으로 다룹니다.
목차 보기
- 어떤 조건에서 쟀는지 먼저 못박을게요
- 세어 보니 42개가 갈렸어요
- 벌어진 폭이 큰 순서로 보면 이래요
- 어느 벤더에 몰려 있나
- 이 차이가 계획에서 어긋나는 자리
- 백만 토큰으로 적힌 137개 중 10개는 공급자 한도가 백만에 못 미쳐요
- 공식 문서는 같은 이름의 필드를 두 번, 다르게 정의해 뒀어요
- 요청 문서 쪽은 아예 이 필드를 모르는 상태예요
- 왜 갈리는지 공급자별로 열어 봤어요
- 여기서 멈춰야 하는 지점이 있어요
- 공급자가 몇 곳이냐에 따라 벌어질 자리가 달라져요
- 더 조용한 함정은 응답 상한 쪽이에요
- 값이 아예 비어 있는 모델도 6개 있어요
- 자기 코드에서 확인하는 순서
- 확인하지 못한 것도 적어 둘게요
- 정리하면
모델을 고를 때 제일 먼저 보는 숫자가 컨텍스트 길이예요. 그런데 그 숫자가 목록 화면과 실제 한도에서 갈리는 경우가 있어요.
결론부터 적을게요. OpenRouter 공개 모델 목록 422개를 전수로 세어 보니, 최상위 context_length 와 top_provider.context_length 가 서로 다른 모델이 42개였어요. 그중 22개는 실제값이 표시값의 절반 이하고, 가장 벌어진 모델은 31.25배 차이였어요.
반대 방향은 하나도 없었어요. 실제값이 표시값보다 큰 모델은 422개 중 0개예요. 어긋남은 전부 한쪽으로만 기울어요.
말을 먼저 맞춰 둘게요. 이 글에서 표시값은 최상위 context_length, 실제값은 top_provider.context_length 를 가리켜요. 둘 다 메타데이터에 적힌 숫자예요. 요청을 실제로 보내서 어느 쪽이 적용되는지 확인한 값이 아니에요.
먼저 잰 범위부터 밝힐게요. 이 글의 숫자는 전부 2026년 8월 24일 오전 11시 21분에서 11시 34분 사이(한국 시각) 에 OpenRouter 공개 API와 공식 문서 두 쪽을 직접 받아 센 값이에요. 전수 집계 422개는 11시 21분에 받은 목록 하나에서 나왔고, 공급자별 엔드포인트 한 건만 11시 34분에 다시 받았어요. 실제 생성 요청은 한 건도 보내지 않았어요.
어떤 조건에서 쟀는지 먼저 못박을게요
값이 조회 시점에 묶이는 종류의 측정이라 조건이 숫자보다 먼저예요.
| 항목 | 값 |
|---|---|
| 데이터 출처 | OpenRouter 공개 모델 목록 API |
| 엔드포인트 | https://openrouter.ai/api/v1/models |
| 원인 대조용 엔드포인트 | 모델별 /endpoints 경로 |
| 인증 | 없음. API 키를 쓰지 않는 공개 경로 |
| 요청 방식 | 파이썬 urllib 로 직접 호출, JSON 원본 저장 |
| HTTP 상태 | 200, 응답 690,261바이트 |
| 응답 최상위 키 | data, total_count, links |
| 모델 총수 | 422 (total_count 필드와 배열 길이가 일치) |
| 문서 | 필드 레퍼런스 1쪽, 요청 파라미터 레퍼런스 1쪽 |
| 조회 시각 | 2026년 8월 24일 오전 11시 21분에서 11시 34분 (한국 시각) |
200이 왔다고 데이터가 온 건 아니에요. 그래서 응답 앞부분에 <html 이 들어 있는지 먼저 확인했어요. 없었고, 첫 바이트가 {"data":[{"id":"meta/muse-spark-1.2-cont 로 시작하는 JSON이었어요. 오류 페이지를 JSON으로 착각해 세는 사고를 막는 절차예요.
검산도 해 뒀어요. 총수 422는 응답의 total_count 필드값이자 data 배열의 실제 길이예요. 두 값이 서로 다르면 그때부터는 어느 쪽도 못 믿어요.
세어 보니 42개가 갈렸어요
모델 하나마다 컨텍스트 길이가 두 자리에 적혀 있어요. 최상위에 context_length 가 있고, top_provider 라는 객체 안에 같은 이름의 필드가 또 있어요. 이 둘을 짝지어 전부 비교했어요.
| 판정 | 모델 수 |
|---|---|
| 두 값이 같음 | 374 |
| 두 값이 다름 | 42 |
top_provider.context_length 가 비어 있음 | 6 |
top_provider 객체 자체가 없음 | 0 |
| 합계 | 422 |
374 더하기 42 더하기 6은 422예요. 빠진 모델은 없어요.
42개를 더 들여다보면 이렇게 갈려요.
| 구간 | 모델 수 |
|---|---|
| 실제값이 표시값의 절반 이하 | 22 |
| 실제값이 표시값보다 큼 | 0 |
여기서 한 가지를 분명히 하고 갈게요. 42라는 숫자에는 1토큰짜리 차이도 들어 있어요. deepseek/deepseek-v4-pro-0813 은 표시 1,048,576 대 실제 1,048,575 예요. 이런 건 실무에 아무 영향이 없어요. 그러니까 "42개가 전부 위험하다"고 읽으면 과장이에요. 실제로 계획을 어긋나게 만드는 구간은 절반 이하인 22개 쪽이에요.
벌어진 폭이 큰 순서로 보면 이래요
비율이 작을수록 top_provider 값이 표시값보다 작다는 뜻이에요. 42개를 다 싣지 않고 15개만 추렸고, 배수가 같은 모델이 여럿인 구간에서는 일부만 넣었어요. 그래서 이 표에 없는 모델이 아래 표에 나오기도 해요.
| 모델 id | 표시값 | 실제 top_provider 값 | 배수 |
|---|---|---|---|
thedrummer/unslopnemo-12b | 1,024,000 | 32,768 | 31.25배 |
meta-llama/llama-guard-4-12b | 1,048,576 | 163,840 | 6.40배 |
anthropic/claude-sonnet-4 | 1,000,000 | 200,000 | 5.00배 |
meta-llama/llama-4-scout | 1,310,720 | 327,680 | 4.00배 |
qwen/qwen3.8-27b | 1,000,000 | 262,144 | 3.81배 |
nvidia/nemotron-3-super-120b-a12b | 1,000,000 | 262,144 | 3.81배 |
qwen/qwen3-30b-a3b | 131,072 | 40,960 | 3.20배 |
qwen/qwen3-14b | 131,072 | 40,960 | 3.20배 |
qwen/qwen3-32b | 131,072 | 40,960 | 3.20배 |
qwen/qwen3-30b-a3b-instruct-2507 | 262,144 | 128,000 | 2.05배 |
minimax/minimax-m3 | 1,048,576 | 524,288 | 2.00배 |
google/gemma-3-27b-it | 262,144 | 131,072 | 2.00배 |
gryphe/mythomax-l2-13b | 8,192 | 4,096 | 2.00배 |
deepseek/deepseek-chat | 163,840 | 128,000 | 1.28배 |
deepseek/deepseek-v3.1-terminus | 163,840 | 131,072 | 1.25배 |
가장 눈에 띄는 건 세 번째 줄이에요. anthropic/claude-sonnet-4 는 목록에 100만으로 적혀 있고 top_provider 값은 20만이에요. 백만 토큰짜리 문서 처리 파이프라인을 이 표시값만 보고 설계하면, 계획과 실제 사이에 다섯 배 간격이 생겨요.
첫 줄은 성격이 조금 달라요. thedrummer/unslopnemo-12b 는 원래 소형 모델이라 1,024,000 이라는 표시값 자체가 눈에 걸려요. 왜 그런 값이 최상위에 적히는지는 아래에서 공급자별로 열어 보면 바로 풀려요.
어느 벤더에 몰려 있나
42개를 모델 id의 앞 부분으로 묶으면 이렇게 나와요.
| 벤더 접두사 | 모델 수 |
|---|---|
qwen | 11 |
deepseek | 7 |
z-ai | 4 |
minimax | 3 |
meta-llama | 2 |
thinkingmachines | 2 |
google | 2 |
xiaomi | 2 |
| 나머지 9곳 각 1개 | 9 |
오픈 웨이트 계열에 몰려 있어요. 이건 자연스러운 결과예요. 같은 가중치를 여러 회사가 각자 서빙하니 공급자마다 한도가 갈리거든요. 반대로 단일 회사가 자기 모델만 서빙하면 값이 갈릴 자리가 없고요. 오픈 웨이트 모델을 실제로 골라 쓰는 기준은 오픈 웨이트 코딩 모델 네 종을 실전 조건에서 비교한 기록에 따로 정리해 뒀어요.
모델 id가 -latest 로 끝나는 별칭 계열 두 개도 이 42개에 들어 있어요. 이 계열이 무엇을 가리키는 별칭인지는 문서에서 확인하지 못해서 표에 넣지 않았어요.
이 차이가 계획에서 어긋나는 자리
숫자만 보면 감이 잘 안 오니까 한 줄로 옮겨 볼게요.
긴 문서를 통째로 넣고 요약을 뽑는 작업을 설계한다고 해 볼게요. 모델 목록에서 anthropic/claude-sonnet-4 의 1,000,000 을 보고, 문서를 90만 토큰까지는 한 번에 넣어도 되겠다고 판단해요. 그런데 top_provider 값은 200,000 이에요. 처음부터 다섯 배를 넘겨 잡은 셈이 되죠.
이런 어긋남이 나쁜 이유는 크기 자체가 아니에요. 틀린 숫자가 조용해서예요. 목록 화면에 멀쩡히 숫자가 들어 있고, 필드 이름도 맞고, 형식도 정상이라 어떤 검사에도 안 걸려요. 코드 리뷰에서도 안 보여요. 값이 비어 있었다면 오히려 그 자리에서 걸렸을 텐데요.
그래서 이 글의 확인 절차는 마지막에 붙이는 점검이 아니라 모델을 고르는 첫 단계에 넣는 게 맞아요. 설계를 끝낸 뒤에 다섯 배를 알게 되면 고칠 게 코드 한 줄이 아니거든요.
백만 토큰으로 적힌 137개 중 10개는 공급자 한도가 백만에 못 미쳐요
요즘 모델을 고르는 기준이 사실상 "백만 토큰이 되느냐"로 굳어 있어서, 이 경계만 따로 세어 봤어요.
| 컨텍스트 구간 | 표시값 기준 | top_provider 값 기준 |
|---|---|---|
| 100만 이상 | 137 | 123 |
| 40만 이상 100만 미만 | 37 | 41 |
| 20만 이상 40만 미만 | 119 | 112 |
| 10만 이상 20만 미만 | 85 | 91 |
| 32,768 이상 10만 미만 | 26 | 31 |
| 32,768 미만 | 18 | 18 |
| 값이 비어 있음 | 0 | 6 |
| 합계 | 422 | 422 |
왼쪽 열과 오른쪽 열의 무게중심이 아래로 한 칸 내려가요. 100만 이상이 137개에서 123개로 줄고, 그만큼 아래 구간들이 불어나요.
경계를 넘어간 모델만 추리면 이래요. 표시값은 100만 이상인데 top_provider 값이 100만에 못 미치는 모델이 10개예요.
| 모델 id | 표시값 | 실제 top_provider 값 |
|---|---|---|
thedrummer/unslopnemo-12b | 1,024,000 | 32,768 |
meta-llama/llama-guard-4-12b | 1,048,576 | 163,840 |
anthropic/claude-sonnet-4 | 1,000,000 | 200,000 |
qwen/qwen3.8-27b | 1,000,000 | 262,144 |
nvidia/nemotron-3-super-120b-a12b | 1,000,000 | 262,144 |
meta-llama/llama-4-scout | 1,310,720 | 327,680 |
thinkingmachines/inkling | 1,048,576 | 524,288 |
thinkingmachines/inkling-small | 1,048,576 | 524,288 |
minimax/minimax-m3 | 1,048,576 | 524,288 |
여기에 이름이 -latest 로 끝나는 별칭 계열 모델 하나가 더 있어서 모두 10개예요. 그 모델은 1,048,576 대 974,842 라서 경계를 아슬아슬하게 못 넘겨요.
검산도 맞아요. 표시값 100만 이상 137개 가운데, 실제값도 100만 이상인 게 123개, 값이 비어 있는 게 4개, 못 미치는 게 10개예요. 123 더하기 4 더하기 10은 137이에요.
한 가지 짚고 갈게요. 위 구간 경계는 제가 임의로 나눈 거예요. 경계를 다르게 잡으면 옮겨 가는 모델 수도 달라져요. 반면 "백만이라 적혀 있는데 백만이 아니다"라는 판정은 경계와 무관하게 그대로 남아요. 그래서 이 절에서 기억하실 숫자는 구간표가 아니라 10 하나예요.
공식 문서는 같은 이름의 필드를 두 번, 다르게 정의해 뒀어요
여기가 이 어긋남의 진짜 자리예요. 필드 레퍼런스를 열어 보면 두 정의가 따로 적혀 있어요.
최상위 필드 쪽 축자예요.
context_length number Maximum context window size in tokens
그리고 같은 페이지 아래쪽, Top Provider Object 정의 안에 같은 이름이 또 나와요.
Top Provider Object
{
"context_length" : number , // Provider-specific context limit
"max_completion_tokens" : number , // Maximum tokens in response
"is_moderated" : boolean // Whether content moderation is applied
}
한쪽은 "최대 컨텍스트 창 크기" 고 다른 쪽은 "공급자별 컨텍스트 한도" 예요. 정의가 이미 다르죠. 문제는 그다음이에요.
두 값이 서로 다를 수 있다는 문장은 제가 연 두 쪽 어디에도 없었어요. 경고도, 각주도, "이 값을 기준으로 잡으라"는 안내도 없어요. 이 페이지에서 context_length 라는 문자열이 등장한 자리는 위 두 곳이 전부였어요. 문서 전체를 뒤진 건 아니라서 다른 쪽에 그런 문장이 있는지는 확인하지 못했어요.
top_provider 필드 자체에 붙은 설명은 이거였어요.
top_provider TopProvider Configuration details for the primary provider
"primary provider의 설정값"이라고만 적혀 있어요. 어떤 기준으로 primary를 고르는지는 적혀 있지 않아요. 이 대목은 아래 확인하지 못한 것에서 다시 짚을게요.
요청 문서 쪽은 아예 이 필드를 모르는 상태예요
더 걸리는 건 요청 파라미터 레퍼런스 쪽이에요. 응답 길이를 정하는 max_tokens 의 범위가 이렇게 적혀 있어요.
max_tokens ?: number ; // Range: [1, context_length)
temperature ?: number ; // Range: [0, 2]
어느 context_length 인지 적혀 있지 않아요. 그리고 이 페이지 전체에서 top_provider 라는 문자열은 0회 등장해요. context_length 는 위 한 줄에만 나오고요. 다만 요청 쪽 문서 가운데 제가 연 건 이 레퍼런스 한 쪽이에요. 같은 문서 묶음의 파라미터 상세 페이지가 상한을 어떻게 적어 두는지까지는 열어 보지 않았어요.
그러니까 이 레퍼런스만 읽고 코드를 짜는 사람은 top_provider.context_length 라는 필드가 있다는 사실 자체를 만나지 못해요. 목록 화면에서 본 숫자 하나만 들고 범위를 잡게 되는 거죠. 모델 목록 API가 공식 문서와 어긋나 있던 다른 사례는 제미나이 모델 지원 종료를 문서와 API로 대조한 기록에도 정리해 뒀어요.
왜 갈리는지 공급자별로 열어 봤어요
모델 목록 응답에는 모델마다 links 필드가 붙어 있고, 그 안에 공급자별 상세 경로가 그대로 들어 있어요. 그 경로를 열면 같은 모델을 서빙하는 공급자가 줄줄이 나와요.
42개 중 12개를 표본으로 뽑아 전부 열어 봤어요. 결과가 한 줄로 정리돼요.
| 대조 항목 | 결과 |
|---|---|
| 최상위 표시값이 공급자별 값 중 최대치와 같았나 | 12개 중 12개 |
top_provider 값이 공급자 목록 안에 실재했나 | 12개 중 12개 |
top_provider 값이 공급자별 값 중 최소치였나 | 12개 중 7개 |
실제 공급자 구성은 이랬어요.
| 모델 | 표시값 | top_provider | 공급자별 값 |
|---|---|---|---|
thedrummer/unslopnemo-12b | 1,024,000 | 32,768 | NextBit 32,768 · Parasail 1,024,000 |
meta-llama/llama-guard-4-12b | 1,048,576 | 163,840 | DeepInfra 163,840 · Together 1,048,576 |
anthropic/claude-sonnet-4 | 1,000,000 | 200,000 | Google 1,000,000 · Amazon Bedrock 200,000 |
qwen/qwen3-32b | 131,072 | 40,960 | DeepInfra 40,960 · Nebius 40,960 · SiliconFlow 131,072 · Groq 131,072 |
gryphe/mythomax-l2-13b | 8,192 | 4,096 | NextBit·Parasail·DeepInfra 각 4,096 · Mancer 2 한 곳만 8,192 |
deepseek/deepseek-chat | 163,840 | 128,000 | StreamLake 128,000 · DeepInfra 163,840 · Novita 64,000 |
mistralai/mistral-small-3.2-24b-instruct | 131,072 | 128,000 | DeepInfra 128,000 · Parasail 131,072 |
그림이 보이시죠. thedrummer/unslopnemo-12b 의 1,024,000 은 Parasail 이라는 공급자 한 곳의 값이에요. 다른 한 곳인 NextBit 은 32,768 이고요. 최상위에 적힌 숫자는 둘 중 큰 쪽이에요.
gryphe/mythomax-l2-13b 는 더 극적이에요. 공급자 네 곳 중 세 곳이 4,096 인데 한 곳만 8,192 예요. 목록에 적히는 값은 8,192 고, 넷 중 셋에는 그 절반인 4,096 이 적혀 있어요.
여기서 멈춰야 하는 지점이 있어요
표본 12개가 전부 같은 방향이었으니 "표시값은 최대치다"라고 굳히고 싶어져요. 그렇게 쓰면 두 군데서 어긋나요.
첫째, 표본은 12개고 42개 전부를 열어 본 게 아니에요. 나머지 30개도 같은지는 몰라요.
둘째, top_provider 는 최소치가 아니에요. 12개 중 7개만 최소였어요. meta-llama/llama-4-scout 은 공급자별 값이 327,680 · 131,072 · 131,072 · 1,310,720 인데 top_provider 값은 327,680 이에요. 최소도 최대도 아닌 중간값이죠.
그래서 이 필드를 "가장 작은 공급자"로 읽으면 틀려요. 문서 표현대로 "primary로 지정된 공급자의 한도" 라고만 읽는 게 맞아요. 어느 공급자로 실제 라우팅되는지는 이번에 확인하지 못했어요.
공급자가 몇 곳이냐에 따라 벌어질 자리가 달라져요
표본 12개를 열면서 공급자 수도 같이 세어 봤어요. 적으면 2곳, 많으면 13곳이었어요.
| 모델 | 공급자 수 | 공급자별 값의 폭 |
|---|---|---|
qwen/qwen3-vl-8b-instruct | 2 | 131,072에서 262,144 |
mistralai/mistral-small-3.2-24b-instruct | 2 | 128,000에서 131,072 |
deepseek/deepseek-chat | 3 | 64,000에서 163,840 |
qwen/qwen3-32b | 4 | 40,960에서 131,072 |
google/gemma-3-27b-it | 5 | 98,304에서 262,144 |
minimax/minimax-m3 | 13 | 256,000에서 1,048,576 |
여기서 두 가지가 보여요.
첫째, 두 값만 봐도 전체 폭은 못 봐요. deepseek/deepseek-chat 은 표시값 163,840, top_provider 값 128,000 이에요. 이 둘만 보면 1.28배 차이죠. 그런데 공급자 셋 중 하나는 64,000 이에요. 최상위 표시값 기준으로는 2.56배 차이인데, 두 필드 비교로는 이 공급자가 보이지 않아요.
둘째, 공급자가 많을수록 폭이 넓어져요. minimax/minimax-m3 은 공급자가 13곳인데 컨텍스트 값이 여섯 가지로 갈려요. 256,000, 262,144, 524,288, 524,300, 1,000,000, 1,048,576 이에요. google/gemma-3-27b-it 도 다섯 곳에서 값이 네 가지로 갈리고요.
같은 모델 안에서 응답 상한도 함께 갈려요. minimax/minimax-m3 을 서빙하는 Novita 는 컨텍스트가 1,000,000 인데 응답 상한이 131,072 이고, Venice 는 컨텍스트 524,288 에 응답 상한 65,536 이에요. 한 모델 이름 아래에 서로 다른 조합이 열세 벌 들어 있는 셈이에요.
그래서 순서를 이렇게 잡는 게 맞아요. 두 필드 비교는 어긋남을 알아채는 신호고, 실제로 얼마나 받는지 정하려면 공급자별 목록까지 열어야 해요. 다행히 그 경로는 모델 객체의 links 안에 이미 들어 있어서 따로 찾을 필요가 없어요.
더 조용한 함정은 응답 상한 쪽이에요
여기서부터는 42개와 별개의 이야기예요. 섞어 읽으면 안 돼요.
앞에서 본 요청 문서의 max_tokens 범위 안내를 다시 볼게요. [1, context_length) 였죠. 그런데 top_provider 객체에는 응답 길이 상한이 따로 있어요. max_completion_tokens 예요. 이 둘을 422개 전수로 비교했어요.
| 판정 | 모델 수 |
|---|---|
max_completion_tokens 가 표시 컨텍스트보다 작음 | 316 |
| 같거나 큼 | 54 |
| 값이 비어 있음 | 52 |
| 합계 | 422 |
316 더하기 54 더하기 52는 422예요.
422개 중 316개, 그러니까 4분의 3에서 응답 상한이 표시 컨텍스트보다 작아요. 격차가 큰 쪽부터 보면 이래요.
| 모델 | 표시 컨텍스트 | 응답 상한 | 배수 |
|---|---|---|---|
writer/palmyra-x5 | 1,040,000 | 8,192 | 127배 |
meta-llama/llama-4-scout | 1,310,720 | 16,384 | 80배 |
meta-llama/llama-guard-4-12b | 1,048,576 | 16,384 | 64배 |
meta-llama/llama-4-maverick | 1,048,576 | 16,384 | 64배 |
bytedance/ui-tars-1.5-7b | 128,000 | 2,048 | 62.5배 |
nvidia/nemotron-3-super-120b-a12b | 1,000,000 | 16,384 | 61배 |
amazon/nova-lite-v1 | 300,000 | 5,120 | 58.6배 |
anthropic/claude-3-haiku | 200,000 | 4,096 | 48.8배 |
맨 윗줄을 잘 봐 주세요. writer/palmyra-x5 는 컨텍스트 두 값이 1,040,000 으로 똑같아요. 앞의 42개 목록에 들어 있지 않다는 뜻이에요. 그런데 응답 상한은 8,192 예요.
즉 컨텍스트가 어긋나지 않은 모델에서도 이 함정은 그대로 남아요. 두 문제는 서로 독립이에요. 42개 목록을 피했다고 안심할 자리가 아니에요.
한 가지 더 있어요. 422개 중 411개가 max_tokens 파라미터를 지원한다고 스스로 광고하고 있어요. 어긋난 42개는 42개 전부가 이 파라미터를 광고해요. 즉 "쓸 수 있다"는 표시와 "얼마까지 쓸 수 있다"는 값이 서로 다른 자리에서 관리되고 있는 셈이에요.
컨텍스트 길이를 토큰이 아니라 한국어 글자 수로 환산해 감을 잡고 싶으시면 한국어 토큰 수를 공식 API로 실측한 기록이 도움이 될 거예요. 어림값과 실측값이 갈리는 폭이 생각보다 커요.
값이 아예 비어 있는 모델도 6개 있어요
앞의 표에서 따로 빼 둔 6개예요. top_provider 객체는 있는데 그 안의 context_length 가 비어 있어요.
| 모델 id | 표시 컨텍스트 | top_provider 값 |
|---|---|---|
openrouter/auto | 2,000,000 | 비어 있음 |
openrouter/auto-beta | 2,000,000 | 비어 있음 |
openrouter/pareto-code | 2,000,000 | 비어 있음 |
openrouter/fusion | 1,000,000 | 비어 있음 |
openrouter/free | 200,000 | 비어 있음 |
openrouter/bodybuilder | 128,000 | 비어 있음 |
여섯 개 전부 같은 접두사예요. 특정 공급자 하나에 묶이지 않는 자체 라우팅 계열이라 값이 비어 있는 것으로 보이는데, 문서에서 그렇게 적힌 문장은 찾지 못했어요. 그러니 이건 제 해석이고, 관측된 사실은 여섯 개가 전부 같은 접두사이고 값이 비어 있다는 것까지예요.
실무 관점에서는 이 여섯이 오히려 다루기 쉬워요. 비어 있으면 코드가 알아채니까요. 어긋난 42개가 더 위험한 건 값이 멀쩡히 들어 있어서 검사에 안 걸리기 때문이에요.
자기 코드에서 확인하는 순서
목록을 통째로 받아 두 값을 짝지어 보면 끝나요. 키가 필요 없어서 바로 돌아가요.
curl -s https://openrouter.ai/api/v1/models > models.json
head -c 40 models.json
먼저 앞 40바이트를 눈으로 보세요. {"data":[ 로 시작하면 JSON이 온 거고, <html 이 보이면 오류 페이지를 받은 거라 그 파일로는 아무것도 세면 안 돼요.
그다음 두 값을 짝지어요.
import json
data = json.load(open('models.json', encoding='utf-8'))['data']
print('총', len(data))
for m in data:
tp = m.get('top_provider') or dict()
shown = m.get('context_length')
real = tp.get('context_length')
if real is not None and shown != real:
print(m['id'], shown, real, round(shown / real, 2))
쓰시는 모델 하나만 급히 보고 싶으면 순서는 이래요.
- 목록 응답에서 그 모델의 최상위
context_length를 적어 둔다. - 같은 객체의
top_provider.context_length를 적어 둔다. - 두 값이 다르면 작은 쪽을 계획 기준으로 잡는다.
- 같은 객체의
max_completion_tokens를 확인하고max_tokens를 그 아래로 잡는다. - 그래도 신경 쓰이면 모델의
links.details경로를 열어 공급자별 값을 직접 본다. - 이 값들은 스냅샷이므로 배포 전에 한 번 더 받는다.
3번과 4번을 굳이 나눠 적은 이유가 있어요. 둘은 서로 다른 필드고 서로 다른 이유로 걸려요. 3번만 챙기고 4번을 빠뜨리면 writer/palmyra-x5 같은 자리에서 그대로 걸려요.
이건 조심하세요
이 글의 전수 집계는 2026년 8월 24일 오전 11시 21분에 받은 목록 하나의 스냅샷이에요. 모델 목록은 수시로 바뀌니까 422도 42도 며칠 뒤엔 달라져요. 그러니 숫자를 외우지 마시고 위 확인 순서를 코드에 넣어 두세요. 그리고 이번 관측은 메타데이터만 읽은 것이라, 표시값에 맞춰 긴 프롬프트를 실제로 보내면 어떻게 되는지는 확인하지 못했어요. 거부되는지 잘리는지 다른 공급자로 넘어가는지 모르는 상태예요.
확인하지 못한 것도 적어 둘게요
이 글이 말하지 않는 것들이에요.
첫째, 실제 요청을 한 건도 보내지 않았어요. API 키 없이 열리는 공개 메타데이터만 읽었어요. 그러니 표시값을 믿고 긴 프롬프트를 보냈을 때 거부되는지, 앞이 잘리는지, 다른 공급자로 넘어가는지 전혀 몰라요. 이 글은 "이렇게 보내면 이런 오류가 난다"를 주장하지 않아요. "메타데이터가 이렇게 갈려 있다"까지가 관측된 전부예요.
둘째, 어느 공급자로 라우팅되는지 확인하지 못했어요. 문서는 top_provider 를 "primary provider"라고만 적었어요. 그 primary가 실제 라우팅 1순위인지, 어떤 기준으로 뽑히는지는 검증하지 않았어요. 표본에서 top_provider 값이 최소치였던 경우가 12개 중 7개뿐이라, 단순한 규칙 하나로 설명되지도 않았고요.
셋째, 42개 중 12개만 공급자별로 열어 봤어요. 나머지 30개의 공급자 구성은 보지 않았어요. "표시값은 언제나 최대치"라는 문장은 이 12개 범위 안에서만 참이에요.
넷째, 가격과 지연, 가동률은 세지 않았어요. 응답에 pricing 과 30분 지연, 가동률 필드가 함께 들어 있었지만 이번 집계에서 뺐어요.
다섯째, 웹 화면 표기는 보지 않았어요. 전부 API 응답과 공식 문서 두 쪽 기준이에요. OpenRouter 웹 모델 페이지가 어떤 숫자를 보여 주는지는 확인하지 않았어요.
여섯째, 다른 게이트웨이는 확인하지 않았어요. 같은 이름의 필드를 다른 서비스가 어떻게 채우는지는 안 봤어요. 이 관측은 OpenRouter 한 곳에 한정돼요.
일곱째, 응답 안의 일부 필드는 뜻을 확인하지 못했어요. 공급자별 응답에 있던 status 값과 모델 id 앞에 붙는 별칭 표기가 그래요. 뜻을 모르는 채로 해석을 얹지 않으려고 본문에서 뺐어요. 공급자 응답에 함께 있던 max_prompt_tokens 도 제가 값을 들여다본 두 모델(thedrummer/unslopnemo-12b·anthropic/claude-sonnet-4)에서는 전부 비어 있어서 무엇을 담는 필드인지 판단하지 않았어요. 다시 세어 보니 minimax/minimax-m3 을 서빙하는 Minimax 공급자처럼 값이 들어 있는 자리도 있어서, 이 필드는 비어 있는 게 기본이라고 읽으면 안 돼요.
여덟째, 값이 비어 있는 6개의 이유는 제 해석이에요. 여섯 개가 전부 같은 접두사라는 건 관측이지만, "자체 라우팅 계열이라 비어 있다"는 건 문서에서 확인한 문장이 아니에요.
아홉째, 이 숫자들은 한 번의 스냅샷이에요. 같은 엔드포인트를 며칠 뒤에 다시 받으면 총수도 어긋난 개수도 달라져요. 그래서 본문에 확인 절차를 함께 적어 뒀어요. 숫자보다 절차가 오래가요.
정리하면
| 물음 | 2026년 8월 24일 오전 11시 21분 기준 답 |
|---|---|
| 모델은 몇 개인가 | 422개 |
| 두 컨텍스트 값이 다른 모델은 | 42개 |
| 그중 절반 이하로 줄어드는 건 | 22개 |
| 가장 벌어진 폭은 | 31.25배 (thedrummer/unslopnemo-12b) |
| 표시값보다 실제값이 큰 경우는 | 0개 |
| 값이 비어 있는 모델은 | 6개, 전부 같은 접두사 |
| 문서가 두 값이 다를 수 있다고 적었나 | 제가 연 두 쪽에서는 찾지 못했어요 |
| 응답 상한이 표시 컨텍스트보다 작은 모델은 | 316개 |
| 그 격차의 최대는 | 127배 (writer/palmyra-x5) |
| 실제로 넘겨 보내면 어떻게 되나 | 확인하지 못했어요 |
| 어느 공급자로 라우팅되나 | 확인하지 못했어요 |
목록 화면의 큰 숫자는 그 모델을 서빙하는 공급자 중 가장 넉넉한 한 곳의 값일 수 있어요. 표본 12개에서는 예외 없이 그랬어요. 그러니 컨텍스트 길이로 설계를 시작하실 때는 큰 숫자 하나가 아니라 두 값을 같이 적어 두고 작은 쪽으로 계획하시는 편이 안전해요. 확인에 걸리는 시간은 요청 한 번이에요.
확인한 자료: OpenRouter 공개 모델 목록 API https://openrouter.ai/api/v1/models 응답 전문(HTTP 200, 690,261바이트, 모델 422개)과 모델별 엔드포인트 조회 15건(모델 12종, 일부는 재확인차 두 번 받았어요). 공식 문서는 필드 레퍼런스 openrouter.ai/docs/guides/overview/models(644,837바이트)와 요청 파라미터 레퍼런스 openrouter.ai/docs/api-reference/overview(596,067바이트) 두 쪽을 HTML 원본으로 받아 문자열을 셌어요. 모두 2026년 8월 24일 오전 11시 21분 58초에서 11시 34분 사이(한국 시각)에 파이썬 urllib 로 직접 받은 값이고, 스크립트가 찍은 시각을 그대로 옮겼어요. 생성 요청은 보내지 않았어요.
❓ 자주 묻는 질문 (FAQ)
모델 목록에 적힌 컨텍스트 길이를 그대로 믿어도 되나요?
모델에 따라 갈려요. 2026년 8월 24일 오전 11시 21분에 OpenRouter 공개 모델 목록을 받아 422개를 전수로 세어 보니, 최상위 context_length 와 top_provider.context_length 가 서로 다른 모델이 42개였어요. 나머지 374개는 두 값이 같았고요. 그러니까 대부분은 맞지만 열에 하나 정도는 어긋난다고 보시면 돼요. 어긋난 42개 중 22개는 실제값이 표시값의 절반 이하였어요.
가장 많이 벌어진 모델은 얼마나 차이가 나나요?
thedrummer/unslopnemo-12b 였어요. 최상위 표시값이 1,024,000 인데 top_provider.context_length 는 32,768 이에요. 31.25배 차이예요. 두 번째가 meta-llama/llama-guard-4-12b 로 1,048,576 대 163,840 이고, 세 번째가 anthropic/claude-sonnet-4 로 1,000,000 대 200,000 이에요. 세 번째 것은 5배 차이라, 백만 토큰을 기대하고 설계하면 top_provider 에 적힌 20만과 다섯 배 어긋나요. 실제로 넘겨 보냈을 때 어떻게 되는지는 이번에 확인하지 않았어요.
반대로 표시값보다 실제값이 큰 경우도 있나요?
422개 중 하나도 없었어요. 어긋남은 전부 한 방향이에요. top_provider 값이 최상위 표시값보다 큰 모델은 0개였어요. 그래서 표시값은 낙관적인 쪽 숫자라고 읽는 게 안전해요. 실무에서는 표시값을 상한으로, top_provider 값을 계획 기준으로 잡는 편이 어긋나지 않아요.
공식 문서에 두 값이 다를 수 있다고 적혀 있나요?
제가 연 문서 두 쪽에서는 그런 문장을 찾지 못했어요. 필드 레퍼런스는 최상위 context_length 를 'Maximum context window size in tokens' 로, Top Provider Object 안의 같은 이름 필드를 'Provider-specific context limit' 으로 각각 정의해 뒀어요. 정의가 다르니 값이 다를 수 있다는 뜻이 되기는 하는데, 그걸 직접 알려 주는 문장이나 경고는 없었어요. 같은 페이지에서 context_length 라는 문자열이 나온 자리는 이 두 곳뿐이었어요.
왜 두 값이 갈리나요?
같은 모델을 여러 공급자가 서빙하는데 공급자마다 한도가 다르기 때문이에요. 42개 중 12개를 뽑아 모델별 엔드포인트 조회로 확인해 보니, 12개 전부에서 최상위 표시값이 공급자별 값 중 최대치와 정확히 같았어요. unslopnemo-12b 는 공급자가 둘인데 NextBit 이 32,768, Parasail 이 1,024,000 이었고, 최상위에 적힌 건 큰 쪽이었어요. 다만 어느 공급자로 실제 라우팅되는지는 이번에 확인하지 못했어요.
max_tokens 를 잡을 때도 주의할 게 있나요?
이쪽이 더 넓게 걸려요. 요청 파라미터 문서는 max_tokens 의 범위를 'Range: [1, context_length)' 로만 안내하는데, 422개 중 316개는 top_provider.max_completion_tokens 가 최상위 context_length 보다 작아요. 가장 벌어진 writer/palmyra-x5 는 컨텍스트가 1,040,000 인데 응답 상한이 8,192 예요. 127배 차이고, 이 모델은 컨텍스트 자체는 어긋나지 않아서 42개 목록에 들어 있지도 않아요.
실제로 그 길이를 넘겨 보내면 어떻게 되나요?
확인하지 못했어요. 이번 관측은 API 키 없이 열리는 공개 메타데이터만 읽은 것이고, 실제 생성 요청은 한 건도 보내지 않았어요. 거부되는지, 앞이 잘리는지, 다른 공급자로 넘어가는지 전부 모르는 상태예요. 그래서 이 글은 '이렇게 보내면 이런 오류가 난다'가 아니라 '메타데이터가 이렇게 갈려 있다'까지만 적었어요.
값이 비어 있는 모델도 있던데 뭔가요?
top_provider 객체는 있는데 그 안의 context_length 가 null 인 모델이 6개 있었어요. openrouter/auto, openrouter/auto-beta, openrouter/pareto-code, openrouter/fusion, openrouter/free, openrouter/bodybuilder 예요. 여섯 개 전부 openrouter 접두사예요. 특정 공급자 하나에 묶이지 않는 계열이라 그런 것으로 보이지만, 문서에서 그렇게 적힌 문장은 찾지 못했어요. 관측된 사실은 여섯 개가 전부 같은 접두사이고 값이 비어 있다는 것까지예요.
공유하기
제미나이 모델 지원 종료 확인 — 폐지 문서 65행 중 종료일 지난 38개, 그중 3개는 목록에 남아 있었어요
쓰던 제미나이 모델이 끝났는지 구글 공식 폐지 문서를 표째로 세고 API 응답과 대조했어요. 모델 행 65개 중 종료일이 지난 38개, 그중 3개는 목록에 남아 있었고 하나는 생성 호출에 답했어요. 2026년 8월 21일 12시 20분대 한국 시각 관측이에요.
한국어 토큰 수 실측 — 공식 countTokens API 값과 문서의 4자 어림이 갈리는 자리
한국어 토큰 수 계산을 어림값 대신 공식 countTokens 엔드포인트로 직접 재 봤어요. 문서는 약 4자에 1토큰이라고 적지만 실측한 한국어는 2자 남짓에 1토큰이었고, 글자 수가 두 배 넘는 영어 문장이 오히려 토큰은 적게 나왔어요.
n8n 템플릿 11,665개 중 값이 붙은 것은 1,255개 — 창작자 2,441명 가운데 값을 붙인 사람은 264명이에요
n8n 공식 템플릿 라이브러리를 47페이지 전수로 받아 11,665편을 셌어요. 값이 붙은 것은 1,255편(결제 링크 기준으로는 1,265편), 중앙값은 20달러, 가장 흔한 가격표는 25달러예요. 창작자 2,441명 중 값을 붙인 사람은 264명이고, 그중 114명은 유료가 딱 한 편이에요. 2026년 8월 24일 오전 관측이에요.
챗GPT 한국어 릴리스 노트는 영어판보다 17일 늦어요 — 최신 7건이 빠지고 옛 항목 14건이 남았어요
챗GPT 도움말의 릴리스 노트를 영어와 한국어를 포함한 여덟 언어로 받아 날짜 헤딩을 전수로 셌어요. 영어만 8월 21일이고 나머지 일곱은 8월 4일에 멈춰 있었어요. 한국어판 상단은 6시간 전 수정이라고 적혀 있고요. 2026년 8월 22일 오후 관측이에요.