AI API-ийн зардлыг 50% бууруул: яаралгүй ажлыг batch-д шилжүүл

Шуурхай хариу шаардахгүй AI API хүсэлтийг batch-д шилжүүлбэл шилжсэн ажлын өртгийг 50% бууруулах боломжтой: OpenAI-ийн Batch API заавар шуурхай API-тай харьцуулахад ийм хөнгөлөлт, 24 цагийн гүйцэтгэлийн цонх санал болгож, их хэмжээний ангилал, embedding болон үнэлгээний ажлыг тохирох хэрэглээ гэж нэрлэдэг. Хэрэглэгч хариугаа дэлгэц дээр хүлээж байгаа хүсэлтийг энэ дараалалд оруулах нь саатал үүсгэнэ.

Нийт API төлбөр яг тал хувиар буурах эсэх нь бүх ажлын хэдийг шилжүүлснээс хамаарна. Ажлаа хариу хэрэг болох хугацаагаар нь ангилж, шилжих хэсгийн токены өртгийг тусад нь бодоод, хүсэлт бүрийг таних ID болон алдаа сэргээх урсгалаа урьдчилан бэлдэх хэрэгтэй.

Аль ажлыг шилжүүлж болох вэ?

Шийдвэрийн гол шалгуур нь хүсэлтийн тоо бус, үр дүн хэрэг болох мөч юм. Ажлыг хуваарьт хугацаанд дуусгахад хангалттай бол batch тохирно. Хариу нь хүний дараагийн үйлдлийг шууд нээдэг бол хүлээлт үйлчилгээний чанарт нөлөөлнө.

• Шуурхай: хэрэглэгчийн асуултад хариулах, захиалгын дараагийн алхмыг шийдэх, хүн үр дүнг нь яг одоо хүлээж буй үйлдэл.
• Batch: нийтлэлийн санг ангилах, хайлтад зориулсан embedding-ийг шинэчлэх, шөнийн үнэлгээ ажиллуулах зэрэг үр дүнг дараа ашиглах ажил.
• Холимог: шинээр орж ирсэн бичлэгийг даруй боловсруулах шаардлагатай ч өмнөх санг бөөнөөр нь шинэчилж болох ажил. Ижил төрлийн хүсэлтийг эцсийн хугацаагаар нь хоёр урсгалд салгана.

Жишээлбэл, өглөөний тайланд орох ангиллыг өмнөх орой илгээж болно. Харин өглөө үүсээд тэр даруй хэрэглэгдэх хүсэлтэд ижил хүлээлт тохирохгүй. Batch цонх дуусахаас өмнө заавал бэлэн байх ажлыг эрт илгээх эсвэл шуурхай горимд үлдээх босгыг ажлынхаа эцсийн хугацаанаас ухрааж тогтоо.

Нийт хэмнэлтийг хэрхэн тооцох вэ?

Claude-ийн үнийн тайлбар batch горимын оролт, гаралтын токенд 50% хөнгөлөлт үйлчилж, prompt caching-ийн үнийн үржүүлэгчтэй давхар тооцогддогийг заадаг. Иймээс нэг загвар, ижил оролт ба гаралтын хэмжээ, ижил cache нөхцөлтэй хүсэлтийг л шуурхай болон batch үнээр шууд харьцуул. Өөр загвар сонгох эсвэл prompt-оо өөрчлөхөд токены хэрэглээ өөр болж, хөнгөлөлтийн үр дүнг тусгаарлан хэмжихэд хэцүү болно.

Нөхцөлт тооцоо: 10 000 хүсэлт тус бүр шуурхай горимд дунджаар 0.01 ам.долларын токены өртөгтэй, тэдгээрийн 70%-ийг batch-д шилжүүлж чадна гэж үзье. Бүгдийг шуурхай явуулахад 100 ам.доллар болно. Харин үлдэх 3 000 хүсэлт 30 ам.доллар, batch-д орох 7 000 хүсэлт 35 ам.доллар болж, нийт 65 ам.доллар гарна. Энэ жишээнд шилжсэн ажлын өртөг 50%, бүх урсгалын өртөг 35% буурч байна.

Бодит төсөвт нэг хүсэлтийн тогтмол үнэ таамаглахын оронд оролт, гаралтын токеныг тусад нь тоол. Сонгосон загварын тарифыг хэрэглэж, batch хөнгөлөлтийг зөвхөн шилжих ажлын өртөгт тооцно. Дахин ажиллуулсан хүсэлт, cache-ийн бичилт ба уншилт, ашигласан нэмэлт үйлчилгээний төлбөрийг тусдаа мөрөөр бүртгэвэл тооцоо бодит төлбөртэйгээ тулна.

OpenAI-ийн оролтын файлыг яаж бэлдэх вэ?

OpenAI-ийн batch үүсгэх лавлахад оролтыг batch зориулалтаар байршуулсан JSONL файл байх, нэг багцад 50 000 хүртэлх хүсэлт, 200 MB хүртэлх файл оруулах нөхцөлийг заасан. Batch үүсгэхдээ байршуулсан файлын ID, endpoint болон гүйцэтгэлийн цонхыг дамжуулна. JSONL-ийн мөр бүр тусдаа хүсэлт тул файл илгээхээс өмнө мөр бүрийг хүчинтэй JSON мөн эсэхийг шалга.

OpenAI-ийн оролтын мөрд custom_id, method, url, body талбарууд орно. custom_id-г тухайн файл дотор давтагдахгүй өгөөд, эх өгөгдлийн бичлэг болон ажлын хувилбартай холбож өөрийн системд хадгал. Жишээлбэл, бүтээгдэхүүн ангилах ажилд бичлэгийн ID дээр ажлын хувилбарыг нэмбэл хуучин болон шинэ ангиллын хариу хоорондоо холилдохгүй.

Нэг оролтын файлын хүсэлтүүдийг ижил endpoint, ижил загварын шаардлагад нийцүүл. Ангилал ба embedding өөр хүсэлтийн бүтэцтэй тул тусдаа багцад бэлтгэх нь алдааг ялгаж, өртгийг тооцоход хялбар. Их хэмжээний ажил илгээхээс өмнө цөөн мөрөөр файлын бүтэц, model нэр, body-ийн талбарууд болон гаралтын боловсруулалтаа шалгах нь засах шаардлагатай хүсэлтийг олноор нь үүсгэхээс сэргийлнэ.

Хариуг зөв бичлэгт хэрхэн тааруулах вэ?

Гаралтын мөрүүдийн дараалал оролтынхтой адил байх албагүй. Тиймээс мөрийн байрлалаар бус, custom_id-гаар эх хүсэлтийг олж, хариуг зөв бичлэгт хадгал. Гаралтын файлыг татаж авах ажиллагаа тасрах эсвэл боловсруулах програм дахин асах үед энэ холбоо хариуг дахин тааруулах үндэс болно.

custom_id бүрийн төлөвийг өөрийн өгөгдлийн санд хадгалбал үр дүн боловсруулах үйлдлийг давтаж болно. Амжилттай хариу аль хэдийн бүртгэгдсэн бол дахин уншсан мөрийг шинэ ажил гэж үзэхгүй; бүртгэгдээгүй мөрийг л нөхнө. Алдааны файлын ID-г мөн эх хүсэлттэй нь холбосноор бүх багцыг бус, зөвхөн шийдээгүй хэсгийг дахин ажиллуулах боломжтой.

Expired болон failed хүсэлтийг яаж сэргээх вэ?

OpenAI-д failed төлөв нь оролтын файл баталгаажуулалтад унасныг, expired төлөв нь багц гүйцэтгэлийн цонхондоо бүрэн дуусаагүйг илэрхийлнэ. Expired багцын дууссан хүсэлтүүд гаралтын файлд үлдэж, дуусаагүй хүсэлтүүд алдааны файлд тэмдэглэгддэг. Иймээс багцын төлөвийг хараад бүх оролтыг дахин илгээх нь аль хэдийн дууссан ажлыг давтах эрсдэлтэй.

1. Batch-ийн төлөв, нийт, дууссан болон алдаатай хүсэлтийн тоог ав. Байгаа бол гаралт ба алдааны файлыг тат.
2. Гаралтын custom_id бүрийг амжилттай үр дүнтэй нь бүртгэ. Алдааны ID болон үр дүнгүй үлдсэн ID-г анхны оролттой тулга.
3. Failed багцын файлын бүтцийн алдааг зассаны дараа дахин байршуул. Expired багцад зөвхөн дуусаагүй хүсэлтээр шинэ файл бэлтгэ.
4. Дахин илгээхийн өмнө ID-д амжилттай үр дүн хожим бүртгэгдээгүйг шалга. Шинэ batch ID-г өмнөх оролдлоготой нь холбон хадгал.

Дахин ажиллуулах үед хүсэлтийн body-г таамгаар сэргээх хэрэггүй: анх илгээсэн агуулга, ашигласан загвар, ажлын хувилбарыг хадгалсан бүртгэлээс ав. Эцсийн хугацаа тулсан үлдэгдлийг шуурхай горимд шилжүүлэхэд өртөг нь өснө; хүлээж болох үлдэгдлийг шинэ batch-д оруулж болно. Энэ сонголтыг ажил эхлэхээс өмнө тогтоосон хугацааны босгоор шийдвэл хэмнэлтээс болж хэрэгтэй үр дүнгээ хоцроохгүй.

Мөн уншаарай:

• OpenAI API эсвэл Azure OpenAI: ижил загварын саатал ижил биш
• Local LLM үргэлж хямд биш: cache хийсэн API нэгж өртгөөр ялжээ
• UiPath агентын ажлыг зураглана: зөрүүтэй дүрэм автоматаар батлагдахгүй