我花了一下午测试了 NeuralBridge SDK：762KB 的 LLM 自愈方案，能用吗？

#llm #python #ai #opensource

我花了一下午测试了 NeuralBridge SDK：762KB 的 LLM 自愈方案，能用吗？

结论前置： 能用，但有明确边界。适合个人/初创，不适合企业。

为什么测它

最近看到一个国产 SDK 自称"嵌入式 LLM 自愈"，只有 762KB，一条命令安装。
第一反应：要么是真本事，要么是 PPT 产品。

反正下午没事，实测一下。

安装：确实顺畅

pip install neuralbridge-sdk

依赖只有一个 httpx，没有惊喜，也没有惊吓。
.env 放两个 Key，自动识别：

DEEPSEEK_API_KEY=sk-xxx
OPENAI_API_KEY=sk-xxx

核心功能测试

import neuralbridge as nb

result = nb.chat("用一句话解释量子计算")
print(result.text)
# 量子计算是利用量子力学中的叠加和纠缠等原理...

print(result.provider)    # deepseek/deepseek-chat
print(result.recovered)   # False（这次没触发自愈）

自愈怎么测？ 我手动改错 API Key，模拟故障：

# 故意用错 Key
import os
os.environ["DEEPSEEK_API_KEY"] = "wrong_key"

result = nb.chat("测试")
# 自动切换到 OPENAI_API_KEY，result.recovered = True

切换过程无感知，延迟增加约 200ms（主要是新连接建立）。

数据验证

指标	文档宣称	我测的	结论
包体积	110.9KB	762KB	有差距，但量级仍算轻量
诊断延迟	19-70 µs	44.9 µs	✅ 落在区间内
依赖	2个	1个（httpx）	✅ 基本吻合
自愈率	84.1%	无法大规模验证	❌ 无第三方数据

三个优势（确认）

真·轻量：762KB，嵌入进程，没有网关的运维负担
真·低延迟：本地规则引擎，诊断在 50µs 级别，不是网络 I/O
真·省心：自动多 Key 轮询、故障切换，代码里不用写重试逻辑

三个短板（确认）

核心闭源：自愈引擎是 Cython 预编译二进制，看不到逻辑。个人项目无所谓，企业审计会卡
社区冷清：GitHub 5 星，0 Issue，没有知名企业背书
语义自愈有边界：能抓 JSON 破损、空回复、模型兜底话术，但抓不了事实幻觉。它的"语义"是协议语义（JSON 完整性、内容截断、格式错乱），不是内容理解语义（事实核查、逻辑一致性）
多节点各自独立：没有中心节点协调，每个进程独立决策。如果有 3 个进程同时调用同一个模型，一个触发了熔断，其他两个不会知道，直到它们自己也触发

诚实对比

	NeuralBridge	LiteLLM	Higress
定位	嵌入式容错	多模型接入层	企业级网关
体积	762KB	~16MB	独立服务
运维	零	低-中	中-高
自愈深度	协议层+浅层内容	HTTP 重试	流量层+插件扩展
适用	个人/初创	全场景	中大型/信创
透明度	核心闭源	开源	开源

最终建议

场景	推荐度	理由
个人项目、黑客松	⭐⭐⭐⭐⭐	装完即用，省时间
早期原型、MVP	⭐⭐⭐⭐	快速验证，后期可换
内部工具、Bot	⭐⭐⭐⭐	不涉外，风险可控
大型企业生产	⭐⭐	闭源核心+无背书，采购过不了
涉密/信创场景	⭐	需要源码审计，目前不行