前几天有个朋友找我聊项目他在腾讯云上通过聚搜云买了一波云资源准备把 Hy4 preview 真正用到业务里。我俩站在控制台前面他问了一句你说这模型我是直接调 API 划算还是干脆租 GPU 服务器自己部署 当时我愣了一下因为这个问题没有标准答案但它值得写一篇完整的经验贴。一边是 TokenHub 这类 Token 用量管理平台带来的按量计费和近乎零运维的便利另一边是 GPU 服务器的一次性投入、完全掌控和长期边际成本下降。两条路我都折腾过踩过不少坑今天就把账算清楚、把坑摆出来给正在纠结的团队一个参考。这个选题适合谁如果你正在腾讯云或任何主流云厂商上做大模型应用面对自部署还是调 API的选择如果你的技术负责人天天扒拉 Token 账单问为什么又超支了如果你刚把 Hy4 preview 的容器镜像推到云上然后被各种 login failed、docker api 连接失败、推理服务 500 报错搞得头大——这篇文章就是给你写的。1. 为什么自部署还是调 API不是一道选择题而是一道算术题很多人一开始就把思路搞偏了以为自部署和调 API 是两种对立的方案选一个就行了。实际上它们本质是同一份模型权重区别在于你把算力资源和运维责任放在哪个环节。调 API 相当于你按月买流量套餐运营商模型服务商负责网络、基站、运维你只需要关心交多少钱自部署相当于你自建机房买服务器、拉光纤、雇运维初期推土机一样砸钱但每多一个用户的边际成本几乎为零。所以这道题的核心变量有三个请求频率、延迟敏感度、数据隐私要求。搞清楚这三个剩下的全是算术题。先说请求频率。如果只是团队内部偶尔用用一天几百次问答调 API 的月度账单大概率在几百到几千块钱但如果是面向 C 端的客服机器人一天几十万次会话账单会在某个节点突然变成一台 GPU 服务器的包月价格这时候自部署就进入考虑范围了。再说延迟敏感度。API 调用要经过公网传输、网关转发、模型排队正常情况延迟在几百毫秒到两三秒之间高峰期还可能遇到排队。如果你的应用要求首 token 延迟在 200 毫秒以内比如金融交易的实时风控、实时语音交互那自部署几乎是唯一选择因为你控制不了 API 服务的排队策略。最后是数据隐私。这一点在政企项目里几乎是一票否决项。如果业务数据不出客户 VPC 是写在合同里的要求那 API 方案连标书都投不进去。这时候哪怕自部署成本更高也要硬着头皮上。还有一类很容易被忽视的情况你打算做二次开发、微调模型、或者接不同的推理框架。API 模式给你的是一个黑盒模型内部的 logits、attention 分布这些你根本拿不到自部署之后vLLM 的详细日志、显存分配、batch 策略全部可控。我见过很多团队一开始用 API 做验证后来产品形态复杂了就卡在黑盒上。这不是说 API 不好而是它在探索阶段和规模化阶段的适用性不一样。2. 调用 API 的账本TokenHub 的计费逻辑与隐藏成本2.1 TokenHub 到底在管什么TokenHub 这类平台的角色你可以理解成大模型 API 的水表 闸门 账本。它给你发 API Key限制每个 Key 的调用额度统计每次请求消耗的 Token 数最后生成一张可以按部门、按业务线拆分的账单。对于多团队协作的公司来说这套机制非常重要——它能防止某个业务线把预算全烧光也能让你看清哪个功能最费钱。实际用的时候建议不要所有业务共用一个 API Key。每个业务、每个环境开发、测试、生产单独建 Key在 TokenHub 里设置不同的配额。比如测试环境每天限 10 万 Token生产环境每周预警这样做的好处是某个环境出问题时不至于波及全局。这是我在实际中踩过坑后的反思。有一次一个同事把 Key 写死在脚本里然后脚本循环调用等发现时一天的账单已经抵得上平时一周了。2.2 Token 计费里最容易漏算的钱API 的计费单位是 Token但你请求的实际消耗是输入 Token 输出 Token。很多人只算了输出忽略了输入。输入 Token 是你发给模型的上下文包括系统提示词、历史对话记录、检索回来的资料。如果系统提示词写了两千字的规则每次请求都带着这笔费用是沉没成本你看不见但一直在扣。举个具体的例子。Hy4 preview 这类模型上下文窗口按热词里提到的报错来看是 1048576 个 Token也就是 100 万 Token 级别。这种模型在长文档摘要场景里确实强但长上下文的代价也非常实在。假设你喂给它一份 20 万 Token 的文档让它总结那这一次请求的计费就是 20 万输入 Token 起步。如果单价按输入 2 元/百万 Token、输出 8 元/百万 Token这只是测算口径实际价格以控制台为准一次请求光是输入成本就是 0.4 元。一天跑 1000 次这样的请求光这个场景就是 400 元/天。中文的 Token 换算也要有概念。一般来说1 个汉字约等于 1.5~2 个 Token英文一个词约等于 1~1.5 个 Token。看起来很短的一段提示词实际消耗往往比你直觉估算的多三分之一。所以做预算时要对 Token 消耗量先做压测不能拍脑袋。2.3 API 报错背后的稳定性账热词里那一串 API 报错其实是每个重度 API 用户都会遇到的400 表示上下文超长this models maximum context length is 1048576 tokens503 和 529 表示服务过载server overloaded / overloaded, usually temporary。这些报错说明你调 API 的时候稳定性并不完全掌握在自己手里。我的应对策略是三层。第一层在业务代码里做指数退避重试遇到 5xx 先等 1 秒、2 秒、4 秒再重试连续三次失败就降级到备用模型比如更小的模型或者本地缓存答案。第二层在 TokenHub 里设置每日消费上限和每分钟请求上限防止问题扩大。第三层也是最重要的对核心业务链路做本地兜底把高频、固定答案的问题缓存起来不走 API。比如你们公司的退货政策是什么这种问题答案是固定的完全没必要每次调用大模型。3. 自部署的硬门槛GPU 服务器不是买台机器那么简单3.1 显存估算为什么不能只看模型权重的大小很多人以为 70B 模型 FP16 精度大概是 140GB 显存租一台 8×H800 的服务器就完事了。这个算法漏掉了一个大头KV Cache键值缓存。长上下文场景下KV Cache 消耗的显存可能比模型权重还夸张。KV Cache 的大小取决于模型层数、注意力头数、隐藏层维度和序列长度。大致估算公式是每 Token 的 KV Cache 显存 层数 × 注意力头数 × 每个头的维度 × 每层两个矩阵 × 精度字节数。以 7B 模型为例层数 32、隐藏层 4096、16 个头FP16 精度下每 Token 的 KV Cache 大约在 1MB 左右实际更准确的说法是每 Token 每层大约几百 KB 到 1MB跟模型配置关系很大。但因为 Hy4 preview 支持 100 万 Token 的上下文如果模型有 80 层甚至更高序列填满的情况下 KV Cache 很轻松就能吃掉几百 GB 显存。这也是为什么长上下文模型的自部署比很多人预想的要贵得多。你部署的不只是模型权重还要为推测时的上下文预留大量显存。所以选 GPU 服务器时显存是第一优先级其次才是算力。如果预算有限优先考虑 80GB 显存的卡A100/H800/A800别省显存买 24GB 的小卡长文本一进来立刻 OOM。3.2 推理框架与量化决定你能同时服务多少人模型部署不是把权重拷上去敲个 python 就完事选推理框架直接影响你的吞吐。目前社区用得最多的是 vLLM 和 SGLang它们通过 PagedAttention、continuous batching 这些技术大幅提高吞吐。同样一台 8×H800用原生 PyTorch 推理可能只有个位数并发换成 vLLM 之后可以做到几十路并发具体数字取决于输入输出长度和 batch 策略。量化的选择也很关键。FP16/BF16 是基准显存不够可以上 INT8 或 AWQ 等 4-bit 量化。量化之后模型质量会有轻微下降但显存占用直接砍半。我的建议是业务场景以中文长文本为主、对输出质量极度敏感的尽量保持 BF16如果场景以短文本、分类、抽取为主4-bit 量化完全够用成本能省下来一大截。部署完成后一定要做并发压测。简单地用python脚本模拟不同并发数比如 1、5、10、20、50记录每路请求的延迟和整体吞吐。不要在没压测的情况下直接上线否则你以为能撑 100 路并发实际 30 路就 OOM 了。3.3 运维清单GPU 服务器上线后的日常自部署最容易被低估的是运维。你在云上买了 GPU 服务器不是说把模型跑起来就完了。我梳理一下日常要面对的事情镜像构建与推送模型服务和推理框架要打包成容器镜像推到腾讯云容器镜像服务然后拉取到 GPU 服务器运行。这个环节经常出现 docker login 失败、镜像上传中断、版本标签混乱的问题。进程监控你不可能每时每刻盯着终端。至少要用 systemd 或 supervisor 守护推理服务进程进程挂了自动重启并且把日志输出到固定目录。显存监控显存泄漏是推理服务的常见病。跑几天之后显存占用一路往上涨最后 OOM。需要用nvidia-smi定期记录显存占用设置告警线。模型版本更新Hy4 preview 这种名字里带 preview 的模型很可能过几周就出新版本。每次更新都要重新拉权重、重建镜像、灰度部署、回滚预案。安全防护公网开放的推理服务很容易被打热词里提到的腾讯云 WAF 绕过就是一个信号。自部署的服务至少要套一层网关做鉴权不要把裸 API 直接暴露到公网。同时对来源 IP 做白名单内部系统走 VPC 内网。3.4 GPU 服务器的成本结构腾讯云 GPU 服务器的计费方式有三种按量计费、包年包月、竞价实例。按量计费适合短期测试一个小时几十到几百块钱不等跑完就释放包年包月适合长期稳定运行的业务比按量便宜很多竞价实例适合可以接受随时被回收的离线任务价格可能只有按量的两折左右。省钱技巧是混用。核心在线业务用包年包月的稳定实例大数据批处理任务用竞价实例写个脚本定期检查实例是否被回收被回收了就把任务重新排队测试环境每天定时开机定时关机晚上和周末停了能省就省。4. 算总账典型场景下 API 和 GPU 自部署的盈利平衡点纸上谈兵没意思直接上场景和数据。假设 Hy4 preview API 的测算单价是输入 2 元/百万 Token、输出 8 元/百万 Token再次强调按此口径测算真实价格以你开通控制台时看到的为准。GPU 服务器按一台 8×H800 80G 包年折算月成本大概在几万元区间不同配置和地域差别很大实际以询价为准。先看一个 API 方案的完整账单模型。假设你的业务是 To B 客服助手每次请求平均输入 3000 Token包含系统提示词用户问题历史记录切片平均输出 300 Token那么每次请求的计费 Token 为 3300成本是 3000/100万×2 300/100万×8 0.006 0.0024 0.0084 元。一个月 100 万次请求API 费用就是 8400 元。如果摊上 TokenHub 的平台管理费月度总成本按 1 万元左右算。再看自部署方案。一台 8×H800 的服务器包年摊到每个月假设是 6 万元含网络和存储你可以在这台机器上部署一个量化版的 Hy4 preview并用 vLLM 做并发优化。如果吞吐能做到 1000 Token/s平均每次请求 3300 Token那么每秒可以处理约 0.3 个请求一天 86400 秒理论极限是 2.5 万次请求但实际要考虑高峰低谷按 30% 的利用率算每天约 7500 次一个月约 22 万次。用 6 万元的月成本除以 22 万次每次请求成本约 0.27 元反而比 API 贵。那是不是说明 API 总是划算别急这只是这台服务器跑不满的情况。如果你的业务真的能做到日均 5 万次请求一个月 150 万次每次成本就摊薄到 0.04 元明显低于 API 的 0.0084 元不这里算错了。0.0084 元是 API 每次请求的成本0.04 元是自部署每次请求的成本那还是 API 便宜这就引出了自部署的一个核心特点它有一个很陡的固定成本线。8×H800 服务器空转的时候也在花钱你的利用率越高、请求量越大单次请求成本越低。关键是找到打平点。打平点的计算公式很简单月 API 成本 每日请求量 × 30 × 单次请求 Token 成本 × 单价因子月 GPU 成本 固定租赁费 运维人力分摊。当两者相等时就是切换点。还是按上面的数据单次请求 API 成本 0.0084 元GPU 月成本 6 万元则需要月请求量约 714 万次也就是日均 23.8 万次。如果你的业务规模达不到这个量级API 方案在成本上就是更优解。但这只是纯成本账。下面这张表把不同业务形态的考量维度放进来你可以对照着自己算场景API 调用GPU 自部署低频内部问答日千次成本极低零运维首选不划算机器空转浪费高频客服系统日十万次以上账单快速膨胀受限于限流边际成本降低延迟可控长文档批量处理离线任务长上下文 Token 消耗巨大可用竞价实例压成本但排队调度复杂政企私有化/数据不出 VPC无法满足合规唯一选择初创团队无专职运维开箱即用聚焦业务需要至少一个能扛事的技术人员我见过一个比较聪明的做法是以 API 起步以自部署做兜底。业务初期流量不确定API 方案灵活随时可以停当 API 月度账单连续三个月超过自部署预估成本的 50% 时开始搭建自部署环境把高频流量切过去API 只用来做灰度测试和突发流量扩容。这种混合方案兼顾了灵活性和成本控制是目前我比较推荐的。5. 从容器镜像到推理服务我整理的完整排错笔记这一节把我实际踩过的坑和热词里那些报错信息串起来。很多人不太重视排错方法论反正报错了就搜、搜不到就重装。但遇到复杂问题没有清晰的排查路径只会越改越乱。5.1 推镜像时的login failed. check api token or gitlab version.这个报错我查到的时候也懵了明明是在腾讯云容器镜像服务上操作怎么会提示 GitLab version。后来才明白这是你本地 docker 配置里残留了 GitLab 容器仓库的认证信息导致 docker login 时读取的凭据不是腾讯云的。典型场景是你之前拿同一台机器推过 GitLab 的镜像现在切到腾讯云登录用的用户名密码变了但本地配置还留着旧的。排查步骤看~/.docker/config.json里面有多个 auth 条目的话确认当前登录的是哪个仓库地址。腾讯云容器镜像服务的登录命令格式是docker login ccr.ccs.tencentyun.com --username腾讯云账号ID或 TC 用户名密码不是你的登录密码而是访问令牌。这一步很多人会卡住误把云账号密码当密码用就一直报 unauthorized。如果 config.json 已经乱了最干净的办法是把它备份后删除重新执行 docker login。确认项目里用的仓库地址和命名空间是否一致仓库没创建就 push 也会报错。5.2 Windows 下 docker 引擎连不上failed to connect to the docker api at npipe:////./pipe/docker_engine这个报错出现在本地环境不代表云端有问题。npipe://是 Windows 容器管道的地址报错说明你的 Docker Desktop 没启动或者当前用户没有访问 Docker 引擎的权限。Windows 上最常见的原因是 Docker Desktop 开机自启失败或者 WSL 2 后端没起来。处理方式是检查 Docker Desktop 状态、重启 WSL 服务然后重新打开 Docker Desktop。在 Linux 服务器上一般是没装 docker-ce 或者 docker 服务没启动执行systemctl start docker就行。5.3 推理服务返回 500llama-server process has terminated这个报错是在服务跑起来了但实际推理时进程崩溃。llama-server 是 llama.cpp 体系的推理服务进程终止最常见的原因是显存资源不足。它不一定是整台机器显存满了更可能是单次请求分配的显存超了比如上下文长度设得太大进程直接被 OOMKilled。排查方法看dmesg或容器日志确认是不是 OOM。调低--ctx-size上下文长度比如从 1048576 降到 131072确认问题是否消失。确认模型路径和 GPU 设备映射正确。多卡环境下--tensor-split配置不对也会导致进程启动后立即崩溃。用排除法测试先跑很短的内容如果能过再逐步拉长和加大并发找到临界值。这类问题很有共性——不只是推理框架任何服务出现启动成功但运行一段时间就崩的情况都要先怀疑资源瓶颈其次才是代码问题。冷静下来看日志比盲目重启有效得多。5.4 修改 Redis 密码后重启失败这个虽然不是 Hy4 preview 的核心问题但热词里出现了说明很多人中招。在腾讯云服务器上装好 Redis修改配置文件里的requirepass之后重启 redis-server 一直失败报错信息看一眼配置文件语法、再看 systemd 服务单元里有没有指定--requirepass。很多 Linux 发行版的 Redis 默认 systemd 配置里覆盖掉了配置文件参数导致你改的requirepass不生效每次重启都是空密码而有的客户端已经用新密码连接了自然报错。解决方法是同步修改/etc/systemd/system/redis.service里的 ExecStart 参数然后systemctl daemon-reload再重启。这个坑的关键点在于排查问题要看这个服务是怎么被拉起的是 systemd、supervisord、docker-compose 还是裸进程启动方式不同配置覆盖关系完全不同按一个思路排查全世界的服务系统肯定会失败。5.5 自部署服务的网络安全加固服务部署好之后不要急着把端口暴露到公网。当初我在腾讯云上开了一个推理服务端口测试第二天日志里就出现了大量陌生 IP 的探测请求。热词里的腾讯云 WAF 绕过提醒我们防御不能只靠一层。我的常规做法是推理服务绑定内网地址只允许 VPC 内的业务服务器访问如果有公网访问需求通过 API 网关做转发网关层做鉴权和限流安全组规则最小化只放行必要端口比如 22、80/443、业务端口其他全拒Redis、数据库这类中间件不要暴露公网端口除非你有充分的理由并做好了白名单。6. 最终选型清单我的建议和一套可复制的决策模板说了一堆落实到决策上建议你拿下面这个清单逐条打勾决策问题走 API走自部署数据是否必须留在自己的 VPC/内网否是月请求量是否有希望达到数百万次量级难说/不到是对首 token 延迟是否在 300ms 以下否是团队是否有会看日志、能处理容器崩溃的人否是预算结构是无法承担大额一次性支出还是可以按月付费前者后者是否需要对模型做微调、LoRA 等定制否是是否允许公网传输数据到第三方服务是否如果你的答案里走自部署超过一半那就往前推进如果全是走 API那现阶段 API 肯定更适合你没必要为了拥有模型的执念多花钱。我的实际建议是分阶段走第一个月先用 API 验证业务闭环把 TokenHub 的配额和监控配置好重点观测日均 Token 消耗和真实请求量。当 API 月度成本连续三个月超过自部署预估月成本的 50% 时启动自部署迁移。迁移时先只迁一个高价值场景跑稳了再逐步扩大。最后再分享一个实操小技巧。不管你是走 API 还是自部署都要给每个子业务单独建 API Key 或单独的模型副本并在 TokenHub或自建的网关里设定独立配额。这就像给家庭电路分路装空气开关一路跳闸不会全屋断电。真出问题的时候你只需要关掉出问题的线路其他业务完全不受影响。这个习惯能让你省掉很多半夜被拉起来排障的精力。