วิธีกำหนดเส้นทางคำขอ LLM ไปยังโมเดลที่เหมาะสมสำหรับแต่ละงาน

คำตอบสั้นๆ: กำหนดเส้นทางคำขอในแอปพลิเคชันของคุณ จากนั้นใช้คีย์ CometAPI เพียงชุดเดียวและฐาน URL ที่เข้ากันได้กับ OpenAI https://api.cometapi.com/v1 เพื่อเรียกโมเดลที่เลือก ส่งงานที่ซ้ำๆ และตรวจสอบง่ายไปยังชั้นราคาประหยัด; ปฏิสัมพันธ์กับลูกค้าที่อ่อนไหวต่อเวลาแฝงไปยังชั้นเร็ว; และงานที่คลุมเครือหรือมีผลกระทบสูงไปยังชั้นความแม่นยำสูง เก็บป้ายกำกับเหล่านี้ไว้เป็นนโยบายภายในของคุณเอง—not เป็นการจัดอันดับโมเดลสากล—and วัดทุกชั้นบนชุดทดสอบเดียวกัน

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

LLM routing คืออะไร?

LLM routing คือกระบวนการส่งแต่ละคำขอไปยังโมเดลหรือชั้นบริการที่เหมาะสมที่สุดกับงาน เป้าหมายเวลาแฝง ข้อกำหนดคุณภาพ และงบประมาณ

ควรกำหนดเส้นทางคำขอ LLM ตามงานอย่างไร?

ณ วันที่ 20 สิงหาคม 2026 มีรหัสโมเดลและฟิลด์ราคาในแคตตาล็อกดังต่อไปนี้ให้ใช้งานผ่าน CometAPI Models API สัดส่วนอัตราผู้บริโภคโดยประมาณด้านล่างใช้ค่า ratio ปัจจุบันของแคตตาล็อกกับราคาอินพุตและเอาต์พุตฐาน ตาม CometAPI pricing guide โปรดยืนยันอัตราสุดท้ายที่แสดงในบัญชีของคุณก่อนใช้จริงในโปรดักชัน

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

ตั้งค่า CometAPI สำหรับตัวกำหนดเส้นทาง LLM อย่างไร?

คุณต้องมีคีย์ CometAPI, Python 3.10 หรือใหม่กว่า และแพ็คเกจ OpenAI Python เก็บคีย์ไว้ฝั่งเซิร์ฟเวอร์แทนการฝังในซอร์สโค้ด

pip install openaiexport COMETAPI_KEY="your-key-here"

ตัวอย่างนี้ใช้ POST /v1/chat/completions CometAPI อธิบายว่านี่คืออินเทอร์เฟซที่แชร์ระหว่างผู้ให้บริการหลายราย แต่พฤติกรรมพารามิเตอร์ยังคงแตกต่างกันไปตามโมเดล ตรวจสอบรายการโมเดลปัจจุบันและ Chat Completions reference ก่อนเพิ่มฟิลด์เฉพาะผู้ให้บริการ

ต้องมีอะไรบ้างเพื่อสร้างตัวกำหนดเส้นทาง LLM?

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

ตรวจสอบความถูกต้องของเอาต์พุต สถานะ HTTP สำเร็จไม่ได้แปลว่าผลลัพธ์ใช้งานได้ ส่ง validator เฉพาะงานไปยังตัวกำหนดเส้นทาง Validator ของการจัดหมวดหมู่สามารถตรวจสอบป้ายที่อนุญาต; ตัวตรวจสอบการตอบลูกค้าสามารถบังคับความยาวและข้อห้ามการอ้างสิทธิ์; เวิร์กโฟลว์แบบมีโครงสร้างสามารถตรวจสอบสคีมา JSON ได้

fallback แบบแคบ ลองเส้นทางถัดไปที่ได้รับอนุมัติหลังจาก timeout, 408, 429, 5xx ชั่วคราว หรือความล้มเหลวของเกตคุณภาพที่มีขอบเขต อย่าใช้โมเดลอื่นเพื่อซ่อนอินพุตที่ผิดรูป คีย์ไม่ถูกต้อง หรือพารามิเตอร์ที่ไม่รองรับ

สร้างตัวกำหนดเส้นทาง LLM ใน Python อย่างไร?

import osimport time​from openai import APIError, OpenAI​client = OpenAI(    api_key=os.environ["COMETAPI_KEY"],    base_url="https://api.cometapi.com/v1",    max_retries=0,    timeout=20,)​MODELS = {    "cheap": "deepseek-v4-flash",    "fast": "gemini-3.7-flash",    "accurate": "claude-opus-5",}​# Put the preferred tier first; later tiers are fallbacks.ROUTES = {    "tag": ["cheap", "fast", "accurate"],    "reply": ["fast", "cheap", "accurate"],    "policy_review": ["accurate", "fast", "cheap"],}​​def retryable(error):    status = getattr(error, "status_code", None)    return status is None or status in {408, 429} or (status and status >= 500)​​def route(task, prompt, validate=lambda text: True):    attempts = []    for tier in ROUTES.get(task, ROUTES["reply"]):        model = MODELS[tier]        started = time.perf_counter()        try:            response = client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )            text = response.choices[0].message.content or ""            attempts.append({                "tier": tier,                "model": model,                "latency_ms": round((time.perf_counter() - started) * 1000),                "accepted": validate(text),            })            if attempts[-1]["accepted"]:                return {                    "text": text,                    "route": tier,                    "model": model,                    "usage": response.usage.model_dump() if response.usage else None,                    "attempts": attempts,                }        except APIError as error:            attempts.append({"tier": tier, "model": model, "status": error.status_code})            if not retryable(error):                raise​    raise RuntimeError(f"No route passed: {attempts}")​​if __name__ == "__main__":    result = route(        "reply",        "Reply to a customer asking when their refund will arrive. Do not promise a date.",        validate=lambda text: 30 <= len(text) <= 600 and "guarantee" not in text.lower(),    )    print(result)

จำกัดการลองใหม่ก่อน fallback อย่างไร?

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

MAX_ATTEMPTS_PER_MODEL = 2​def call_model(model, prompt):    for attempt in range(1, MAX_ATTEMPTS_PER_MODEL + 1):        try:            return client.chat.completions.create(                model=model,                messages=[{"role": "user", "content": prompt}],                max_tokens=400,            )        except APIError as error:            if not retryable(error) or attempt == MAX_ATTEMPTS_PER_MODEL:                raise            time.sleep(min(0.5 * (2 ** (attempt - 1)), 2.0))

ใน route() ให้แทนที่การเรียก client.chat.completions.create(...) ด้วย call_model(model, prompt) ด้วยสามชั้น คำขอหนึ่งครั้งจะหยุดหลังจากเรียกผู้ให้บริการมากที่สุดหกครั้ง ความล้มเหลวของการตรวจสอบยังคงเลื่อนขั้นเพียงครั้งละหนึ่งชั้นแทนที่จะลองเอาต์พุตเดิมซ้ำ

รันด้วย python3 llm_task_router.py หากต้องการเปลี่ยนผู้ให้บริการหรือรุ่นของโมเดลภายหลัง ให้ปรับ MODELS; นโยบายงานและสัญญาการตอบกลับจะยังคงอยู่ในที่เดียว

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

ทดสอบนโยบายการกำหนดเส้นทาง LLM อย่างไร?

ตรวจสอบก่อนว่านโยบายเชิงกำหนด (deterministic) เลือกชั้นหลักตามที่ตั้งใจไว้ นี่คือความคาดหวังของการกำหนดเส้นทาง ไม่ใช่ผลการทำงานของผู้ให้บริการ:

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

{  "text": "...",  "route": "fast",  "model": "gemini-3.7-flash",  "usage": {    "prompt_tokens": "measured value",    "completion_tokens": "measured value"  },  "attempts": [    {      "tier": "fast",      "model": "gemini-3.7-flash",      "latency_ms": "measured value",      "accepted": true    }  ]}

เพื่อการเปรียบเทียบจริง ให้รันคำขอที่ติดป้ายเดียวกันผ่านทั้งสามโมเดล บันทึกอัตราผ่านงาน เวลาแฝง p50 และ p95 อัตราความผิดพลาด โทเค็นอินพุตและเอาต์พุต อัตรา fallback และอัตราการรีวิวโดยมนุษย์ ตัวชี้วัดที่สำคัญมักเป็น “ต้นทุนต่อเอาต์พุตที่ยอมรับได้” ไม่ใช่ต้นทุนต่อการเรียก API

ค่ากำหนดเส้นทางหลายโมเดลเท่าไร?

ใช้รูปแบบงานเดียวเพื่อการเปรียบเทียบที่ยุติธรรม สมมติรวม 1 ล้านโทเค็น: โทเค็นอินพุต 800,000 และโทเค็นเอาต์พุต 200,000 โดยใช้อัตราที่ได้จากแคตตาล็อก ณ วันที่ 20 สิงหาคม 2026:

หากทราฟฟิกเป็น 60% ราคาประหยัด, 30% เร็ว, และ 10% ความแม่นยำสูง ต้นทุนโทเค็นเฉลี่ยแบบผสมประมาณ $1.19 ต่อ 1 ล้านโทเค็นทั้งหมด การส่งส่วนผสมเดียวกันไปยังเส้นทางความแม่นยำสูงทั้งหมดจะอยู่ที่ประมาณ $7.20 ภายใต้สมมติฐานเหล่านี้ นี่คือการคำนวณราคา ไม่ใช่หลักฐานว่านโยบายแบบผสมจะบรรลุเป้าหมายคุณภาพของคุณ

การลองใหม่และการปฏิเสธส่งผลต่อผลลัพธ์ อัตราการลองใหม่แบบครั้งเดียว 5% ทำให้การประมาณ $1.19 เพิ่มขึ้นเป็นประมาณ $1.25 หากเอาต์พุตต้นทุนต่ำไม่ผ่านการตรวจสอบและต้องเรียกซ้ำทั้งคำขอบนชั้นความแม่นยำสูง ให้คิดทั้งสองครั้ง ติดตามเอาต์พุตที่ยอมรับได้เพื่อไม่ให้โมเดลที่ดูเหมือนราคาถูกซ่อนต้นทุนการรีวิวหรือการสร้างใหม่

ความล้มเหลวของการกำหนดเส้นทาง LLM ที่พบบ่อยที่สุดคืออะไร?

error and retry guide แนะนำให้ลองใหม่สำหรับ rate limit และความล้มเหลวของแพลตฟอร์มชั่วคราวด้วย backoff ในขณะที่คำขอที่ผิดรูปและความล้มเหลวด้านการยืนยันตัวตนควรถูกแก้ไข fallback guide เช่นกันกำหนดให้ fallback ของโมเดลมีลำดับและชัดเจน

Routing ในแอป vs. CometAPI Auto: ควรใช้แบบไหน?

ใช้ routing ฝั่งแอปเมื่อความควบคุมและการทำซ้ำได้สำคัญ เก็บการตัดสินใจไว้ในโค้ดเมื่อภารกิจมีเสถียรภาพและคุณต้องการตัวตนโมเดลที่ตายตัว งบประมาณต่อชั้น ตัวตรวจสอบแบบกำหนดเอง และลำดับ fallback ที่ตรวจสอบย้อนกลับได้ วิธีนี้ยังทำให้เปรียบเทียบแมปโมเดลเดียวกันข้ามเวอร์ชันง่ายขึ้น

ใช้ CometAPI Auto เมื่อการลดภาระดูแล routing สำคัญกว่า ตั้งค่า model=auto สำหรับค่าเริ่มต้นที่สมดุล หรือ model=auto-high เมื่อให้ความสำคัญกับคุณภาพ CometAPI จะเลือกโมเดลที่มีสิทธิ์แบบไดนามิกจากลักษณะคำขอและพูลการกำหนดเส้นทางปัจจุบัน ดังนั้นโมเดลพื้นฐานอาจเปลี่ยนได้; สิ่งนี้ทำให้ Auto ไม่เหมาะเมื่อทุกการรันต้องใช้โมเดลเดียวกันหรือมีพารามิเตอร์เฉพาะโมเดล

รันนโยบายการกำหนดเส้นทาง LLM ในโปรดักชันอย่างไร?

รีเฟรชทะเบียนโมเดล เรียก GET https://api.cometapi.com/api/models ระหว่างการดีพลอยหรือเริ่มต้น และล้มเหลวการปล่อยหากไม่มี ID ที่กำหนดหรือเอ็นด์พอยต์ที่จำเป็น ID โมเดล ราคา และความสามารถอาจเปลี่ยนแปลง

เก็บตัวเลือกเฉพาะผู้ให้บริการไว้นอกตัวกำหนดเส้นทาง พื้นผิว Chat Completions ที่ใช้ร่วมกันไม่ได้ทำให้ทุกพารามิเตอร์เหมือนกัน ตัวอย่างเช่น การรองรับ logprobs, การควบคุมการให้เหตุผล หรือผู้สมัครหลายรายอาจแตกต่างกัน ใส่ความแตกต่างเหล่านั้นในอแดปเตอร์ที่ผ่านการทดสอบ

จำกัดทราฟฟิกและเอาต์พุต จำกัด concurrency ก่อนที่คำขอจะออกจากแอปพลิเคชัน ใช้ exponential backoff พร้อม jitter สำหรับ 429 และกำหนดเพดานโทเค็นเอาต์พุต rate-limit guide ของ CometAPI แนะนำการควบคุมฝั่งแอปเช่นเดียวกัน

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

โปรโมตเส้นทางด้วยหลักฐาน เก็บชุดประเมินที่ติดป้ายสำหรับแต่ละงาน ปรับเปลี่ยนแมปทีละน้อย เปรียบเทียบกับนโยบายก่อนหน้า และรักษาเส้นทางย้อนกลับอย่างรวดเร็ว

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

CometAPI ตัดสินใจอัตโนมัติหรือไม่ว่าโมเดลใดราคาประหยัด เร็ว หรือแม่นยำ?

บทเรียนนี้เก็บนโยบายไว้ในโค้ดแอป CometAPI จัดให้มีคีย์ที่ใช้ร่วมกัน ฐาน URL แคตตาล็อกโมเดล อินเทอร์เฟซ Chat Completions และบล็อกการสร้าง fallback ที่มีเอกสาร ทีมของคุณกำหนดว่าชั้นแต่ละชั้นหมายถึงอะไรและโมเดลใดผ่านการทดสอบ

ใช้คีย์ CometAPI หนึ่งชุดเรียกโมเดลจากผู้ให้บริการต่างๆ ได้หรือไม่?

ได้ สำหรับเส้นทางข้อความที่เข้ากันได้กับ OpenAI ใช้ https://api.cometapi.com/v1 และเปลี่ยนค่าของ model ควรตรวจสอบแคตตาล็อกปัจจุบันก่อนดีพลอย

ทำไมไม่ส่งทุกคำขอไปยังโมเดลที่ถูกที่สุด?

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

ควรให้ความล้มเหลวด้านคุณภาพทริกเกอร์ fallback หรือไม่?

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

แผนที่โมเดลควรเปลี่ยนบ่อยแค่ไหน?

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

สามารถเพิ่มโมเดลของ OpenAI ภายหลังได้หรือไม่?

ได้ เพิ่มรหัสโมเดลที่เข้ากันได้กับ OpenAI ปัจจุบันไปยัง MODELS ทดสอบสัญญาคำขอและการตอบกลับแบบเดียวกัน และวางในลำดับเส้นทาง ไคลเอนต์ คีย์ และฐาน URL ยังคงไม่เปลี่ยนแปลง

ทำอย่างไรให้นโยบายการกำหนดเส้นทาง LLM ดูแลง่าย?

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