独享推理从开通到跑通，我踩过的坑

我花了两天试了一下 Together AI 的 Dedicated Model Inference。名字听着唬人，实际就一件事，不跟别人挤同一批 GPU，自己包下来跑模型。

先解释两个词。平时大家调模型，大多是按 token 付费的共享 API，你发一条请求，服务商从公共池子里分一块算力给你。这像公共食堂，按份收钱，便宜，但饭点得排队。独享推理是自己包一个灶台，GPU 只跑你的活，费用按预留的机器和时长算。素材里 DigitalOcean 讲这件事用的是「预留容量消掉了共享资源的波动」，CoreWeave 那边把它拆成建网关、建部署两步走。口径基本一致，都是同一件事的三种说法。

先说你要不要包这个灶台。判断标准其实只有一条，看你的调用量是不是每天都稳。量小、波动大，用共享 API 就行。量大、全天都在跑、延迟一飘业务就出问题，才轮到独享。我前阵子拆 AI 服务器回收那篇也是这个路子，先看成本结构再看结论，别被宣传口径带着走。这个产品给的是 99% 可用性 SLA 和预留吞吐，翻译成人话就是机器先给你留着，出问题有兜底承诺。代价是空转也得付钱。

从零到跑通第一条请求，下面是我这边的完整路径，菜单名不同账号可能差一两个字，位置都在部署类目下面。

1. 注册完进控制台，左侧找 Dedicated 或者 Models，点进去是模型列表。

2. 选模型。列表里是 Llama、Qwen 这类开源模型。看两栏，上下文长度和量化版本。上下文长度是一次能塞进去多少字，量化版本可以理解成压缩过的模型，跑得快、占显存少，回答质量会掉一点。

3. 选硬件和副本数。副本数就是同时开几台机器，1 台够跑通，2 台以上才开始谈吞吐。第一次填 1。

4. 起个部署名字，提交。状态先显示 Pending，我这边大概等了十几分钟才变 Running。这步最容易手贱刷新页面，别刷。

5. 变成 Running 后，页面给一个 base URL 和一把 API key。它兼容现有 API 格式，代码里基本只改两行，base_url 换新的，模型名换成你部署的那个。

6. 先发一条最小请求，别一上来就压测。

7. 通了之后，再拿真实数据跑一轮。

踩坑都集中在第 5、6 步。我第一条请求报错，是因为模型名填了列表页显示的那个，实际要用部署详情页里的 ID。第二个坑是冷启动，刚 Running 的头几条请求明显慢，别拿这个当性能结论。第三个坑是并发，按共享 API 的习惯直接怼几十个并发上去，独享这边副本数是固定的，超出部分只能排队，这次是我自己副本配少了。

再说优缺点。延迟稳，共享池晚高峰会飘，独享这边我测下来基本是一条线；成本可预测，按预留算不按 token 算，做预算的时候好写；迁移成本低，兼容现有 API，改动量小。反过来，空转也付钱，量小的时候比按 token 贵得多；弹性差，突发流量来了加副本要等，不像共享池那样自动扩；运维责任变多，选型号、调副本、盯利用率，这些活以前是服务商干的，现在归你。

我的判断是，它适合日均调用稳定、延迟敏感的场景，不适合白天冷清、晚上爆发的业务。

学完这个，下一步可以试的是，把你现在的调用日志导出来，按天画一条曲线，看波峰和波谷差多少倍。差得小就切独享，差得大就先留着共享，或者两条腿走路。包灶台这件事，最后还是落到算账上。