Part ০৭
Inference (model চালানো)
API-ভিত্তিক বনাম নিজে host করা inference; vLLM, TGI, SGLang, Ollama, llama.cpp; GGUF/AWQ/GPTQ/INT4-INT8 quantisation; KV cache, prefix caching, speculative decoding; continuous batching; TTFT বনাম TPS; GPU-র অর্থনীতি, edge inference, আর বড় বড় hosted provider (Together, Fireworks, Groq, Cerebras, Replicate, AWS Bedrock)। প্রতিটি section দুই ভাবে লেখা: engineer-এর জন্য technical version (code আর diagram সহ), আর সাধারণ পাঠকের জন্য সহজ ভাষায় ব্যাখ্যা (উপমা সহ)। প্রতিটি topic-এর শেষে বাংলা ব্যাখ্যাও আছে।
১টি section · ৩০টি source · তিনভাবে ব্যাখ্যা
01
Inference: server, quantization আর provider
প্রতিটা LLM call-এর দুই দিক: আপনার পাঠানো request, আর সেটা যে inference সামলায়। বেশিরভাগ team শুরুতে ভাড়া নেয় (Together, Fireworks, Groq, Cerebras, Replicate, AWS Bedrock)। ব্যবহার যথেষ্ট বাড়লে তারা vLLM, TGI, SGLang, Ollama বা llama.cpp দিয়ে নিজে host করে। তখন optimization-এর একদম নতুন শব্দভান্ডার শিখতে হয়: KV cache, prefix caching, speculative decoding, continuous batching।
অনুশীলন · ৪টি task
যেকোনো free AI chat খোলো: ChatGPT · Claude · Gemini
অনুশীলন কীভাবে করবে
- নতুন chat মানে একদম নতুন কথোপকথন, আগের কোনো history নেই। ChatGPT, Claude বা Gemini-তে New chat-এ click করো। সাধারণত এটা উপরে বাঁ দিকে থাকে।
- একই chat মানে: যে chat খোলা আছে, সেখানেই লিখতে থাকো। আগে যা পাঠিয়েছ, AI তা মনে রাখে।
- Prompt ব্যবহার করতে: Copy-তে click করো, chat-এর message box-এ click করো, paste করো (Ctrl+V, বা phone-এ চেপে ধরে রাখো), তারপর Enter চাপো।
- AI-এর উত্তর প্রতিবার একটু আলাদা হয়। তোমার উত্তর example-এর সাথে হুবহু মিলতে হবে না। একই ধারণা আছে কি না, সেটা দেখো।
- শুধু বানানো data ব্যবহার করো। নিজের বা অন্যের ব্যক্তিগত তথ্য chat-এ paste করবে না।
Task ১
ঠিক করো: hosted API, না self-host
এটা কেন দরকার
তোমার chatbot জনপ্রিয় হলে কেউ একসময় প্রশ্ন করবে: আমরা কি hosted API-তে টাকা দিতে থাকব, না নিজেদের GPU-তে model চালাব? উত্তর দেওয়ার আগে খরচের অঙ্ক কষতে হবে।
ধাপ ১
নতুন chatএই prompt টা copy করো, paste করে Enter চাপো। এটা দুই option-এর মাসিক খরচ জানতে চায়।
Prompt Scenario (সব সংখ্যা বানানো): ShopLink নামে একটা ছোট কোম্পানি একটা customer-support chatbot চালায়। প্রতি মাসে সেটা 2 billion token ব্যবহার করে। Option 1, hosted API: প্রতি 1 million token-এ 0.50 USD। Option 2, self-host: প্রতি ঘণ্টায় 3 USD দরে 2টা GPU ভাড়া, মাসে 730 ঘণ্টা, সাথে অর্ধেক সময়ের একজন ML engineer, মাসে 3,000 USD। বিদ্যুৎ আর storage-এর ছোট খরচ ধরবে না। কাজ: 1. প্রতিটা option-এর মাসিক খরচ বের করো। হিসাব দেখাও। 2. Break-even বের করো: মাসে কত token হলে দুটো option-এর খরচ সমান হয়? একটা ছোট table দিয়ে উত্তর দাও, তারপর এক বাক্যে বলো এখন কোনটা সস্তা।
তুমি দেখবে: Hosted-এ মাসে প্রায় 1,000 USD লাগে। Self-host-এ প্রায় 7,380 USD। Break-even মাসে প্রায় 14.8 billion token। 2 billion token-এ hosted সস্তা।
Example উত্তর
Hosted: 2,000 million token × 0.50 USD = মাসে 1,000 USD। Self-host: GPU 2 × 3 × 730 = 4,380 USD, সাথে engineer 3,000 USD = মাসে 7,380 USD। Break-even: 7,380 ÷ 0.50 = 14,760 million token, অর্থাৎ মাসে প্রায় 14.8 billion। 2 billion token-এ hosted API সস্তা।
তোমার উত্তরের ভাষা একটু আলাদা হবে।
ধাপ ২
একই chatএকটা সংখ্যা নিজে calculator-এ মিলিয়ে দেখো: 2 × 3 × 730। উত্তরের GPU খরচের সাথে মেলাও।
তুমি দেখবে: 4,380 USD। এটা model-এর উত্তরের GPU খরচের সাথে মেলে।
ধাপ ৩
একই chatএই prompt টা copy করো, একই chat-এ paste করে Enter চাপো। কোম্পানি বড় হয়েছে, আর একটা privacy নিয়ম এসেছে।
Prompt এবার অবস্থা বদলেছে। ShopLink-এর ব্যবহার বেড়ে মাসে 20 billion token হয়েছে। একজন নতুন customer আরও বলেছে, chat-এর লেখা কখনো ShopLink-এর নিজের server-এর বাইরে যেতে পারবে না। আগের দামই ধরো। ধরে নাও ওই 2টা GPU-ই এই load সামলাতে পারে। এখন তুমি কী recommend করবে, আর কেন? দুই option-এর মাসিক খরচ দাও, আর 120 শব্দের কম লিখে উত্তর দাও।
তুমি দেখবে: Hosted-এ এখন প্রায় 10,000 USD। Self-host থাকে 7,380 USD। বেশিরভাগ model খরচ আর privacy, দুই কারণেই self-host recommend করে।
Example উত্তর
আমি self-host recommend করব। Hosted: 20,000 million token × 0.50 USD = মাসে 10,000 USD। Self-host: মাসে 7,380 USD, আগের মতোই। এখন self-host সস্তা, আর এতে chat-এর লেখা ShopLink-এর নিজের server-এই থাকে, যা নতুন customer চেয়েছে।
তোমার উত্তরের ভাষা একটু আলাদা হবে।
এইমাত্র কী হলো
Token বাড়লে hosted API-র খরচও বাড়ে (token হলো লেখার ছোট একটা টুকরো, প্রায় একটা শব্দের মতো)। Self-host-এ খরচ স্থির: GPU আর একজন engineer, traffic যা-ই হোক। 2 billion token-এ এই স্থির খরচ অনেক বড়। 20 billion token-এ সেটা API-র bill-এর চেয়ে ছোট। Privacy-র নিয়মও তোমাকে self-host করতে বাধ্য করতে পারে।
কাজ শেষ, যখন তোমার কাছে দুই অবস্থার জন্য দুই option-এর মাসিক খরচ আছে, আর GPU খরচ তুমি নিজে হাতে মিলিয়েছ।
নিজেকে যাচাই করোবেশিরভাগ team প্রথমে hosted API দিয়ে শুরু করে, পরে self-host-এ যায় কেন?উত্তর দেখো
Hosted API দিয়ে দ্রুত শুরু করা যায়, আর load সামলানো vendor-এর কাজ। Self-host-এ স্থির খরচ আছে, তাই এটা লাভজনক হয় শুধু যখন token-এর bill অনেক বড়, অথবা privacy বা পুরো নিয়ন্ত্রণ দরকার।
Task ২
16, 8, 4 bit-এ model-এর memory হিসাব করো
এটা কেন দরকার
একটা model চালানোর জন্য বাছার সময় প্রথম প্রশ্ন: এটা কি আমার GPU বা laptop-এর memory-তে ধরবে? 140 GB-এর file download করার আগেই একটা সহজ হিসাবে কয়েক সেকেন্ডে এর উত্তর পাওয়া যায়।
ধাপ ১
নতুন chatএই prompt টা copy করো, paste করে Enter চাপো। Model 70 billion parameter-এর model-এর জন্য একটা memory table বানাবে।
Prompt একটা language model-এর 70 billion parameter আছে। এই নিয়মটা ব্যবহার করো: weight-এর memory (GB) = billion-এ parameter সংখ্যা × প্রতি weight-এর bit ÷ 8। 16-bit, 8-bit আর 4-bit-এ weight-এর memory-র একটা table বানাও। তারপর বলো এর মধ্যে কোনগুলো 80 GB memory-র একটা GPU-তে ধরে। শেষে এক বাক্যে বলো, weight ছাড়া server-এর run করার সময় আর কী ধরনের memory লাগে।
তুমি দেখবে: 16-bit-এ 140 GB, 8-bit-এ 70 GB, 4-bit-এ 35 GB। 80 GB-তে শুধু 8-bit আর 4-bit ধরে, আর 8-bit-এ জায়গা খুব কম থাকে।
Example উত্তর
Weight memory = 70 × bit ÷ 8 16-bit: 70 × 16 ÷ 8 = 140 GB 8-bit: 70 × 8 ÷ 8 = 70 GB 4-bit: 70 × 4 ÷ 8 = 35 GB 80 GB-র একটা GPU-তে ধরে: 8-bit (তবে জায়গা খুব কম বাকি থাকে) আর 4-bit। 16-bit ধরে না। Weight ছাড়াও server-এর KV cache-এর জন্য memory লাগে, যা এ পর্যন্ত পড়া লেখার model-এর স্বল্পমেয়াদি স্মৃতি।
তোমার উত্তরের ভাষা একটু আলাদা হবে।
ধাপ ২
একই chatএই prompt টা copy করো, একই chat-এ paste করে Enter চাপো। এবার লক্ষ্য 8 GB খালি জায়গার একটা laptop।
Prompt আমি আমার laptop-এ 8 billion parameter-এর একটা model চালাতে চাই। Laptop-এ 16 GB RAM আছে, তার প্রায় 8 GB model-এর জন্য খালি। একই নিয়ম ব্যবহার করে বলো, কোন precision (16-bit, 8-bit, না 4-bit) আমি ব্যবহার করতে পারব? প্রতিটার memory দাও। তারপর সবচেয়ে ছোট precision ব্যবহারের একটা ঝুঁকি বলো।
তুমি দেখবে: 8B model: 16 GB, 8 GB, 4 GB। শুধু 4-bit আরামে ধরে। 8-bit পুরো 8 GB নিয়ে নেয়, তাই সেটা খুব টানাটানি।
Example উত্তর
16-bit: 8 × 16 ÷ 8 = 16 GB। অনেক বড়। 8-bit: 8 × 8 ÷ 8 = 8 GB। তোমার পুরো খালি memory লাগবে, তাই খুব টানাটানি। 4-bit: 8 × 4 ÷ 8 = 4 GB। এটা ধরে। 4-bit ব্যবহার করো। একটা ঝুঁকি: উত্তরের মান একটু খারাপ হতে পারে, যেমন কঠিন প্রশ্নে ভুল বাড়তে পারে।
তোমার উত্তরের ভাষা একটু আলাদা হবে।
এইমাত্র কী হলো
একটা model আসলে অনেক বড় একটা সংখ্যার list, যাকে বলে weight। 16 bit-এ প্রতিটা সংখ্যা 2 byte নেয়। Quantization প্রতিটা সংখ্যা কম bit-এ (8 বা 4) রাখে, তাই model-এর 2 থেকে 4 গুণ কম memory লাগে। দাম হলো মানে সামান্য কমতি। Weight-ই পুরো memory না: server-এর KV cache-এর জন্যও memory লাগে (এ পর্যন্ত পড়া লেখার স্বল্পমেয়াদি স্মৃতি)।
কাজ শেষ, যখন তোমার কাছে 70B model-এর memory table (140, 70, 35 GB) আর 8B model-এর table (16, 8, 4 GB) আছে।
নিজেকে যাচাই করোQuantization কী বদলায়, আর তার trade-off কী?উত্তর দেখো
এটা weight-কে কম bit-এ রাখে, যেমন 16-এর বদলে 4, তাই model-এর প্রায় 2 থেকে 4 গুণ কম memory লাগে আর সেটা দ্রুত চলে। বেশিরভাগ কাজে এর দাম হলো মানে সামান্য কমতি।
Task ৩
Prefix caching-এ কত সাশ্রয়, হিসাব করো
এটা কেন দরকার
তুমি যখন একটা support bot বানাবে, প্রতিটা request-এ একই লম্বা instruction বারবার যায়। সেই token-গুলোর দাম তুমি বারবার দাও। Prompt সঠিক ক্রমে লিখলে caching এই bill অনেক কমাতে পারে।
ধাপ ১
নতুন chatআগে আন্দাজ করো: caching কি খরচের অর্ধেকের বেশি বাঁচাবে? তারপর এই prompt টা copy করো, paste করে Enter চাপো।
Prompt একটা support bot দিনে 10,000টা request পায় (সব সংখ্যা বানানো)। প্রতিটা request একই 3,000 token-এর system prompt দিয়ে শুরু হয়। User-এর message আরও 100 token যোগ করে। Input token-এর দাম 1 million-এ 1 USD। Cached input token-এর দাম 1 million-এ 0.10 USD (90% ছাড়)। দিনের input খরচ বের করো: (1) prefix caching ছাড়া, আর (2) prefix caching-সহ, যেখানে system prompt cache করা। হিসাব দেখাও। তারপর সাশ্রয়টা শতাংশে দাও।
তুমি দেখবে: Caching ছাড়া: দিনে 31 USD। Caching-সহ: দিনে 4 USD। সাশ্রয় প্রায় 87%। তুমি 'অর্ধেকের বেশি' বললে তোমার আন্দাজ ঠিক ছিল।
Example উত্তর
Caching ছাড়া: 3,100 token × 10,000 = 31 million token × 1 USD = দিনে 31 USD। Caching-সহ: cache করা অংশ 3,000 × 10,000 = 30 million token × 0.10 USD = 3 USD। নতুন অংশ 100 × 10,000 = 1 million token × 1 USD = 1 USD। মোট 4 USD। সাশ্রয়: 27 USD, প্রায় 87%।
তোমার উত্তরের ভাষা একটু আলাদা হবে।
ধাপ ২
একই chatভাবো: prompt আজকের তারিখ আর user-এর নাম দিয়ে শুরু হলে কী সমস্যা হবে? তারপর এই prompt টা copy করো, একই chat-এ paste করে Enter চাপো।
Prompt Team এখন system prompt বদলেছে। প্রথম লাইন হয়েছে: "Today is {current date and time}. The user's name is {name}."। বাকি 3,000 token আগের মতোই আছে। এখন prefix caching ভালো কাজ করছে না। 3টা ছোট বাক্যে কারণটা বুঝিয়ে বলো, আর prompt কীভাবে বদলালে cache আবার কাজ করবে, সেটা দেখাও।তুমি দেখবে: তারিখ আর নাম প্রতিটা request-এ বদলায়, তাই prompt-এর শুরুটা কখনো একই থাকে না। Cache আর ব্যবহার করা যায় না। সমাধান: স্থির লেখা আগে, বদলানো লেখা শেষে রাখো।
Example উত্তর
তারিখ, সময় আর নাম প্রতিটা request-এ বদলায়। Prompt-এর শুরু হুবহু এক থাকলেই শুধু cache কাজ করে, তাই server-কে প্রতিবার শূন্য থেকে কাজ করতে হয়। সমাধান: আগে 3,000 token-এর স্থির অংশ রাখো, তারপর শেষে তারিখ, সময় আর নাম যোগ করো: [fixed system prompt] Today is {date}. The user's name is {name}.তোমার উত্তরের ভাষা একটু আলাদা হবে।
এইমাত্র কী হলো
Server তোমার prompt-এর শুরুর অংশে অনেক কাজ করে আর সেটা জমিয়ে রাখে। এই জমানো কাজের নাম KV cache। Prefix caching থাকলে একই লেখা দিয়ে শুরু হওয়া নতুন request সেটা আবার ব্যবহার করে, আর ওই অংশের জন্য তুমি প্রায় 90% কম দাও। কিন্তু মিল হতে হবে প্রথম অক্ষর থেকে হুবহু। উপরের একটা বদলানো লাইনই এটা ভেঙে দেয়।
কাজ শেষ, যখন তোমার কাছে দিনের খরচ 31 USD আর 4 USD আছে, আর স্থির লেখা আগে রাখা একটা নতুন prompt আছে।
নিজেকে যাচাই করোPrompt-এর সবার জন্য এক রকম অংশ কেন আগে রাখতে হয়?উত্তর দেখো
Prompt-এর শুরু হুবহু মিললেই server cache আবার ব্যবহার করে। শুরুর দিকে কিছু বদলালে পুরো prompt নতুন মনে হয়, তাই cache hit হয় না।
Task ৪
Symptom দেখে inference metric চিনে নাও
এটা কেন দরকার
তুমি যখন নিজের model server চালাবে, user বলবে "এটা ধীর"। কিন্তু "ধীর" মানে চার রকম হতে পারে। আগে সঠিক metric চিনতে হবে, নইলে ভুল fix বাছবে।
ধাপ ১
নতুন chatএই prompt টা copy করো, paste করে Enter চাপো। উত্তর পড়ার আগে ৩ নম্বর symptom-এর metric কী হবে, আন্দাজ করো।
Prompt আমি একটা LLM inference server চালাই। প্রতিটা symptom-এর জন্য বলো কোন মূল metric খারাপ, আর ১টা সবচেয়ে ভালো fix বাছো। Metric: - TTFT: প্রথম শব্দ দেখা যাওয়া পর্যন্ত সময়। - TPS per request: একজন user-এর জন্য শব্দ কত দ্রুত আসে। - Aggregate throughput: সব user মিলিয়ে প্রতি সেকেন্ডে মোট token। - p99 latency: সবচেয়ে ধীর 1% request-এর সময় কত লাগে। Fix-এর list থেকে বাছো: prefix caching, continuous batching (server GPU-তে একসাথে অনেক request মিশিয়ে চালায়), speculative decoding (একটা ছোট model শব্দ আন্দাজ করে, বড় model সেগুলো যাচাই করে), ছোট prompt, ছোট বা quantized model, অথবা আরও GPU। Symptom: 1. User-রা 20,000 token-এর একটা document পাঠায়। প্রথম শব্দ আসার আগে তারা 6 সেকেন্ড অপেক্ষা করে। এরপর লেখা দ্রুত আসে। 2. Server-এ মাত্র একজন user থাকলেও লেখা আসে প্রতি সেকেন্ডে 8 token, যা ধীর লাগে। 3. GPU প্রায় 60% সময় বসে থাকে। Server একটা request পুরোপুরি শেষ করে তারপর পরেরটা শুরু করে। সব user মিলিয়ে প্রতি সেকেন্ডে token কম। 4. বেশিরভাগ request দ্রুত, কিন্তু queue লম্বা হলে সবচেয়ে ধীর 1% request-এ 40 সেকেন্ড লাগে। একটা table দিয়ে উত্তর দাও: symptom নম্বর, metric, fix, আর 12 শব্দ বা কম শব্দে কারণ।
তুমি দেখবে: ৪ সারির একটা table। মোটামুটি: ১ হলো TTFT, ২ হলো TPS per request, ৩ হলো aggregate throughput, ৪ হলো p99 latency। কিছু symptom-এর একাধিক ভালো fix থাকতে পারে।
Example উত্তর
1 | TTFT | ছোট prompt | লম্বা prompt-এ প্রথম শব্দ দেরিতে আসে 2 | TPS per request | speculative decoding | আন্দাজ করা শব্দে এক user-এর stream দ্রুত হয় 3 | Aggregate throughput | continuous batching | request মিশিয়ে চালায়, GPU বসে থাকে না 4 | p99 latency | আরও GPU | লম্বা queue ধীরতম request-কে কষ্ট দেয়
তোমার উত্তরের ভাষা একটু আলাদা হবে।
ধাপ ২
একই chatএই প্রশ্নটা copy করো, একই chat-এ paste করে Enter চাপো। উত্তরটা table-এর সাথে মেলাও।
Prompt একটা server-এর aggregate throughput বেশি হয়েও কি একজন user-এর কাছে ধীর লাগতে পারে? ২টা ছোট বাক্যে উত্তর দাও।
তুমি দেখবে: হ্যাঁ। Throughput সব user মিলিয়ে গোনে, কিন্তু একজন user শুধু নিজের অপেক্ষা আর নিজের গতি টের পায়।
Example উত্তর
হ্যাঁ। Throughput সব user-এর token একসাথে গোনে, তাই ব্যস্ত server-এর স্কোর বেশি হতে পারে। তবুও একজন user শুধু প্রথম শব্দের জন্য নিজের অপেক্ষা আর নিজের গতি টের পায়, আর লম্বা queue হলে সেই অপেক্ষা বড় হতে পারে।
তোমার উত্তরের ভাষা একটু আলাদা হবে।
এইমাত্র কী হলো
"ধীর"-এর চারটা চেহারা আছে। TTFT (প্রথম শব্দ আসার সময়) হলো অপেক্ষা। TPS per request হলো এক user-এর stream-এর গতি। Aggregate throughput হলো server-এর মোট কাজ। p99 latency হলো সবচেয়ে ধীর 1% user-এর অপেক্ষা। প্রতিটার fix আলাদা।
কাজ শেষ, যখন তোমার কাছে ৪টা symptom-এর metric আর fix-সহ একটা table আছে, আর throughput বনাম এক user-এর অনুভূতি নিয়ে একটা পরিষ্কার উত্তর আছে।
নিজেকে যাচাই করো২ নম্বর symptom-টা মাত্র একজন user থাকলেও হয়। Continuous batching এটা ঠিক করতে পারে না কেন?উত্তর দেখো
Continuous batching তখনই কাজে লাগে যখন অনেক user একটা GPU ভাগ করে, তাই এটা মোট throughput বাড়ায়। একজন user থাকলে GPU আগে থেকেই শুধু তার জন্যই কাজ করছে। ওই এক stream দ্রুত করতে ছোট বা quantized model, অথবা speculative decoding লাগে।
ভিডিও দেখো · ৮টি
Hosted LLM APIs vs. Self-Hosting: The Ultimate LLM Ops Decision Guide Analytics Vidhya
What is vLLM? Efficient AI Inference for Large Language Models IBM Technology
Which Quantization Method is Right for You? (GPTQ vs. GGUF vs. AWQ) Maarten Grootendorst
KV Cache in LLMs Explained Visually | How LLMs Generate Tokens Faster ExplainingAI
Accelerating LLM inference with speculative decoding: From Zero to Hero, By Eldar Kurtić ARGO Vision
An Intermediate Guide to Inference Using vLLM Red Hat Open
LLM’s INFERENCE: Cost vs. Latency vs. Throughput César Soto Valero
TLMs: Tiny LLMs and Agents on Edge Devices with LiteRT-LM — Cormac Brick, Google AI Engineer
তথ্যসূত্র
Sources
সব citation মূল paper (arXiv), vendor-এর docs (OpenAI, Anthropic, Google) বা official team blog-এ যায়। প্রতিটি পাতা খুলে citation-এর তথ্য যাচাই করা হয়েছে।
- [1]Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (ICLR 2023)
- [2]Wei et al., "Plan-and-Execute Agents" / "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" — NeurIPS 2022
- [3]Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning" — NeurIPS 2023
- [4]Xu et al., "ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models"
- [5]Anthropic Engineering blog — "How we built our multi-agent research system" (2025)
- [6]LangGraph — official documentation (LangChain)
- [7]Temporal — "Durable Execution for LLM Agents"
- [8]Park et al., "Generative Agents: Interactive Simulacra of Human Behavior" — 2023
- [9]Anthropic — "Introducing computer use, a new Claude 3.5 Sonnet capability" (Oct 2024)
- [10]Anthropic — Tool use / function calling documentation
- [11]OpenAI — Function calling guide
- [12]Anthropic — Model Context Protocol (MCP) specification
- [13]Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention" — vLLM paper, SOSP 2023
- [14]Zheng et al., "SGLang: Efficient Execution of Structured Language Model Programs" — 2023
- [15]llama.cpp — open-source GGUF-native inference (ggerganov)
- [16]Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration" — MLSys 2024
- [17]Anthropic — Prompt caching documentation
- [18]Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" — NeurIPS 2023
- [19]Es et al., "Ragas: Automated Evaluation of Information Retrieval Augmented Language Models" — 2023
- [20]Yue et al., "Large Language Model Cascades with Mixture of Thought Representations" — 2024
- [21]GPTCache — open-source semantic cache
- [22]Guo et al., "DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via RL" — 2025
- [23]Jiang et al., "LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models" — EMNLP 2023
- [24]LiteLLM — unified interface for 100+ LLMs
- [25]OWASP — "Top 10 for LLM Applications" (LLM01 Prompt Injection, 2025)
- [26]Bai et al., "Constitutional AI: Harmlessness from AI Feedback" — Anthropic, 2022
- [27]NVIDIA NeMo Guardrails — open-source toolkit
- [28]Qwen2-VL Team, "Qwen2-VL: Enhancing Vision-Language Model's Perception of the World at Any Resolution" — 2024
- [29]OpenAI — Realtime API documentation
- [30]OpenAI — Production best practices guide