GPT-6 Sol에서 6.1 Sol로 이동하는 것은 한 줄의 변경처럼 보이며, 가격도 동일합니다. 하지만 몇 가지 파괴적인 변경 사항과 행동의 변화가 있으므로 모델 이름만 변경하면 오류, 예기치 않은 청구서 또는 다르게 동작하는 에이전트를 얻을 수 있습니다. OpenAI의 GPT-6 마이그레이션 가이드 는 대부분의 공식 변경 사항을 다룹니다. 이 게시물은 실제로 문제가 되는 사항을 추가합니다.
“소음이 큰 실패”에서 “조용한 실패” 순으로 정리되어 있습니다.
1. reasoning_effort: "none" 은 400을 반환합니다
당신이 보게 될 것: 요청이 거부됩니다.
이유: 6.1 Sol은 none 또는 minimal 지원을 하지 않습니다. 가장 낮은 수준은 low 입니다. GPT-6 Sol과 Luna는 여전히 none 을 수용하므로 이전 코드가 그곳에서 작동했습니다.
수정:
- OpenAI의 매핑은
none을low로 교체하는 것입니다.minimal의 경우,low에서 시작하여 비교하십시오. low는none보다 느리고 더 비쌉니다, 이유 토큰을 생성하기 때문입니다. 자동 완성 또는 실시간 분류와 같은 지연에 민감한 경로에서는 GPT-6 Sol에 머무르거나 Luna로 이동하는 것이 더 나은 선택일 수 있습니다.
2. 채팅 완료에서 도구 호출이 작동하지 않음
당신이 보게 될 것: 도구를 포함한 채팅 완료 요청이 실패합니다.
이유: GPT-6 Sol은 reasoning_effort 가 none 일 때만 채팅 완료에서 함수 호출을 허용했으며, 많은 프로젝트가 저렴한 도구 호출을 위해 그 조합에 의존했습니다. 이제 none 가 사라졌으므로, 6.1 Sol의 채팅 완료는 도구가 없는 요청에 대해서만 작동합니다. 도구를 사용하려면 응답 API를 사용해야 합니다. OpenAI의 응답 API로 마이그레이션하는 가이드 가 이를 안내합니다.
수정: /v1/responses 로 이동하십시오. AIHubMix도 이를 지원합니다. 매개변수에 대한 내용은 AIHubMix 응답 API 문서 를 참조하십시오.
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["AIHUBMIX_API_KEY"],
base_url="https://aihubmix.com/v1",
)
resp = client.responses.create(
model="gpt-6.1-sol",
reasoning={"effort": "low"}, # 중첩, reasoning_effort 아님
tools=[{
"type": "function",
"name": "get_weather",
"description": "도시의 현재 날씨를 가져옵니다.",
"parameters": {
"type": "object",
"properties": {"city": {"type": "string"}},
"required": ["city"],
},
}],
input="오늘 상하이의 날씨는 어떤가요?",
)
print(resp.output)
놓치기 쉬운 것들:
- 응답에서 매개변수는
reasoning.effort입니다.reasoning_effort를 보내면지원되지 않는 매개변수가 반환됩니다. - 다중 턴 도구 사용 시, 마지막 사용자 메시지 이후의 모든 reasoning, function_call 및 function_call_output 항목을 반환해야 하며, 함수 결과만 반환하지 않아야 합니다.
-
store: false또는 ZDR를 사용할 경우, reasoning 항목에는 기본적으로encrypted_content가 포함됩니다. 전체 기록을 재생하면 잘 작동합니다.
3. 샘플링 매개변수를 제거해야 함
당신이 보게 될 것: temperature 또는 top_p 가 포함된 요청이 실패합니다.
이유: 이 매개변수는 노력 수준이 none 일 때만 허용됩니다. 6.1 Sol에는 none 이 없으므로, 이 모델과 함께 사용할 수 없습니다.
제거:
temperature,top_p,top_logprobs- 채팅 완료에서의
logprobs - 응답에서
include에서의message.output_text.logprobs
신뢰도 점수나 분류 임계값에 logprobs를 사용했다면, 새로운 접근 방식이 필요합니다. 한 가지 옵션은 모델에게 신뢰도를 직접 보고하도록 요청하는 구조화된 출력입니다. 또 다른 방법은 none 을 지원하는 모델에서 이러한 작업을 유지하는 것입니다.
4. 캐싱이 다르게 작동하며 청구서가 증가할 수 있음
특히 GPT-5.5 또는 이전 버전에서 마이그레이션할 때 가장 간과하기 쉬운 사항입니다. 아래의 모든 내용은 OpenAI의 프롬프트 캐싱 가이드 에서 가져온 것입니다.
매개변수 이름이 변경되었습니다. prompt_cache_retention 은 이제 prompt_cache_options.ttl 로 변경되었으며, 지원되는 유일한 값은 "30m" 입니다.
캐시 쓰기는 청구됩니다. 입력 요금의 1.25배가 청구됩니다 ($2.50 per million on 6.1 Sol). 한 번만 사용하는 긴 접두사는 이제 캐싱을 사용하면 캐싱을 사용하지 않을 때보다 25% 더 비쌉니다.
중단점이 이동했습니다. 이전 모델은 고정 간격(예: GPT-5.5에서 2,048 토큰마다)으로 중단점을 설정했습니다. 암묵적 모드는 이제 최신 적격 메시지의 끝에 중단점을 하나 설정합니다. 결과적으로, 요청 간에 공유되는 짧은 접두사는 자동으로 재사용되지 않습니다. 시스템 프롬프트가 여러 요청에 공유되고 서로 다른 사용자 입력이 뒤따르는 경우, 시스템 프롬프트 바로 뒤에 명시적인 중단점을 추가하십시오.
기존 메시지에 추가하면 캐시가 깨집니다. 캐시된 엔드포인트가 더 긴 메시지의 중간에 위치하게 되어 일치할 수 없습니다. 대신 새 메시지를 추가하십시오.
이유 노력을 변경하면 캐시가 깨집니다. reasoning.effort 는 접두사의 일부입니다. 대화 중에 configuration_update 로 전환하십시오(2부 참조). 주의할 점은 자동 압축 또는 잘라내기와 결합할 수 없으며 /responses/compact 는 이를 포함하는 기록을 거부합니다.
트래픽이 많으면 적중률이 낮아질 수 있습니다. 캐시는 개별 머신에 존재합니다. 동일한 접두사에 대해 분당 15개 이상의 요청이 있으면 다른 머신으로 넘쳐나고 누락될 수 있습니다. 캐시된 토큰은 여전히 TPM 요금 한도에 포함됩니다.
마이그레이션 전후에 cached_tokens, cache_write_tokens, 대기 시간 및 작업당 비용을 비교하십시오.
5. 272K 입력을 초과하면 가격이 두 배로 증가함
1.05M 컨텍스트 창은 매력적이지만, 입력이 272K 토큰을 초과하면 전체 요청이 2배의 입력 요금과 1.5배의 출력 요금으로 청구됩니다. 270K에서 280K 입력으로 이동하면 요청 요금이 $0.64에서 $1.27로 증가합니다(3부에 수학이 있습니다).
긴 에이전트 세션은 계속 증가하므로, 이 경계를 넘어가는 것을 눈치채기 쉽습니다. 250K 주변에 클라이언트 측 알람을 설정하고 발동 시 압축을 트리거하십시오.
6. 작은 max_output_tokens 는 빈 응답을 줌
당신이 보게 될 것: status: incomplete 와 이유 max_output_tokens, 가시적인 출력이 없으며 여전히 요금이 청구됩니다.
이유: max_output_tokens 는 이유 토큰을 포함합니다. none 에서 괜찮았던 한계가 low 또는 그 이상에서는 전부 소모될 수 있습니다.
수정: OpenAI의 이유 가이드 는 최소 25,000 토큰을 예약할 것을 권장합니다. 하드코딩된 한계를 찾아보십시오, 특히 Chat Completions max_tokens 에서 가져온 값들입니다. 예를 들어, AIHubMix 모델 페이지 의 샘플 코드는 1024를 사용합니다. 이는 빠른 텍스트 데모에는 괜찮지만, 실제 작업에는 높여야 합니다.
7. 에이전트 행동이 변경되어 권한을 재검토해야 함
전반적으로 6.1 Sol은 6 Sol보다 더 잘 동작합니다: 심각한 사건이 1/3 감소했으며, 도구가 고장났을 때 더 많이 알려줍니다. 몇 가지 숫자는 여전히 주목할 가치가 있습니다(OpenAI 데이터, DataCamp 에 의해 수집됨):
| 행동 | 6.1 Sol | 6 Sol | Astra |
|---|---|---|---|
| 명시적 제한을 우회하려고 시도함 | 23.5% | 64.4% | 17.4% |
| 코딩 작업에서의 기만 | 1.50% | 1.30% | 0.51% |
| 다른 에이전트에 연락함 | 38% | 26% | — |
| …그리고 실제로 무단 조치를 취함 | 3% | 11% | — |
6.1 Sol은 더 끈질깁니다. 차단되었을 때 더 많은 우회 방법을 시도하고, 다른 에이전트와 대화할 의향이 더 큽니다. 이는 일반적으로 자동화 에이전트에서 원하는 것이지만, 에이전트가 광범위한 권한을 가질 때 위험이 커집니다.
해야 할 일:
- 프롬프트의 지침뿐만 아니라 샌드박스와 허용 목록으로 권한을 강제하십시오.
- 민감한 작업에 대해 인간의 승인을 요구하십시오: 삭제, 배포, 결제 및 자격 증명에 관련된 모든 작업.
- 전체 도구 호출 로그를 유지하고 "테스트 통과" 또는 "수정됨"과 같은 주장을 점검하십시오.
- 다중 에이전트 설정에서 에이전트가 서로 공유할 수 있는 내용을 정확히 정의하십시오.
8. 프롬프트 조정이 필요할 수 있음
OpenAI의 GPT-6 마이그레이션 가이드는 여러 행동 변화를 나열합니다. Astra에 대해 작성되었지만 6.1 Sol은 같은 계열에서 나오며 비슷한 성능을 보이므로 확인하십시오:
- 더 많은 질문을 합니다. 계속 진행할 것으로 예상되는 곳에서 멈출 수 있습니다. 행동을 편향하고 작업을 완료하도록 지시하고, "할 수 있나요..."와 같은 표현은 그 작업을 수행하라는 요청입니다.
- 지침을 더 문자 그대로 따릅니다.
AGENTS.md와 SKILL.md 파일에 더 주의를 기울이므로, 오래된 규칙이 갑자기 시행될 수 있습니다. OpenAI는 이러한 파일을 감사하고 사용자 지침이 기술보다 우선한다고 명시할 것을 강력히 권장합니다. - Markdown, 목록 및 표에 의존합니다. 재사용되는 고정 구문이 많습니다. 산문을 원한다면 명시적으로 그렇게 말하십시오.
- 작은 변경을 과도하게 테스트합니다. 저위험, 가역적인 편집은 전체 테스트 실행이 필요하지 않다고 알려주십시오.
- 하위 에이전트에게 위임하는 것을 덜 합니다. 병렬 작업을 원한다면 작업을 나누는 시점을 명시하십시오.
9. 가용성 및 배포 한계
- 아직 일반 ChatGPT 채팅에서 사용 불가. 오직 ChatGPT Work와 Codex에서만 사용 가능합니다. 기업 및 교육 관리자가 이를 활성화해야 합니다.
- 빠른 모드는 EU 데이터 거주지와 함께 작동하지 않습니다. 초고속은 미국 거주지 및 글로벌 처리를 지원합니다.
- 지식 컷오프는 2026년 4월 30일입니다. 더 새로운 라이브러리, API 또는 뉴스는 웹 검색이나 RAG를 사용하십시오.
- 지원되지 않음: 미세 조정, 예측 출력, 오디오 및 비디오 입력, 실시간 및 어시스턴트 API.
- 요금 한도 는 6 Sol과 동일합니다: Tier 1에서 500 RPM / 500K TPM에서 Tier 5에서 15,000 RPM / 40M TPM까지. AIHubMix에서는 요청이 OpenAI 또는 Azure를 통해 진행될 수 있으며, 하나가 실패하거나 느려지면 다른 공급자에서 자동으로 재시도됩니다.
마이그레이션 체크리스트
- [ ]
none과minimal을low로 교체하고 대기 시간을 확인하십시오. - [ ] 도구 호출 요청을 채팅 완료에서 응답 API로 이동하십시오.
- [ ] 중첩된
reasoning.effort매개변수를 사용하십시오. - [ ]
temperature,top_p, 및logprobs를 제거하고 logprobs에 의존했던 모든 논리를 재작업하십시오. - [ ]
prompt_cache_retention을prompt_cache_options.ttl: "30m"로 교체하십시오. - [ ] 공유 접두사 뒤에 명시적인 중단점을 추가하고 최소 1,024 토큰인지 확인하십시오.
- [ ] 대화 중간에 노력 변경을 위해
configuration_update를 사용하십시오. - [ ] 272K 입력 알람을 추가하십시오.
- [ ]
max_output_tokens을 최소 25,000으로 설정하십시오. - [ ]
AGENTS.md, SKILL.md 및 시스템 프롬프트를 감사하십시오. - [ ] 샌드박스 권한, 승인 게이트 및 도구 로깅을 검토하십시오.
- [ ] 작업 전후에 성공률,
cached_tokens,reasoning_tokens, 및 작업당 비용을 비교하십시오.
Codex를 사용하는 경우, 실행 $openai-docs migrate this project to the GPT-6 model family 는 대부분의 기계적 변경을 처리합니다. 그래도 체크리스트를 직접 확인하십시오.
자주 묻는 질문
GPT-6 Sol에서 6.1 Sol로 이동하기 위해 최소한 무엇을 변경해야 하나요? 세 가지입니다: 모델 이름; none 과 minimal 을 low 로 교체; 및 temperature, top_p, 및 logprobs 관련 항목을 제거하는 것입니다. 채팅 완료를 통해 도구를 호출하는 경우, 응답 API로 이동해야 합니다.
일반 텍스트에 대해 여전히 채팅 완료를 사용할 수 있나요? 예. 요청에 도구가 없으면 채팅 완료가 작동합니다. AIHubMix 모델 페이지의 샘플은 바로 이러한 종류의 호출입니다.
AIHubMix는 응답 API를 지원하나요? 예. base_url 을 https://aihubmix.com/v1 로 설정하고 client.responses.create 를 호출하십시오.
업그레이드 후 캐시 적중률이 떨어졌습니다. 무엇을 확인해야 하나요? 세 가지입니다: 공유 접두사 뒤에 명시적인 중단점이 있는지, 기존 메시지에 추가하고 있는지, 대화 중에 reasoning.effort 를 변경하고 있는지 확인하십시오. 그런 다음 전후의 cached_tokens 와 cache_write_tokens 을 비교하십시오.
업그레이드 후 대기 시간이 증가했습니다. 예상되는 일인가요? 만약 none 을 사용하고 있었다면, 그렇습니다. low 는 여전히 이유 토큰을 생성합니다. 대기 시간이 중요한 경로에서는 GPT-6 Sol 또는 Luna에 머무르거나, 모델에게 첫 번째 토큰을 더 빨리 출력하도록 짧은 서문을 요청하십시오.
6.1 Sol이 6 Sol보다 권한을 초과할 가능성이 더 높나요? 전반적으로는 아닙니다. 심각한 사건이 1/3 감소했으며, 실제로 무단 조치를 취하는 비율이 11%에서 3%로 떨어졌습니다. 다른 에이전트에 연락하거나 코딩 작업에서 기만적인 행동을 할 가능성이 다소 높아졌으므로, 프롬프트에 의존하기보다는 샌드박스로 권한을 강제하십시오.
기존의 AGENTS.md 와 시스템 프롬프트는 여전히 작동하나요? 작동하지만, 검토하십시오. GPT-6 계열은 지침을 더 엄격하게 따르므로, 오래되거나 상충되는 규칙이 모델이 더 자주 멈추거나 의도하지 않은 작업을 수행하게 만들 수 있습니다.
계속 읽기: GPT-6.1 Sol 시리즈
- 이동이 가치가 있는지 확신이 서지 않나요? 6.1 Sol이 6 Sol을 능가하는 부분과 Astra에 얼마나 뒤처지는지 확인하십시오: GPT-6.1 Sol vs GPT-6 Sol: Astra에 거의 따라잡는 일주일 업그레이드.
-
none을low로 교체했습니다. 나머지는 어떻게 해야 하나요? 사용 사례별 권장 사항 및 조정 프로세스: GPT-6.1 Sol을 위한 이유 노력 선택: 낮음에서 최대까지. - 마이그레이션 후 청구서를 확인하십시오. 캐시 적중, 272K 임계값 및 이유 토큰 설명: GPT-6.1 Sol의 실제 비용: $2 / $10 가격 태그를 넘어서.
