DeepSeek 這一波，真的是把各家雲廠商都逼急了，你叫得出名字的，叫不出的，紛紛上線了 DeepSeek R1 模型。而且優惠力度非常大——半價、免費、送 Tokens 等，簡直把曾經發起 API 價格戰的 DeepSeek 官方都卷沉默了。
我本來是一直在拍手叫好的，但是作為開發者，我實際用了一圈後，我沉默了。
因為我發現不少雲廠商，雖然免費，但 TPM（Tokens Per Mintute）給限制的非常低，市面上大部分把 TPM 限制到了 1 萬左右，這直接讓我懵逼了。
這意味著什麼呢？
來，我給你算一算。
R1 的回答平均 Tokens 假如算 500（不算思維鏈內容），平均記憶 3 輪，再加上當前輪的輸入 tokens，輸入 tokens 平均 2000 不過分的。
而比較要命的其實是 R1 的輸出 Tokens（含思維鏈 Tokens），這個平均值相比非推理模型擴大了 4 倍 +，大部分業務場景，可以輕鬆跑出 2k+ 的平均 tokens 數量。
這意味著，平均來說，向無聯網搜尋能力的 R1 模型提問一次，會消耗約 4k 的 Tokens。
而 TPM=1 萬時，你每分鐘大約能向 R1 提問 10k/4k=2.5 次。
注意：這裡的平均每分鐘提問次數，並不等於執行緒層面的併發量；在 TPM 一定的情況下，推理速度越慢，可支援的執行緒併發量越大，但不會影響到實際能支撐的平均每分鐘提問次數。本文所指的併發主要指平均每分鐘提問次數。
好傢伙，我都準備拿你承接潑天的流量了，結果你告訴我你的 API 平均每分鐘只能呼叫 2.5 次。
如果你加上聯網搜尋功能或者文件對話功能，單次提問的 Tokens 消耗量可以輕鬆過萬，一分鐘平均只能提問不到 1 次。
完全沒有一點點併發能力…
這…雲廠商你這到底是在服務開發者/B 端，還是轉型服務 C 端了啊…
這也難怪不少開發者們乾脆折騰起來本地部署了…
但昨天，我突然發現了一個非常牛逼的雲廠商，終於把這個行業尬狀打破了。
火山引擎這一波，直接把 TPM 限制捲上來 500 倍，達到了 500 萬的 TPM 的限制，平均每分鐘可以撐起 500～1250 次提問。這就意味著，終於有可以拿來支撐真實場景流量的高併發滿血版 DeepSeek R1 API 了！
當我看到這個數字的時候，直接當場去手擼 demo 指令碼去做測試了。
我重點測試下面幾個維度：
-
效果測試：看是否真的是 671B 滿血版 -
吞吐率（throughout，也就是吐字速度，單位 tokens/s） -
首字延遲
先講下這個火山引擎的 R1 怎麼跑起來，已經熟悉的可以快速跳過。
火山引擎 DeepSeek-R1 的 API 呼叫流程
前置準備：去火山引擎官網註冊個賬號，進入火山方舟控制檯
火山引擎官網連結：
https://www.volcengine.com/
註冊完成後，點選上方大模型，然後找到下面的火山方舟，點選進入。
然後點選立即體驗，跳到火山方舟的控制檯——
附火山方舟控制檯直跳連結：
https://console.volcengine.com/ark
之後，你就能看到這個頁面了——
直接在方舟上就能體驗滿血版了，這裡跳過，我們直接看怎麼呼叫 API。
第一步：先建立模型推理接入點
模型推理接入點：是方舟將模型及配置抽象成的概念，提供靈活控制、服務指標監控、安全加固、風險防護等能力。
在火山方舟左側欄中點選【線上推理】，就能看到“建立推理接入點”選項了。
點選進入“建立推理接入點”的頁面，這裡填寫基本配置資訊，包括模型和計費方式，這裡模型一定選擇 DeepSeek-R1-250120 這個版本，和 deepseek 官方完全一樣。
建立好之後，就能看到我們剛才新建的接入點了，點右側“API 呼叫”。在這之前都是在平臺上的準備工作。
第二步：獲取 API Key
這一步就是拿到 model endpoint ID（建立接入點後就會有一個 ID）和 API key，後面呼叫需要用到。
第三步：API呼叫測試
Client 端測試程式碼示例：
import
os
from
openai
import
OpenAI
client = OpenAI(
api_key = os.environ.get(
"ARK_API_KEY"
),
base_url =
"https://ark.cn-beijing.volces.com/api/v3"
,
)
# Streaming:
print(
"----- streaming request -----"
)
stream = client.chat.completions.create(
model =
"your model endpoint ID"
,
# 建立推理接入點時就會對應一個ID
messages = [
{
"role"
:
"system"
,
"content"
:
"你是DeepSeek-R1, 是深度求索推出的推理大模型"
},
{
"role"
:
"user"
,
"content"
:
"模仿海子，寫一首現代愛情詩"
},
],
stream=
True
)
for
chunk
in
stream:
ifnot
chunk.choices:
continue
print(chunk.choices[
0
].delta.content, end=
""
)
print()
成功——
效果測試：檢測是否是 671B 滿血版 R1
這裡首先給小白科普一下，AI 不具備自我意識，並且可以內建 sysprompt 的影響。所以其實沒法直接透過問“你是 671B 滿血版嗎”這類問題來判斷對方是不是滿血版。
這裡“驗明真身”最靠譜的方式，還是直接去提問有難度的問題。因為 671B 滿血版，你可以認為是 R1 的能力上限。而市面上大大小小的蒸餾版本，都會導致回答效果大打折扣，尤其當遇到有挑戰、重推理的問題時，就非常容易露出馬腳。
比如我們可以用這個問題（來自知乎使用者 AI 大法師）：
網路梗 什麼你太美 用一個字回答 禁止搜尋
這個問題一方面需要 AI 具備一些世界知識儲備，蒸餾版的知識儲備往往不行；此外，解答該問題需要推理，蒸餾版的推理能力往往不行；最後，解答這個問題，需要指令遵循能力，蒸餾版這塊能力也比較差。
我們先看官網的回答——
沒錯，就一個“雞”。
我跑了下火山引擎的滿血版，回答如下——
與 DeepSeek 官網一樣。
需要強調一點，AI 的回答有隨機性，所以不可能出現兩個一模一樣的回答，尤其是思維鏈，不可能每個字都一致。這裡重點要關注的是 AI 是否有能力正確回答我們的問題。
此外，DeepSeek-R1 聯網搜尋之後，會基於參考資料作答，測試回答會有出入，以及更高的隨機性。
而火山引擎也提供了 32B 和 7B 的 R1 蒸餾版本。
比如你看 32B 蒸餾版本的回答——
好傢伙，“慘你太美”嗎？慘是誰？能吃嗎？
而 7B 版本的回答就更離譜了——
直接給崩了個“絕絕子”出來。你這個回答確實絕絕子，再見吧。
效果測試，完美透過。
更加炸裂的來了——
吞吐率實測
如果說火山引擎這波 R1 的高併發能力是一張王炸，那再搭配上它恐怖的吞吐率絕對可以說是雙王炸。
這是官方的測試——
你們直觀感受下這吐字速度——
我這裡隨機跑了 30 條問題，輸入長度不等。
計算一下，發現吞吐率竟然達到了恐怖的 35.4 tokens/s。這個速率，比市面上大部分 R1 API 快了數倍。
首字延遲實測
不止吞吐率，對使用體驗影響大的首字延遲，同樣低到令人髮指，一般都在幾百毫秒——
同樣，我這裡也批次跑了一下首字延遲統計——
不同輸入長度下，平均首字延遲僅有 0.39 秒。
除此之外，我也順手做了一把壓測，在 TPM 不被打爆的情況下，成功率均達到了 100%。
這裡順嘴提一下，我壓測的時候發現，如果 ReadTimeOut 設定的太小（例如 5 秒），會導致較高的失敗率，大家高併發的生產環境中時，一定要記得把這個數字打高（比如我這裡設定的是 30 秒，官方文件裡甚至建議改到 30min）。
恕我直言，在我的調研能力範圍內，能同時 671B 滿血版的併發量、吞吐率和首字延遲做到這麼高可用性的，我確實沒找到第二家。
DeepSeek-R1 聯網搜尋外掛
今天在逛火山官網的時候，我還發現了一個有用的玩法。
你可以在火山引擎的應用實驗室建立一個基於 DeepSeek-R1 的應用（智慧體），讓 R1 具備更強大的上層能力，如聯網、知識庫等。
比如這裡，我們在建立的時候，開啟聯網搜尋外掛——
這樣建立好的 DeepSeek-R1 智慧體便具備聯網搜尋能力了。
當然，不願意自己搭的話，在應用實驗室 – 廣場，有 DeepSeek-R1 搜尋的 Demo 可以直接用——
無論是橫向對比，絕對體感，還是增量 feature，我只能說火山上的這個滿血版 DeepSeek-R1 的 API 是真的香。
結語
不得不說這世界變化太快了。
如果說 DeepSeek 改變了遊戲規則，將 AI 賽道重新拉回了開源世界。
那麼此時此刻，火山引擎似乎已成為這場開源遊戲中跑的最快的雲廠商選手。
不說了，趁著現在火山的 DeepSeek-R1 還在半價折扣期，我先衝了！