딥시크, 실험판 비전 모델 공개… 세 가지 이미지 입력 방식과 384토큰 상한

딥시크가 이미지와 텍스트를 함께 처리하는 실험판 모델 deepseek-v4-flash-vision-exp의 사용 가이드를 공개했다. 이 모델은 사진 묘사, 스크린샷 속 텍스트 판독, 차트 분석 같은 작업을 텍스트 프롬프트와 결합해 수행할 수 있다. 이름에 붙은 exp(experimental)가 시사하듯 아직 실험 단계지만, 인터페이스 설계는 이미 시장에서 사실상 표준이 된 OpenAI 호환 규격을 그대로 따르고 있어 기존 코드베이스에 얹기 쉽다는 점이 눈에 띈다.

지원 이미지 형식은 JPEG, PNG, GIF, WebP 네 가지다. 여기서 실무자가 주의할 대목은 형식 판별 기준이다. 딥시크는 파일 이름이나 요청에 선언된 MIME 타입이 아니라 실제 파일 내용을 검사해 형식을 결정한다. 확장자만 png로 바꿔 놓은 파일이나 잘못 지정된 Content-Type 때문에 생기는 흔한 오류를 피할 수 있는 반면, 서버가 실제 바이트를 읽어 형식을 확정하므로 클라이언트 쪽에서 헤더만 손봐서는 동작을 우회할 수 없다는 뜻이기도 하다.

세 가지 이미지 입력 경로

이미지를 모델에 전달하는 방법은 세 가지로 정리된다. 첫째는 이미지를 base64로 인코딩해 data: URL 형태로 요청 본문에 직접 삽입하는 방식으로, 로컬 파일을 다룰 때 가장 간단하다. 둘째는 공개적으로 접근 가능한 http(s) 링크를 넘겨 모델이 직접 내려받게 하는 방식이다. 셋째는 Files API로 이미지를 한 번 업로드한 뒤 반환된 file_id(file-api-로 시작하는 식별자)를 여러 요청에서 재사용하는 방식이다. 세 방법 모두 content가 문자열이 아니라 블록 배열로 구성되는 OpenAI 호환 Chat Completions 포맷을 쓰며, 기준 base_url은 https://api.deepseek.com이다.

각 경로에는 서로 다른 용량 제약이 걸린다. base64나 file_data로 본문에 실어 보내는 인라인 이미지는 48MiB의 요청 본문 크기 한도에 포함된다. 외부 URL 방식은 링크가 최대 8192자, 이미지 파일이 최대 32MiB여야 하고 다운로드가 60초 안에 끝나야 한다. Files API로 올린 이미지는 이러한 32MiB 개별 이미지 검사를 받지 않고 최대 64MiB까지 허용된다. 따라서 같은 이미지를 여러 요청에 반복 사용하거나, 인라인으로는 본문 한도를 넘길 만큼 큰 이미지를 다룰 때는 Files API가 유리하다. 참고로 file 블록은 file_id와 file_data(인라인 base64)를 상호 배타적으로 받으며, 둘을 동시에 지정할 수는 없다.

리사이즈와 384토큰 상한

과금과 성능 예측 측면에서 가장 실무적인 정보는 토큰 계산 규칙이다. 이미지는 크기에 따라 토큰으로 변환되어 텍스트 토큰과 함께 청구되는데, 추론에 앞서 모든 이미지가 자동으로 리사이즈된다. 그 결과 이미지 한 장당 토큰은 384개를 상한으로 한다. 예컨대 2000×2000 이미지와 5000×5000 이미지는 리사이즈 후 동일한 토큰을 소비한다. 여러 장을 한 요청에 담아도 각 이미지가 같은 규칙으로 독립 계산될 뿐, 다중 이미지에 대한 별도 산식은 없다. 특정 크기의 토큰 비용을 미리 가늠하려면 문서의 토큰 계산기를 활용하면 된다. 이 상한은 초고해상도 원본을 그대로 넣어도 비용이 무한정 늘지 않는다는 예측 가능성을 주지만, 동시에 아주 세밀한 텍스트나 미세한 디테일은 리사이즈 과정에서 손실될 수 있음을 의미한다. detail 필드로 low·high·original·auto 등 처리 방식을 지정할 수 있으나, file_id로 이미지를 넘긴 경우 detail은 무시된다.

앤트로픽 호환 경로와 제약

딥시크는 OpenAI 호환 엔드포인트 외에도 앤트로픽 호환 /messages 엔드포인트(base_url은 https://api.deepseek.com/anthropic)를 통한 이미지 전송을 지원한다. 차이는 이미지 콘텐츠 블록의 형태뿐이다. 앤트로픽 규격에서는 image_url 대신 source 객체를 가진 image 블록을 쓰며, source의 type이 base64·url·file 중 하나로 앞선 세 가지 방식과 그대로 대응된다. 같은 세 입력 방식과 동일한 한도는 OpenAI 호환 Responses API에도 적용되고, 이 경우 이미지는 input_image 파트에 담긴다.

실무에 곧바로 반영해야 할 제약도 있다. Responses API에서 image_url과 file_id는 상호 배타적이며, 시스템 메시지나 어시스턴트 메시지에 이미지를 넣으면 400 오류로 거부된다. 즉 이미지는 사용자 또는 개발자 메시지, 그리고 도구 출력 항목을 통해서만 전달해야 한다. 정리하면, 이 모델은 표준 규격 위에서 세 갈래 입력 경로와 명확한 용량·토큰 규칙을 제공해 통합 자체는 수월한 편이지만, 384토큰 상한에 따른 해상도 손실과 메시지 위치 제약은 기획 단계에서 미리 고려해 둘 필요가 있다. 아직 실험판인 만큼 사양이 바뀔 여지가 있다는 점도 감안하는 편이 안전하다.