养虾指南：低成本部署AI自动化服务的完整方案

先说结论：圈子里常说的“养虾”，指的不是水产养殖，而是“低成本部署一个长期运行的AI自动化服务”。这活儿最早是从自建聊天机器人、定时任务助手那批人嘴里传出来的，后来范围越扩越大，自动日报、订阅源聚合、定时爬虫、个人知识库问答、甚至挂个自动回复机器人都叫“养虾”。核心诉求就一句话：把AI跑起来，还要跑得久、跑得稳，最好一个月一分钱不花。

这篇文章我准备把最近一套“个人养虾最优部署方案”完整拆开，从需求分析、方案选型，到真实部署步骤、token消耗计算，再到怎么通过合规渠道白嫖上亿token，一次讲清。整个教程偏保姆级，适合刚入门又想省钱的人，也适合已经跑了几个月想把成本继续压下去的开发者。所有配置、命令、参数我都按自己实测过的版本写出来，直接照着抄基本能跑通。

1. “养虾”到底在养什么：先想清楚再动手

1.1 没有明确用途，千万别先买服务器

我见过不少新入坑的朋友，第一句话就是“我想搞个AI机器人”，然后立刻去开了一台高配服务器，装了一堆框架，结果一个月后连需求都没想清楚。养虾这件事，第一步不是买装备，而是想明白这只“虾”到底要干哪几件事。

拿我目前维护的“虾池”来举例，它大致承担三类任务：

• 每天早上8点自动抓取我订阅的几个技术资讯源，整理成摘要发到聊天群里。
• 有人通过群聊或网页端问问题，它能调用知识库做简单问答，替代一部分搜索引擎。
• 每周生成一份个人项目周报，素材来自这一周的代码提交记录和笔记，输出结构化文案。

这三类任务有个共同点：不是高并发、不是大流量、也不是多复杂的计算，而是“长期稳定地重复跑”。理解这点很重要，因为长期运行的东西，最怕的不是性能不够，而是费用失控和稳定性坍塌。服务器再便宜，一个月也得几十块钱，加上API调用费，一年下来就是一笔不小的开销。所以养虾的核心矛盾，从来不是“跑不动”，而是“跑不起”。

1.2 三条主流路线的成本账，差点把人带沟里

圈子里常见的方案，粗略能分成三条路线，各有各的坑。

第一条路线是“重度云API流”。所有任务都请求某个大模型厂商的在线API，效果好、接入快，但成本完全看调用量。我见过有人就养一个聊天机器人，一个月聊下来，token账单直接到了上千块。这种方案只适合有预算的人，和“白嫖”的目标背道而驰。

第二条路线是“本地大模型流”。自己搞一台好显卡的机器，跑开源大模型，看似零API成本，但硬件投入就是一笔大开销。哪怕用二手卡，一张几年前的卡也得几千块，电费也不低。而且个人首次配置大模型的推理环境，光是显存、CUDA、依赖库就能折腾好几个晚上。性价比并不高，除非你本来就有闲置的高配机器，或者纯粹为了学习和折腾。

第三条路线是“混合组合流”。这也是我最终选定的方向：用一台极其廉价的云容器，甚至免费的云函数，搭配开源的小参数模型处理简单任务，再让复杂任务走在线API的免费额度。复杂任务只占了总请求量的很小比例，而日常大量重复简单任务，全部在本地小模型和缓存里消化。这样既能享受开源模型的0成本，又能在关键场景用上大模型的能力。

1.3 我最终选定的方案组合

我这套方案具体是这么组成的：

• 运行载体：某大厂云的轻量容器，配置是2核2G，一个月费用低到可以忽略不计，经常参加活动还能白拿几个月的体验券。容器上跑Docker，里面挂了基础服务、缓存和调度器。
• 默认模型：一个1.5B参数的开源小模型，量化后体积不到1G，2G内存完全跑得动，回答短问题、做关键词抽取、判断意图已经足够。
• 大模型能力：只在复杂问答、长文总结、代码解释这类场景，才转发到在线大模型API，用的是我攒起来的免费token额度。
• 网络入口：容器自带公网IP，再挂一个轻量反向代理，就能把服务暴露给聊天机器人或网页端。

这套方案最大的优势是“成本天花板极低”。模型推理几乎不花钱，在线API有免费额度顶着，服务器费用也可以压缩到十几块钱。整只“虾”一年养下来，总成本可能还没有别人一个月花得多。

2. 保姆级部署实操：从零到一个能跑的“虾池”

2.1 准备一个刚刚好的容器，别追求高配

很多新人选配置的时候，总想着“反正不贵，要个4核8G”。但养虾的负载模式是持续低占用，不是突发高计算。2核2G的容器，跑一个小模型加几个轻量服务已经绰绰有余，选更高配只会白白多付钱。

我自己用的是2核2G、30G磁盘的配置，操作系统选了Ubuntu 22.04，Docker直接装好。系统装完后，第一件事是把必要的目录挂出来，比如宿主机上的/data/shrimp作为数据目录，用来放模型文件、缓存和日志。这样哪怕容器重建，数据也不会丢。

注意：容器选地域的时候，尽量选离你接入服务近的节点。很多人忽略了这一点，结果延迟高了一倍多，排查半天发现是跨区域网络问题。

2.2 部署基础运行环境：Docker和调度器

基础环境其实非常朴素，不需要什么高深的编排工具。我用的是Docker加一个简单的Python调度器，没有引入k8s或者复杂队列，因为个人项目根本没有那个规模。

第一步，装好Docker：

sudo apt update sudo apt install docker.io -y sudo systemctl enable docker sudo systemctl start docker

第二步，准备模型和服务的目录结构：

mkdir -p /data/shrimp/{models,cache,logs,scripts} cd /data/shrimp

第三步，运行模型推理服务。这里我用的是一个开源的量化小模型，下载完模型文件后，通过vLLM或者Ollama这类工具直接起一个API服务，端口设为8080。命令大致是这样：

docker run -d --name shrimp-model \ -v /data/shrimp/models:/models \ -p 8080:8080 \ --restart=always \ some-model-image \ --model /models/quantized-model \ --port 8080

整个过程如果顺利，执行完就可以用curl localhost:8080/v1/chat/completions测试一下。能返回正常JSON，说明本地推理服务已经起来了。

2.3 把免费token池接入在线大模型API

本地小模型能做不少事，但遇到复杂的语义理解、长文本归纳、代码调试，还是不如大模型。所以在线API的接入是必须的。

这是整个方案里唯一需要你“拥有账号”的部分。国内外的平台都有不少，注册后一般会送一笔体验额度。我同时接入了两到三个平台，把它们的Key写在一个配置文件里，调度器每次请求前会先检查当前哪个Key还有余额，自动切换。这个思路和你手机上装了几张流量卡自动切换是一个道理。

配置文件的格式是简单的YAML：

llm_providers: - name: platform_a base_url: https://api.placeholder-a.com/v1 api_key: sk-xxxx free_quota: 10000000 used: 0 - name: platform_b base_url: https://api.placeholder-b.com/v1 api_key: sk-yyyy free_quota: 5000000 used: 0

2.4 调度器：让任务自动跑起来

调度器是整个虾池的大脑。我用的方案是APScheduler加一个简单的队列池。每天中午和早上各跑一轮定时任务，每个任务被拆成一系列子请求，子请求进入队列后，由工作线程依次处理。

调度器逻辑不复杂，但有一个重点：必须设置全局并发限制。我一开始没设限制，结果某天凌晨的任务突然并发跑起来，直接把在线API的免费额度在几分钟内打光了。后来我加了一行配置，把全局并发数锁在2。宁可排队，也不要梭哈。额度用完不是最可怕的，最可怕的是被平台判定为异常使用，直接把整个账号封掉。

并发限制之后，还需要给每个任务单独设超时。比如调用在线API的请求，超时时间设置成120秒，超过这个时间就自动放弃并记入日志。

3. 白嫖上亿token的合规攻略：额度来源、叠加技巧与消耗控制

3.1 免费token的几大来源，先摸清地图

白嫖的核心不是去撸平台漏洞，而是把各家平台正规赠送的免费额度集中起来用。只要合理使用、不滥用，这本身没什么问题，就跟商家开业免费试吃一样，你去吃没问题，但你不能把全店的试吃品一次性搬空。

目前常见且相对靠谱的额度来源，大致有以下几类：

• 云平台的“新用户免费额度包”：不少大厂云会给新用户发放几百万到上千万token的额度，有的还附带几个月的免费服务器。
• 模型平台注册赠送额：国内外好几家直接提供大模型API的平台，注册即送一定额度，有的甚至达到几千万token。
• 开发者社区或技术活动：一些社区会和模型厂商合作，在限时活动里发放体验token，数量可观。
• 学生认证或教育套餐：如果你还在学校，有些平台的教育计划也会提供免费额度，比普通注册送的更多。

我的做法是建了一个表格，记录每个平台的赠送数量、有效期、已经用了多少。每次在线请求之前，程序会优先选“余额多且快过期”的额度，这才叫真正的利用效率。

下表是我当时整理的一个简化版本：

这几项加一起，光在线额度就有9000万token，再把本地模型长期跑下去，上亿token的实际可用量是真实存在的。

3.2 请求瘦身四招，让同样的token跑更久

很多人在意“源头”，却忽略了“耗损”。同样的一个任务，不同写法消耗的token能差好几倍。我总结了四个实际验证过有效的瘦身方法。

第一招，压缩system prompt。很多人习惯把角色设定写得特别长，动不动就几百字。但绝大多数任务根本不需要那么长的提示词，我后来把system prompt普遍压缩到40个字以内，只保留核心约束，token消耗直接降了一截。

第二招，控制max_tokens。有些平台默认的返回上限是2048或者4096，而很多简单任务根本不需要那么多字。比如判断用户意图这种任务，我设置max_tokens为32，既能正常返回，又能避免模型输出一堆无关内容。这个参数很多人不重视，实际上它对成本的影响极大。

第三招，历史消息滑动窗口。带上下文的多轮对话是最容易吃token的地方。如果每次都把整段历史发给模型，消耗会随着对话轮数线性上涨。我采取的做法是只保留最近3到5轮对话，更早的内容直接丢掉，或者用摘要替代。

第四招，拆请求而不是堆请求。一个复杂的任务，不要试图让模型在一段话里全部完成，而是拆成几个小步骤，每一个小步骤单独请求。比如“总结文章并列出三个要点”这个请求，拆成“先总结全文”“再提取三个要点”两个子请求，虽然请求次数变多了，但每次返回的内容更短，总token反而更省，而且准确率高很多。

3.3 缓存和批处理，把重复消耗降到零

你有没有算过，一个定时任务每天跑一遍，其中有多少次是拿到了一模一样的结果？如果答案没变，那这一次请求就是纯浪费。所以我的方案里特意加了一个本地缓存层，以“任务类型+输入内容哈希”作为key，把系统返回的结果缓存120分钟。同一个请求在这个窗口内直接命中缓存，不会再消耗任何token。

另外，对可以合并的请求，尽量合并处理。比如早上要抓取10个资讯源，如果每个源都单独调用模型做摘要，就会产生10次请求；但如果把10个源的文章文本拼成一个批量输入，让模型一次性输出10段摘要，再自己拆分，大概率能省下30%到50%的token。预算紧张的时候，这种小优化能撑大用。

提示：批处理要注意模型的输入长度上限。如果你的文章都很长，最好把一次性合并的数量控制在3到5篇以内，避免触发超长截断导致质量下降。

4. 常见问题与排查实录：养虾路上的坑

4.1 token对不上账，最先查这四个地方

养虾头一个月，最容易遇到的问题是：明明没怎么调用，额度却少了非常多。我拿到日志挨个排查，最后发现问题通常出在四个地方。

第一是system prompt没优化。有时候你在调试中反复调整提示词，每调一次都走一遍完整请求，积少成多，额度悄悄就没了。第二是历史消息没有瘦身。连续对话场景里，如果不做滑动窗口，token消耗会指数级上涨。第三是失败的请求被重试。网络抖动一次，SDK默认重试3次，相当于一次失败顶四次消耗。第四是平台统计口径不一样，有的平台把输入输出都算token，有的平台还额外计入缓存token，你看到消耗和预估不一致是正常的。

排查的办法是给每个请求打印详细的消耗清单，包括prompt字数、返回字数、命中缓存与否、重试次数。有了这些数据，你才能定位到具体的优化点。

4.2 免费额度的有效期陷阱

不同平台的额度有效期计算方式差别很大。有的是注册后固定30天有效，有的是从首次使用开始算，有的是每月1号刷新。我就吃过一次亏：某个平台的额度是次月作废，结果月底忘了用，白瞎了几百万token。

后来我给调度器加了一个“月末冲刺”逻辑：如果某个平台额度快过期了，而当前队列里又有合适的任务，就临时提高该平台的权重，优先把临期额度用完。这也是白嫖的规则之一：宁可让额度花在刀刃上，也别让平台把钱省回去。

4.3 触发限流或风控，先别慌

刚开始养虾的人，最容易一看到429就觉得天塌了。其实限流是常态，平台为了保护自家服务，都会对一些高频请求做限制。我遇到过的情况有几种：请求频率过高被临时限流，单次请求超时被中断，以及一次性消耗过快被风控系统盯上。

应对方式很简单：请求间隔设置成指数退避，第一次失败等5秒，第二次等20秒，第三次等60秒，并且严格控制并发数。如果连续失败超过5次，就暂时停掉这个平台的调用，把任务自动转到备用额度上。千万不能无限重试，也不要为了追求速度同时发起十几个请求，那样只会让账号死得更快。

4.4 个人养虾不要太“贪”

最后聊一点可能让你意外的话。白嫖攻略看起来很爽，但个人养虾这个事，追求上亿token不是目的，够用才是目的。我认识的一位朋友，花了一个星期搭好了一只虾，又花了一个月去研究怎么白嫖，最后发现真正每天消耗的token也就几十万，白嫖来的额度根本用不完。折腾了半天，省下来的钱没多少，时间倒是亏大了。

我的原则是：先让虾跑起来，再优化成本。如果一开始就钻牛角尖去抠token，反而容易陷入无休止的调参循环里。毕竟养虾这个东西，跑起来才有价值，放在配置里再华丽也是一堆代码。

5. 一些个人体会和后续扩展思路

自己跑这套方案大概三个月，踩过的坑不少，但收获也实在。整个项目走到现在，最让我意外的其实是本地小模型的表现——很多人以为开源小模型很拉胯，但当你把任务的输入输出腔调都严格控制好、不给它自由发挥的空间时，它在中短文本的处理上是完全能打的。每周自动总结报告、分类资讯、关键词抽取，这些常规任务我用本地模型跑了几个月，质量足够稳定。

关于后续扩展，我目前正在做的两件事，也顺手分享给你。

第一件事是给“虾池”接入语音通道。现在家里有个闲置的智能音箱，我在研究怎么把上面的语音助手和现有的问答案例打通。技术上不难，主要的挑战还是唤醒词的延迟控制。第二件事是尝试给本地小模型做定向微调，让它更熟悉我常用的文本格式。这个相对费时间，但一旦训好，后续生成质量提升的空间会很大。

如果你也想自己养一只虾，我的建议很简单：先拿一个最小的任务跑通，比如搭配一个免费容器加本地小模型，做定时摘要。跑通之后，再慢慢增加复杂功能。不要一上来就要搞个大而全的系统，容易失去掌控，也容易失去信心。养虾这件事没有标准答案，适合自己的配置就是最优配置，能长期跑下去就是最好的方案。