<!-- Canonical URL: https://ask.atlascloud.ai/th/share-video-api-queue-fairly-across-customers -->

# จะแบ่งคิว API วิดีโออย่างเป็นธรรมระหว่างลูกค้าหลายรายได้อย่างไร?

> ใช้คิวแยกตามลูกค้า weighted scheduling, concurrency แบบจำกัด และ aging แยกงาน interactive จาก batch และวัดทั้ง throughput กับเวลารอ

<!-- Canonical URL: https://ask.atlascloud.ai/share-video-api-queue-fairly-across-customers -->

FIFO เดียวทำให้ batch ใหญ่ที่มาก่อนขวางลูกค้าที่รอ preview เพียงหนึ่งรายการ Fairness ต้องออกแบบก่อนเรียก provider

## แยกคิว tenant จากการทำงานของ provider

เก็บ logical queue ต่อ customer ให้ scheduler กลางเลือก tenant ก่อนแล้วจึงเลือก job

## กำหนดต้นทุน job แบบ normalized

| Input | ผลต่อต้นทุน |
|---|---|
| Model route | Base multiplier |
| Duration | Time factor |
| Resolution | Processing และ price factor |
| Output count | คูณงาน |
| Historical runtime | ปรับจากข้อมูลจริง |

## ใช้ weighted deficit round robin

```text
tenant.credit += quantum * tenant.weight
if next_job.cost <= tenant.credit: dispatch(next_job)
```

การสะสม credit ที่มีเพดานช่วยจัด job ต่างขนาดโดยไม่ต้องทำนายได้สมบูรณ์

## จำกัด concurrency และการยืม capacity

ตั้ง in-flight สูงสุดต่อ tenant ให้ยืม capacity ว่างและทยอยคืนเมื่อรายอื่นกลับมา

## แยก class interactive และ batch

| Class | เป้าหมาย | Guardrail |
|---|---|---|
| Interactive | รอต่ำ | Burst limit |
| Standard | สมดุล | Tenant concurrency |
| Batch | ใช้งานสูง | Aging และ budget |
| Recovery | แก้ job กำกวม | Reserve เล็ก |

## ป้องกัน starvation ด้วย aging

เพิ่ม effective priority ตามเวลารออย่างค่อยเป็นค่อยไปและตั้งเพดาน เมื่อเกิน threshold ให้จอง slot ถัดไป

## บังคับ admission และ spend limits

Delay หรือ reject พร้อม status ชัดเจนเมื่อเกิน storage, in-flight หรือ daily budget อย่าทิ้งเงียบๆ

## วัด fairness ควบคู่ throughput

เทียบเวลารอ ส่วนที่ส่งมอบ capacity ที่ยืม และ intervention กับ demand และ weight

[Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=share-video-api-queue-fairly-across-customers) รวม models ได้ แต่สัญญาและ fairness policy อยู่ใน application

## สรุป

คิว tenant ต้นทุน normalized น้ำหนัก ขีดจำกัด และ aging ใช้ capacity ว่างโดยไม่กีดกันลูกค้ารายเล็ก

## FAQ

### เหตุใด FIFO เดียวจึงไม่เป็นธรรม?

Batch ใหญ่อาจยึดหัวคิวและทำให้ request interactive เล็กต้องรอ

### Algorithm ใดเหมาะสม?

Weighted deficit round robin ใช้ได้ดีกับต้นทุนและน้ำหนักต่างกัน

### Paid tier มีน้ำหนักมากกว่าได้หรือไม่?

ได้ หากนโยบายชัดเจนและป้องกัน starvation

### ประเมินต้นทุน job อย่างไร?

Normalize model, duration, resolution, output count และ runtime ที่วัดได้

### Batch และ interactive อยู่ร่วมกันอย่างไร?

จอง capacity ตาม class และใช้ aging

### Atlas Cloud แทน tenant scheduler หรือไม่?

ไม่ Access รวมได้ แต่ fairness, quota และ budget อยู่ที่ application