點擊下方“JavaEdge”，選擇“設(shè)為星標(biāo)”

第一時間關(guān)注技術(shù)干貨！

免責(zé)聲明~ 任何文章不要過度深思！ 萬事萬物都經(jīng)不起審視，因為世上沒有同樣的成長環(huán)境，也沒有同樣的認(rèn)知水平，更「沒有適用于所有人的解決方案」； 不要急著評判文章列出的觀點，只需代入其中，適度審視一番自己即可，能「跳脫出來從外人的角度看看現(xiàn)在的自己處在什么樣的階段」才不為俗人。 怎么想、怎么做，全在乎自己「不斷實踐中尋找適合自己的大道」

0 前言

今天我會首先解釋為什么 LLM 的部署很難，因為許多人可能并不理解其中的復(fù)雜性。接著，我會分享七個提高 LLM 部署效果的技巧和方法。

1 為啥 LLM 部署困難？

“最近在忙啥？”

“我一直在讓 LLM 服務(wù)變得更簡單�！�

“LLM 部署難嗎？不是直接調(diào)用 OpenAI API 就行？”

“某種程度上是這樣�！币驗樘岬� LLM，大多數(shù)人只會想到 OpenAI，調(diào)用 API 確實簡單。她為什么要談這些內(nèi)容？調(diào)用 API 誰不會？但實際上，訪問 LLM 的方式不止一種�？捎猛泄艿腁PI如 OpenAI、Cohere、Anthropic 和 AI21 Labs 等。他們已為你完成托管和部署，你只需調(diào)它們。雖然這確實減少你的工作量，但仍存在復(fù)雜性，如減少幻覺輸出。不過，他們已經(jīng)完成很多繁重任務(wù)。很多場景，你可能更傾向自托管，如調(diào)用 Mistral或托管 Llama 或其他模型。這意味著你在自己的環(huán)境中托管它，無論VPC還是PC。

那為啥還自托管？

很多原因：

• 降低大規(guī)模部署成本。如只做概念驗證，基于 OpenAI API 模型成本確實低。但如大規(guī)模部署，自托管最終成本更低。因為只需解決自己的業(yè)務(wù)問題，可用更小模型，而 OpenAI 必須托管一個能解決編程和寫作莎士比亞問題的大模型，因此需要更大的模型。大規(guī)模部署時，自托管成本會低得多

• 性能提升。當(dāng)你用特定任務(wù)的LLM或?qū)ζ湮⒄{(diào)，使其專注你的任務(wù)，通常得到更好性能

• 大多數(shù)客戶選擇自托管的原因：隱私和安全。如你處受監(jiān)管行業(yè)，如需遵循 GDPR 或滿足合規(guī)團隊的要求，你可能也需自托管

如果這幾點不重要，就用 API 夠了。

企業(yè)選擇開源的主要原因

包括控制權(quán)、定制化和成本。最重要的是控制權(quán)。擁有 AI 獨立性至關(guān)重要，如當(dāng) OpenAI 再次解雇 CEO，你仍可訪問自己的模型，尤其是當(dāng)你構(gòu)建重要的業(yè)務(wù)應(yīng)用時。如果你正在考慮自托管，你絕對不是孤軍奮戰(zhàn)，大多數(shù)企業(yè)都在努力建立自托管能力。

對沖基金的一員說：“隱私對我的用例很重要，因此自托管是有意義的�！比缓笏赡軙䥺枺骸白酝泄苷娴挠心敲措y嗎？”我經(jīng)常聽到類似的話，這讓我非常惱火。答案是：確實更難。你不能忽視那些你看不到的復(fù)雜性。當(dāng)你調(diào)用基于 API 的模型時，你受益于他們的工程師在構(gòu)建推理和服務(wù)基礎(chǔ)設(shè)施方面所做的所有努力。實際上，像 OpenAI 這樣的公司有 50 到 100 人的團隊在管理這些基礎(chǔ)設(shè)施。包括模型壓縮、Kubernetes、批處理服務(wù)器、函數(shù)調(diào)用、JSON 生成、運行時引擎等。當(dāng)你使用 API 模型時，這些你都不需要操心，但當(dāng)你自托管時，這些問題突然變成了你的責(zé)任。

他可能會說：“但我經(jīng)常部署機器學(xué)習(xí)模型，比如 XGBoost 或線性回歸模型。部署這些 LLM 會有多難？”我們的回答是：“你知道 L 代表什么嗎？”部署這些模型要困難得多。為什么呢？LLM 中的第一個 L 代表“大”（Large）。我記得我們剛成立公司時，認(rèn)為一個擁有 1 億參數(shù)的 BERT 模型已經(jīng)算大了。現(xiàn)在，一個擁有 70 億參數(shù)的模型被認(rèn)為是小型模型，但它仍然有 14GB 的大小，這絕對不小。

第二個原因是 GPU。與 CPU 相比，GPU 更難處理，它們也更昂貴，因此高效利用 GPU 十分重要。如果你對 CPU 的利用率不高，可能問題不大，因為它們成本低得多。但對于 GPU，成本、延遲和性能之間的權(quán)衡非常明顯，這是以前可能沒有遇到過的。

第三個原因是，這個領(lǐng)域發(fā)展非常快。我們現(xiàn)在用于部署、優(yōu)化和服務(wù)模型的技術(shù)，有一半在一年前還不存在。還有一個值得一提的問題是編排問題。通常，對于這些大語言模型應(yīng)用，你需要協(xié)調(diào)多個不同的模型。例如，RAG（檢索增強生成）就是一個典型的例子。你需要協(xié)調(diào)一個嵌入模型和一個生成模型。如果是最先進的 RAG，你可能還需要多個解析模型，比如圖像模型和表格模型，此外還需要一個重排序模型。最終，你可能會用到五六個不同的模型。這會讓人感到非常困惑。此外，部署應(yīng)用還有其他常見難點，比如擴展性和可觀察性。

2 咋讓 LLM 部署更輕松？

分享一些讓 LLM 部署更輕松的技巧。雖然仍會很痛苦，但不會那么糟糕。

1. 知道你的部署邊界

構(gòu)建應(yīng)用程序時，應(yīng)解你的部署邊界。通常，人們在構(gòu)建出一個自認(rèn)為可行的應(yīng)用程序后，才開始考慮部署邊界。我認(rèn)為，你應(yīng)該先花時間思考你的需求，這會讓后續(xù)一切變得更簡單。如考慮你的：

• 延遲需求是什么？

• 預(yù)計負(fù)載是多少？

• 應(yīng)用程序是頂多只有三個用戶，還是像 DoorDash 一樣要服務(wù)數(shù)百萬用戶？

• 有什么硬件資源可用？

• 需要在本地部署，還是可用云實例？如是云實例，需要什么類型實例？

所有這些問題都要提前規(guī)劃。你可能無法知道精確需求，所以最好列出范圍。如：“只要延遲低于 1 秒就可以接受�！被颉爸灰哂谀硞�值也行。”。還有一些問題如：我是否需要保證輸出是 JSON 格式？是否需要保證輸出符合特定的正則表達式規(guī)則？這些都值得提前思考。

2. 始終進行量化

提前規(guī)劃好這些需求，那后續(xù)所有決策都容易得多。始終對模型進行量化。量化本質(zhì)是一種模型壓縮技術(shù)，它將LLM的權(quán)重精度降低到你想要的任何形式。4-bit 是我最喜歡的量化，從 FP32（32位浮點數(shù)）開始。因為它在準(zhǔn)確性和壓縮比之間達到極佳平衡。你可以看到這張圖表，我們有一個準(zhǔn)確性與模型位數(shù)的關(guān)系圖，也就是模型的大小。

假設(shè)原始模型是 FP16（16位浮點數(shù)），其實它通常是 32 位的。紅線表示它的準(zhǔn)確性。當(dāng)我們壓縮模型時，比如從 FP16 降低到 4-bit，固定資源下，使用量化模型的性能實際上要好于未量化的模型。通過這張圖表我們可以得出結(jié)論，對于固定資源，量化模型通常能夠在準(zhǔn)確性和資源利用率之間取得更好的平衡。

我們從基礎(chǔ)設(shè)施開始，倒推需求。假設(shè)我們可用 L40S GPU，它有 48GB 顯存。因為我們知道可用的資源，可以根據(jù)現(xiàn)有的模型倒推需求。如是 Llama 13B（130億參數(shù)）模型，它需要 26GB 顯存，沒問題，可運行。但如是當(dāng)前最先進 Mixtral 模型，它無法直接運行。然而，一個經(jīng) 4-bit 量化的 Mixtral 模型可運行，這就很棒了。通過這種方式，就知道哪些模型可用來實驗。

那個關(guān)于 Tim Dettmers 的圖表也告訴我們，4-bit 量化模型在性能上可能更優(yōu)。假設(shè) Llama 模型和 Mixtral 模型體積一樣，4-bit 模型通常會保留原來模型的高精度，同時大大減小了模型體積。我們通過基礎(chǔ)設(shè)施倒推，找到能適配資源的量化模型，這很可能是當(dāng)前性能最優(yōu)的解決方案。

3. 花時間優(yōu)化推理

建議只花一點時間是因為，部署這些模型時，你最初想到的策略往往是完全錯誤的。雖然你不需要花大量時間思考這個問題，但稍微投入一些時間，可以使 GPU 利用率提升幾個數(shù)量級。

舉個例子，關(guān)于批處理策略。批處理是指多個請求同時處理。部署這些模型時，GPU 利用率是最寶貴的資源。因為 GPU 很昂貴，所以最大化其利用率非常重要。

如果我不使用批處理，那么 GPU 的利用率大概是這樣的，非常糟糕。一個常見的錯誤做法是使用動態(tài)批處理，這種方法適用于非生成式 AI 應(yīng)用，比如你之前可能用過的系統(tǒng)。動態(tài)批處理的原理是等待一小段時間，收集在這段時間內(nèi)到達的請求，然后一起處理。在生成式模型中，這種方法會導(dǎo)致 GPU 利用率下降。開始時利用率很高，但隨后會下降，因為用戶會因較長的生成時間被卡在隊列中。

動態(tài)批處理雖然是常見做法，但通常效果不好。如果你花點時間思考這個問題，可以采用持續(xù)批處理（Continuous Batching）。這是我們使用的一種方法，也是當(dāng)前生成式模型的最先進批處理技術(shù)。它允許新到的請求中斷正在處理的請求，以保持 GPU 利用率始終處于高水平。這樣不僅減少了排隊時間，還大幅提升了資源利用效率。這張 GPU 利用率圖表是我們幾周前的狀態(tài)。相比動態(tài)批處理，持續(xù)批處理在 GPU 成本上可以帶來一個數(shù)量級的提升。這完全不影響模型準(zhǔn)確性，但大大提高了利用率。

對于非常大的模型，單個 GPU 無法滿足推理需求。例如，Llama 70B、Mixtral 或 Jamba 等模型非常龐大。通常需要將它們分布在多個 GPU 上進行推理。這要求你能夠設(shè)計一種多 GPU 推理的方法。最常見的方法（例如 Hugging Face 的 Accelerate 推理庫所使用的方式）是按層級劃分模型。如果模型占用 90GB，可以分配 30GB 給每個 GPU，共使用三個 GPU。然而，這種方法的缺點是每次只有一個 GPU 處于活躍狀態(tài)，導(dǎo)致資源浪費，因為后續(xù) GPU 需要等待前一個 GPU 完成任務(wù)。

這種方式存在局限性，例如在 Hugging Face Accelerate 庫中。我們認(rèn)為更優(yōu)的方法是Tensor Parallel。這種方式將模型按“長度”分割，使每個 GPU 能同時運行每一層，從而大幅提升推理速度，并支持任意大小的模型。所有 GPU 同時運行，因此避免了資源浪費。例如，在一個模型中，可以實現(xiàn) GPU 利用率提升 3 倍，再加上其他優(yōu)化，可以顯著提升資源效率。

4. 整合基礎(chǔ)設(shè)施

目前為止，我的建議包括：考慮部署需求、量化、推理優(yōu)化。第四個建議是整合基礎(chǔ)設(shè)施。生成式 AI 的計算成本非常高，因此集中的基礎(chǔ)設(shè)施管理能帶來很大優(yōu)勢。傳統(tǒng)企業(yè)的機器學(xué)習(xí)團隊往往以孤島形式存在，導(dǎo)致基礎(chǔ)設(shè)施整合效率低下。通過集中的 MLOps 團隊（如 Ian 所領(lǐng)導(dǎo)的團隊），可實現(xiàn)一次性部署并由單一團隊進行維護，這讓應(yīng)用開發(fā)團隊專注于構(gòu)建應(yīng)用。

舉個例子，一個中央計算基礎(chǔ)設(shè)施可以提供訪問模型（如 Llama 70、Mixtral 和 Gemma 7B）的權(quán)限，并由中央團隊定期更新模型（例如從 Llama 2 升級到 Llama 7）。各個應(yīng)用開發(fā)團隊可以個性化模型，例如添加LoRA（輕量化適配器）或RAG（結(jié)合專有數(shù)據(jù)的檢索增強生成）。中央團隊負(fù)責(zé)維護基礎(chǔ)設(shè)施，而分散的開發(fā)團隊僅需調(diào)用這些模型構(gòu)建應(yīng)用。這種方法不僅提高了 GPU 的利用率，還為組織提供類似 OpenAI 的體驗，但使用的是私有模型。

關(guān)鍵點包括：確保推理服務(wù)器具備可擴展性、支持 LoRA 適配器以實現(xiàn)微調(diào)。如果做好這些工作，可以顯著提升 GPU 利用率。GPU 的利用率非常重要，甚至可以說是僅次于家人和朋友的存在。

案例研究：RNL

一個美國企業(yè) RNL 擁有四個不同的生成式 AI 應(yīng)用，每個應(yīng)用使用獨立 GPU。這種方式導(dǎo)致了 GPU 利用率低下，因為不是所有應(yīng)用始終滿負(fù)荷運行。我們幫助他們將所有應(yīng)用資源整合到一個推理服務(wù)器中，使各團隊通過共享資源構(gòu)建應(yīng)用。這種方式將所需 GPU 數(shù)量減少了一半，同時也能更高效地管理生成式和非生成式任務(wù)。

5. 構(gòu)建時考慮模型替換周期

建議的第五點是，假設(shè)在 12 個月內(nèi)需要替換模型。隨著 LLM 的快速發(fā)展，僅通過切換模型即可獲得性能提升。例如，一個客戶去年使用 Llama 1 開發(fā)了首個應(yīng)用程序，在一年內(nèi)更換了四次模型。

每周他們都會說，這個新模型出來了。你們支持嗎？我會說，是的，但為什么這是第六次更改了？讓我們回想一下一年前最先進的技術(shù)是什么。一年前，也許那時Llama已經(jīng)發(fā)布了，但如果在那之前，可能是T5系列。T5模型是當(dāng)時最好的開源模型。我們所見證的是開源大語言模型生態(tài)系統(tǒng)的驚人爆發(fā)。這一切都始于Llama，然后是Llama 2，接著許多企業(yè)在此基礎(chǔ)上構(gòu)建。

例如，Mistral 70B實際上是用與Llama相同的架構(gòu)構(gòu)建的。我們有來自阿聯(lián)酋的Falcon。我們有Mistral的Mixtral。你們有很多，而且它們還在不斷涌現(xiàn)。實際上，如果你查看Hugging Face，這是所有這些模型存儲的地方，如果你查看他們的開源模型排行榜，頂級模型幾乎每周都在變化。最新和最偉大的模型不斷出現(xiàn)。這些模型將會不斷變得更好。這是所有模型的性能，無論是開源還是非開源，你可以看到許可證，專有的或非專有的。開源模型正在慢慢地占據(jù)排行榜。我們開始接近開源和非開源之間的平等�，F(xiàn)在，開源模型大約在GPT-3.5左右。那是我們所有人都為之驚嘆的原始ChatGPT。

我的預(yù)期是，我們將在未來一年內(nèi)達到GPT-4的質(zhì)量。這意味著你真的不應(yīng)該將自己與單一模型或單一供應(yīng)商綁定�；氐轿抑跋蚰銈冋故镜腶16z報告，大多數(shù)企業(yè)都在使用多個模型供應(yīng)商。他們正在以一種可互操作的方式構(gòu)建他們的推理棧，如果OpenAI出現(xiàn)故障，我可以輕松地將其替換為Llama模型�；蛘�，如果現(xiàn)在Claude比GPT-4更好，我可以很容易地替換它們。以這種可互操作性為念進行構(gòu)建真的很重要。我認(rèn)為OpenAI給我們的最偉大的事情不一定是他們的模型，盡管它們真的很棒，但他們實際上違反直覺地民主化了AI領(lǐng)域，不是因為他們開源了他們的模型，因為他們真的沒有，而是因為他們?yōu)樾袠I(yè)提供了API的統(tǒng)一性。如果你以O(shè)penAI API為念進行構(gòu)建，那么你就可以捕捉到很多價值，并且能夠輕松地替換模型。

這對構(gòu)建方式意味著什么？以API和容器為先的開發(fā)使生活變得更輕松。這是相當(dāng)標(biāo)準(zhǔn)的事情。抽象真的很好，所以不要花時間為你的特定模型構(gòu)建自定義基礎(chǔ)設(shè)施。你很可能在12個月內(nèi)不會使用它。如果你要構(gòu)建，嘗試構(gòu)建更通用的基礎(chǔ)設(shè)施。我們總是說，在當(dāng)前階段，我們?nèi)栽谠S多組織中證明AI的價值，工程師應(yīng)該花時間構(gòu)建出色的應(yīng)用體驗，而不是糾結(jié)于基礎(chǔ)設(shè)施。因為現(xiàn)在，對于大多數(shù)企業(yè)來說，我們很幸運有足夠的預(yù)算去嘗試這些生成式AI的東西。

我們需要快速證明價值。我們傾向于說，不要使用只支持Llama的框架，因為這只會給你帶來更多麻煩。無論你選擇什么架構(gòu)或基礎(chǔ)設(shè)施，確保當(dāng)Llama 3、4、5、Mixtral、Mistral出現(xiàn)時，它們將幫助你采用它。我可以回到我之前談到的案例研究。我們以這種方式構(gòu)建，顯然，用Mixtral替換Llama 3非常容易，當(dāng)Llama 3出現(xiàn)時。例如，如果出現(xiàn)了更好的Embedder，就像幾周前出現(xiàn)的非常好的Embedder，我們也可以很容易地替換它。

6. GPU看起來真的很貴，無論如何都要使用它們

GPU看起來真的很貴。無論如何都要使用它們。GPU是如此驚人。它們非常適合生成式AI和生成式AI工作負(fù)載。生成式AI涉及大量并行計算，這恰好是GPU非常擅長的事情。你可能會看價格標(biāo)簽，覺得它比CPU貴100倍。是的，確實如此，但如果你正確使用它并從中獲得你需要的利用率，那么最終處理的訂單數(shù)量將會多得多，而且每個請求的成本將會便宜得多。

7. 盡可能用小型模型

當(dāng)你可以的時候，使用小型模型。GPT-4是王者，但你不會讓王者洗碗。洗碗是什么：GPT-4是了不起的。它是一項真正卓越的技術(shù)，但使它如此出色的是它在能力上非常廣泛。我可以使用GPT-4模型寫情書，你可以用它成為一個更好的程序員，我們使用的是完全相同的模型。這很瘋狂。那個模型有很多能力，因此它真的非常大。它是一個巨大的模型，而且推理起來非常昂貴。我們發(fā)現(xiàn)，你最好使用GPT-4來處理那些開源模型還無法處理的真正困難的事情，然后使用較小的模型來處理那些更容易的事情。通過這樣做，你可以大幅降低成本和延遲。當(dāng)我們談到你之前擁有的延遲預(yù)算或資源預(yù)算時，如果你只在真正需要的時候使用GPT-4，你可以最大限度地利用資源預(yù)算。

三個常見的例子是RAG Fusion。這是當(dāng)你的查詢被大型語言模型編輯后，然后所有查詢都進行搜索，然后結(jié)果進行排名以提高搜索質(zhì)量。例如，你可以通過不使用GPT-4而獲得很好的結(jié)果，只在必要時使用GPT-4。例如，使用RAG，你可以只使用一個生成模型來重新排名，所以只是在最后檢查Embedder說相關(guān)的東西是否真的相關(guān)。小型模型，特別是針對函數(shù)調(diào)用的微調(diào)模型非常好。函數(shù)調(diào)用的一個非常常見的用例是，如果需要我的模型輸出類似JSON或regex的東西，我基本上有兩種方法可以做到這一點。要么我可以微調(diào)一個更小的模型，要么我可以給我的小模型添加控制器�？刂破髡娴暮芸�。控制器本質(zhì)上是，如果我自托管模型，我可以禁止我的模型說出任何會破壞JSON模式或我不想要的regex模式的標(biāo)記。像這樣的事情，實際上大多數(shù)企業(yè)用例，你不一定需要使用那些基于API的模型，你可以立即獲得成本和延遲的好處。

3 總結(jié)

確定你的部署邊界，然后反向工作。因為你知道你的部署邊界，你知道你應(yīng)該選擇的模型，當(dāng)你將其量化下來時，就是那個大小�；〞r間思考優(yōu)化推理，這可以真正地產(chǎn)生多個數(shù)量級的差異。生成式AI受益于基礎(chǔ)設(shè)施的整合，所以盡量避免讓每個團隊負(fù)責(zé)他們的部署，因為很可能會出錯。假設(shè)你將在12個月內(nèi)替換你的模型進行構(gòu)建。GPU看起來很貴，但它們是你最好的選擇。當(dāng)你可以的時候，你會使用小型模型。然后我們對Russell說這些，然后他說，“這太有幫助了。我非常興奮地使用你的提示部署我的關(guān)鍵任務(wù)LLM應(yīng)用�！比缓笪覀冋f，“沒問題，如果你有任何問題，請讓我們知道”。

4 問答

Q：你說過要為靈活性而構(gòu)建。頻繁更換模型的用例是什么？我們在自定義微調(diào)和自定義數(shù)據(jù)上花費的時間和精力將不得不重復(fù)？在頻繁更換模型的情況下，你有什么建議嗎？

A：你什么時候想要頻繁更換模型？一直都是。隨LLM改進速度，幾乎總是可以僅通過更換模型就獲得更好性能。你可能需要對提示進行一些調(diào)整，但通常，一對一的切換是可行的。例如，如果我的應(yīng)用構(gòu)建在GPT-3.5上，我將其替換為GPT-4，即使我使用相同的提示，我的模型性能可能會提高，這是一件非常低努力的事情。這與更換所需的工程努力如何協(xié)調(diào)？如果這是一個月的長過程，如果沒有顯著改進，那么你就不應(yīng)該進行那個切換。我建議嘗試以一種方式構(gòu)建，使其不是一個月的長過程，實際上可以在幾天內(nèi)完成，因為那樣幾乎總是值得的。

這與微調(diào)如何協(xié)調(diào)？我有一個辛辣而熱門的觀點，即對于大多數(shù)用例，你不需要微調(diào)。微調(diào)在幾年前的深度學(xué)習(xí)中非常流行。隨模型越來越好，它們也更擅長遵循你的指示。你通常不需要為許多用例進行微調(diào)，可用RAG、提示工程和函數(shù)調(diào)用等方法。這就是我傾向于說的。如果你正在尋找你的第一個LLM用例，談?wù)摳鼡Q模型，一個非常好的第一個LLM用例就是嘗試替換你的NLP管道。許多企業(yè)都有現(xiàn)成的NLP管道。如果你可以將它們替換為LLMs，通常，你會獲得多個點的準(zhǔn)確性提升。

Q：你認(rèn)為企業(yè)級硬件和消費者最大硬件在本地硬件上的區(qū)別是什么，因為我選擇了消費者最大硬件，因為你的內(nèi)存可以高達6000兆傳輸，PCI通道更快。

A：因為像他這樣的人已經(jīng)拿走了所有的A100s，當(dāng)我們進行內(nèi)部開發(fā)時，我們實際上使用的是4090s，這是消費者硬件。它們更容易獲得，也比獲得數(shù)據(jù)中心硬件便宜得多。這就是我們用于開發(fā)的東西。我們實際上沒有使用消費者級硬件進行大規(guī)模推理，盡管沒有理由它不會工作。

如果它適合你的工作負(fù)載。我們也使用它。我們認(rèn)為它們非常好。它們也便宜得多，因為它們作為消費者級而不是數(shù)據(jù)中心級出售。

Q：你說GPU是一個整體，也是最重要的。我有點驚訝，但也許我的問題會解釋。我用只有CPU的小虛擬機做了一些概念驗證，我每秒幾次請求就得到了相當(dāng)好的結(jié)果。我沒有問自己關(guān)于可擴展性的問題。我在想我們應(yīng)該在多少請求時切換到GPU？

A：實際上，也許我在GPU方面有點過于強烈，因為我們也在CPU上部署過。如果延遲足夠好，這通常是人們首先抱怨的問題，是延遲，那么CPU可能沒問題。只是當(dāng)你在尋找規(guī)模經(jīng)濟并且當(dāng)你在尋找擴展時，它們幾乎總是每個請求更貴。如果你的請求數(shù)量合理地低，延遲也足夠好，那么你可以繼續(xù)使用它。我認(rèn)為我們的第一個推理服務(wù)器的概念驗證是在CPU上完成的。你也會知道的另一件事是，你將限制你可以使用的模型的大小。例如，如果你正在做一個70億量化的，你可能也可以繼續(xù)使用CPU。我認(rèn)為如果你從一張白紙開始，GPU更好。如果你的起點是你已經(jīng)有一個充滿CPU的大型數(shù)據(jù)中心，而且你否則不會使用它們，那么仍然值得嘗試是否可以利用它們。

Q：我有一個關(guān)于通常使用的API的問題，當(dāng)然，OpenAI的API通常也被應(yīng)用程序使用。我也知道很多人真的不喜歡OpenAI的API。你看到其他API了嗎？因為很多人只是在模仿它們，或者他們只是使用它，但沒有人真的喜歡它。

A：當(dāng)你說他們不喜歡它時，是他們不喜歡API結(jié)構(gòu)，還是不喜歡模型？

Q：這是關(guān)于API結(jié)構(gòu)的。這是關(guān)于文檔的。這是關(guān)于狀態(tài)的，關(guān)于你無法完全理解的很多事情。

A：我們也真的不喜歡它，所以我們編寫了自己的API，稱為我們的推理服務(wù)器，然后我們有一個與OpenAI兼容的層，因為大多數(shù)人使用那種結(jié)構(gòu)。你可以查看我們的文檔，看看你是否更喜歡它。我認(rèn)為，因為它是第一個真正爆發(fā)的，它是整個行業(yè)在API結(jié)構(gòu)上匯聚的地方。

關(guān)注我，緊跟本系列專欄文章，咱們下篇再續(xù)！

★ 作者簡介：魔都架構(gòu)師，多家大廠后端一線研發(fā)經(jīng)驗，在分布式系統(tǒng)設(shè)計、數(shù)據(jù)平臺架構(gòu)和AI應(yīng)用開發(fā)等領(lǐng)域都有豐富實踐經(jīng)驗。 各大技術(shù)社區(qū)頭部專家博主。具有豐富的引領(lǐng)團隊經(jīng)驗，深厚業(yè)務(wù)架構(gòu)和解決方案的積累。 負(fù)責(zé)： 中央/分銷預(yù)訂系統(tǒng)性能優(yōu)化 活動&券等營銷中臺建設(shè) 交易平臺及數(shù)據(jù)中臺等架構(gòu)和開發(fā)設(shè)計 車聯(lián)網(wǎng)核心平臺-物聯(lián)網(wǎng)連接平臺、大數(shù)據(jù)平臺架構(gòu)設(shè)計及優(yōu)化 LLM Agent應(yīng)用開發(fā) 區(qū)塊鏈應(yīng)用開發(fā) 大數(shù)據(jù)開發(fā)挖掘經(jīng)驗 推薦系統(tǒng)項目 目前主攻市級軟件項目設(shè)計、構(gòu)建服務(wù)全社會的應(yīng)用系統(tǒng)。 ”

參考：

• 編程嚴(yán)選網(wǎng)

編程嚴(yán)選網(wǎng)：http://www.javaedge.cn/ 專注分享軟件開發(fā)全生態(tài)相關(guān)技術(shù)文章、視頻教程資源、熱點資訊等，全站資源免費學(xué)習(xí)，快來看看吧~ 【編程嚴(yán)選】星球

歡迎長按圖片加好友，我會第一時間和你分享軟件行業(yè)趨勢，面試資源，學(xué)習(xí)方法等等。

添加好友備注【技術(shù)群交流】拉你進技術(shù)交流群

關(guān)注公眾號后，在后臺私信：

• 更多教程資源應(yīng)有盡有，歡迎關(guān)注并加技術(shù)交流群，慢慢獲取

• 為避免大量資源被收藏白嫖而浪費各自精力，以上資源領(lǐng)取分別需要收取1元門檻費！