GPT Image 2.5 Flare & Sunburst가 EvoLink에 출시되었습니다GPT Image 2.5 체험하기
본문으로 이동
바위 협곡을 따라 황금빛 강이 흐르는 Kimi K3.1 Pro 일러스트
리뷰

Kimi K3.1 Pro 평가: 코딩, 3D 모델링과 조사 능력

공개 벤치마크와 작업 사례로 살펴보는 Kimi K3.1 Pro의 코드 수정, Blender·CAD, 데이터 분석과 최종 답변 지연.

EvoLink Team
32분 소요

Kimi K3.1 Pro의 공개 테스트에서는 코드 수정과 데이터 조사에 성공한 사례와 함께, 브라우저 검증의 빈틈과 데이터 그룹 분류 오류도 확인됩니다. Moonshot AI의 공식 3D 사례는 여기에 또 다른 측면을 더합니다. 모델이 Blender와 CAD 도구를 사용해 구조를 갖춘 장면과 객체를 만들 수 있다는 점입니다.

실무에서 중요한 질문은 결과물이 얼마나 잘 작동하는지, 무엇을 확인해야 하는지, 최종 답변까지 얼마나 걸리는지입니다. Artificial Analysis, Atomic Agent, PacBench, Plotly의 구체적인 결과를 Moonshot AI의 공식 사례와 함께 살펴봅니다.

Kimi K3.1 Pro 평가: 코딩, 에이전트, 추론

Artificial Analysis가 2026년 10월 23일 공개한 출시 평가에는 터미널 작업, SaaS 워크플로, 지식 업무, 고난도 추론 문제가 포함됩니다.

평가K3.1 Pro 결과주요 평가 대상
Terminal-Bench 4.067%터미널 환경의 코딩과 운영 작업
AutomationBench-AA73%에이전트의 SaaS 워크플로 실행
GDPval-AA1,846 Elo지식 업무 결과물의 상대적 성능
Humanity’s Last Exam52%고난도 지식 및 추론 문제
출처: Artificial Analysis, 2026-10-23. 평가마다 지표가 다릅니다. Elo는 상대 평점이며 작업 성공률이 아닙니다.

네 평가는 서로 다른 업무를 다룹니다. 터미널과 SaaS 작업은 에이전트가 환경 안에서 행동하도록 요구하고, 지식 업무 평가는 만들어 낸 결과물을 봅니다. 어려운 질문은 복잡한 추론을 거쳐 정답에 도달하는 능력을 더합니다. 한 범주의 좋은 성적과 워크플로의 다른 부분에 있는 약점은 함께 존재할 수 있습니다.

개발자에게 이 구분은 코딩 벤치마크와 생성된 애플리케이션이 다르게 보이는 이유를 설명합니다. 저장소의 과제를 해결하려면 파일을 읽고, 수정하고, 검사를 실행하고, 실패를 해석해야 합니다. 대화형 애플리케이션을 전달하려면 조작, 렌더링, 실행 후 사용자가 겪는 동작까지 확인해야 합니다. 다음 사례에서 이런 차이가 드러납니다.

코딩: 코드 수정과 장시간 작업

Python 수정 과제에서 비교한 low와 max

Atomic Agent는 의도적으로 다섯 개의 버그와 두 개의 미구현 기능을 넣은 Python 패키지를 테스트했습니다. 빠진 기능은 정산 함수와 명령줄 도구였습니다. 에이전트에는 과제 파일을 읽고, 작업을 마치고, 테스트가 통과할 때까지 실행하라는 짧은 지시가 주어졌습니다. 모든 실행은 같은 과제와 도구를 사용한 Atomic Agent v0.6.9 환경에서 진행됐습니다.

추론 설정마다 세 번 실행했고, 실행마다 비공개 검증문 32개로 결과를 확인했습니다. 이는 작업 중 에이전트가 볼 수 있는 테스트와 분리된 검사입니다. 두 설정 모두 모든 검증을 통과했습니다.

설정세 번의 실행에서 통과한 검증평균 시간평균 모델 호출 수
Low96/962.2분19회
Max96/964.9분28회
출처: 자체 에이전트로 진행한 Atomic Agent 실험. 합계는 하나의 과제를 세 번 실행한 결과이며, 서로 다른 과제 96개가 아닙니다.

이 과제에서는 low가 더 효율적이었습니다. 보고된 평균으로 계산하면 max는 약 2.2배의 시간과 약 47% 더 많은 모델 호출을 사용했으며, 통과 결과는 같았습니다.

토큰 구성을 보면 차이를 더 구체적으로 이해할 수 있습니다. Atomic은 실행당 평균 출력이 low에서 약 5.4K 토큰, max에서 약 17.3K 토큰이었고, 이 중 추론 토큰은 각각 약 1.4K와 12.2K였다고 보고했습니다. 긴 실행은 같은 답을 천천히 내보낸 것이 아니라 훨씬 많은 내용을 생성하고 더 많은 단계를 거쳤습니다. 출처: Atomic 상세 결과.

코드 수정에서는 완성된 패치가 유용한 비교 기준입니다. 요청한 동작을 고쳤는지, 공개 인터페이스를 유지했는지, 관련 없는 변경을 피했는지를 봐야 합니다. 높은 추론 단계는 이런 결과를 개선할 때 가치가 있습니다. 설명이 길거나 도구 호출이 많다는 것은 실행 특성이며, 그 자체로 더 나은 패치를 뜻하지는 않습니다.

긴 작업 중 진단 방향을 바꾸기

Moonshot AI의 내부 보행 시뮬레이션 사례에서는 제어기 보상을 조정해도 개선이 제한적이었습니다. K3.1 Pro는 시뮬레이터를 조사해 어깨 근육의 모멘트암 계산 오류 36개를 수정한 뒤 제어기를 다시 학습했습니다. Moonshot은 번갈아 내딛는 보행이 11.2초 동안 이어졌다고 보고합니다. 출처: 공식 Coding 설명.

시뮬레이터는 골격 구성 요소 296개와 근육 구성 요소 402개를 포함한 human-atlas 해부 모델을 바탕으로 만들어졌습니다. Moonshot은 모델이 개방 루프 동역학 시험으로 팔 움직임 문제를 조사한 다음 계산을 수정하고 제어기를 다시 학습했다고 설명합니다.

서로 연결된 시스템에서는 이 순서가 중요합니다. 잘못된 시뮬레이션을 상대로 제어기를 학습할 수 있고, 애플리케이션 코드를 고장 난 의존성이나 잘못된 테스트 준비 데이터에 맞춰 조정할 수도 있습니다. 바깥쪽 루프를 계속 개선해도 근본 결함은 남을 수 있습니다. 이 사례에서는 학습 목표에서 학습 환경을 정의하는 시뮬레이터로 조사 대상이 바뀌었습니다.

따라서 긴 코딩 작업의 진전에는 의존성 읽기, 수치 가정 확인, 새로운 결과에 따라 초기 설명 수정하기 같은 진단 전환도 포함됩니다. 결과물에는 변경 파일, 테스트 명령, 측정 결과 등 충분한 흔적을 남겨 다른 개발자가 작업을 이어 갈 수 있어야 합니다.

생성된 게임과 남아 있는 검증의 빈틈

Kimi K3.1 Pro 모델 이름과 생성된 Pac-Man 미로가 보이는 PacBench 게임 화면
PacBench가 외부 코딩 사례로 공개한 Kimi K3.1 Pro의 Pac-Man 게임. PacBench원본 크기로 보기 ↗

PacBench의 K3.1 Pro 항목은 high를 사용했고, 모델 응답 17회에 약 11.5분이 걸렸습니다. 생성된 Pac-Man 게임은 실행 기록과 함께 공개되어 직접 플레이할 수 있습니다.

샌드박스가 헤드리스 브라우저 실행을 막자 모델은 Node의 canvas 대체 환경으로 게임 로직을 확인했습니다. 그래도 평가자는 조작, 캐릭터 동작, 소리에서 결함을 기록했습니다. 출처: 실행 기록, 프로젝트 저장소.

평가자는 잘된 부분도 기록했습니다. 전통적인 28×31 미로, 244개 점 모두에 도달 가능한 구조, 테스트한 프레임 속도에서 이동이 막히지 않는 동작입니다. 이 정보가 있어 남은 결함을 단순히 ‘작동한다’ 또는 ‘작동하지 않는다’보다 구체적으로 이해할 수 있습니다.

조작 문제 하나는 마우스로 시작한 뒤 Start 버튼에 포커스가 남는 것이었습니다. 플레이 도중 Space나 Enter를 누르면 게임이 다시 시작될 수 있었습니다. 또 유령 집의 카운터가 목숨마다 초기화되어 Clyde가 집 안에 너무 오래 머물렀습니다. 소리 검사에서는 숨겨진 탭에서도 사이렌이 계속 재생됐습니다. 자세한 내용은 PacBench 기능별 기록에 있습니다.

남은 일은 브라우저 검증이었습니다. Node 대체 환경은 게임 상태 전환을 실행할 수 있어도 키보드 포커스와 백그라운드 탭 오디오는 브라우저 동작입니다. 대화형 결과물에서는 승리 조건을 확인하는 일과 실제 플레이 경험을 확인하는 일이 별개의 완료 항목입니다.

3D 모델링: Blender, CAD와 결과물 검토

Moonshot의 3D 기술 설명은 K3.1 Pro가 Blender나 CAD 스크립트를 작성하고 실행해 형상, 재질, 장면을 구성하는 흐름을 보여 줍니다. 결과물은 채팅 답변만으로 만들어지는 것이 아니라 모델이 해당 도구와 함께 작업한 결과입니다.

CAD 벤치마크가 재구성하는 것

Moonshot은 1,000개 사례의 부분집합에서 도구 사용 시 BenchCAD 92.7을 보고했습니다. BenchCAD는 여러 방향의 렌더링 이미지로부터 CAD 코드를 재구성하도록 요구합니다. 모델은 서로 다른 각도의 정보를 연결해 코드로 생성할 수 있는 기하 표현으로 바꿔야 합니다.

지표는 Voxel IoU로, 생성 형상과 기준 형상이 복셀 공간에서 얼마나 겹치는지 측정합니다. 형상 유사도를 나타내며 제작에 바로 쓸 수 있는 자산의 비율은 아닙니다. 그럴듯한 이미지를 만드는 일보다는 객체 구조를 복원하는 일에 가깝습니다.

3D 사례를 볼 때도 이 구분이 도움이 됩니다. 렌더링은 한 카메라에서 본 표면을 보여 주지만, 편집 가능한 모델에는 부품 관계, 치수, 시점이나 매개변수가 바뀌어도 일관성을 유지할 구성 방식이 들어 있습니다. Moonshot은 3D 설명에서 부품, 건축, 구성을 바꿀 수 있는 객체의 파라메트릭 모델링을 강조합니다.

보이는 형상에서 편집 가능한 자산으로

개별 자산은 세 가지 측면에서 살펴볼 수 있습니다.

관찰 측면확인할 내용
전체 형상윤곽, 비율, 공간 배치
세부 구조연결, 가림, 대칭, 세부 요소
실제 활용원본 파일, 치수, 토폴로지, 내보내기 결과

자산 검토 항목: 이 글에서 정리했습니다.

공식 3D 사례를 출발점으로 삼아 객체를 회전시키며 뒷면과 숨은 연결을 확인하고, 겹치는 부품과 반복 세부 요소를 확대해 볼 수 있습니다.

기계 객체라면 연결 부품이 제자리에서 맞닿는지, 치수를 바꿔도 관계가 유지되는지를 확인하면 좋습니다. 건축 장면에서는 반복 구성 요소, 개구부, 공간 배치를 살펴봅니다. 이런 검사는 한 시점에서 가려질 수 있는 교차나 누락된 연결을 드러내는 데 도움이 됩니다.

전달 형식도 중요합니다. 미리보기는 외관 검토를, 편집 파일은 후속 수정을, 내보내기 파일은 다른 도구에서의 활용을 지원합니다. 작업을 시작할 때 원하는 형식을 정하면 보기 좋은 전시물과 다른 사람이 실제로 이어서 작업할 수 있는 자산을 구분하기 쉽습니다.

데이터 분석: Plotly의 42/43과 그룹 분류 오류

Plotly는 합성 풍력발전단지 데이터와 비공개 질문 43개로 K3.1 Pro를 테스트했습니다. 벤치마크 설명에 따르면 에이전트는 Plotly Studio Embedded에서 2,000만 행 규모의 데이터 웨어하우스를 다룹니다. 질문에는 일반 분석, 모호한 요청, 답할 수 없는 요청, 통계 함정, 데이터 품질, 숨은 패턴이 포함됩니다.

모델은 42개를 통과했으며, 숨은 패턴 질문 다섯 개와 데이터 품질 질문 세 개를 모두 맞혔습니다.

질문에서 직접 언급하지 않은 문제 찾기

데이터 품질 사례에서 K3.1 Pro는 중복 행과 월말 마지막 날의 누락을 찾았고, 퇴역해서 데이터가 없는 터빈과 실제 발전량이 0인 터빈을 구분했다고 Plotly는 보고했습니다. 단순 집계에서는 비슷해 보여도 서로 다른 데이터 상태입니다.

퇴역 터빈 한 기의 짧은 이력으로 신뢰할 만한 연간 고장률을 구하라는 불가능한 요청에는 터빈군 전체의 비율을 대신 제시했습니다. 실제 분석에서는 답할 수 있는 질문으로 바꾸는 일도 쿼리를 작성하는 일만큼 유용할 수 있습니다. 출처: Plotly 사례 설명.

숨은 패턴 질문에는 정확히 무엇을 찾아야 하는지 지시받지 않은 상태에서 관계를 조사하는 작업도 필요합니다. 앞선 쿼리에서 발견한 내용에 따라 다음 쿼리를 정하는 탐색적 분석과 관련 있는 결과입니다.

작은 그룹 분류 오류가 답을 바꾸는 방식

실패한 질문은 특정 펌웨어 버전과 다른 펌웨어를 비교하는 것이었습니다. K3.1 Pro는 펌웨어 설치 이전의 터빈·일 단위 기록 2,775개를 ‘다른 펌웨어’ 그룹에 넣었습니다. 출처: Plotly 데이터 분석 평가.

이렇게 하면 비교 모집단이 바뀝니다. 아예 펌웨어가 없는 기록이 섞여 있다면 ‘이 펌웨어를 쓰지 않음’과 ‘다른 펌웨어를 사용함’은 다른 그룹입니다. 설치 전 상태의 기록을 추가하는 순간 통계 검정을 적용하기도 전에 비교 기준이 달라집니다.

따라서 분석 방법이 꼼꼼해 보여도 이미 다른 질문에 답하고 있을 수 있습니다. 검토는 모집단부터 시작하는 것이 좋습니다. 어떤 기록이 각 그룹에 들어갔는지, 무엇이 제외됐는지, 이 데이터에서 결측값은 무엇을 뜻하는지 봅니다. 그런 다음 계산과 설명문이 실제 필터에 부합하는지 확인합니다. 그룹이 업무 정의와 일치해야 계산도 의도한 질문에 답합니다.

금융 모델과 조사 결과물

Moonshot AI가 공개한 NVDA 모델링 워크북의 분기별·연도별 재무 요약 시트
Moonshot AI가 공개한 NVDA 모델링 워크북의 재무 요약 페이지. Moonshot AI원본 크기로 보기 ↗
Moonshot의 공개 샘플에는 NVDA 모델링 워크북, CATL 발표 자료, 양자 산업 보고서가 있습니다. 조사 내용을 열어 확인할 수 있는 스프레드시트, 슬라이드, 보고서로 구성하는 방식을 보여 줍니다.

NVDA 화면에는 분기별·연도별 열과 매출, 이익, 이익률, 희석 주당순이익이 함께 보입니다. 재무 요약 페이지의 유용성은 주요 수치를 그 뒤의 가정과 보조 시트까지 얼마나 쉽게 연결할 수 있는지에 달려 있습니다.

모델링 워크북에서는 예측 하나를 골라 가정에서 수식 참조를 거쳐 요약까지 따라가 봅니다. 회계 기간이 맞는지, 가정을 바꾸면 의도한 출력이 갱신되는지 확인합니다. 보고서나 발표 자료에서는 중요한 주장을 출처까지 추적하고, 차트와 문장 결론이 같은 기간과 정의를 쓰는지 봅니다.

이 파일들은 조사 결과 전달이 긴 답변 생성보다 넓은 작업이라는 점도 보여 줍니다. 워크북에는 수치 의존 관계가 있고, 슬라이드에는 명확한 논증 순서가 필요하며, 보고서의 결론에는 추적 가능한 근거가 있어야 합니다. 다른 사람이 검토하고 수정할 수 있는 형식으로 이런 관계를 정리하는 것도 모델의 역할입니다.

이미지·동영상 이해: 실무 확인 항목

공식 시각 입력 가이드에 따르면 K3.1 Pro는 이미지와 동영상 입력을 지원합니다. 유용한 확인 항목은 애플리케이션에 따라 달라집니다.
  • 차트에서는 수치, 단위, 통계 정의를 함께 확인합니다.
  • 공간 과제에서는 객체의 위치와 관계를 확인합니다.
  • 동영상에서는 프레임 사이의 동작 순서와 상태 변화를 테스트합니다.

차트 과제는 읽기와 해석의 차이를 보여 줍니다. 한 계열의 단위, 기간, 모집단이 다르다면 수치 두 개를 추출하는 것은 시작일 뿐입니다. 유용한 답변은 값을 올바른 축, 범례, 주변 설명에 연결해야 합니다.

입력에도 구체적인 요구 사항이 있습니다. Kimi 기본 API는 멀티모달 content를 메시지 부분의 배열로 받고, 이미지는 base64나 업로드한 파일 참조로 전달합니다. 가이드는 동영상 처리를 키프레임 기준으로 설명하며, 프레임 수와 해상도가 입력 크기에 영향을 줍니다. 자세한 내용은 시각 입력 가이드에 있습니다.

동영상은 고장 전에 무엇이 달라졌는지, 어떤 동작이 먼저였는지처럼 단일 프레임보다 순서가 답을 결정하는 사례를 고르는 것이 좋습니다. 여기서 다룬 공개 테스트는 코딩과 데이터 작업에 집중되어 있습니다. 시각 애플리케이션에는 실제로 인식해야 할 사건과 세부 사항에 맞는 자체 사례가 필요합니다.

추론 지연: 최종 답변까지 기다리는 시간

K3.1 Pro의 기본 API 문서는 추론 단계를 low, high, max로 구분하며, 기본값은 max이고 사고 모드는 항상 켜져 있습니다. 스트림은 추론과 최종 답변을 나누어 반환합니다. 출처: 공식 빠른 시작.

2026년 10월 24일 AIHubMix는 해시맵 설명과 Python 코드를 요청하는 프롬프트 하나로 표준 Pro를 low에서 세 번 실행했습니다. 첫 추론 토큰과 첫 최종 답변 토큰까지의 대기 시간은 크게 달랐습니다.

첫 추론 토큰과 첫 최종 답변 토큰까지의 대기 시간

표준 Pro · 프롬프트 하나 · low · 세 번 실행

첫 추론 토큰
3.6–4.5 초
첫 최종 답변 토큰
71–91 초

요청 시작 후 경과 시간(초)

구간은 세 번의 실행에서 관측한 범위이며 단일 요청의 시간 흐름이 아닙니다. 출처: AIHubMix, 2026-10-24.

이 실행들에서는 완료 토큰의 약 85%–90%가 추론이었으며, 한 번은 완료 토큰 상한인 8,192개에 도달했습니다. 따라서 최종 답변만 표시하는 화면은 모델이 이미 추론을 스트리밍하고 있어도 멈춘 것처럼 보일 수 있습니다.

스트림 진행과 사용할 수 있는 답변

경험을 설명하는 시간은 세 가지입니다. 스트림이 시작되는 시점, 최종 답변 본문이 시작되는 시점, 응답이 완료되는 시점입니다. 연결이 정상이어도 사용자는 쓸 수 있는 답을 기다릴 수 있습니다. 첫 토큰 시간이 짧다는 사실만으로 전체 대기 시간을 설명할 수는 없습니다.

대화형 애플리케이션에서는 실제 사용자의 프롬프트로 세 시점을 모두 측정해야 합니다. 추론 단계와 완료 제한도 기록해 빠르지만 잘린 응답과 완성된 답변을 구분합니다. 백그라운드 작업에서는 첫 글자가 나타나는 속도보다 최종 품질과 총 소요 시간이 더 중요할 수 있습니다.

Kimi 기본 스트림은 추론 증분에 reasoning_content, 최종 답변 증분에 content를 사용합니다. 애플리케이션은 처리 상태와 표시하거나 파싱할 답변을 구분할 수 있습니다. 여러 턴의 도구 워크플로에서는 빠른 시작이 최종 답변만 남기지 말고 전체 assistant 메시지와 대응하는 도구 결과를 보존하도록 요구합니다.

이렇게 시간 측정은 에이전트의 행동과 연결됩니다. 애플리케이션은 도구 요청, 반환된 관찰, 최종 답변을 포함하는 진행 중인 작업을 관리합니다. 추론 단계는 그 과정의 조절 항목 하나이며, 검증과 메시지 처리도 결과를 올바르게 전달하는 데 영향을 줍니다.

Kimi K3.1 Pro가 적합한 작업

사례마다 우선해서 볼 항목이 다릅니다.

능력공개 근거가 뒷받침하는 내용남아 있는 한계
코딩과 장시간 작업코드 수정 완료와 지속적인 디버깅큰 프로젝트의 신뢰성은 목표 환경에서 검증해야 함
3D와 공간 추론도구를 활용한 장면과 객체 구성형상 겹침만으로 토폴로지나 내보내기 품질을 판단할 수 없음
데이터 분석과 조사Plotly 전문 테스트의 좋은 성적그룹 분류 규칙과 가정은 여전히 틀릴 수 있음
시각 이해공식 이미지·동영상 입력 지원이 테스트로 전문 시각 과제의 정확도를 판단할 수 없음
추론과 실행상당한 추론과 도구 사용추가 노력이 지연을 늘려도 측정 결과를 개선하지 못할 수 있음

앞에서 살펴본 출처를 정리한 표입니다.

먼저 평가할 수 있는 코드 수정이나 데이터 분석 작업으로 시작합니다. 수정 과제는 원래 실패 사례를 보관하고 최종 diff를 봅니다. 분석은 정답이 알려진 사례를 준비하고 결측이나 예외 상태를 포함합니다. 3D 결과물은 미리보기를 보기 전에 원본과 내보내기 형식을 합의합니다.

최종 품질, 실행 시간, 도구 호출, 토큰 사용량을 비교한 다음 구조가 덜 정해진 작업으로 넓혀 갑니다. Atomic의 low/max 비교, PacBench의 브라우저 검증 빈틈, Plotly의 분류 오류는 각각 구체적인 검사 항목으로 바꿀 수 있습니다. 이를 통해 평가를 모델이 실제로 수행할 일과 연결할 수 있습니다.

모델 선택지와 현재 요금은 EvoLink의 Kimi K3.1 Pro를 확인하세요. 출시 배경은 출시 소개, 업그레이드 판단은 K3.1 Pro와 K3 비교에서 다룹니다.

자주 묻는 질문

Kimi K3.1 Pro로 편집 가능한 3D 모델을 만들 수 있나요?

공식 사례는 Blender나 CAD 도구로 모델을 구성하고 확인하며 내보냅니다. 편집 가능한 결과물이 필요하면 렌더링과 함께 원본 파일을 요청하고, 치수·토폴로지·조립 관계를 요구 사항에 맞춰 확인하세요. 공식 3D 사례를 참고할 수 있습니다.

코딩에는 low와 max 중 무엇을 써야 하나요?

대표적인 작업 집합으로 먼저 비교하세요. Atomic Agent의 Python 실험에서는 같은 검증을 통과했고, low는 평균 2.2분·19회 호출, max는 4.9분·28회 호출을 사용했습니다. 더 높은 단계가 패치 품질이나 통과율을 개선해 추가 시간과 사용량을 정당화할 때 높이는 것이 좋습니다.

Kimi K3.1 Pro가 스트리밍 중인데 최종 답변이 없는 이유는 무엇인가요?

추론 증분과 최종 답변 증분은 따로 도착합니다. 클라이언트가 최종 답변만 표시하면 진행 중인 출력을 숨길 수 있습니다. 어떤 증분이 도착하는지, 스트림이 정상인지, 완료 제한에 도달했는지 확인하세요. 기본 스트리밍 가이드와 사용하는 게이트웨이 문서도 확인해야 합니다.

Plotly에서 42/43을 통과했다면 조사 결론을 바로 써도 되나요?

Plotly의 합성 풍력발전 데이터에서 얻은 좋은 결과입니다. 틀린 펌웨어 문제는 모집단과 그룹 분류 규칙을 여전히 검토해야 하는 이유를 보여 줍니다. 다른 데이터에서는 결측값, 기간, 수식, 출처를 확인한 뒤 결론을 사용해야 합니다.

통합 API로 AI 모델 연동하기

모델 기능과 현재 요금을 비교한 뒤 API 문서에 따라 작업에 맞는 모델을 연동하세요.