我被偷跑的平台并不是 deepseek ，而是杭州的另一 LLM 厂商，为了避免麻烦，隐去名字了，下面就叫它杭州厂。
事情是上个月发生的，然而时至今日，我仍然不知道我的 apikey 为何被盗，也请大家帮我分析分析。
我厂是个小作坊，主用火山的豆包模型，杭州厂是故障备份，系统按请求结果自动切换主备。我们每天在火山大约消耗 1 亿 token ，杭州厂这边则是零零星星，一个月消费一两块。
6 月底，杭州厂的商务打电话给我们，说发现 LLM 用量突增，希望线下拜访了解业务，我们这才发现当月 LLM 账单暴增到 2000 多。
在 5 、6 两个月，我们断断续续被盗刷了大约 2755 元。我们的主力业务 apikey ，使用了两个业务不会用到的模型，一个是翻译模型，另一个是个新模型，输入 1.4 亿，输出 3.5 亿，IP 是 114.242.33.* 北京联通家宽。杭州厂的工单人员抽查发现，所有请求都是在干一件事：翻译。而翻译的文本题材天南海北，毫无规律，有些文字甚至都不太通顺。
在更换 apikey 的时候，我们发现了一些很奇妙的事情。
我们原本在杭州厂有 4 个 LLM apikey ，创建时间从去年 3 月到今年 4 月。被盗用的是最早的 key ，4 个 key 除去 sk-的前缀后，按照创建时间，开头分别是 0,2,a,d ，看起来是一个自增的 32 位的 uuid 。如果 uuid 的生成算法有缺陷，就可能被撞出来。
建立新 key 时，发现杭州厂的 apikey 系统已经彻底革新，新 key 达到了 100 个字符以上的长度，甚至给每个账号提供了不同的 base url ，这就解决了我们担忧的被撞的问题，真是巧啊。
工单面对我撞 key 的疑问，在沉默了一周后，回复「 Key 本身也具备足够的安全性，无法被暴力破解」。
当你发现一只蟑螂的时候…… 我们就查了查自己的屋子：
实在是也找不出什么问题。
总之，到最后也没弄明白，黑客到底怎么拿到这个 apikey ，又为什么要翻译那几亿文字。
这件事留下的谜太多了。。。
