Hetzner：我们在实验AI推理API，就想知道用户是否真需要它

德国云服务商Hetzner的工程师们最近做了一个让人有点意外的动作：他们在自家的基础设施上跑起了一个大语言模型推理API，并且直接开放给用户试用。没有账单、没有服务等级协议、没有任何生产环境保障，目前只挂了一个模型。按照Hetzner自己的说法，这就是一个纯粹的实验——团队想弄清楚几件事：用户是不是真的需要这种服务？系统能扩到什么程度？哪些功能才是开发者真正在乎的？承载的压力能有多大？

这不是一次正式的产品发布，更像是一个技术团队把早期阶段的东西推到用户面前，然后蹲在数据后台看反馈。这种“先扔出来再看”的做派在消费级互联网里不算新鲜，但在企业级云服务领域其实挺少见。通常的剧本是先把功能锁在私有预览里，让大客户用几个月，再配上完整的价格和SLA才敢对外说“我们有了”。而Hetzner这次直接把实验的控制台和API token生成交给了所有愿意试的人，连一篇像样的产品文档都没准备齐全。

实验性的API叫Hetzner Inference，完全兼容OpenAI的接口规范。你只要在Hetzner的实验控制面板里创建一个API令牌，然后把OpenAI客户端库的base_url指向Hetzner的地址，剩下的调用方式和绝大部分推理API没什么区别。这对于已经熟悉OpenAI Python SDK的开发者来说，几乎不需要学习成本。Hetzner还特意放出了一份简短教程，教你怎么把OpenCode这个编码工具直接接到他们的API上，连代码都不用写就能用起来。

目前唯一能调用的模型是Qwen/Qwen3.6-35B-A3B-FP8。这是一个35B参数的混合专家模型，每次推理实际激活的参数量只有3B。它既支持文本也支持图片输入，上下文窗口长达262K token，权重采用FP8量化。从选型的角度来看，这个模型很适合拿来当实验品：体量不大，不需要一大片昂贵的GPU集群去伺候，但又足够有代表性，能让开发者用真实的负载去测试API的各项能力。如果用太小的模型，很多应用场景根本测不出效果；直接用几百B的稠密模型，实验成本又太高。35B的MoE模型恰好踩在一个很舒服的平衡点上。

混合专家架构本身值得多说两句。传统的稠密模型无论处理什么问题，整个模型的所有参数都会被激活。而MoE把模型拆成多个“专家”子网络，每次推理只按需激活其中一小部分。这就好比一家大公司里有很多专业部门，但每一个具体的任务只调动两三个相关团队，其他人继续休息。这样既保持了模型整体的知识宽度，又把每一次推理的计算量压了下来。Hetzner选用的这个模型总参数达到350亿，但真正跑起来只要驱动30亿个参数，推理成本自然就下来了。FP8量化则进一步裁剪了权重存储和计算的精度，用更少的显存和更快的矩阵运算换取几乎不打折扣的生成质量。这种搭配意味着在用户端感受上，响应速度会比较快；而站在Hetzner的立场，单位时间的服务成本也更好控制，适合大范围开放测试。

API的使用方式非常标准。用pip装好openai库，写几行代码就行。有意思的是请求体里一个叫enable_thinking的额外参数。模型的推理过程可以分两部分：内部“思考”时间和最终生成可见答案的时间。如果不关掉这个选项，模型可能会把一部分生成预算花在推理链条上，用户在前端要等好一阵子才能看到文字蹦出来。在测试中这个开关确实有效，能明显压减等待感。但Hetzner目前没有把这个参数写到正式文档里，只是在实验环境中暴露了出来，这意味着围绕它的具体请求格式可能还会变动，暂时不适合拿来构建生产特性。

7月23日我用单个客户端做了一些粗略测试，结果就是三个字：相当快。具体数字我不想列，因为这个产品还处在实验期，此时此刻跑出来的一组数字说明不了任何稳态性能，尤其当大量用户同时开始调用的时候，延迟曲线会是什么样的谁也不知道。Hetzner没承诺任何响应时间，所以哪怕明天速度变慢或者偶发失败也完全在预期范围内。真正有价值的是模型的输出质量大致符合预期：格式化指令和检索类任务多数能正确执行，图片输入也能正常处理，不过在几个非常简单的测试上出过错误。这恰好印证了实验的定位——现在API和模型都不是拿来干正事儿的，而是拿来发现问题、迭代打磨的。

把这次实验放在更大的背景下看，它的有趣之处不在于Hetzner突然变出了一套AI推理服务，而在于一家长期以高性价比云基础资源著称的公司，开始试探性地向上层应用靠近。Hetzner过去的主力产品是便宜且稳定的虚拟服务器和裸金属服务器，跟AI推理之间差了一个“平台化交付”的台阶。现在它自己搭了一套推理栈，把模型权重加载在自己机房里的GPU上，再通过标准API往外提供token生成能力，本质上是在对“云厂商要不要自己搞模型推理服务”这个问题给出一种实践式的回答。而且回答的方式最低调、最务实：先不急着定价，先不保证稳定性，先看看用户到底会不会用、怎么用、愿意为什么买单。

这种试探思路对开发者来说也有一个直接价值——降低尝试的门槛。正式的商业推理API通常要充值、签协议、选定服务等级，而Hetzner Inference目前完全没有这些环节。有想法的人几分钟就能拿到token直接调，这很契合开发者社区里“先跑起来看看”的惯性思维。哪怕最后证明这套API不成熟，或者日后收费策略跟预期不符，在实验期间积累的接入经验和反馈也能帮Hetzner校准方向。而对于那些原本就在Hetzner上托管应用的团队，未来如果能在一个云账号下同时管理计算、存储和推理资源，整体架构的复杂性会明显简化。

当然，话必须说清楚：现在把任何生产级AI负载迁移过去都太早了。只有一个模型、没有SLA、没有付费渠道、连API行为都可能随时变更，这离“可用”还隔着一层“实验”的标记。但正是这层标记让整个尝试显得更真实：Hetzner没有试图包装成已经准备好服务的样子，而是把当前的真实状态摊开给所有人看。对于一线工程师和产品决策者来说，这种透明度比很多过度承诺更有参考价值。它等于在告诉外界：我们正在学，不确定的部分很多，但我们愿意跟社区一起推进。

回到那个核心问题上——用户到底需不需要云厂商自己搞的推理API？市场上有大量专门的模型推理平台、开源部署方案和闭源巨头提供的端点，Hetzner的切入理由是什么？实验本身还没有给出答案，但它已经开始收集数据了。而在AI基础设施的重心逐渐从训练向推理偏移的当下，任何认真回答这个问题的动作都值得关注一下。