DeepSeek-V4.1-Flash Vision API: วิธีส่งรูปภาพไปยังโมเดล Multimodal ของ DeepSeek

การรองรับวิชันของ DeepSeek สิ้นสุดการเป็นโครงการเสริมในวันที่ 10 กันยายน 2026 ด้วยการเปิดตัว DeepSeek-V4.1-Flash อย่างเป็นทางการ (GA release) การป้อนรูปภาพจะรวมอยู่ในโมเดลหลักภายใต้ ID เดียวคือ deepseek-flash ไม่มีเวอร์ชันวิชันแยกต่างหากและไม่มีคำต่อท้าย “Exp” บันทึกการเผยแพร่ ได้ยกเลิกทั้ง deepseek-v4-flash และ deepseek-v4-flash-vision-exp โดยการร้องขอที่ใช้ชื่อใดชื่อหนึ่งในตอนนี้จะถูกส่งไปยัง V4.1-Flash

เรื่องนี้สำคัญหากคุณพัฒนาโดยใช้ endpoint ทดลองเมื่อสามสัปดาห์ก่อน รูปแบบการร้องขอที่คุณเขียนเพื่อใช้งาน V4-Flash-Vision-Exp ยังคงใช้งานได้ แต่โมเดลที่ใช้อ่านรูปภาพของคุณเป็นโมเดลใหม่: มีพารามิเตอร์ 763B พร้อมตัวเข้ารหัสวิชันที่ได้รับการฝึกฝนตั้งแต่เริ่มต้นพร้อมกับโครงสร้างหลักของข้อความ คู่มือนี้ครอบคลุมความหมายของ “multimodal แบบเนทีฟ” ในทางปฏิบัติ วิธีการส่งรูปภาพสามวิธี พารามิเตอร์ detail ค่าใช้จ่ายของรูปภาพ และวิธีการสร้างการทดสอบวิชันที่ทำซ้ำได้ใน Apidog ซึ่งพิสูจน์ว่าชื่อเดิมและชื่อใหม่ทำงานในลักษณะเดียวกัน

สรุป

• ID โมเดล: deepseek-flash ชื่อเดิม deepseek-v4-flash-vision-exp ยังคงใช้งานได้ แต่จะถูกให้บริการโดย V4.1-Flash
• รูปภาพจะอยู่ในอาร์เรย์ content ของข้อความผู้ใช้: เป็น Base64 data URL (สูงสุด 32 MiB), external URL (สูงสุด 8,192 ตัวอักษร) หรือ file ID
• ฟิลด์ detail (ไม่บังคับ): low, high (หรือ original), หรือ auto
• เกณฑ์มาตรฐานวิชันตามที่ DeepSeek รายงาน: MMMU-Pro 56.5, CVBench 77.9, DocVQA 95.6, RefCOCO 86.0
• ราคาเป็นอัตรา Flash มาตรฐาน: $0.15 ต่อ 1 ล้านโทเค็นอินพุตแบบ cache-miss ในช่วงนอกเวลาทำการ, $0.30 ในช่วงเวลาทำการ
• Context คือ 1M โทเค็น, เอาต์พุตสูงสุด 384K, เท่ากับการเรียกใช้งานแบบข้อความเท่านั้น

“Multimodal แบบเนทีฟ” ในที่นี้หมายถึงอะไร

Vision-Exp ได้เชื่อมต่อตัวเข้ารหัสรูปภาพเข้ากับโมเดลข้อความที่เสร็จสมบูรณ์ แต่ V4.1-Flash ทำในทางตรงกันข้าม ตาม การ์ดโมเดล รูปภาพเป็นส่วนหนึ่งของคลังข้อมูลการฝึกอบรมล่วงหน้า 45 ล้านล้านโทเค็นตั้งแต่เริ่มต้น และตัวเข้ารหัสคือ DeepSeek-ViT ใหม่ที่ได้รับการฝึกฝนตั้งแต่เริ่มต้น แทนที่จะยืมมาจากโมเดลวิชันที่มีอยู่ โครงสร้างหลักคือโมเดล Mixture-of-Experts ขนาด 552 พันล้านพารามิเตอร์; เมื่อเชื่อมต่อตัวเข้ารหัสแล้ว จะมีทั้งหมด 763 พันล้านพารามิเตอร์ มีเพียง 8 พันล้านพารามิเตอร์เท่านั้นที่ทำงานในระหว่างการประมวลผลเบื้องต้น (prefill) และ 16 พันล้านในระหว่างการถอดรหัส (decode) ซึ่งเป็นสาเหตุที่ทำให้โมเดลขนาดใหญ่เช่นนี้ยังคงทำงานด้วยความเร็วและราคาแบบ Flash ได้ V4-Flash ซึ่งเป็นโมเดลที่รองรับเฉพาะข้อความใน คู่มือ API V4-Flash เป็นพื้นฐานที่ Vision-Exp ได้ต่อยอด

DeepSeek รายงานคะแนนวิชันทั้งสี่นี้ในการ์ดโมเดล เป็นการวัดผลของทางผู้ให้บริการเอง ดังนั้นควรพิจารณาเป็นข้อกล่าวอ้างจนกว่าคุณจะทดสอบเอกสารของคุณผ่าน API ด้วยตนเอง

สำหรับผู้ใช้งาน API, DocVQA และ RefCOCO คือแถวที่ควรจับตามอง การตอบคำถามเอกสาร (Document QA) คือคะแนนเบื้องหลังการดึงข้อมูลจากใบแจ้งหนี้และแบบฟอร์ม RefCOCO คือการระบุตำแหน่ง: หากได้รับคำสั่งว่า “ปุ่ม Submit ที่อยู่ใต้ช่องอีเมล” โมเดลจะหามันเจอหรือไม่? ทักษะนี้จะเปลี่ยนภาพหน้าจอเป็นการกระทำของเอเจนต์ ภาพรวมสถาปัตยกรรม ครอบคลุมด้านข้อความและรายงานทางเทคนิคในรายละเอียดเพิ่มเติม

รูปแบบการร้องขอ: สามวิธีในการส่งรูปภาพ

ไม่มีการเปลี่ยนแปลงใดๆ เกี่ยวกับรูปแบบการสื่อสาร เรียกใช้ endpoint Chat Completions ที่ https://api.deepseek.com ด้วย OpenAI SDK, ใส่ส่วนข้อความและรูปภาพในอาร์เรย์ content เดียวกัน และตั้งค่าโมเดลเป็น deepseek-flash นี่คือการเรียกใช้งานเต็มรูปแบบที่แปลงใบแจ้งหนี้เป็น JSON:

import base64, json
from openai import OpenAI

client = OpenAI(api_key="YOUR_DEEPSEEK_KEY", base_url="https://api.deepseek.com")

with open("invoice-2026-0912.png", "rb") as f:
    image_b64 = base64.b64encode(f.read()).decode()

schema_hint = (
    "Return only JSON with keys: invoice_number (string), issue_date (YYYY-MM-DD), "
    "vendor (string), currency (string), line_items (array of {description, quantity, "
    "unit_price, amount}), subtotal, tax, total (numbers)."
)

response = client.chat.completions.create(
    model="deepseek-flash",
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": schema_hint},
            {
                "type": "image_url",
                "image_url": {
                    "url": f"data:image/png;base64,{image_b64}",
                    "detail": "high",
                },
            },
        ],
    }],
    temperature=1.0,
    max_tokens=2048,
)

invoice = json.loads(response.choices[0].message.content)
print(invoice["invoice_number"], invoice["total"])
print(response.usage.prompt_tokens, "prompt tokens")

นั่นคือตัวเลือกแรก, Base64 แบบ inline: เป็นแบบครบวงจร, จำกัดขนาดสูงสุด 32 MiB ต่อรูปภาพ, และเหมาะสมสำหรับการเรียกใช้ครั้งเดียวหรือไฟล์ที่ไม่เคยออกจากเครือข่ายของคุณ

ตัวเลือกที่สองคือ External URL หากรูปภาพมีลิงก์สาธารณะอยู่แล้วบน CDN หรือใน object storage ให้ข้ามการเข้ารหัสและส่งผ่านลิงก์นั้นได้เลย (สูงสุด 8,192 ตัวอักษร) คำสั่ง curl นี้จะอ่านแผนภูมิราคาที่โฮสต์ไว้:

curl https://api.deepseek.com/chat/completions \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-flash",
    "messages": [{
      "role": "user",
      "content": [
        {"type": "text", "text": "List every plan name and its monthly price from this chart as a JSON array."},
        {"type": "image_url", "image_url": {"url": "https://assets.example-saas.com/pricing/plans-q3.png", "detail": "auto"}}
      ]
    }]
  }'

ตัวเลือกที่สามคือ File ID อัปโหลดรูปภาพหนึ่งครั้งผ่าน DeepSeek’s Files API จากนั้นอ้างอิงถึงมันด้วยส่วน file แทนที่จะส่งข้อมูลไบต์ซ้ำ:

{"type": "file", "file": {"file_id": "file-api-xxxxxxxxxxxxxxxx"}}

เลือกใช้ File ID เมื่อใดก็ตามที่รูปภาพเดียวกันปรากฏในการร้องขอมากกว่าหนึ่งครั้ง เช่น ภาพหน้าจออ้างอิงที่ใช้ในการเปรียบเทียบในทุกการทดสอบในชุด การอธิบายพารามิเตอร์ทั้งหมดอยู่ใน คู่มือ API V4.1-Flash

พารามิเตอร์ detail และข้อจำกัดในการร้องขอ

detail เป็นพารามิเตอร์เสริมและอยู่ในออบเจกต์ image_url ค่าสามค่าที่สืบทอดมาจาก Vision-Exp:

• "low" จะลดขนาดภาพลงเหลือ 512x512 ราคาถูกที่สุดและเร็วที่สุด; เหมาะสำหรับคำถามประเภท "นี่คือแดชบอร์ดหรือใบเสร็จ"
• "high" (หรือ "original") จะรักษารูปภาพความละเอียดต้นฉบับไว้ ใช้สำหรับเอกสารที่มีข้อมูลหนาแน่น, ตัวอักษรขนาดเล็ก, และภาพหน้าจอ UI ที่ป้ายกำกับขนาด 12px มีความสำคัญ
• "auto" ให้ API เลือกเอง

ข้อจำกัดที่คุณจะพบเป็นอันดับแรก:

คู่มือ Vision-Exp ระบุข้อจำกัดเพิ่มเติมเกี่ยวกับจำนวนรูปภาพ, ขนาดเนื้อหา (body size), และขนาดพิกเซล ข้อจำกัดเหล่านั้นถูกเผยแพร่สำหรับโมเดลทดลอง; โปรดตรวจสอบ บันทึกการเปลี่ยนแปลงของ API ก่อนที่จะนำไปใช้กับ V4.1-Flash กฎข้อหนึ่งที่ยังไม่เปลี่ยนแปลงคือ: รูปภาพควรอยู่ในข้อความของผู้ใช้ (user messages) หากใส่รูปภาพในข้อความระบบหรือข้อความผู้ช่วย คุณจะได้รับข้อผิดพลาด 400

ค่าใช้จ่ายของรูปภาพบน deepseek-flash

ไม่มีราคาสำหรับวิชันแยกต่างหาก รูปภาพจะถูกคิดค่าบริการเป็นโทเค็นอินพุตในอัตรา Flash จาก หน้าการกำหนดราคา ซึ่งมีผลตั้งแต่วันที่ 10 กันยายน 2026 เวลา 04:00 UTC:

ช่วงเวลาทำการคือวันจันทร์ถึงศุกร์ เวลา 01:00 ถึง 04:00 และ 06:00 ถึง 10:00 UTC; นอกเวลาทำการคิดราคาครึ่งหนึ่ง ใน Vision-Exp รูปภาพแต่ละภาพจะถูกคิดค่าบริการไม่เกิน 384 โทเค็นอินพุต การที่ข้อจำกัดนี้ยังคงใช้ได้กับ V4.1-Flash โดยไม่มีการเปลี่ยนแปลงหรือไม่นั้น [ตรวจสอบ] กับเอกสารอีกครั้ง usage.prompt_tokens ของการตอบกลับทุกครั้งจะรายงานจำนวนจริง ซึ่งเป็นเหตุผลที่ตัวอย่าง Python พิมพ์ค่านั้นออกมา

หากข้อจำกัด 384 โทเค็นยังคงอยู่ รูปภาพหนึ่งภาพจะมีค่าใช้จ่ายประมาณ $0.000115 ในอัตรา cache-miss สูงสุด และครึ่งหนึ่งในช่วงนอกเวลาทำการ ดังนั้นใบแจ้งหนี้หนึ่งพันฉบับจะมีค่าใช้จ่ายประมาณ $0.12 สำหรับอินพุตรูปภาพ เอาต์พุตมีบทบาทสำคัญในไปป์ไลน์จริง: JSON 400 โทเค็นต่อใบแจ้งหนี้มีค่าใช้จ่ายประมาณสี่เท่าของตัวรูปภาพเองในช่วงเวลาทำการ ปัจจัยสำคัญคือโครงสร้างการตอบกลับที่กระชับ ไม่ใช่การลดขนาดรูปภาพ การคำนวณราคาช่วงเวลาทำการ, นอกเวลาทำการ, และ cache-hit ได้อธิบายไว้ใน การอธิบายราคา DeepSeek-V4.1-Flash; สรุปสั้นๆ คืออินพุตแบบ cache-miss ถูกกว่าที่ Vision-Exp คิดค่าบริการในเดือนสิงหาคม 32%

สามกรณีการใช้งานที่ควรนำร่อง

• การดึงข้อมูลจากเอกสาร ใบแจ้งหนี้, ใบเสร็จ, บันทึกการจัดส่ง, แบบฟอร์มประกันภัย กำหนด JSON schema แบบตายตัว, ส่งด้วย detail: "high", และตรวจสอบว่ารายการรวมกันเป็นยอดรวมย่อยก่อนที่คุณจะเชื่อถือข้อมูล
• ภาพหน้าจอ UI สำหรับการทดสอบ assertions จับภาพหน้าจอหลังจากปรับใช้, ถามว่าองค์ประกอบที่คาดหวังปรากฏอยู่หรือไม่และอยู่ที่ใด, และเปลี่ยนคำตอบเป็นการผ่าน/ไม่ผ่าน RefCOCO คือเกณฑ์มาตรฐานที่เกี่ยวข้อง: งานคือการค้นหาองค์ประกอบที่มีชื่อ
• การอ่านแผนภูมิ ดึงชื่อชุดข้อมูล, ป้ายแกน, และค่าที่พล็อตออกมาจากรูปภาพแผนภูมิลงในตาราง เส้นที่ทับซ้อนกันหรือแกนที่ไม่มีป้ายกำกับจำเป็นต้องมีการตรวจสอบด้วยสายตามนุษย์

การทดสอบ Vision Endpoint ใน Apidog

การร้องขอวิชันเป็นเรื่องยากที่จะทำซ้ำด้วยตนเอง: blob Base64 ทำให้ body ของ JSON อ่านยาก และการเปรียบเทียบการตั้งค่า detail หมายถึงการจัดการเพย์โหลดที่เกือบจะเหมือนกัน นี่คือวงจรที่ยังคงอ่านง่ายและสามารถรันใหม่ได้ในคลิกเดียว

1. ตั้งค่าสภาพแวดล้อม สร้างตัวแปรสำหรับ base_url, api_key, model (deepseek-flash), และ detail (high) การเปลี่ยนระดับรายละเอียดในภายหลังคือการเปลี่ยนในดรอปดาวน์ ไม่ใช่การแก้ไขเพย์โหลด
2. เข้ารหัสรูปภาพใน pre-request script แทนที่จะวาง Base64 ลงใน body ให้ pre-request script เข้ารหัสไฟล์ตัวอย่างและเขียนผลลัพธ์ไปยังตัวแปร image_b64 body ที่มองเห็นได้จะยังคงมีความยาวไม่กี่บรรทัด และการสลับรูปภาพทดสอบหมายถึงการเปลี่ยนแค่หนึ่งเส้นทาง
3. บันทึก request body ด้วยตัวแปร ใช้ "model": "{{model}}", "detail": "{{detail}}", และ "url": "data:image/png;base64,{{image_b64}}" บันทึกเป็น test case เพื่อให้สามารถนำกลับมาใช้ใหม่ได้
4. ยืนยันรูปทรงของ JSON ยืนยันว่าการตอบกลับสามารถแยกวิเคราะห์เป็น JSON ได้, invoice_number เป็นสตริงที่ไม่ว่างเปล่า, line_items เป็นอาร์เรย์ที่ไม่ว่างเปล่า, total เป็นตัวเลข, และ usage.prompt_tokens ต่ำกว่าเกณฑ์ที่คุณเลือก นั่นจะเปลี่ยนคำว่า “ดูดี” ให้กลายเป็นผลลัพธ์ผ่าน/ไม่ผ่าน
5. ยืนยันว่าชื่อเดิมนำไปยังโมเดลเดียวกัน ทำซ้ำคำขอที่บันทึกไว้, ตั้งค่า model เป็น deepseek-v4-flash-vision-exp, และรันทั้งสองในสถานการณ์การทดสอบเดียวกันโดยใช้รูปภาพเดียวกัน เปรียบเทียบฟิลด์ที่ดึงออกมาและจำนวน usage.prompt_tokens ผลลัพธ์ที่ตรงกันยืนยันสิ่งที่บันทึกการเผยแพร่ระบุไว้: ทั้งสองชื่อส่งไปยัง V4.1-Flash ดังนั้นคุณจึงสามารถเปลี่ยนชื่อในการตั้งค่าของคุณได้อย่างมั่นใจ
6. รันใน CI รันสถานการณ์ด้วย apidog-cli ทุกครั้งที่มีการเปลี่ยนแปลง prompt เพื่อให้การถดถอยของ schema ถูกตรวจพบก่อนการผลิตจริง

ดาวน์โหลด Apidog และการตั้งค่าจะใช้เวลาประมาณสิบห้านาทีในการสร้าง Apidog ทดสอบเลเยอร์ API ไม่ใช่โฮสต์โมเดล ดังนั้นสถานการณ์เดียวกันจึงสามารถใช้ได้กับ endpoint ที่เข้ากันได้กับ OpenAI ที่คุณจะใช้ในภายหลัง

สิ่งที่คุณจะได้รับ

endpoint ทดลองได้พิสูจน์รูปแบบการร้องขอและจุดราคาแล้ว V4.1-Flash ยังคงรักษาทั้งสองสิ่งไว้และเปลี่ยนไปใช้โมเดลที่รับรู้รูปภาพตั้งแต่โทเค็นการฝึกอบรมแรก กำหนด client ของคุณไปยัง deepseek-flash, เก็บ detail ไว้ในตัวแปร, ยืนยัน JSON ที่คุณได้รับกลับมา, และรันชื่อเดิมผ่านสถานการณ์ Apidog เดียวกันหนึ่งครั้งเพื่อยืนยันการเปลี่ยนเส้นทาง หลังจากนั้น คำถามเดียวที่เหลือคือความแม่นยำบนเอกสารของคุณเอง และตอนนี้คุณมีการทดสอบที่สามารถตอบคำถามนั้นได้แล้ว