발표에서 확인된 핵심 사실

32 MiB에 묶여 있던 인라인 이미지 처리 용량이 최대 64 MiB까지 확대됐다. 요청 본문의 48 MiB 제한을 초과하는 고해상도 데이터를 전송해야 하는 환경에서 데이터 처리 방식이 바뀐다. 대용량 파일을 다루는 기업이 API 요청 효율을 높일 수 있는 조건이다.

deepseek-v4-flash-vision-exp 모델은 텍스트와 이미지를 동시에 처리하는 멀티모달 기능을 제공한다. 사용자는 모델에게 사진 설명을 요청하거나 스크린샷 내 텍스트 읽기, 차트 분석 등을 수행하게 할 수 있다. 지원하는 이미지 형식은 JPEG, PNG, GIF, WebP다. 파일 이름이나 선언된 MIME 타입이 아니라 실제 파일 콘텐츠를 분석해 형식을 감지한다.

Files API(파일 관리 인터페이스)를 사용하면 더 큰 용량의 이미지 처리와 효율적인 재사용이 가능하다. 동일한 이미지를 여러 요청에서 반복해서 참조하는 작업에 가장 적합한 옵션이다. 인라인 이미지에 적용되는 32 MiB당 이미지 체크 제약을 받지 않는다. file_id를 통해 참조되는 이미지는 최대 64 MiB까지 지원한다.

이미지를 모델에 제공하는 세 가지 방법(데이터 URL

데이터 URL이나 HTTP 링크, 혹은 파일 업로드 방식을 선택해 이미지를 입력한다. 이미지를 base64로 인코딩하여 data: URL 형태로 요청에 직접 삽입하는 방식이 있다. 공개적으로 접근 가능한 http(s) 링크를 전달하면 모델이 해당 이미지를 직접 다운로드하여 처리한다. Files API(파일 업로드 및 관리 인터페이스)를 통해 이미지를 한 번 업로드한다. 이후 요청에서는 생성된 file_id를 참조해 이미지를 호출한다. 사용자는 전송하려는 이미지의 공개 여부와 데이터 용량에 따라 세 가지 입력 경로 중 하나를 선택한다.

두 회사의 API 엔드포인트를 모두 지원해 통합 유연성을 높였다. OpenAI 호환 Chat Completions API를 통해 이미지를 처리할 수 있다. Responses API 역시 OpenAI 호환 규격으로 지원하여 기존 환경을 유지하게 한다. Anthropic 호환 /messages 엔드포인트를 통한 이미지 전송도 가능하다. Anthropic 방식은 image_url 필드를 사용하지 않는다. 대신 base64, url, file 타입을 가진 source 객체를 사용하는 이미지 블록 구조를 취한다. 서로 다른 API 규격을 동시에 수용해 개발자의 전환 비용을 제거했다.

이미지는 크기에 따라 토큰으로 변환되며, 이미지당 최대

2000×2000 이미지와 5000×5000 이미지는 동일한 수의 토큰을 소비하며 비용 차이를 만들지 않는다. 모든 이미지는 모델의 추론이 본격적으로 수행되기 전 자동으로 리사이징 과정을 거친다. 이미지 한 장당 소비되는 토큰의 최대치는 384개로 제한된다. 이렇게 변환된 이미지 토큰은 텍스트 토큰과 함께 묶여 비용이 청구된다. 이미지의 물리적 해상도가 매우 높더라도 토큰 소비량은 상한선 내에서 고정되어 비용 예측이 가능하다.

`image_url` 입력을 사용할 때는 `input_image` 파트 내의 `detail` 필드를 설정해 이미지 처리 방식을 직접 제어한다. 사용자는 low, high, original, auto 중 하나의 옵션을 선택해 처리 수준을 결정할 수 있다. 반면 `file_id`를 통해 이미지를 제공하는 경우에는 `detail` 필드 설정이 적용되지 않고 무시된다. 사용자가 선택한 입력 인터페이스의 종류에 따라 이미지 처리 세부 제어권의 유무가 결정된다.

Base64의 요청 바디 48MiB, URL의 파일 32MiB, Files API의 파일 64MiB 제한 수치를 기준으로 API 호출 전략을 결정한다.