1. 算力交付之后真正的生意才剛開始很多人對(duì)智算中心的想象還停留在“堆顯卡、賣算力”的階段——機(jī)房建起來GPU上架客戶按卡時(shí)或者按整機(jī)租用生意就成立了。但真正在這個(gè)圈子里待過一段時(shí)間的人都清楚算力交付只是整個(gè)鏈條的起點(diǎn)不是終點(diǎn)?；浉蹫持撬氵@類區(qū)域性算力樞紐的定位本質(zhì)上不是做一個(gè)“顯卡二房東”而是要在算力之上長(zhǎng)出可持續(xù)的商業(yè)模式。這個(gè)模式的核心抓手就是Token。先把概念說清楚避免后面討論跑偏。這里的Token不是登錄鑒權(quán)那個(gè)Token而是大模型處理文本時(shí)的最小計(jì)量單位。你給模型發(fā)一段話模型把它切成一個(gè)個(gè)Token再計(jì)算輸出的內(nèi)容同樣按Token計(jì)。算力是“電”Token是“用電量計(jì)費(fèi)的單位”兩者之間隔著一層模型推理服務(wù)?；浉蹫持撬惆阉懔桓冻鋈ブ笕绻皇諜C(jī)柜租金那它跟傳統(tǒng)IDC沒有本質(zhì)區(qū)別只有當(dāng)它把算力轉(zhuǎn)化成可計(jì)量的Token服務(wù)才能從“賣資源”升級(jí)到“賣能力”。這篇文章適合三類人看一是正在或準(zhǔn)備接入智算中心算力的開發(fā)者你需要搞清楚Token是怎么被計(jì)量、被計(jì)費(fèi)、被優(yōu)化的二是做AI應(yīng)用的產(chǎn)品和技術(shù)負(fù)責(zé)人你要算明白自己的成本結(jié)構(gòu)到底卡在哪一環(huán)三是對(duì)AIDC商業(yè)模式感興趣的同行我們可以一起拆解算力交付之后的錢從哪里來。下面我會(huì)從整體設(shè)計(jì)思路、核心細(xì)節(jié)、實(shí)操落地、問題排查幾個(gè)層面把“算力之后怎么做Token生意”這件事講透。2. 整體設(shè)計(jì)與思路拆解為什么是Token而不是算力2.1 從賣算力到賣Token中間隔了什么傳統(tǒng)IDC的生意邏輯很直白機(jī)柜、帶寬、電力按月或按年收租。AIDCAI數(shù)據(jù)中心如果照搬這套問題會(huì)非常明顯。GPU的折舊速度遠(yuǎn)快于普通服務(wù)器一張卡買回來那天就開始貶值而租卡時(shí)長(zhǎng)的定價(jià)又受制于市場(chǎng)供需波動(dòng)。更關(guān)鍵的是客戶要的從來不是GPU本身而是GPU能跑出來的結(jié)果。一個(gè)做客服機(jī)器人的團(tuán)隊(duì)不關(guān)心你用的是A100還是H800他關(guān)心的是每處理一萬(wàn)次對(duì)話要花多少錢。所以從算力到Token中間至少隔了三層轉(zhuǎn)化第一層是硬件資源池化把物理GPU抽象成可調(diào)度的算力單元第二層是推理服務(wù)封裝把模型加載、批處理、并發(fā)控制這些臟活累活包起來對(duì)外暴露API第三層才是Token計(jì)量與計(jì)費(fèi)把每次調(diào)用的輸入輸出Token數(shù)記錄下來形成賬單?；浉蹫持撬氵@類平臺(tái)的價(jià)值就在于它把這三層都做了客戶不需要自己搭推理框架、不需要自己維護(hù)模型版本、不需要自己寫計(jì)量邏輯直接調(diào)API按Token付費(fèi)。這個(gè)設(shè)計(jì)背后的考量很實(shí)際。如果平臺(tái)只提供裸算力客戶自己部署模型那平臺(tái)就失去了對(duì)服務(wù)質(zhì)量的把控也拿不到服務(wù)溢價(jià)。而一旦平臺(tái)提供Token化的推理服務(wù)它就可以做錯(cuò)峰調(diào)度、批量合并、模型熱切換這些優(yōu)化把GPU利用率從30%拉到70%以上這部分效率提升就是平臺(tái)的利潤(rùn)空間。換句話說Token生意的本質(zhì)是用調(diào)度效率換服務(wù)溢價(jià)。2.2 三種主流Token商業(yè)模式對(duì)比目前市面上做Token生意大致有三種路徑各有各的適用場(chǎng)景。我整理了一張對(duì)比表方便你判斷自己適合哪一種。模式計(jì)費(fèi)方式優(yōu)勢(shì)劣勢(shì)適合誰(shuí)按Token計(jì)費(fèi)輸入/輸出分別計(jì)價(jià)按量付費(fèi)用多少付多少成本透明單價(jià)高量大時(shí)總成本驚人中小開發(fā)者、驗(yàn)證期項(xiàng)目包月/包量套餐固定費(fèi)用含一定Token額度預(yù)算可控單價(jià)低額度用不完浪費(fèi)超量另算用量穩(wěn)定的成熟應(yīng)用算力Token混合底租算力超額Token計(jì)費(fèi)兼顧穩(wěn)定性和彈性計(jì)費(fèi)邏輯復(fù)雜對(duì)賬麻煩有波峰波谷的業(yè)務(wù)粵港灣智算這類平臺(tái)通常會(huì)同時(shí)提供多種模式讓客戶按需選擇。我個(gè)人的經(jīng)驗(yàn)是項(xiàng)目早期用按Token計(jì)費(fèi)驗(yàn)證跑通之后切包月套餐壓成本大促或活動(dòng)期用混合模式兜底。這個(gè)切換節(jié)奏很重要切早了浪費(fèi)預(yù)算切晚了賬單爆炸。2.3 為什么Token計(jì)量比想象中復(fù)雜很多人以為Token計(jì)量就是數(shù)一下字?jǐn)?shù)其實(shí)遠(yuǎn)不止。不同模型的Tokenizer不一樣同一段中文在GPT系列和國(guó)產(chǎn)模型里切出來的Token數(shù)可能差30%以上。而且輸入Token和輸出Token的成本通常不同輸出往往更貴因?yàn)榻獯a過程是逐Token生成的算力消耗更大。更麻煩的是多輪對(duì)話場(chǎng)景歷史上下文每次都要重新計(jì)入輸入Token一輪輪累積下來輸入Token量會(huì)遠(yuǎn)超你的直覺。提示做成本預(yù)估時(shí)千萬(wàn)不要用“字?jǐn)?shù)除以2”這種土辦法估算Token。一定要用目標(biāo)模型官方的Tokenizer工具實(shí)測(cè)否則預(yù)算偏差可能達(dá)到一倍以上。平臺(tái)側(cè)要做的就是在每次API調(diào)用時(shí)準(zhǔn)確切分輸入輸出、記錄Token數(shù)、按模型單價(jià)計(jì)算費(fèi)用還要處理流式輸出場(chǎng)景下的實(shí)時(shí)計(jì)量。流式輸出尤其棘手因?yàn)門oken是一個(gè)個(gè)吐出來的你得在流沒結(jié)束時(shí)就累計(jì)計(jì)數(shù)同時(shí)還要防止連接中斷導(dǎo)致的計(jì)量遺漏。這些細(xì)節(jié)決定了Token生意能不能算清楚賬。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 Token計(jì)量的技術(shù)實(shí)現(xiàn)要點(diǎn)要讓Token生意成立計(jì)量必須準(zhǔn)確到每一次調(diào)用。技術(shù)上通常的做法是在推理服務(wù)的入口和出口各埋一個(gè)計(jì)量鉤子。入口處對(duì)請(qǐng)求體做Tokenize得到輸入Token數(shù)出口處對(duì)模型生成的完整響應(yīng)做Tokenize得到輸出Token數(shù)。如果是流式響應(yīng)出口處需要邊生成邊累加并在流結(jié)束時(shí)落庫(kù)。這里有個(gè)容易踩的坑不同模型的Tokenizer實(shí)現(xiàn)不一樣不能混用。比如你平臺(tái)同時(shí)接了多個(gè)模型每個(gè)模型的Tokenizer都得單獨(dú)集成計(jì)量時(shí)按模型ID路由到對(duì)應(yīng)的計(jì)數(shù)器。我見過有平臺(tái)圖省事統(tǒng)一用一套Tokenizer估算結(jié)果某些模型的賬單和實(shí)際用量對(duì)不上客戶投訴不斷。另一個(gè)要點(diǎn)是計(jì)量的原子性。一次API調(diào)用要么完整計(jì)量要么不計(jì)不能出現(xiàn)“請(qǐng)求成功了但沒記上賬”的情況。通常的做法是把計(jì)量記錄和請(qǐng)求ID綁定寫入消息隊(duì)列異步落庫(kù)同時(shí)保留原始請(qǐng)求日志用于對(duì)賬。如果追求強(qiáng)一致可以在響應(yīng)返回前同步寫計(jì)量表但會(huì)增加延遲需要權(quán)衡。3.2 模型推理服務(wù)的封裝策略Token生意的載體是推理服務(wù)封裝得好不好直接決定成本和體驗(yàn)。核心要解決三個(gè)問題批處理、并發(fā)控制、模型加載。批處理是指把多個(gè)用戶的請(qǐng)求合并成一個(gè)批次一起推理這樣GPU的矩陣計(jì)算單元才能吃滿。單條請(qǐng)求推理時(shí)GPU利用率可能只有20%合并成batch后能到60%以上。但批處理會(huì)引入延遲因?yàn)橐葴悏蛞慌虐l(fā)車。常見的折中是設(shè)置一個(gè)最大等待時(shí)間比如50毫秒超時(shí)就用當(dāng)前攢到的請(qǐng)求發(fā)一批。并發(fā)控制是防止某個(gè)客戶把GPU占滿。通常按客戶維度做限流比如每個(gè)API Key每秒最多N個(gè)請(qǐng)求、每分鐘最多M個(gè)Token。限流閾值要根據(jù)客戶的套餐等級(jí)動(dòng)態(tài)調(diào)整這本身就是Token生意的一部分——想要更高并發(fā)就買更貴的套餐。模型加載策略則決定了冷啟動(dòng)速度。如果每個(gè)模型都常駐顯存顯存很快就不夠用如果按需加載第一次調(diào)用會(huì)非常慢。折中方案是熱模型常駐冷模型懶加載LRU淘汰把最常用的幾個(gè)模型釘在顯存里其余按需加載并設(shè)置淘汰策略。3.3 定價(jià)模型的設(shè)計(jì)邏輯Token定價(jià)不是拍腦袋定的得覆蓋成本還要有利潤(rùn)。成本側(cè)主要包括GPU折舊、電力、機(jī)房、人力、帶寬。把這些折算成每千Token的成本再加上目標(biāo)毛利率就是基礎(chǔ)定價(jià)。但實(shí)際定價(jià)會(huì)更復(fù)雜因?yàn)橐獏^(qū)分輸入輸出、區(qū)分模型大小、區(qū)分時(shí)段。大模型單價(jià)高小模型單價(jià)低輸出Token比輸入貴夜間閑時(shí)可以有折扣。這些差異化定價(jià)的目的是引導(dǎo)客戶把不緊急的任務(wù)放到閑時(shí)跑從而提升整體GPU利用率。注意定價(jià)模型一旦上線調(diào)整要非常謹(jǐn)慎。頻繁調(diào)價(jià)會(huì)讓客戶無(wú)所適從也會(huì)增加對(duì)賬復(fù)雜度。建議至少保持一個(gè)季度穩(wěn)定調(diào)價(jià)前提前公告。3.4 客戶側(cè)的成本優(yōu)化技巧站在客戶角度怎么用Token最省錢這里面門道不少。第一是控制上下文長(zhǎng)度多輪對(duì)話不要無(wú)腦全量帶上歷史該截?cái)嗑徒財(cái)嘣撜驼?。第二是選對(duì)模型簡(jiǎn)單任務(wù)用小模型復(fù)雜任務(wù)才上大模型別拿大炮打蚊子。第三是利用緩存相同或相似的請(qǐng)求可以命中緩存直接返回不消耗Token。第四是批量提交把能合并的請(qǐng)求合并減少調(diào)用次數(shù)。我實(shí)測(cè)過一個(gè)客服場(chǎng)景通過上下文截?cái)嘈∧Ｐ头至鹘Y(jié)果緩存三招組合Token成本直接降了六成多。這些優(yōu)化不需要改業(yè)務(wù)邏輯只是在調(diào)用層做文章性價(jià)比極高。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 從零搭建Token計(jì)量模塊假設(shè)你現(xiàn)在要給一個(gè)推理服務(wù)加上Token計(jì)量下面是我實(shí)際用過的一套流程。第一步確定Tokenizer方案。如果平臺(tái)接的是開源模型直接用HuggingFace的AutoTokenizer按模型名加載對(duì)應(yīng)的分詞器。如果是閉源模型的API代理就用官方提供的計(jì)數(shù)接口或SDK。關(guān)鍵是把分詞器實(shí)例緩存起來不要每次請(qǐng)求都重新加載。from transformers import AutoTokenizer tokenizer_cache {} def get_tokenizer(model_name): if model_name not in tokenizer_cache: tokenizer_cache[model_name] AutoTokenizer.from_pretrained(model_name) return tokenizer_cache[model_name] def count_tokens(text, model_name): tokenizer get_tokenizer(model_name) return len(tokenizer.encode(text))第二步在請(qǐng)求入口處計(jì)量輸入Token。注意要把system prompt、歷史消息、當(dāng)前用戶輸入全部算進(jìn)去因?yàn)檫@些都是要送進(jìn)模型的。def count_input_tokens(messages, model_name): total 0 for msg in messages: total count_tokens(msg[content], model_name) return total第三步在響應(yīng)出口處計(jì)量輸出Token。如果是流式需要在每個(gè)chunk到達(dá)時(shí)累加。def stream_with_counting(stream, model_name): output_tokens 0 for chunk in stream: output_tokens count_tokens(chunk, model_name) yield chunk record_usage(output_tokens)第四步把計(jì)量結(jié)果寫入賬單表。字段至少包括請(qǐng)求ID、客戶ID、模型名、輸入Token數(shù)、輸出Token數(shù)、時(shí)間戳、單價(jià)、金額。4.2 計(jì)費(fèi)系統(tǒng)的對(duì)賬邏輯計(jì)量準(zhǔn)了計(jì)費(fèi)還得對(duì)得上。對(duì)賬的核心是三方核對(duì)客戶側(cè)記錄、平臺(tái)計(jì)量記錄、實(shí)際GPU消耗。三者理論上應(yīng)該吻合但實(shí)際總會(huì)有偏差。偏差來源主要有幾個(gè)一是網(wǎng)絡(luò)重試導(dǎo)致的重復(fù)計(jì)量需要在請(qǐng)求層做冪等二是流式中斷導(dǎo)致的計(jì)量遺漏需要在連接關(guān)閉時(shí)補(bǔ)記三是Tokenizer版本差異導(dǎo)致的計(jì)算偏差需要鎖定版本。對(duì)賬周期建議按天做發(fā)現(xiàn)偏差及時(shí)排查不要等到月底才發(fā)現(xiàn)賬對(duì)不上。我踩過的一個(gè)坑是早期沒做冪等客戶網(wǎng)絡(luò)抖動(dòng)重試了一次結(jié)果同一請(qǐng)求計(jì)了兩次費(fèi)客戶直接投訴。后來在請(qǐng)求頭加了唯一ID服務(wù)端做去重問題才解決。這個(gè)教訓(xùn)是計(jì)量系統(tǒng)從第一天就要考慮冪等和補(bǔ)償不能等出問題再補(bǔ)。4.3 一個(gè)完整的Token計(jì)費(fèi)鏈路示例把上面的環(huán)節(jié)串起來一個(gè)完整的鏈路是這樣的客戶攜帶API Key發(fā)起請(qǐng)求請(qǐng)求體包含模型名和消息列表網(wǎng)關(guān)校驗(yàn)API Key檢查余額和限流計(jì)量模塊對(duì)輸入做Tokenize得到輸入Token數(shù)請(qǐng)求進(jìn)入推理隊(duì)列等待批處理調(diào)度模型推理生成響應(yīng)流式或非流式計(jì)量模塊對(duì)輸出做Tokenize得到輸出Token數(shù)計(jì)費(fèi)模塊按模型單價(jià)計(jì)算本次費(fèi)用扣減客戶余額寫入賬單明細(xì)響應(yīng)返回給客戶附帶本次Token用量這個(gè)鏈路里第3步和第6步是計(jì)量的關(guān)鍵第7步是計(jì)費(fèi)的關(guān)鍵。任何一步出問題都會(huì)導(dǎo)致賬目不準(zhǔn)。所以生產(chǎn)環(huán)境一定要有監(jiān)控對(duì)Token用量、費(fèi)用、余額做實(shí)時(shí)告警。4.4 參數(shù)選擇與容量規(guī)劃做Token生意容量規(guī)劃直接決定成本。核心參數(shù)是并發(fā)數(shù)和批大小。并發(fā)數(shù)決定同時(shí)能處理多少請(qǐng)求批大小決定每次推理吃多少請(qǐng)求。假設(shè)一張GPU每秒能處理1000個(gè)Token平均每個(gè)請(qǐng)求輸入500 Token、輸出200 Token那么單請(qǐng)求耗時(shí)約0.7秒。如果批大小為8單批耗時(shí)約0.7秒批處理不顯著增加時(shí)間那么單卡每秒能處理約11個(gè)請(qǐng)求。按這個(gè)算一天能處理約95萬(wàn)請(qǐng)求對(duì)應(yīng)約6.6億Token。這個(gè)數(shù)字決定了你的定價(jià)底線。如果每千Token定價(jià)0.01元單卡日收入約6600元扣除電力和折舊毛利率大概在40%到60%之間。具體數(shù)字因卡而異但計(jì)算邏輯是通用的。提示容量規(guī)劃要留20%到30%的余量應(yīng)對(duì)突發(fā)流量。滿載運(yùn)行雖然利用率高但一旦有波動(dòng)就會(huì)排隊(duì)客戶體驗(yàn)很差。5. 常見問題與排查技巧實(shí)錄5.1 Token計(jì)量不準(zhǔn)的排查思路計(jì)量不準(zhǔn)是最常見的問題排查時(shí)按這個(gè)順序走先確認(rèn)Tokenizer版本是否一致再確認(rèn)輸入是否完整計(jì)入然后確認(rèn)流式輸出是否漏計(jì)最后確認(rèn)是否有重復(fù)計(jì)量?，F(xiàn)象可能原因排查方法解決賬單比預(yù)期高上下文重復(fù)計(jì)入檢查歷史消息是否全量帶上做上下文截?cái)嗷蛘~單比預(yù)期低流式輸出漏計(jì)檢查流結(jié)束時(shí)的補(bǔ)記邏輯連接關(guān)閉時(shí)強(qiáng)制落庫(kù)同一請(qǐng)求計(jì)兩次重試未冪等檢查請(qǐng)求ID去重加冪等鍵不同模型賬單偏差Tokenizer混用核對(duì)模型與分詞器映射按模型路由分詞器5.2 推理服務(wù)超時(shí)與降級(jí)Token生意最怕服務(wù)不可用。推理超時(shí)的常見原因是批處理等待過久、顯存不足導(dǎo)致?lián)Q頁(yè)、模型加載卡住。應(yīng)對(duì)策略是設(shè)置多級(jí)超時(shí)批處理等待超時(shí)、單次推理超時(shí)、整體請(qǐng)求超時(shí)。任何一級(jí)超時(shí)都觸發(fā)降級(jí)比如返回緩存結(jié)果、切換到小模型、或者直接返回錯(cuò)誤并退還Token。我個(gè)人的經(jīng)驗(yàn)是降級(jí)策略要提前設(shè)計(jì)好不能等出事再想。而且降級(jí)要透明客戶得知道這次請(qǐng)求被降級(jí)了否則體驗(yàn)會(huì)很差。5.3 客戶余額與欠費(fèi)處理Token生意是預(yù)付費(fèi)模式為主客戶先充值后使用。余額不足時(shí)要及時(shí)提醒欠費(fèi)時(shí)要停止服務(wù)。這里的關(guān)鍵是提醒的時(shí)機(jī)和頻率。提醒太早客戶煩提醒太晚客戶來不及充值。通常設(shè)置三檔余額低于20%提醒一次低于10%再提醒歸零停止服務(wù)并保留數(shù)據(jù)一段時(shí)間。欠費(fèi)處理要溫和不要一欠費(fèi)就刪數(shù)據(jù)。給客戶一個(gè)緩沖期期間可以充值恢復(fù)。緩沖期過了再清理但清理前要再次通知。這些細(xì)節(jié)決定了客戶會(huì)不會(huì)續(xù)費(fèi)。5.4 模型切換與版本管理平臺(tái)上的模型會(huì)不斷更新新版本出來要切換。切換時(shí)最大的風(fēng)險(xiǎn)是行為不一致同樣的輸入新版本輸出不同可能導(dǎo)致客戶業(yè)務(wù)異常。所以切換要灰度先切一小部分流量觀察一段時(shí)間再全量。同時(shí)要保留舊版本一段時(shí)間方便回滾。版本管理還要注意計(jì)費(fèi)一致性。如果新舊版本單價(jià)不同切換時(shí)要明確按哪個(gè)版本計(jì)費(fèi)。通常按請(qǐng)求實(shí)際路由到的版本計(jì)費(fèi)但要在賬單里標(biāo)注清楚避免爭(zhēng)議。6. 算力之后Token生意的長(zhǎng)期邏輯把上面這些串起來看Token生意的本質(zhì)是把不穩(wěn)定的算力資源轉(zhuǎn)化成穩(wěn)定的服務(wù)能力再轉(zhuǎn)化成可計(jì)量的收入。粵港灣智算這類平臺(tái)的價(jià)值不在于它有多少?gòu)埧ǘ谟谒懿荒馨芽ㄗ兂煽蛻粼敢獬掷m(xù)付費(fèi)的Token服務(wù)。這個(gè)生意要長(zhǎng)期成立得滿足幾個(gè)條件計(jì)量要準(zhǔn)計(jì)費(fèi)要清服務(wù)要穩(wěn)成本要低。前三個(gè)是基本功第四個(gè)是競(jìng)爭(zhēng)力。誰(shuí)能把GPU利用率做得更高、把推理成本壓得更低誰(shuí)就能在Token單價(jià)上更有優(yōu)勢(shì)也就能吸引更多客戶。我在實(shí)際項(xiàng)目里的體會(huì)是Token生意不是一錘子買賣而是運(yùn)營(yíng)驅(qū)動(dòng)的細(xì)水長(zhǎng)流。定價(jià)、套餐、優(yōu)惠、降級(jí)、對(duì)賬每一個(gè)環(huán)節(jié)都要持續(xù)打磨。客戶用得好、算得清、付得值才會(huì)一直用下去。算力交付只是開場(chǎng)Token運(yùn)營(yíng)才是正戲。