在云計(jì)算的發(fā)展過程中，計(jì)費(fèi)方式往往是開發(fā)者最直觀的感知。最初，用戶需要直接購(gòu)買資源，按小時(shí)計(jì)費(fèi)；后來(lái)，函數(shù)計(jì)算將粒度細(xì)化到按請(qǐng)求執(zhí)行的毫秒級(jí)。很多開發(fā)者第一次接觸一款云產(chǎn)品時(shí)，關(guān)注的往往不是架構(gòu)，而是賬單。因?yàn)橘~單背后映射的，正是云廠商在 資源抽象、調(diào)度方式、安全隔離與開發(fā)體驗(yàn) 上的關(guān)鍵選擇。

函數(shù)計(jì)算的演進(jìn)史，其實(shí)也是一部計(jì)費(fèi)方式的演化史。透過計(jì)費(fèi)這一窗口，我們可以一管窺全豹，清晰地看到背后產(chǎn)品形態(tài)在技術(shù)與體驗(yàn)上的深刻變化，以及技術(shù)架構(gòu)隨應(yīng)用場(chǎng)景不斷演化的能力。

階段一：從資源租用到按請(qǐng)求計(jì)費(fèi)

在函數(shù)計(jì)算發(fā)展的最初階段，最大突破點(diǎn)在于計(jì)費(fèi)方式的根本轉(zhuǎn)變：用戶不再像租用虛擬機(jī)一樣，為實(shí)例的持續(xù)運(yùn)行付費(fèi)，而是只在函數(shù)被真正調(diào)用、執(zhí)行時(shí)支付費(fèi)用。換句話說(shuō)，在沒有請(qǐng)求執(zhí)行的時(shí)間段，用戶無(wú)需承擔(dān)任何閑置成本，這一階段的創(chuàng)新，讓“只為代碼運(yùn)行時(shí)刻付費(fèi)”成為 Serverless 的立身之本，也迅速降低了開發(fā)者的使用門檻。如下圖所示。

支撐這種計(jì)費(fèi)模式的關(guān)鍵技術(shù)包括：

1. 精準(zhǔn)識(shí)別請(qǐng)求邊界
   • 請(qǐng)求的生命周期就是計(jì)費(fèi)的生命周期，平臺(tái)必須在微秒/毫秒級(jí)準(zhǔn)確地識(shí)別“開始”和“結(jié)束”，保證賬單公平與精確。
2. 按請(qǐng)求分配獨(dú)占資源
   • 每個(gè)請(qǐng)求都獲得確定的 CPU/內(nèi)存資源，避免資源競(jìng)爭(zhēng)導(dǎo)致性能抖動(dòng)，從而保障賬單的可控性。
3. 低延時(shí)大并發(fā)的冷啟動(dòng)能力
   • 實(shí)例不常駐，而是按需啟動(dòng)。平臺(tái)必須優(yōu)化冷啟動(dòng)延時(shí)，在大規(guī)模并發(fā)場(chǎng)景下快速分配資源，同時(shí)在空閑時(shí)立即回收，避免浪費(fèi)。
4. 1ms完成活躍/閑置狀態(tài)轉(zhuǎn)化
   • 在無(wú)請(qǐng)求時(shí)通過凍結(jié)函數(shù)實(shí)例的 CPU 調(diào)度，轉(zhuǎn)成閑置狀態(tài)，確保不再消耗時(shí)間片，請(qǐng)求來(lái)到時(shí)候，實(shí)時(shí)轉(zhuǎn)成活躍狀態(tài)，允許CPU調(diào)度，這是實(shí)現(xiàn)毫秒級(jí)精確計(jì)費(fèi)和公平性的保障。

這一階段讓函數(shù)計(jì)算真正區(qū)別于虛擬機(jī)和容器租用模式，奠定了“按請(qǐng)求計(jì)費(fèi)”的核心心智模型。

階段二：多并發(fā) + 毫秒級(jí)計(jì)費(fèi) —— 面向 Web 應(yīng)用的優(yōu)化

隨著函數(shù)計(jì)算逐漸普及，除了事件觸發(fā)外，Web Server 等 I/O 型場(chǎng)景也開始被采用。如果繼續(xù)采用單請(qǐng)求獨(dú)占計(jì)費(fèi)，對(duì)比傳統(tǒng)多并發(fā)的服務(wù)模型，成本很難接受，因此進(jìn)入了第二階段的演化。

核心變化是：突破單并發(fā)限制，按函數(shù)實(shí)例的活躍時(shí)間段計(jì)費(fèi)，并將粒度精細(xì)化到 1ms，從而支撐 Web 應(yīng)用、API 服務(wù)等主流場(chǎng)景，如下圖所示。

支撐這一演化的關(guān)鍵技術(shù)包括：

1. 識(shí)別活躍時(shí)間段作為計(jì)費(fèi)邊界
   • 從“單請(qǐng)求時(shí)長(zhǎng)”轉(zhuǎn)變?yōu)椤盎钴S區(qū)間”，只要實(shí)例內(nèi)有請(qǐng)求在執(zhí)行，即視為活躍計(jì)費(fèi)，不管并發(fā)多少請(qǐng)求。
2. 引入 Custom Runtime / Container Runtime
   • 支持用戶平滑遷移主流 Web 框架（如 Express、Flask、Spring Boot），這些框架天然支持多并發(fā)，能夠降低成本并收斂數(shù)據(jù)庫(kù)連接數(shù)，減少連接暴漲帶來(lái)的風(fēng)險(xiǎn)。
3. 縮短計(jì)費(fèi)粒度：從 100ms 到 1ms
   • 大多數(shù) Web 請(qǐng)求延時(shí)低于 100ms，如果仍按 100ms 粒度計(jì)費(fèi)，用戶成本過高。精細(xì)化到 1ms，使賬單更公平。
4. 極致優(yōu)化平臺(tái)全鏈路延遲
   • Web 應(yīng)用對(duì)端到端延遲極其敏感，平臺(tái)必須在鑒權(quán)、路由、調(diào)度、轉(zhuǎn)發(fā)等環(huán)節(jié)做性能優(yōu)化，避免平臺(tái)開銷成為主要瓶頸。

這一階段的價(jià)值在于：從“為單個(gè)請(qǐng)求買單”轉(zhuǎn)變?yōu)椤盀榛钴S區(qū)間買單”，輔以更精細(xì)的粒度和運(yùn)行時(shí)靈活性，讓函數(shù)計(jì)算從事件驅(qū)動(dòng)擴(kuò)展到主流 Web/API 服務(wù)場(chǎng)景。

階段三：按實(shí)際資源消耗計(jì)費(fèi) —— AI 時(shí)代的價(jià)值計(jì)費(fèi)

AI 應(yīng)用具有長(zhǎng)會(huì)話、強(qiáng)交互、低延遲的特點(diǎn)：

• 模型對(duì)話需要保持上下文；
• 語(yǔ)音/流式生成需要實(shí)時(shí)響應(yīng)；
• 會(huì)話中可能包含多種工具調(diào)用與后臺(tái)任務(wù)。

這類應(yīng)用往往是 稀疏型負(fù)載：大多數(shù)時(shí)間處于低負(fù)載，僅維持長(zhǎng)連接和上下文。傳統(tǒng)“請(qǐng)求邊界=活躍，閑置時(shí)凍結(jié) CPU”的機(jī)制不再適配：如果一律計(jì)為活躍，用戶在“低價(jià)值”的?；顮顟B(tài)下將付出過高成本。

因此，第三階段的核心轉(zhuǎn)變是：在識(shí)別請(qǐng)求邊界的基礎(chǔ)上，引入按實(shí)際資源消耗動(dòng)態(tài)區(qū)分“活躍/閑置”的計(jì)費(fèi)模型。低負(fù)載狀態(tài)下減免 CPU 費(fèi)用，同時(shí)仍然允許 AI 應(yīng)用運(yùn)行后臺(tái)任務(wù)。

支撐這種演化的關(guān)鍵技術(shù)包括：

1. 支持會(huì)話親和性
   • 引入會(huì)話親和性機(jī)制，使得同一會(huì)話的請(qǐng)求路由到同一個(gè)實(shí)例，避免上下文丟失。
   • 用戶可通過配置IdleTimeout主動(dòng)控制會(huì)話保留時(shí)間（即將發(fā)布）。
2. 按實(shí)際資源消耗判斷活躍/閑置
   • 在過去“有請(qǐng)求=活躍”的基礎(chǔ)上，引入根據(jù)資源利用率感知活躍/閑置的機(jī)制。
   • 如果 CPU 使用超過閾值，則記為“活躍”并計(jì)算CPU費(fèi)用；如果只是心跳/輕量?；睿珻PU使用極低，則記為閑置，免去CPU費(fèi)用，僅收內(nèi)存/磁盤/網(wǎng)絡(luò)成本。
3. 執(zhí)行期間低負(fù)載的減免機(jī)制
   • 在有請(qǐng)求執(zhí)行時(shí)，函數(shù)計(jì)算以秒為周期采樣，如果 CPU 使用低于閾值，自動(dòng)減免該周期的 CPU 費(fèi)用。
   • 在 MCP、WebSocket 等典型低負(fù)載場(chǎng)景默認(rèn)啟用，平臺(tái)主動(dòng)讓利，避免“在線=計(jì)費(fèi)”的粗暴邏輯。
4. 支持不凍結(jié)，允許后臺(tái)任務(wù)持續(xù)運(yùn)行
   • 在 AI 場(chǎng)景中，凍結(jié)會(huì)導(dǎo)致長(zhǎng)連接中斷、緩存失效，恢復(fù)代價(jià)高。
   • 函數(shù)計(jì)算支持不凍結(jié)模式，允許請(qǐng)求結(jié)束后繼續(xù)運(yùn)行后臺(tái)任務(wù)，如緩存預(yù)熱、索引更新、回調(diào)處理。
   • 這類任務(wù)的費(fèi)用仍然根據(jù)實(shí)際資源消耗判定為活躍或閑置，差異化計(jì)費(fèi)。

第三階段的價(jià)值在于：從“為活躍區(qū)間買單”進(jìn)一步演化為“按資源消耗分層計(jì)費(fèi)”，賬單更好地對(duì)齊到有效計(jì)算，避免因長(zhǎng)連接或低負(fù)載?；疃a(chǎn)生額外成本，讓 Serverless 真正適配 AI 時(shí)代的長(zhǎng)會(huì)話與強(qiáng)交互負(fù)載。（由于GPU等異構(gòu)資源的稀缺性，暫不納入支持范圍）

函數(shù)計(jì)算的演化方向是把產(chǎn)品形態(tài)與用戶價(jià)值更緊密地對(duì)齊

函數(shù)計(jì)算的計(jì)費(fèi)方式經(jīng)歷了三個(gè)階段：

• 階段一：按請(qǐng)求計(jì)費(fèi) —— 降低門檻，讓用戶只為調(diào)用付費(fèi)；
• 階段二：活躍區(qū)間計(jì)費(fèi) —— 擴(kuò)展場(chǎng)景，讓 Web/API 應(yīng)用也能高效低成本運(yùn)行；階段三：
• 按資源消耗計(jì)費(fèi) —— 貼近價(jià)值，讓 AI 應(yīng)用在長(zhǎng)會(huì)話與低負(fù)載下也能公平付費(fèi)。

在 AI 時(shí)代，函數(shù)計(jì)算一直堅(jiān)持走向“讓開發(fā)者只關(guān)心業(yè)務(wù)邏輯，云廠商自動(dòng)完成一切資源管理與調(diào)度”的愿景，最終讓計(jì)算像水、電一樣隨時(shí)可得、按實(shí)際使用價(jià)值付費(fèi)。