Q1：本周IDC圈疯传的“词元按带宽计费”是怎么回事？会影响我跑开源大模型吗？
这源于某头部云厂商更新了AI服务器租用条款，将推理过程中的“词元吞吐量”与出网带宽叠加计费。通俗说，以前带宽按GB算，现在按“每秒生成的词元数”折算成带宽占用。对跑开源模型（如Llama 3）的企业，这直接导致成本模型剧变。但更关键的是许可证问题——如果你的模型是AGPL或SSPL授权，对外提供API服务时，词元流经的服务器和网络设备，是否构成“再分发”或“网络交互”？本周Linux基金会的一份非正式备忘指出，按词元计费可能触发AGPL第13条的“网络使用”条款，即用户通过公共网络使用修改版软件时，需提供对应源代码。这比传统带宽计费更容易踩雷，因为每次词元交互都被视为一次“网络传播”。
Q2：我买的二手AI服务器预装了开源驱动，许可证合规责任是卖家的还是我的？
本周一个典型判例在德国慕尼黑法院初裁：二手服务器上的GPL驱动固件，卖家需提供完整对应源码，但买家在知情后继续用于商业推理服务，则视为“共同责任人”。IDC行业常见误区是“只要我不改驱动，就不算衍生作品”——但GPL的“运行”权利附带了“不附加额外限制”的义务。若你的服务器带宽被IDC机房做了QoS限速或流量整形，这属于“技术措施限制”，可能违反GPL第6条禁止的“额外限制”。建议：采购二手AI服务器时，合同必须明确“源码交付”条款，并让卖方书面承诺无隐藏网络限制。
Q3：开源许可证对“服务器带宽”本身有约束吗？比如我用开源软路由或SDN软件。
这是本周最被忽视的坑。很多IDC用开源如Open vSwitch或DPDK做网络虚拟化，但许可证（Apache-2.0或BSD）不约束带宽。然而，若你用了基于Linux内核的TC（流量控制）或XDP程序，且以模块方式加载，GPL传染性会覆盖整个网络栈。本周一个案例：某IDC用GPL的eBPF程序做DDoS清洗，被原作者投诉其“带宽整形逻辑”未开源。法院初步支持原告，认为带宽管理属于“核心功能”，必须提供对应源码。合规建议：区分“用户态软件”和“内核模块”，后者务必审计许可证；网络设备的配置脚本如果调用了GPL库函数，脚本本身也可能被视为衍生作品。
Q4：AI推理时的“词元流”经过开源负载均衡器（如Nginx或HAProxy），这算‘网络传播’吗？
争议焦点在于“词元”是否属于“软件输出”。Nginx是BSD许可，不限制流量内容。但若你使用Nginx的第三方模块（例如基于AGPL的AI网关插件）来处理词元路由，那么整个请求链的日志、缓存、甚至带宽计量插件都可能被传染。本周Reddit上爆出一个案例：某公司用AGPL的AI网关插件，其内部监控工具记录了每个词元的大小和方向，被原作者要求公开监控面板源码——因为监控数据属于“修改后的网络交互状态”。目前无判例定论，但主流合规意见是：将开源网关与商业监控解耦，或改用Apache 2.0的替代方案（如Envoy）。建议用开源负载均衡器时，只启用纯转发功能，关闭任何记录或转换词元的插件，避免被判定为“修改行为”。
0 留言