LLM 사고 제어: 13개 모델의 수용, 무시, 강제 동작

동일한 사고 제어 매개변수는 어떤 모델에 전달하느냐에 따라 세 가지 다른 의미를 갖습니다: thinking_budget: 16은 Qwen 3.8 Max, GLM 5.2, 그리고 두 DeepSeek V4 빌드에서 정확히 16개의 추론 토큰을 소모하고, Kimi K3와 MiniMax M3에서는 조용히 무시되며, GPT-5.6에서는 400 오류로 거부됩니다. 저희는 아홉 개 벤더의 13개 모델을 대상으로 OpenAI 호환 인터페이스가 허용하는 모든 제어 표기법을 시험한 다음, 각 다이얼 위치가 추론 토큰 측면에서 얼마나 많은 비용을 발생시키고 정확도 측면에서 무엇을 손상시키는지를, 동일하게 솔트 처리된 네 개의 작업에서 셀당 세 번씩 실행하여 측정했습니다.

TL;DR

• thinking: {"type": "disabled"}는 13개 모델 중 11개에서 추론을 0으로 만들며, 두 예외(Gemini pro, GPT-5.6)는 이를 거부합니다.
• Qwen, GLM, DeepSeek는 thinking_budget: 16을 정확히 16으로 소진합니다. Kimi와 MiniMax는 이 필드를 받아들이지만 아무것도 바꾸지 않습니다: Kimi는 그 상한에 대해 8-97을 소진했으며, 결코 16을 소진하지 않았습니다.
• 사고 기능을 끄자 5단계 산술이 8개 모델에서 3/3에서 0-1/3로 떨어졌습니다. DeepSeek V4 Pro와 Claude는 단계를 보이는 답변에 작성하여 3/3을 유지했습니다.
• JSON 추출은 끄기를 지원하는 12개 모델 모두에서 사고 기능을 끈 상태로 3/3을 기록했습니다.

API별로 어떤 사고 제어를 받는가?

OpenAI 호환 interface에는 3가지 제어 계열이 쓰이지만, 이들을 모두 따르는 모델은 없다. reasoning_effort는 enum 값(none부터 max까지)을 받고, thinking_budget은 token 수를 받는다. thinking: {"type": "disabled"}와 유사한 enable_thinking: false는 사고를 완전히 끄도록 요청한다. 다음은 cell마다 간단한 salted 질문 1개를 보내 측정한 수용 현황이다.

두 행에는 주의 표시가 필요하다. Google은 자체 라인을 나눈다: flash 티어는 깔끔하게 꺼지는 반면 the pro tier는 모든 off 표기를 400으로 거부하는데, 이는 pro급 사고를 비활성화할 수 없다는 Google의 입장과 일치한다. 그리고 “accepted”로 표시된 두 개의 claude-fable-5 셀은 사고를 비활성화할 수 없다고 명시한 해당 모델에 대한 Anthropic의 공개된 계약과 다르므로, 그 셀들은 유동적인 것으로 간주하라.

”수용”은 “강제 적용”을 뜻하는가?

아니다. 그 차이에도 비용은 청구된다. 200 response는 parameter parsing에 성공했다는 뜻일 뿐, 해당 값이 모델까지 전달됐다는 보장은 없다. 둘을 구분하는 방법은 간단하다. budget을 16으로 보내고 meter를 확인하면 된다.

Qwen, GLM, 그리고 두 DeepSeek 빌드는 정확히 16을 소모했습니다. Kimi는 동일한 상한선에 대해 네 번의 실행에서 8, 19, 79, 97을 소모했으며 결코 16은 아니었고, MiniMax도 18-44에서 동일하게 동작했으며, 평소처럼 청구되었고, 응답에는 상한선이 해제되었음을 암시하는 내용이 전혀 없었습니다. Gemini는 예산을 자체 제어 체계로 거친 단위로 변환합니다: flash에서 0부터 64까지의 상한선은 완전히 꺼진 것처럼 동작한 반면 1,024는 사고를 허용했습니다(우리의 5단계 작업에서 중앙값 141); pro 등급은 상한선 아래에서 소모량을 줄였지만 요청된 64에 대해 약 200에서 하한을 형성했으며 0에 도달할 수 없습니다. GPT-5.6과 Claude는 스펙트럼의 정직한 쪽에 자리합니다: 숫자 예산은 400으로 거부되며 여러분은 즉시 자신의 위치를 알 수 있습니다.

실무 규칙은 간단하다. 사고 제어를 설정한 다음 response에서 completion_tokens_details.reasoning_tokens를 확인해 실제 사용량이 바뀌었는지 검증해야 한다. 명시적으로 실패하는 제어는 retry 1회 비용이면 끝난다. 조용히 실패하는 제어는 cap을 걸었다고 생각한 reasoning 비용을 호출할 때마다 계속 발생시킨다.

모든 모델에 통하는 off-switch가 있는가?

thinking: {"type": "disabled"}가 가장 근접합니다. 이는 Kimi, Qwen, 두 DeepSeek, GLM, Gemini flash, MiniMax, ByteDance의 Seed 라인, 그리고 세 개의 Claude 모델을 아우르는 13개 모델 중 11개에서 추론을 0으로 만들었습니다. 이와 유사한 enable_thinking: false는 거의 모든 곳에서 일치하지만, 한 가지 조용한 예외가 있습니다. MiniMax는 이를 받아들이면서도 추론을 유지합니다(우리의 프로브에서 31개의 추론 토큰).

두 가지 예외는 조용히 실패하는 대신 요란하게 실패합니다: Gemini pro는 모든 잘못된 표기에 대해 400을 반환하며(해당 티어는 thinking을 비활성화할 수 없음), GPT-5.6도 해당 필드를 거부합니다. GPT-5.6은 같은 의미의 off-switch가 필요하지 않습니다: gpt-5.6-luna는 기본적으로 단순한 조회와 추출에 대해 추론 토큰을 0개 소모하며(해당 제품군의 two-lever 패턴), reasoning_effort: "none"은 수학 형태의 입력에 대해서도 그 동작을 고정합니다.

사고를 끄면 정확도가 얼마나 떨어지는가?

5단계 산술 연산에서는 치명적이었다. 사고를 끄자 8개 모델의 정확도가 3/3에서 0/3 또는 1/3으로 떨어졌다. 2-hop 문장제에서는 영향이 훨씬 작았다. 대부분 사고를 꺼도 3/3을 유지했고, Kimi와 MiniMax만 0/3으로 떨어졌다. K3 출시 build 연구에서 확인한 것과 같은 불안정한 off 상태다. 모델이 visible pass 한 번에 처리할 수 있는 수준보다 단계 수가 많아지는 지점에서 정확도가 급락한다.

정확도를 유지한 3개 모델에는 공통점이 있다. 사고를 끄면 중간 단계를 visible answer에 작성한다. DeepSeek V4 Pro의 reply 중앙값은 115 token에서 142 token으로, Sonnet 5는 70 token에서 139 token으로 늘었다. hidden reasoning 비용 대신 visible reasoning 비용을 지불하는 셈이다. 대부분의 요금표에서 둘 다 같은 output 단가가 적용되므로 “off” switch는 비용을 없애기보다 비용의 명목을 바꾼다. off 상태에서 지시대로 1-4 token만 답하는 모델이 정확도 급락을 겪었다.

정확도가 급락하는 경우에도 적은 budget으로 복구할 수 있었다. thinking_budget: 256을 설정하자 Qwen과 두 DeepSeek build가 3/3으로 돌아왔고, reasoning token 중앙값은 77-128이었다. DeepSeek 재학습 모델과 Qwen 3.8의 hidden cap에서도 같은 최소 budget 복구 패턴을 측정했다.

matrix에서 수치가 전혀 나오지 않은 cell도 하나 있었다. claude-fable-5는 정확히 같은 산술 표현에 대해 모든 effort 설정에서 12회 중 12회 stop_reason: "refusal"(category cyber)을 반환했다. 의미는 같지만 표현만 바꾼 문장은 12회 모두 통과했다. Anthropic은 refusal을 1급 stop reason으로 정의하고 opt-in fallback 방식을 제공한다. fable급 모델을 rotation에 넣는다면 실제로 refusal이 발생하기 전에 해당 stop reason 처리부터 구현해야 한다.

effort level을 높이면 실제로 무엇이 달라지는가?

vendor마다 곡선이 다르고, 위로 꾸준히 증가한 것은 Google뿐이었다. 각 모델이 받는 enum 값을 모두 사용해 같은 5단계 task를 설정별로 3회 실행하고, 중앙값을 하나의 scale에 표시했다.

곡선은 4가지 형태로 나뉜다. 실제로 작동하는 throttle: 두 Gemini는 단조 증가했다. flash는 reasoning token 137에서 390까지, pro는 180에서 387까지 증가했으며 high에서 포화됐다. low는 상위 설정의 3분의 1에서 절반 수준만 사용하면서도 정확도 3/3을 유지했다. 따라서 Gemini pipeline에서는 low를 기본값으로 고정할 만하다. 평평한 곡선: DeepSeek는 low 78, max 54로 오히려 감소했다. Kimi는 minimal 94, max 67이었고, MiniMax는 일정한 순서 없이 61-93을 기록했다. 이들은 여러 단계의 설정을 제공하지만 어느 위치에서도 실질적인 변화가 없다. DeepSeek의 model card는 “max reasoning effort”에서 측정한 benchmark를 제시하지만, 이미 default와 차이가 없음을 확인했다. 상한에 도달하지 않는 cap: Qwen의 level은 budget 상한이다. 이 정도 규모의 task에서는 차이가 드러나지 않아 추세 없이 85-156을 기록했고, 별도로 측정한 것처럼 깊은 작업에서만 실제 효과가 나타난다. 비단조형: GLM은 low 184, max 345였지만 high는 116만 사용했다. 이 mapping이 안정되기 전까지는 중간 설정에 순서가 없다고 봐야 한다. adaptive 모델 2개는 설정 자체가 거의 필요 없다. gpt-5.6-luna는 전체 enum에서 32-41 token 범위에 머물렀다. Opus 5의 output_config.effort가 visible output에 미친 차이도 noise 수준인 54-63 token뿐이었다. Sonnet 5도 71-92로 같았다. 실질적인 판단은 adaptive thinking이 담당했다.

곡선 형태에서 운영 원칙을 도출할 수 있다. Gemini에서는 각 단계가 실제 비용으로 이어지므로 level을 의도적으로 선택해야 한다. Qwen, GLM, DeepSeek에서는 enum이 아니라 정확히 적용되는 thinking_budget과 off-switch를 사용해야 한다. 나머지 모델에서 enum은 off와 default 사이를 장식할 뿐이다. 어느 유형인지 확인하는 유일한 방법은 위와 같은 ladder test다. 같은 task를 모든 설정으로 실행하고 meter를 읽으면 된다.

task 형태에 따른 결과도 일반화할 수 있다. 단일 단계 JSON 추출에서 사고를 켰을 때 matrix 전체에서 가장 높은 사용량이 나왔다. GLM은 reasoning token 377개, Gemini flash는 332개를 사용했지만 아무 이득도 없었다. 사고를 끌 수 있는 모델 12개 모두 off 상태에서 해당 task를 3/3으로 처리했다. 구조화 추출은 불필요한 reasoning 비용이 가장 크게 발생하는 workload이며, 동시에 off-switch를 안전하게 적용할 수 있는 영역이다.

비용을 낸 사고 내용을 확인할 수 있는가?

billing meter는 모든 모델에서 제공되지만, 사고 내용은 그렇지 않다. open-weight 계열 중 6개 모델은 reasoning_content로 reasoning text를 반환한다. GLM 5.2와 DeepSeek V4 Pro는 reasoning token 167개와 100개에 대해 각각 508자와 312자를 반환했으며, 전체 chain에 가까워 보였다. Kimi, Qwen, DeepSeek Flash, MiniMax, Seed는 적은 사용량에 대체로 비례하는 더 짧은 trace를 반환했다. GPT-5.6과 두 Gemini는 아무것도 반환하지 않는다. reasoning token은 과금되지만 내용은 볼 수 없다. Claude는 thinking block을 반환하지만, 측정한 interface에서는 기본적으로 content가 생략됐다. 사고가 수행됐다는 사실만 알 수 있고 내용은 볼 수 없다.

이 가시성 차이는 budget 동작을 debug할 때 중요하다. 아무 내용도 반환하지 않는 모델에서는 usage detail의 reasoning_tokens가 유일한 계측 수단이다. 200 response가 아니라 meter를 믿어야 한다.

FAQ

OpenAI 호환 API에서 사고를 끄려면 어떻게 해야 하는가?

thinking: {"type": "disabled"}를 보내세요. 우리의 13개 모델 매트릭스에서 11개(Kimi, Qwen, DeepSeek x2, GLM, Gemini flash, MiniMax, Seed, 그리고 Claude 계열)의 추론이 0으로 설정되었습니다. Gemini pro는 끌 수 없으며 400을 반환합니다. GPT-5.6은 해당 필드를 거부하지만 기본적으로 간단한 작업에서는 거의 생각하지 않습니다. 다음 응답에서 reasoning_tokens를 읽어 확인하세요.

thinking_budget: 0으로 사고를 끌 수 있는가?

모델에 따라 다릅니다. Gemini flash와 ByteDance Seed에서는 0이 깔끔한 끄기로 작동합니다. Qwen과 DeepSeek은 0을 400으로 거부하며, Kimi와 MiniMax는 어떤 budget이든 받아들이지만 무시합니다. budget이 토큰 단위로 엄격하게 적용되는 경우(Qwen, GLM, DeepSeek), 최소한의 유용한 값은 작은 양수입니다. 256은 5단계 작업에서 Qwen과 두 DeepSeek 빌드 모두에서 3/3을 유지한 반면, GLM은 동일한 설정에서 2/3으로 흔들렸습니다.

JSON 추출에서 사고를 꺼도 안전한가?

이번 실행에서는 안전했다. 단일 단계 추출은 off를 지원하는 모든 모델에서 사고를 끄고도 3/3을 기록했다. 사고를 켜면 같은 output을 만드는 데 reasoning token을 최대 377개까지 사용했다. 경계는 output 형식이 아니라 단계 수다. 다단계 task는 11개 모델 중 8개가 사고를 끄면 정확도가 무너졌다. DeepSeek 연구에서 확인한 예외도 있다. 0731 재학습 모델에서는 사고를 켜면 strict JSON 값이 오히려 손상됐다. 이 경우 off-switch는 정확도까지 개선한다.

어떤 모델이 thinking budget을 정확히 강제하는가?

Qwen 3.8 Max, GLM 5.2, 그리고 두 DeepSeek V4 빌드: 16을 요청하면 계측기가 16으로 표시됩니다. Kimi K3와 MiniMax는 동일한 필드를 받아들이지만 무시합니다. Gemini는 이를 대략적으로 변환합니다(작은 값은 flash에서 off처럼 작동하고, pro는 high로 하한을 정합니다). GPT-5.6과 Claude 5세대 모델들은 숫자 예산을 완전히 거부합니다(Claude의 budget_tokens는 적응형 사고를 가리키는 400을 반환합니다).

2026-08-11/12에 Synthorai 게이트웨이를 통해 측정: 13개 모델에 걸쳐 reasoning_effort(7개 값), thinking_budget(0/16/1024), enable_thinking, thinking:{"type":"disabled"}에 대한 수용 프로브를 실행하고 발행 몇 시간 전에 재검증함; 그 다음 552회 호출 규모의 세금 매트릭스(4개의 솔트 처리된 작업 형태 x 각 암(arm)당 3회 실행, 각 암은 해당 모델의 검증된 작동 컨트롤로 제한됨), 5단계 작업에 대한 183회 호출 규모의 전체 열거 사다리(차트의 데이터), 보충 셀, 그리고 모델별 추론 가시성 프로브. 정확도는 원본 답변을 기준으로 채점; 토큰 중앙값은 n=3; 추론 토큰은 completion_tokens_details.reasoning_tokens에서 읽음(Claude 모델은 출력 토큰만 보고함). 프롬프트는 호출마다 솔트 처리됨. 다이얼 의미론과 열거값은 이 날짜에 측정한 표면이며 변경될 수 있음; 어느 단일 셀에라도 의존하기 전에 재프로브할 것.

← 블로그로 돌아가기