ทางเลือกแทน Replicate สำหรับ API ของโมเดล AI ในปี 2026

TL;DR ไม่มีตัวแทนเดียวที่แทน Replicate ได้ทั้งหมด เพราะทีมใช้งานเพื่อสองงานต่างกัน: รันโค้ดโมเดลแบบกำหนดเอง และเรียกใช้ API ของโมเดลที่พร้อมใช้งานอยู่แล้ว ทางเลือกที่เหมาะขึ้นอยู่กับว่างานใดสำคัญกว่า

• คงใช้ Replicate หรือใช้แพลตฟอร์มโฮสต์แบบกำหนดเองเมื่อคุณต้องการโค้ดตามอำเภอใจ น้ำหนักโมเดลส่วนตัว (private weights) การพึ่งพิงไลบรารีแบบกำหนดเอง หรือไปป์ไลน์รูปภาพ เสียง และวิดีโอที่ไม่ปกติ
• พิจารณา Hugging Face Inference Endpoints เมื่อคุณต้องการเอนด์พอยต์แบบจัดการและเฉพาะสำหรับโมเดล หรือ custom inference handler ภายในระบบนิเวศของ Hugging Face
• พิจารณา Modal เมื่อคุณต้องการอินฟราสตรักเชอร์ GPU แบบเซิร์ฟเวอร์เลสที่นิยามด้วย Python โดยควบคุมคอนเทนเนอร์ ตัวเร่ง (accelerators) และออโตสเกลได้
• พิจารณา API แบบรวม เช่น CometAPI เมื่อเวิร์กโหลดใช้โมเดลที่โฮสต์และรองรับแล้ว และปัญหาหลักคือการดูแลการเชื่อมต่อผู้ให้บริการหลายราย แทนที่จะเป็นการโฮสต์น้ำหนักโมเดลแบบกำหนดเอง

การตัดสินใจที่ใช้งานได้จริงไม่ใช่ “แพลตฟอร์มไหนมีรายชื่อโมเดลยาวที่สุด?” แต่คือ “เราต้องรันโค้ดโมเดลของเราเอง หรือเราต้องการวิธีที่ง่ายขึ้นในการเรียกโมเดลที่โฮสต์ไว้อยู่แล้ว?”

ประเด็นสำคัญ

• Replicate ยังคงเหมาะกับเวิร์กโหลดการอนุมานแบบกำหนดเองและรันนาน การย้ายออกไปไม่ได้แปลว่าอัปเกรดโดยอัตโนมัติ
• คอลด์สตาร์ตเป็นเรื่องของการตั้งค่า ไม่ใช่ค่าคงที่ของทั้งแพลตฟอร์ม ความจุที่วอร์มไว้ช่วยลดเวลาเริ่มต้น แต่สร้างต้นทุนขณะว่าง
• เปรียบเทียบต้นทุนทั้งหมดของเวิร์กโหลด รวมถึงการรีทราย การเข้าคิว ความจุว่าง เวลาและแรงวิศวกรรม และงานมิเกรต แทนที่จะดูเพียงราคาต่อหน่วยที่โฆษณา
• API ที่เข้ากันได้กับ OpenAI ลดความแตกต่างในการอินทิเกรต แต่ความเข้ากันได้ไม่รับประกันว่าพารามิเตอร์ อีเวนต์สตรีมมิง เครื่องมือ หรือการตอบข้อผิดพลาดจะเหมือนกันข้ามโมเดล
• API แบบรวมสามารถทำให้การเข้าถึงโมเดลมาตรฐานที่โฮสต์ง่ายขึ้น แต่ไม่ใช่ตัวแทนของแพลตฟอร์มคอนเทนเนอร์อเนกประสงค์สำหรับโมเดลแบบกำหนดเอง

สิ่งที่ Replicate ทำได้ดีอยู่แล้ว

Replicate ยังมีประโยชน์เมื่อทีมต้องการแพ็กเกจโค้ดและน้ำหนักโมเดลโดยไม่ต้องดูแลคลัสเตอร์ GPU เอง API รองรับทั้งการพยากรณ์แบบซิงก์และอะซิงก์ พร้อมการโพลและเว็บฮุคสำหรับงานที่รันนาน จึงเหมาะกับเวิร์กโหลดที่เวลา 실행ไม่พอดีกับคำขอแชตที่ต้องการเวลาแฝงต่ำแบบทั่วไป

เรื่องคอลด์สตาร์ตก็ซับซ้อนกว่าคำกล่าวง่ายๆ ว่า “Replicate ช้า” ตามเอกสารของ Replicate โมเดลสาธารณะอาจเจอการบูตเย็นหรือข้อจำกัดคิวร่วม แต่โมเดลทางการจะถูกทำให้วอร์มไว้ ทีมยังสามารถใช้ดีพลอยเมนต์ที่ตั้งค่าอินสแตนซ์ขั้นต่ำและสูงสุดได้เมื่อจำเป็นต้องควบคุมความจุ

เอกสารการคิดค่าบริการ ของ Replicate แยกความต่างระหว่างโมเดลสาธารณะ โมเดลส่วนตัว โมเดลทางการ และดีพลอยเมนต์ ซึ่งไม่ได้มีพฤติกรรมการคิดเงินแบบเดียวกันทั้งหมด การวิเคราะห์มิเกรตจึงควรเริ่มจากชนิดของโมเดลและการตั้งค่าดีพลอยเมนต์ที่ใช้อยู่จริงในปัจจุบัน

ทางเลือกของ Replicate โดยสรุป

หมายเหตุการเปรียบเทียบราคา Replicate, Hugging Face Inference Endpoints และ Modal โดยหลักเผยค่าใช้จ่ายอินฟราสตรักเชอร์หรือรันไทม์ ในขณะที่ CometAPI เผยราคาการใช้งานโมเดล เพื่อเทียบอย่างยุติธรรม จงแปลงแต่ละตัวเลือกเป็นต้นทุนต่อภารกิจที่สำเร็จบนเวิร์กโหลดเดียวกัน ราคาแบบต่อตัวอักษร ต่อรูปภาพ ต่อวินาทีวิดีโอ ต่อวินาที GPU และต่อชั่วโมงอินสแตนซ์ไม่สามารถเทียบตรงๆ กันได้

ตัวเลือกที่ 1: ปรับแต่ง Replicate ก่อนจะแทนที่

อาจไม่จำเป็นต้องมิเกรต หากปัญหาจริงคือความถี่ของคอลด์สตาร์ต การแยกคิว หรือการควบคุมความจุ มากกว่ารูปแบบการรันของ Replicate

เอกสารทางการของ Replicate ระบุสองเส้นทางที่เกี่ยวข้อง:

1. โมเดลทางการ: Replicate ระบุว่าโมเดลเหล่านี้เปิดตลอด ใช้ API ที่เสถียร และมีหน่วยการใช้งานที่คาดเดาได้
2. ดีพลอยเมนต์: ทีมสามารถกำหนดฮาร์ดแวร์และพารามิเตอร์การสเกล รวมถึงอินสแตนซ์ขั้นต่ำ สำหรับโมเดลที่ต้องการเอนด์พอยต์คงที่หรือคิวคำขอของตนเอง

นี่เป็นตัวเลือกที่เปลี่ยนแปลงน้อยที่สุดสำหรับแอปที่พึ่งพาสคีมาอินพุตเฉพาะของโมเดลบน Replicate, prediction ID, เว็บฮุค หรือการจัดการเอาต์พุตอยู่แล้ว มันหลีกเลี่ยงการเขียนใหม่ แต่ไม่อาจแก้ปัญหาที่กว้างกว่าของการอินทิเกรตโมเดลจากผู้ให้บริการ API หลายรายที่ไม่เกี่ยวข้องกัน

เลือกแนวทางนี้เมื่อ

• โมเดลทำงานได้ถูกต้องบน Replicate อยู่แล้ว
• แอปพึ่งพาวงจร prediction แบบอะซิงโครนัสของ Replicate
• โค้ดโมเดลแบบกำหนดเองหรือการพึ่งพิงพิเศษทำให้การพกพาแพง
• ทีมยอมรับต้นทุนของความจุที่วอร์มไว้ตามที่จำเป็นได้

ตัวเลือกที่ 2: Hugging Face Inference Endpoints สำหรับการเสิร์ฟแบบจัดการเฉพาะ

Hugging Face Inference Endpoints เหมาะเมื่อทีมต้องการดีพลอยโมเดลในระบบนิเวศ Hugging Face แบบจัดการ แต่ยังต้องควบคุมอินสแตนซ์เสิร์ฟได้

Hugging Face ให้ตั้งค่าเรพลิกาขั้นต่ำและสูงสุด และดีพลอย custom inference handler เมื่อการทำงานตามดีฟอลต์ไม่พอ เอกสารการคิดราคา ระบุว่าค่าของเอนด์พอยต์ขึ้นกับทรัพยากรอินสแตนซ์ที่เลือกระหว่างการเริ่มต้นและการทำงาน คิดตามนาที

การ scale-to-zero เป็นตัวเลือก ไม่ได้เปิดอัตโนมัติในทุกการตั้งค่า เมื่อเปิดจะช่วยลดต้นทุนว่างแต่เพิ่มคอลด์สตาร์ต คู่มือออโตสเกล ของ Hugging Face ยังระบุว่าคำขออาจได้ 502 ระหว่างที่เอนด์พอยต์ที่สเกลเป็นศูนย์กำลังเริ่มต้น ดังนั้นไคลเอนต์ควรมีการเข้าคิวหรือรีทราย

เลือกแนวทางนี้เมื่อ

• โมเดลหรือไฟน์จูนถูกเก็บอยู่บน Hugging Face Hub แล้ว
• ทีมต้องการฮาร์ดแวร์แบบจัดการเฉพาะโดยไม่ต้องดูแล Kubernetes เอง
• custom inference handler เพียงพอ; ไม่ต้องการคอนเทนเนอร์แอปพลิเคชันตามอำเภอใจเต็มรูปแบบ
• การมีเรพลิกาที่คาดเดาได้สำคัญกว่าการกำจัดต้นทุนว่างทั้งหมด

ตัวเลือกที่ 3: Modal สำหรับอินฟราสตรักเชอร์ GPU แบบเซิร์ฟเวอร์เลสที่นิยามด้วยโค้ด

Modal ใกล้เคียงแพลตฟอร์มคอมพิวต์แบบเซิร์ฟเวอร์เลสมากกว่าแคตตาล็อกโมเดล นักพัฒนานิยามอิมเมจคอนเทนเนอร์ ฟังก์ชัน Python ตัวเร่ง และนโยบายการสเกลในโค้ด เหมาะสำหรับเซิร์ฟเวอร์อนุมานแบบกำหนดเอง งานแบตช์ ไฟน์จูน และไปป์ไลน์ที่ต้องการการควบคุมมากกว่าเอนด์พอยต์โมเดลสำเร็จรูป

ฟังก์ชันของ Modal สเกลลงเป็นศูนย์โดยดีฟอลต์ แต่ทีมสามารถตั้งค่าอินสแตนซ์ขั้นต่ำ อินสแตนซ์บัฟเฟอร์ และหน้าต่างการสเกลดาวน์ เพื่อแลกต้นทุนว่างกับเวลาเริ่มต้นที่ต่ำลง เอกสารเอนด์พอยต์ยังชี้เส้นแบ่งการคิดเงินอย่างชัดเจน: คิดคอมพิวต์เฉพาะตอนคอนเทนเนอร์ของเอนด์พอยต์กำลังรัน และเอนด์พอยต์ที่สเกลเป็นศูนย์จะไม่มีค่าใช้จ่ายคอมพิวต์ที่แอคทีฟ

เลือกแนวทางนี้เมื่อ

• แอปต้องการโค้ด Python แบบกำหนดเองหรือเอนจินอนุมานแบบกำหนดเอง
• ทีมต้องการเลือกชนิด GPU และจูนคอนเคอเรนซีโดยตรง
• เวิร์กโหลดผสมการอนุมานออนไลน์กับงาน GPU แบบแบตช์หรือกำหนดเวลา
• วิศวกรพร้อมรับผิดชอบโค้ดดีพลอยและการปรับแต่งประสิทธิภาพ

ตัวเลือกที่ 4: CometAPI สำหรับโมเดลที่รองรับหลัง API เดียว

API แบบรวมแก้ปัญหาอีกแบบ แทนที่จะโฮสต์น้ำหนักโมเดลแบบกำหนดเอง มันให้วิธีที่สม่ำเสมอในการเรียกโมเดลที่ถูกดำเนินการโดยผู้ให้บริการต้นทางหรือพาร์ตเนอร์โฮสติ้งอยู่แล้ว

ไดเรกทอรีโมเดลของ CometAPI คือแหล่งข้อมูลปัจจุบันของโมเดลที่รองรับและอัตราค่าบริการที่แสดง สำหรับทีมที่ใช้งานไคลเอนต์สไตล์ OpenAI อยู่แล้ว แพลตฟอร์มมีเอกสาร base URL ที่เข้ากันได้กับ OpenAI และรูปแบบคำขอ ซึ่งช่วยลดการตั้งค่าเฉพาะผู้ให้บริการสำหรับเวิร์กโฟลว์แชตและเจนเนอเรชันมาตรฐาน

ประโยชน์หลักคือการรวมการอินทิเกรต:

• กุญแจ API และ base URL เดียวสำหรับโมเดลที่รองรับ
• รูปแบบคำขอร่วมสำหรับเอนด์พอยต์ที่เข้ากันได้
• หน้าราคา ศูนย์กลางสำหรับหน่วยและอัตราที่แสดงอยู่ตอนนี้
• หน้าสถานะโมเดล สาธารณะสำหรับตรวจสอบความพร้อมให้บริการ

อย่างไรก็ดี ความเข้ากันได้ยังต้องทดสอบ พารามิเตอร์เฉพาะโมเดล เซมานติกของสตรีมมิง การใช้เครื่องมือ เอาต์พุตแบบมีโครงสร้าง ลิมิตเรต และข้อผิดพลาด อาจต่างกันแม้หน้าตาไคลเอนต์จะคล้าย API ของ OpenAI แอปในโปรดักชันควรยืนยันแต่ละโมเดลเป้าหมาย และมีกลยุทธ์ไทม์เอาต์ รีทราย และ fallback ของตนเอง

CometAPI ไม่ใช่สิ่งทดแทน Replicate เมื่อเวิร์กโหลดต้องการน้ำหนักโมเดลเฉพาะ สิทธิ์รันคอนเทนเนอร์ตามอำเภอใจ การพึ่งพิงเนทีฟแบบกำหนดเอง หรือโมเดลเฉพาะทางที่ไม่มีในแคตตาล็อกที่รองรับ

เลือกแนวทางนี้เมื่อ

• แอปใช้โมเดลมาตรฐานที่โฮสต์จากหลายผู้ให้บริการ
• แหล่งความฝืดหลักคือการดูแล SDK, กุญแจ และบัญชีบิลแยกต่างหาก ไม่ใช่การโฮสต์โมเดล
• ทีมอยากเปรียบเทียบหรือสลับโมเดลที่รองรับโดยไม่ต้องออกแบบขอบเขตแอปใหม่
• ไม่ต้องการโฮสต์โมเดลแบบกำหนดเอง

กรอบการตัดสินใจเชิงปฏิบัติ

ใช้ลำดับต่อไปนี้ก่อนเลือกแพลตฟอร์ม

1. จัดประเภทเวิร์กโหลด

ถามว่างานเป็นการเรียก API โมเดลที่โฮสต์ไว้ หรือการรันโมเดลแบบกำหนดเอง ความต่างเดียวนี้จะตัดตัวเลือกที่ไม่เหมาะออกไปมาก

• การเรียกโมเดลที่โฮสต์: API แบบรวมหรือ API ของผู้ให้บริการโดยตรงอาจเพียงพอ
• การรันโมเดลแบบกำหนดเอง: ใช้ Replicate, Hugging Face Inference Endpoints, Modal หรือแพลตฟอร์มที่รองรับน้ำหนักและรันไทม์ของคุณโดยชัดเจน

2. กำหนดเป้าหมายเวลาแฝง

วัดเวลาไปยังไบต์แรก เวลาไปยังโทเค็นแรก (ถ้าเกี่ยวข้อง) และเวลาสิ้นสุดทั้งหมดภายใต้ทราฟฟิกที่สมจริง อย่าคาดคะเนเวลาแฝงจากคำว่า “เซิร์ฟเวอร์เลส” หรือ “เฉพาะ”

หากบริการสเกลเป็นศูนย์ได้ ให้ทดสอบทั้งคำขอแบบวอร์มและคูลด์ หากคงอินสแตนซ์ขั้นต่ำไว้ ให้รวมต้นทุนว่างในโมเดลค่าใช้จ่ายด้วย

3. คำนวณต้นทุนต่อภารกิจที่สำเร็จ

ราคาต่อหน่วยเทียบตรงกันไม่ได้ระหว่างวินาทีที่แอคทีฟ นาที GPU โทเค็น รูปภาพ และวิดีโอ การเปรียบเทียบที่มีประโยชน์ควรรวม:

• ปริมาณอินพุตและเอาต์พุต
• เวลาเฉลี่ยในการรัน
• ความจุวอร์มหรือความจุว่าง
• การรีทรายและคำขอที่ล้มเหลว
• พฤติกรรมการเข้าคิวและไทม์เอาต์
• ความพยายามด้านวิศวกรรมและการมอนิเตอร์

ตัวชี้วัดที่ถูกต้องคือ ต้นทุนต่อภารกิจที่สำเร็จตามคุณภาพและเวลาแฝงที่ต้องการ ไม่ใช่ราคาต่อหน่วยที่ถูกที่สุดที่โฆษณา

4. ตรวจสอบความเข้ากันได้ของอินเทอร์เฟซ

รันทดสอบตัวแทนสำหรับทุกโมเดลและเอนด์พอยต์ ตรวจสอบ:

• สคีมาของคำขอและคำตอบ
• อีเวนต์สตรีมมิง
• การเรียกใช้เครื่องมือหรือฟังก์ชัน
• พฤติกรรมเอาต์พุตแบบมีโครงสร้าง
• ไฟล์และอินพุตแบบมัลติโมดัล
• โค้ดข้อผิดพลาด ไทม์เอาต์ และลิมิตเรต
• นโยบายเก็บข้อมูลและข้อกำหนดภูมิภาค

5. ทดสอบพฤติกรรมเมื่อเกิดความล้มเหลว

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

เช็กลิสต์การมิเกรต

1. สำรวจทุกโมเดล Replicate เวอร์ชัน เอนด์พอยต์ prediction เว็บฮุค และสคีมาอินพุตแบบกำหนดเอง
2. แยกงานที่เป็นโมเดลโฮสต์มาตรฐานออกจากงานน้ำหนักโมเดลแบบกำหนดเองและโค้ดตามอำเภอใจ
3. เก็บฐานข้อมูลเวลาแฝง อัตราสำเร็จ คุณภาพ และต้นทุนต่อภารกิจที่เสร็จสิ้น
4. คัดกรองแพลตฟอร์มตามประเภทเวิร์กโหลดก่อนค่อยเทียบราคา
5. รันทดสอบชุดเดียวกันบนความจุแบบวอร์มและคูลด์
6. ยืนยันสคีมาเอาต์พุต สตรีมมิง พฤติกรรมด้านความปลอดภัย และการจัดการข้อผิดพลาด
7. เพิ่มไทม์เอาต์ฝั่งไคลเอนต์ รีทรายแบบมีขอบเขต และกฎ fallback ที่ชัดเจน
8. ย้ายทราฟฟิกส่วนเล็กก่อน แล้วเทียบเมตริกโปรดักชันก่อนคัตโอเวอร์ทั้งหมด

คำถามที่พบบ่อย

ทางเลือก Replicate ที่ดีที่สุดสำหรับโมเดลแบบกำหนดเองคืออะไร?

ไม่มีตัวเลือกสากลที่ดีที่สุด Hugging Face Inference Endpoints เหมาะกับทีมที่ทำงานในระบบนิเวศ Hub พร้อมการเสิร์ฟแบบจัดการเฉพาะ ขณะที่ Modal เหมาะกับทีมที่ต้องการคอนเทนเนอร์และการรัน GPU ที่นิยามด้วยโค้ด Replicate เองอาจยังเป็นตัวเลือกเสี่ยงต่ำสุดเมื่อการแพ็กเกจโมเดลและวงจร prediction ของมันตรงกับเวิร์กโหลดอยู่แล้ว

ทางเลือก Replicate ที่ดีที่สุดสำหรับ LLM API แบบโฮสต์หลายรายคืออะไร?

API แบบรวม เช่น CometAPI อาจเหมาะเชิงสถาปัตยกรรมมากกว่าเมื่อโมเดลถูกโฮสต์อยู่แล้ว และปัญหาคือการอินทิเกรตผู้ให้บริการ ไม่ใช่การดีพลอยโมเดล ยืนยันว่าโมเดลและฟีเจอร์ที่ต้องการอยู่ในแคตตาล็อกสด และทดสอบความเข้ากันได้ก่อนมิเกรตทราฟฟิกโปรดักชัน

เอนด์พอยต์แบบเฉพาะกำจัดคอลด์สตาร์ตได้หรือไม่?

เฉพาะเมื่อการตั้งค่าคงอย่างน้อยหนึ่งเรพลิกาพร้อมไว้ ทั้งแพลตฟอร์มแบบเฉพาะและเซิร์ฟเวอร์เลสอาจมีการตั้งค่า scale-to-zero การคงเรพลิกาที่วอร์มไว้ลดเวลาเริ่มต้น แต่เพิ่มต้นทุนว่าง

API ที่เข้ากันได้กับ OpenAI แทนที่ได้แบบเสียบปลั๊กสำหรับทุกโมเดลหรือไม่?

ไม่โดยอัตโนมัติ ไลบรารีไคลเอนต์และรูปทรงคำขอระดับบนอาจใช้ซ้ำได้ แต่พารามิเตอร์โมเดล การเรียกใช้เครื่องมือ สตรีมมิง พฤติกรรมข้อผิดพลาด และโมดาลิตีที่รองรับอาจต่างกัน มองความเข้ากันได้เป็นตัวเร่งการมิเกรต ไม่ใช่ตัวแทนการทดสอบ

ควรย้ายทุกเวิร์กโหลดบน Replicate ไปทางเลือกเดียวหรือไม่?

โดยมากไม่ สถาปัตยกรรมแบบผสมมักใช้งานได้จริงกว่า: งานแบบกำหนดเองหรือเฉพาะทางคงอยู่บนแพลตฟอร์มที่รองรับคอนเทนเนอร์ ขณะที่โมเดลมาตรฐานที่โฮสต์ย้ายไปหลัง API ของผู้ให้บริการโดยตรงหรือ API แบบรวม การแยกควรอิงตามความต้องการเวิร์กโหลดมากกว่าจำนวนผู้ขาย

บทสรุป

การเลือกทางเลือกของ Replicate เริ่มจากการระบุว่า Replicate ทำอะไรอยู่ในระบบปัจจุบัน ทีมที่รันโค้ดและน้ำหนักโมเดลแบบกำหนดเองต้องการแพลตฟอร์มโฮสติ้ง ส่วนทีมที่เรียกใช้โมเดลมาตรฐานที่โฮสต์อยู่แล้วต้องการชั้นอินทิเกรต API ที่เชื่อถือได้ นี่คือปัญหาอินฟราสตรักเชอร์คนละแบบ

Hugging Face Inference Endpoints มอบการเสิร์ฟแบบจัดการเฉพาะสำหรับเวิร์กโฟลว์ที่ยึด Hub Modal ให้โครงสร้างพื้นฐาน GPU แบบเซิร์ฟเวอร์เลสที่นิยามด้วยโค้ด CometAPI ช่วยลดภาระอินทิเกรตสำหรับโมเดลที่รองรับผ่านผิวสัมผัส API ร่วม Replicate ยังคงเป็นตัวเลือกที่ใช้การได้เมื่อวงจร prediction การแพ็กเกจโมเดล และการควบคุมดีพลอยเมนต์สอดคล้องกับแอปพลิเคชันอยู่แล้ว

ก่อนมิเกรต ให้ทดสอบเวิร์กโหลดเดียวกันบนแพลตฟอร์มที่เป็นตัวเลือก และเปรียบเทียบเวลาแฝงแบบคูลด์และวอร์ม ต้นทุนต่อภารกิจที่สำเร็จ พฤติกรรมเมื่อผิดพลาด และความเข้ากันได้ของฟีเจอร์ หลักฐานเหล่านี้จะให้การตัดสินใจที่เชื่อถือได้กว่ารายการฟีเจอร์เพียงอย่างเดียว