> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prismgateway.io/llms.txt
> Use this file to discover all available pages before exploring further.

# การ routing และความทนทาน

> Prism จัดการ timeout, retry และ fallback ข้าม provider อย่างไร และอ่าน response header อย่างไร

# การ routing และความทนทาน

คำขอ chat, messages และ embeddings ทุกรายการจะถูกส่งไปยัง provider ตาม catalog ของ
model เมื่อ provider นั้นล้มเหลว Prism สามารถ retry และย้ายไป provider ถัดไปที่ตั้งค่าไว้
ก่อนจะส่ง error กลับ หน้านี้อธิบายว่าเกิดอะไรขึ้น คุณควบคุมอะไรได้ และอ่านผลอย่างไร

## Timeout

แต่ละครั้งที่เรียก upstream จะมี timeout ถึง byte แรก ค่าเริ่มต้นคือ 60 วินาที ส่ง header
`x-prism-timeout-ms` เพื่อเปลี่ยนค่าสำหรับคำขอนั้น:

```bash theme={null}
curl -sS "$PRISM_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $PRISM_API_KEY" \
  -H "Content-Type: application/json" \
  -H "x-prism-timeout-ms: 15000" \
  --data-binary @request.json
```

ค่าจะถูกจำกัดตามขอบเขตของเซิร์ฟเวอร์ (อย่างน้อย 1000 ms) ค่าที่ไม่ใช่จำนวนเต็มของมิลลิวินาที
จะถูกละเว้นและใช้ค่าเริ่มต้นแทน timeout ที่ต่ำกว่าค่าเริ่มต้นของเซิร์ฟเวอร์จะปิดการ retry
กรณี timeout สำหรับคำขอนั้น เพื่อไม่ให้ timeout สั้นบนคำตอบยาวแบบไม่ stream สร้างค่าใช้จ่าย
สองรอบ

## Retry และ fallback

เมื่อผู้ดูแลเปิดใช้ Prism จะ retry provider เดิมเมื่อเจอความล้มเหลวชั่วคราว (rate limit, `5xx`,
connection error, timeout หนึ่งครั้ง) ด้วย exponential backoff และเคารพ `Retry-After` ของ
provider ถ้ายังล้มเหลวและ model มี provider สำรองตั้งค่าไว้ คำขอจะย้ายไป provider ถัดไป
ลำดับทั้งหมดใช้งบเวลาเดียวกัน คำขอจึงไม่รอ retry อย่างไม่มีที่สิ้นสุด

Prism จะไม่ retry หรือ fallback กับ error ที่เกิดจากตัวคำขอเอง เช่น prompt เกิน context
window ของ model, parameter ไม่ถูกต้อง หรือ provider ปฏิเสธว่าคำขอผิดรูปแบบ กรณีเหล่านี้จะส่ง
กลับตามเดิม

คุณถูกคิดเงินครั้งเดียว เฉพาะครั้งที่ให้ผลลัพธ์ ครั้งที่ล้มเหลวไม่ถูกคิดเงิน

## Conditional routing

ผู้ดูแลระบบสามารถผูก rule กับ model เพื่อส่ง request ไปยัง provider, upstream
model หรือ credential อื่นเมื่อ context ตรงเงื่อนไข context ประกอบด้วย tag ของ
organization (ผู้ดูแลกำหนด), scope ของ key, model id และ request metadata คือ
object `metadata` ใน body รวมทับ header `x-prism-metadata` (JSON object ไม่เกิน
4 KB ไม่เกิน 32 ค่าแบบ primitive) metadata ใช้เปรียบเทียบเท่านั้น ไม่ได้ระบุ
provider เอง

```json theme={null}
{ "metadata": { "tier": "gold", "region": "de" } }
```

rule แรกที่ตรงจะถูกใช้และแทนที่ chain ทั้งหมดของ model รวมถึง fallback ดังนั้น
rule ที่ปักหมุด region จะไม่หลุดออกนอก region เมื่อเกิด failure ชั่วคราว
`x-prism-provider` ยังรายงาน provider ที่ให้บริการ request นั้นเช่นเดิม

metadata มาจากผู้เรียก ดังนั้น key ไหนก็ส่งค่าอะไรก็ได้ ผู้ดูแลจึงใช้มันกับ
preference (region, experiment) และใช้ tag ขององค์กรหรือ scope ของ key กับ
สิ่งที่มีผลด้านต้นทุนหรือ compliance key ที่ไม่มีใน metadata ไม่เท่ากับ `null`
แต่ผ่านเงื่อนไข `$ne`

## การอ่าน response header

| Header                        | ความหมาย                                                              |
| ----------------------------- | --------------------------------------------------------------------- |
| `x-prism-provider`            | provider ที่ให้บริการคำขอนี้                                          |
| `x-prism-retry-count`         | จำนวน retry ก่อนได้คำตอบ รวมทุก provider ที่ลอง                       |
| `x-prism-attempted-fallbacks` | provider ที่ล้มเหลวก่อนตัวที่ให้บริการ คั่นด้วยจุลภาค ไม่มีถ้าไม่เกิด |
| `x-prism-trace-id`            | request ID สำหรับติดต่อ support และดู usage                           |
| `retry-after`                 | มีใน `429` เมื่อ provider ขอให้รอ                                     |

header เหล่านี้ถูกตั้งใน error response ด้วย จึงเห็นได้ว่า Prism ลองอะไรไปก่อนยอมแพ้

## รหัส error

เมื่อทุกความพยายามล้มเหลว รหัส error จะบอกว่าเกิดอะไรขึ้นครั้งสุดท้าย:

| รหัส                                          | Status | ความหมาย                                             |
| --------------------------------------------- | ------ | ---------------------------------------------------- |
| `runtime_chat_failed:upstream_timeout`        | `502`  | provider ไม่ตอบภายใน timeout                         |
| `runtime_chat_failed:upstream_rate_limited`   | `429`  | provider กำลัง rate limit มี `retry-after` เมื่อทราบ |
| `runtime_chat_failed:upstream_server_error`   | `502`  | provider ตอบ `5xx`                                   |
| `runtime_chat_failed:upstream_unreachable`    | `502`  | เชื่อมต่อ provider ไม่ได้                            |
| `runtime_chat_failed:context_length_exceeded` | `400`  | คำขอเกิน context window ของ model                    |
| `runtime_chat_failed:upstream_rejected`       | `4xx`  | provider ปฏิเสธคำขอ                                  |

Embeddings ใช้รหัสเดียวกันโดยขึ้นต้นด้วย `runtime_embeddings_failed:` ดูแนวทาง retry ได้ที่
[Errors](/th/errors)

[Read in English](/routing)