免费 LLM 端点在 CI 中不可靠,需要验证 JSON 契约有效性、延迟、幂等性、失败模式和输出漂移,而非简单信任。
免费模型端点并不神奇:CI 信任前的五项检查
一个免费模型端点在演示中看起来很棒。
但一次模型调用就是一个依赖项。它可能限流、超时,或者返回损坏的 JSON。我把它视为不可信,直到它通过一组小型测试。
声明:本文是 MonkeyCode 产品推广的一部分。
目标是 MonkeyCode 的免费模型端点和免费服务器选项。
我不预设模型名称、配额或硬件。这些细节会变。这套测试工具只需要一个端点 URL 和一个 token。
免费服务器在这里很有用。从那台服务器上运行测试脚本,而不是从笔记本上跑。你需要把端点的慢速和你的 Wi-Fi 隔离开来。
免费端点并不天然就是坏的。它只是需要证据。
合约有效性。响应能否解析为 JSON?是否包含你要求的字段?
重试下的延迟。一次调用需要多长时间?第一次调用失败时会发生什么?
幂等性。如果你发送相同的 prompt 两次,得到的结果结构是否相同?重试会改变答案吗?
失败模式。429、500、空响应体、或截断的 JSON 长什么样?
漂移。运行相同的 prompt 十次。输出变化有多大?
这些检查不衡量质量。它们只衡量端点是否可以安全地放入流水线。
把这个保存为 free_endpoint_probe.py。
import json
import os
import time
import urllib.error
import urllib.request
ENDPOINT = os.environ['MONKEYCODE_ENDPOINT']
TOKEN = os.environ['MONKEYCODE_TOKEN']
CASES = [
{'id': 'json_extract', 'prompt': 'Return JSON only with title and severity keys.'},
{'id': 'empty_prompt', 'prompt': ''},
{'id': 'long_prompt', 'prompt': 'Analyze this issue: ' + ('context ' * 500)},
]
def parse_json(raw: str):
try:
return json.loads(raw)
except json.JSONDecodeError:
start = raw.find('{')
end = raw.rfind('}')
if start != -1 and end != -1 and end > start:
try:
return json.loads(raw[start:end + 1])
except json.JSONDecodeError:
pass
return None
def call_once(prompt: str, timeout: int = 20):
payload = json.dumps({'prompt': prompt}).encode()
req = urllib.request.Request(
ENDPOINT,
data=payload,
headers={
'Authorization': f'Bearer {TOKEN}',
'Content-Type': 'application/json',
},
)
start = time.monotonic()
try:
with urllib.request.urlopen(req, timeout=timeout) as resp:
raw = resp.read().decode()
elapsed_ms = (time.monotonic() - start) * 1000
return {
'ok': True,
'status': resp.status,
'ms': round(elapsed_ms, 1),
'raw': raw,
'json': parse_json(raw),
}
except urllib.error.HTTPError as exc:
elapsed_ms = (time.monotonic() - start) * 1000
return {
'ok': False,
'status': exc.code,
'ms': round(elapsed_ms, 1),
'body': exc.read().decode()[:200],
}
except Exception as exc:
elapsed_ms = (time.monotonic() - start) * 1000
return {'ok': False, 'status': 'exception', 'ms': round(elapsed_ms, 1), 'error': str(exc)}
for case in CASES:
result = call_once(case['prompt'])
print(json.dumps({'case': case['id'], **result}, indent=2))
运行方式:
MONKEYCODE_ENDPOINT=https://your-endpoint MONKEYCODE_TOKEN=your-token python free_endpoint_probe.py
不要提交 token。
把它变成记分卡
在运行之前先制定通过/失败规则。
如果任何一项失败,先不要把端点接入 CI。
我预期会看到、但你需要验证的
这些是免费端点中的常见失败模式。不要把它们当作关于 MonkeyCode 的既定事实。用你自己的账户测试它们。
突发调用时的 429。
被句子或 markdown 围栏包裹的 JSON。
因为采样是非确定性的,重试会改变输出。
长 prompt 导致超时。
空 prompt 收到空响应体。
其中一些是可以接受的。429 可以接受,只要客户端会退避。但如果下一个任务假设是整数,损坏的 JSON 就不可接受。
这个测试工具不测什么
它不测准确性。
它不测模型给出的 severity 是否正确。它只测响应是否可用。
它也无法证明一个月的正常运行时间。如果你需要这个信号,把它做成定时任务来跑。
在发布时,我没有用当前的 MonkeyCode 配额运行过这组完整的测试。重点是协议,不是具体数字。
谁不应该在 CI 中使用免费端点
生产环境需要严格 SLA 的团队。
重试会改变结果含义的任务。
发送私有或受监管数据的工作负载。
不会固定和审查 prompt 合约的团队。
如果你承受不起检查损坏的 JSON,免费端点就不是你的瓶颈。
免费模型端点可以是一个有用的初体验。
但信任是测试结果,不是营销噱头。
复制这套测试工具。设置阈值。从免费服务器上跑。让记分卡来决定。
用和测试任何新依赖相同的方式测试 MonkeyCode 的免费端点。