AI技術現在很火，各大公司都開始朝著這個領域發力。他們不僅創建出很多出色成果，還通過一系列技術、工具和服務，説明普通開發者也能輕而易舉地開發出新穎的AI應用。

本文將告訴大家如何在Akamai雲計算平臺上優化一個基於Qwik和OpenAI服務的Web專案。具體來說，我們將通過本文詳細剖析項目的整體架構和優化方式，從而為廣大開發者帶來啟發。

基本架構

假設有這樣的一個Web應用：

在兩個文字方塊中輸入兩個“對手”，隨後由AI來決定在戰鬥中誰會獲勝。該應用還提供了一些解釋決策原因以及創建圖像的選項。該應用相當基礎，用戶提交兩個對手，然後應用程式即時返回一個由AI生成的回應，從中得知哪個對手會在戰鬥中獲勝。

架構也很簡單：

1. 用戶端向伺服器發送請求。

2. 伺服器構造提示並將提示轉發給OpenAI。

3. OpenAI向伺服器返回一個流式響應。

4. 伺服器對流式回應進行任何必要的調整，並將其轉發給用戶端。

該應用搭建在Akamai的雲計算服務（以前的Linode）上，不過下文將要介紹的內容對任何雲平臺應該都適用。

🤵看起來像是高級餐廳裡的服務員，👁️‍🗨️則是“一隻眼睛”，或者說是AI

從技術上講，這是完全可行的，但存在一些問題，特別是當用戶提交重複請求時。將回應存儲在我們自己的伺服器上，並且只針對唯一請求訪問OpenAI，可能會讓整個過程更快速，更具成本效益。

這就需要假設我們不需要每個請求都是非確定性的（即相同的輸入產生不同的輸出）。我們可以假設相同的輸入產生相同的輸出是可接受的。畢竟，誰會贏得一場戰鬥的預測結果可能並不會改變。

添加資料庫架構

如果我們想要存儲來自OpenAI的響應，一種實際的放置地點是某種類型的資料庫，這種資料庫應該能讓我們圍繞兩個對手進行快速、簡單的查找。這樣，在收到請求時，就可以首先檢查資料庫：

1. 用戶端向伺服器發送請求。

2. 伺服器檢查資料庫中是否存在與使用者輸入相匹配的條目。

3. 如果存在匹配的記錄，伺服器使用該資料回復並完成請求。跳過後續步驟。

4. 如果不存在匹配的記錄，則伺服器繼續執行上一小節中流程的第三步（聯繫OpenAI）。

5. 在關閉回應前，伺服器將OpenAI的結果存儲在資料庫中。

虛線代表可選請求，而💽看起來像是一個硬碟

有了這樣的設置，任何重複的請求都將由資料庫直接處理。通過將一些OpenAI請求設置為可選，我們還有可能降低用戶體驗的延遲，同時通過減少API請求的數量來節省費用。

這是一個很好的開始，特別是如果伺服器和資料庫位於同一個地區。這將比訪問OpenAI的伺服器快得多。

然而，隨著應用程式變得更加受歡迎，我們可能會開始吸引來自世界各地的用戶。資料庫查詢的速度自然是越快越好，但往返傳輸資料造成的延遲又該如何消除？我們可以通過將應用移動到距離用戶更近的地方來解決這個問題。

引入邊緣計算

邊緣（Edge）指一種讓內容盡可能接近使用者的方式。對一些應用場景來說，邊緣可能意味著物聯網設備或手機基站，但在Web應用之類的場景中，最典型的邊緣往往是內容分發網路（CDN）。

CDN是一種全球分佈的電腦網路，可以從網路中最近的節點回應用戶請求。傳統的CDN是為靜態資產設計的，但近年來，CDN開始支持邊緣計算。

有了邊緣計算，我們可以將很多後端邏輯移動到距離使用者非常近的地方，而且不僅限於計算！大多數邊緣計算提供商還在同一邊緣節點上提供某種最終一致的鍵值存儲服務。

這會對我們的應用程式產生什麼影響？

1. 用戶端向我們的後端發送請求。

2. 邊緣計算網路將請求路由到最近的邊緣節點。

3. 邊緣節點檢查與使用者輸入匹配的鍵值存儲中是否存在現有記錄。

4. 如果存在匹配的記錄，邊緣節點將使用該資料回復，完成請求。跳過後續步驟。

5. 如果不存在匹配的記錄，則邊緣節點將請求轉發到原始伺服器，原始伺服器再將其傳遞給OpenAI……

6. 在關閉回應前，伺服器將OpenAI的結果存儲在邊緣鍵值存儲中。

邊緣節點是藍色方框，用🔪表示；EdgeWorker是Akamai的邊緣計算產品，用🧑‍🏭表示；EdgeKV是Akamai的鍵值存儲服務，用🔑🤑🏪表示。從物理距離來說，邊緣節點比雲中的原始伺服器更接近用戶端原始伺服器在這裡可能並非絕對必要，但我們認為它的存在有一定必要性。基於資料、計算和邏輯流程考慮，這與先前的架構基本相同。主要區別在於先前存儲的結果現在更接近用戶，幾乎可以立即返回。

注意：儘管資料被緩存在邊緣，但回應仍然是動態構建的。如果不需要動態回應，將CDN放置在原始伺服器前並設置正確的HTTP頭來緩存回應，可能是一種更簡單的做法。

這樣就完成了！任何重複請求幾乎會立即得到回應，同時也節省了不必要的API請求。文本回應的架構問題順利解決，但是別忘了，還有AI圖像生成功能呢。

緩存圖片

處理圖片時，我們需要考慮內容的交付和存儲。相信OpenAI有自己的解決方案，但一些企業出於安全、合規性或可靠性等原因的考慮，可能希望與圖片交付和存儲有關的整個基礎設施都完全由自己掌控。一些情況下，企業甚至可能寧願運行自己的圖像生成服務，而不是使用OpenAI。

在當前的工作流程中，使用者發出請求，最終請求傳遞到OpenAI。OpenAI生成圖像，但不返回圖像，而是返回一個JSON響應，其中包含圖像的URL，該URL託管在OpenAI的基礎設施上。使用此回應時，可以用URL將<img>標籤添加到頁面，從而啟動另一個請求來獲取對應的圖像。

如果要將圖像託管在自己的基礎設施上，需要一個存儲圖像的地方。我們可以將圖像寫入原始伺服器的磁片，但這可能會快速使用大量磁碟空間，並且必須升級伺服器，這可能會很昂貴。物件存儲是一種更便宜的解決方案，我們可以將圖像上傳到自己的物件存儲實例，並使用該實例對應的URL。

這解決了存儲問題，但物件存儲桶通常都部署在單個區域，這與我們在資料庫中存儲文本時遇到的問題類似。單個區域可能距離使用者很遠，這可能會導致很高的延遲。

又到了邊緣的用武之地了。為純靜態資產添加CDN功能其實非常簡單。一旦配置完成，CDN將在初始請求時從物件存儲中拉取圖像，並將其緩存以供來自同一區域的後續訪問者直接交付。

我們的圖片處理流程如下：

1. 用戶端發送請求，根據對手生成圖像。

2. 邊緣計算檢查該請求的圖像資料是否已存在。如果存在，則直接返回URL。

3. 圖像與URL一起添加到頁面，並由流覽器請求圖像。

4. 如果圖像已經緩存在CDN中，則流覽器幾乎能立即載入。流程結束。

5. 如果圖像尚未被緩存，CDN將從物件存儲位置拉取圖像，緩存一份副本供未來的請求使用，並將圖像返回給用戶端。這是流程的另一個結尾。

6. 如果圖像資料不在邊緣鍵值存儲中，生成圖像的請求將發送到伺服器，然後傳遞到OpenAI，後者生成圖像並返回URL資訊。伺服器啟動任務將圖像保存在物件存儲桶中，將圖像資料存儲在邊緣鍵值存儲中，並將圖像資料返回給邊緣計算節點。

7. 使用新的圖像資料，用戶端創建圖像，生成新請求，並從步驟五繼續。

內容交付網路以交付卡車（🚚）和網路信號（📶）表示，物件存儲以盒子裡的襪子（🧦📦）或存儲中的物件表示

誠然，最後這種架構稍微複雜了一些，但如果應用程式要處理大量流量，這種架構也是很有必要的。

大功告成

通過所有這些改變，我們已經為唯一請求創建了AI生成的文本和圖像，並為重複請求提供了來自邊緣的緩存內容。結果是更快的回應時間和更好的用戶體驗（當然，API調用也更少）。

上述內容完全以Akamai雲計算平臺為例，但其實所涉及的各種資料庫、邊緣計算、物件存儲和CDN也適用於其他平臺。這是一個有著廣泛適用性的思路。只不過通過與Akamai的雲計算和邊緣計算服務整合不僅僅能改善性能，還可以獲得很多非常酷的安全功能。

例如，在Akamai的網路上，我們可以使用諸如Web應用程式防火牆（WAF）、分散式拒絕服務（DDoS）防護、智慧爬蟲檢測等功能，從而更好地保障應用程式、資料、客戶資訊的安全性。

這些額外的服務還能提供哪些好處？歡迎關注Akamai。