硅基流动拉新活动：接入 OpenCode 实测 GLM-5.2 首字延迟

硅基流动（SiliconFlow）近期推出拉新活动，新用户注册即可获得免费额度，体验 GLM-5.2、DeepSeek、Qwen 等主流开源模型。本文记录将该平台接入 OpenCode 编程代理的完整步骤，并用脚本实测 GLM-5.2 的首字返回时间（TTFT），供追求低延迟编码体验的开发者参考。

为什么选硅基流动

日常用 OpenCode 这类 AI 编程代理时，模型响应速度直接决定编写体验。常见的痛点是：

海外平台延迟高：OpenRouter、together.ai 等平台从国内访问，首字常常要 3 秒以上；
网关代理抖动大：走 omniroute 之类的二次路由，虽然能聚合多家模型，但网关本身会叠加数百毫秒到数秒不等的延迟；
本地部署门槛高：自己跑 GLM-5.2 这种大模型，显存和时间成本都不低。

硅基流动是国内 inference 服务商，服务器在国内，模型推理和跨境都没额外开销。当前还有拉新活动，新用户注册送免费额度，适合先用小钱试水。

活动注册入口（填写邀请码自动绑定）：https://cloud.siliconflow.cn/i/cdIVTUIN

注册并获取 API Key

打开硅基流动控制台，使用手机号或 GitHub 账号登录；
进入「API 密钥」页面，点击「新建密钥」，复制以 sk- 开头的字符串；
妥善保存密钥，后续配置要用。

免费额度足以跑完本文的 TTFT 测试，也可以直接拿来做日常编程。

接入 OpenCode

OpenCode 支持任意 OpenAI 兼容的 provider，硅基流动的接口路径是 https://api.siliconflow.cn/v1，完全兼容。

配置文件

打开 ~/.config/opencode/opencode.jsonc，在 provider 段增加：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "siliconflow": {
      "name": "硅基流动",
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://api.siliconflow.cn/v1",
        "apiKey": "{env:SILICONFLOW_API_KEY}"
      },
      "models": {
        "zai-org/GLM-5.2": {
          "name": "GLM-5.2",
          "limit": {
            "context": 128000,
            "output": 16384
          }
        }
      }
    }
  }
}

几个要点说明：

npm：固定写 @ai-sdk/openai-compatible，适配 /v1/chat/completions 接口；
apiKey：用 {env:XXX} 语法引用环境变量，避免密钥硬编码进配置文件；
limit.context / limit.output：这步最关键。OpenCode 对标准 provider 会从 models.dev 自动拉取模型上下文窗口大小，但自定义 provider 不会。如果漏写 limit 字段，OpenCode 不知道模型能吃多少 token，UI 里的上下文剩余量会一直显示为 0，自动压缩、截断策略也会失效。GLM-5.2 的上下文为 128K，输出上限 16K，按上面填即可。

设置环境变量

把密钥放进环境变量，PowerShell 执行：

1
[Environment]::SetEnvironmentVariable("SILICONFLOW_API_KEY", "sk-你的密钥", "User")

重启终端后 echo $env:SILICONFLOW_API_KEY 应能看到密钥。

选择模型

在 OpenCode TUI 里输入 /models，选 硅基流动 / GLM-5.2 即可开始对话。

实测 GLM-5.2 首字延迟

光看体感不够严谨，下面用一个脚本直接打 API，测 5 次取平均，分别记录：

TTFB：从发出请求到收到第一个字节的时间（含网络往返 + 模型 TTFT）；
Total：完整响应结束的总耗时。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
$key = $env:SILICONFLOW_API_KEY
$body = '{"model":"zai-org/GLM-5.2","messages":[{"role":"user","content":"say ok"}],"stream":true}'

$ttfts = @(); $totals = @()
for ($i = 1; $i -le 5; $i++) {
    $r = cmd /c "curl -s -w ""\nTTFT:%{time_starttransfer}s Total:%{time_total}s HTTP:%{http_code}"" -X POST https://api.siliconflow.cn/v1/chat/completions -H ""Content-Type: application/json"" -H ""Authorization: Bearer $key"" -d ""$body""" 2>&1
    $lines = $r -split "`n"
    $timingLine = ($lines | Select-String "TTFT:" | Select-Object -First 1).ToString().Trim()
    $ttft = [double]($timingLine -replace ".*TTFT:([0-9.]+)s.*", '$1')
    $total = [double]($timingLine -replace ".*Total:([0-9.]+)s.*", '$1')
    Write-Output ("Run {0}: TTFT={1}s Total={2}s" -f $i, $ttft, $total)
    $ttfts += $ttft * 1000; $totals += $total * 1000
    Start-Sleep -Milliseconds 500
}

$tAvg = [math]::Round(($ttfts | Measure-Object -Average).Average, 0)
$tMin = ($ttfts | Measure-Object -Minimum).Minimum
$tMax = ($ttfts | Measure-Object -Maximum).Maximum
Write-Output ("TTFT  Avg: {0}ms | Min: {1}ms | Max: {2}ms" -f $tAvg, $tMin, $tMax)

测试结果

我用上面的脚本跑了五轮，prompt 为最简单的 say ok，开启流式输出：

1
2
3
4
5
6
7
Run 1: 2048ms | Model=zai-org/GLM-5.2 | HTTP=200
Run 2: 1660ms | Model=zai-org/GLM-5.2 | HTTP=200
Run 3: 1481ms | Model=zai-org/GLM-5.2 | HTTP=200
Run 4: 2259ms | Model=zai-org/GLM-5.2 | HTTP=200
Run 5: 1826ms | Model=zai-org/GLM-5.2 | HTTP=200

Avg: 1855ms | Min: 1481ms | Max: 2259ms

注意这是完整响应结束时间，不是严格意义上的 TTFT。由于 prompt 只有两个 token、输出也很短，token 生成本身耗时几百毫秒，真实流式首字时间估算在 1.0s~1.8s 之间。

与 omniroute 网关方案对比

我之前在 OpenCode 里走 omniroute 的 auto/coding 路由，它背后实际也路由到 GLM-5.2，但中间多了一层网关。用同样的脚本测五次：

1
2
3
4
5
6
7
omniroute (自定义网关) Run 1:  4382ms | Gateway=676ms
omniroute (自定义网关) Run 2:  8094ms | Gateway=1093ms
omniroute (自定义网关) Run 3:  4879ms | Gateway=2077ms
omniroute (自定义网关) Run 4: 13349ms | Gateway=11356ms ← 抖动
omniroute (自定义网关) Run 5:  4615ms | Gateway=1454ms

Avg: 7064ms | Min: 4382ms | Max: 13349ms

汇总对比：

方案	平均响应	最小值	最大值	稳定性
硅基流动直连	1855ms	1481ms	2259ms	抖动小
omniroute 网关	7064ms	4382ms	13349ms	明显抖动

硅基流动直连快约 4 倍，而且 P99 表现稳得多——max 只有 2.3s，omniroute 却飙到 13s。对交互式编码来说，「偶尔卡 10 秒」比「平均慢一点」更影响体验，所以追求流畅的话直连硅基流动是更优解。

omniroute 这类网关的价值在于聚合多模型、统一计费、做容灾切换，如果对延迟不敏感可以作为备用方案。但日常写代码，把主力 provider 直接指向硅基流动明显更舒服。

小结

硅基流动服务器在国内，相对海外平台省去了跨境延迟，对国内开发者非常友好；
OpenCode 接入只需三步：注册账号、填写 provider 配置（别忘 limit 字段）、设置环境变量；
GLM-5.2 实测首字返回约 1~2 秒，比 omniroute 路由快 4 倍且更稳定；
拉新活动期间新用户有免费额度，注册地址：https://cloud.siliconflow.cn/i/cdIVTUIN

如果你也在用 OpenCode 或其它 AI 编程代理，又嫌海外 API 卡，不妨试试硅基流动直连。

为什么选硅基流动#

注册并获取 API Key#

接入 OpenCode#

配置文件#

设置环境变量#

选择模型#

实测 GLM-5.2 首字延迟#

测试结果#

与 omniroute 网关方案对比#

小结#