默认域名限制：是的，edgeone.cool 等免费子域仅用于临时预览，强制带 eo_token 且有时效。这是官方设计，无法通过配置改为长期公开链接。 加速区域修改：不可直接修改。免费版一旦选定含中国大陆的节点，后续无法切换为“不含大陆”。若需切换，只能删除当前项目/站点，重新创建时选择“全球（不含中国大陆）”。注意：删除操作会清除部署记录，需提前备份代码和构建配置。 自定义域名与备案： 必须备案：只要加速区域包含中国大陆，绑定自定义域名就必须完成 ICP 备案，否则会被拦截或返回 403/401。 无备案替代方案：若不想备案，只能选择“全球（不含中国大陆）”加速区域，并绑定海外域名服务器解析的域名。但这样国内用户访问速度可能较慢（取决于 CDN 节点分布）。 建议：面向国内同学，建议尽快办理 ICP 备案，绑定自有域名以获得稳定、高速、无需 token 的访问体验。 官方详细解决方案：https://cloud.tencent.com/product/teo... 展开详请

别慌，这大概率是用了 EdgeOne 的免费子域名（比如 xxx.edgeone.cool）。这种平台自带的二级域名，底层虽然走了 HTTPS 传输，但前端展示上往往不吐证书链，或者浏览器直接当 HTTP 处理，所以你看不到锁标。 想看到绿锁？必须绑定自有域名。去控制台把 DNS CNAME 解析到你自己的域名上，系统会自动帮你签发 Let's Encrypt 证书。等 DNS 生效（通常几分钟到几小时），访问你的域名就能看到证书了。 另外，如果你绑的是国内域名，记得先备案，不然 HTTPS 可能开不了。如果是海外节点，直接绑就行。总之，免费子域名就别指望看证书细节了，那是给正式站点准备的。 官方详细解决方案：https://cloud.tencent.com/product/teo... 展开详请

不能直接预装，但可以通过“自定义运行时”实现。 Google Cloud Functions Gen 2（包括 Makers/Spark 计划）允许你指定 Node 版本，但不是像 Docker 那样“预装”镜像，而是通过 package.json 声明依赖。 操作步骤： 创建 runtime.txt 或配置 engines：在函数目录的 package.json 中明确指定："engines": { "node": "22" } 部署时选择运行时：使用 Firebase CLI 或 gcloud 部署时，确保指定 --runtime=nodejs22。 注意限制： Gen 2 支持 Node 20/22，但需确认 Google 是否已正式推送 22.23.4 这个具体小版本。通常平台会提供最新 LTS 或当前稳定版，不一定能锁定到补丁级版本。 Makers 计划有资源限制：内存最高 512MB，CPU 有限制。Node 22 本身不耗资源，但你的代码逻辑可能吃内存。 冷启动时间：新运行时首次加载可能稍慢，对延迟敏感场景需注意。 建议：先测试 Node 22 通用版，如果必须用 22.23.4，检查 Google 官方文档是否支持精确版本锁定。否则，用 Node 22 最新可用版本即可，兼容性差异极小。 官方详细解决方案：https://console.cloud.tencent.com/edgeone... 展开详请

结论：守住生产边界靠的不是把限流、超时、熔断、降级全部打开，而是明确各层职责、统一请求预算，并用故障演练验证。产品取舍和商业收费，也要建立在可测量的服务目标上。 一、技术上先统一预算，再安排保护动作 1. 从用户请求入口定义端到端截止时间，覆盖排队、连接、下游处理、重试和兜底。下游调用只能使用剩余预算，还要给上游组装结果留时间；不能每层都单独设置一个完整超时。超时后应尽可能取消后续任务，但客户端超时不代表服务端写操作已经撤销。 2. 入口限流负责控制总流量及租户公平性，服务内部用并发上限、有限队列和连接池保护稀缺资源。不同租户、核心与非核心业务需要适当隔离，避免一个慢依赖耗尽全部线程。不要把熔断的统计范围误当成资源池隔离。 3. 熔断负责停止持续失败的下游调用，降级负责给出明确的替代结果。熔断打开后不要通过另一层重试重新打回同一个故障依赖；半开恢复时限制探测流量，避免同时恢复形成冲击。兜底路径也必须有独立的容量和超时限制。 4. 重试尽量只由一层负责，只针对可重试错误和幂等操作，受剩余时间、次数及总体流量预算约束，配合退避和随机抖动。不能网关、业务服务、SDK 各自重试。支付、入账等写请求必须先具备业务幂等或结果查询能力；不可把执行结果未知直接包装成成功。 5. 使用腾讯云 TSF 时，可按服务、实例或 API 范围配置熔断，并结合失败率、慢请求统计治理。具体能力要匹配所用框架和 SDK 版本；限流、熔断阈值应来自压测与业务容量，而非照搬一组固定数字。 二、首音与成功率不达标，先区分核心能力和附加体验 1. 语音场景分别统计首音耗时分位数、完整任务成功率、中断率和降级占比。只统计有首音的成功请求会掩盖失败，也不能把播放固定提示音当成业务回答已经开始。 2. 优先关闭非必要的工具调用、复杂音效或额外检索，保住核心回答；在用户知情且场景允许时，才切到较简单的模型、文字输出或人工渠道。涉及交易、授权、合规判断时，宁可明确失败或转人工，也不能以错误答案换低延迟。 3. 是否砍功能取决于该功能是否持续破坏核心服务目标，以及关闭后的实际效果。设置恢复条件和观察窗口，避免指标在阈值附近波动时反复切换。 三、灰度回滚与运维交接能否收费，要用交付结果验证 客户是否持续付费不能由技术功能直接推断。可以将版本发布、故障演练、值班响应、恢复验证和交接培训做成可验收服务，约定服务时间、责任边界、响应目标以及不覆盖的风险，再通过试点续费验证需求。 交付时至少演练依赖变慢、实例退出和突发流量，记录端到端延迟、真实成功率、重试放大、降级比例及恢复耗时。灰度回滚还要检查数据库和消息格式是否向后兼容：应用版本退回，不代表数据变更也能撤销。最终验收应是接手人员能按手册完成一次受控恢复，而不只是收到一份文档。... 展开详请

1、在 腾讯云 SSL 证书服务下载证书时，优先找“完整证书链 / fullchain / CA bundle / 证书链”一类的下载包（命名在不同页面略有差异）。 2、拿到你要上传到 CLB 的“证书内容”那份，确认它包含 多段 BEGIN CERTIFICATE。 3、将该完整链重新绑定到 CLB 的 443 HTTPS 监听器（你已“重新选择并保存”，但如果选错文件/选到只含叶子的那份，就会一直复现）。... 展开详请

先别急着改代码，这通常是网络或配置层面的“背锅”。第一步，登录阿里云控制台，检查轻量服务器的防火墙设置。很多人忘了在控制台的“防火墙”标签页里放行Docker映射的端口（比如8080），光在Linux内部开没用，云厂商的安全组也得放行。 第二步，确认Docker容器是否真的监听在0.0.0.0而不是127.0.0.1。如果启动时绑定了本地回环地址，外网肯定连不上。可以用docker ps看下端口映射情况，或者进容器执行netstat -tlnp验证。 第三步，排查IP冲突或端口占用。有时候宿主机上其他服务占用了该端口，导致Docker没成功绑定。最后，试试在服务器本地用curl http://localhost:端口号测试，如果本地不通，那就是应用本身的问题；如果本地通但外网不通，90%是上述两步防火墙或绑定地址搞鬼。按这个顺序查，基本能解决。 官方详细解决方案：https://cloud.tencent.com/product/lighthouse?Is=sdk-topnav... 展开详请

这大概率是 Nginx 开了 Gzip 压缩导致的。EdgeOne 验证节点拿到的可能是压缩后的二进制流，和源站明文比对自然失败。 先查 Nginx 配置，针对 .well-known 目录强制关闭 gzip（gzip off;）。很多全局配置会误伤这种小文件，导致返回 Content-Encoding: gzip 但内容长度不对。 其次，刷新 EdgeOne 缓存。控制台可能缓存了之前的错误状态。在后台做“URL 刷新”，专门刷那个 txt 文件链接。 最后，确认文件末尾绝对没有换行符或 BOM 头，纯 ASCII 32 字节。如果关了 Gzip、清了缓存还报错，直接提工单给腾讯云后台。附上你的 Nginx 日志截图，证明他们验证节点拿到的是乱码或错误数据，让他们后端重置验证状态。别跟前端死磕，这是平台侧的缓存/解码 Bug。 官方详细解决方案：https://cloud.tencent.com/document/product/228/61702... 展开详请

先分清是本地私有化还是直接调 API。私有化部署 Kimi 开源版主要卡显存：百亿级参数 FP16 加载一般要 40G 以上显存，单卡不够就用 vLLM 或 SGLang 做多卡张量并行，两个框架对 Moonshot 系架构支持都比较成熟。步骤大致是：从 HuggingFace 或 ModelScope 拉权重，起 vLLM 时指定 tensor-parallel-size 为实际卡数，然后按 OpenAI 兼容接口暴露服务，业务侧基本不用改代码。没有强私有化需求就直接走 Kimi 官方 API，自建的成本大头是 GPU 而不是模型。想省成本跑量化版的话，GPTQ 或 AWQ 量化后单张 24G 卡也能跑，但精度有折损，先拿自己业务的真实 case 回归测一遍再定。... 展开详请

别慌，这是 EdgeOne 的“透明代理”特性在作祟。既然桶不在你控制台，说明是系统托管资源，你没法直接改 COS ACL。 解决思路分两步： 源头封堵（推荐）：直接提工单给腾讯云，要求将源站 COS 桶权限改为“私有”，并授权 EdgeOne 服务账号读取。这是最彻底的办法，让外部根本无法直连 COS。 边缘拦截：如果无法改源站，必须在 EdgeOne 控制台加一道锁。去【站点配置】->【安全策略】或【自定义规则】，添加一条规则：若请求无鉴权 Header（如 Token），直接返回 403。这样即使 COS 开着匿名读，用户也得先过 EdgeOne 这一关。 防收录的话，在 EdgeOne 响应头里加上 X-Robots-Tag: noindex, nofollow 即可。记住，CDN 只是通道，权限还得靠后端或者边缘节点硬控。 官方详细解决方案：https://cloud.tencent.com/developer/article/2696268... 展开详请

部署图只是结果，真正难复制的是踩坑过程和取舍依据。一个架构能跑起来，背后往往是十次失败回滚、监控告警救火、容量评估修正。看别人的图只能学到「用了什么」，学不到「为什么没用别的」。要复制经验，得把当时的业务量级、团队能力、预算约束、故障案例一起打包看。否则照猫画虎，很容易就复制出一套跑不动的东西。... 展开详请

这是 SCF（云函数）的部署包限制：代码包 zip 压缩后 128MB，解压后上限 512MB（含层）。超限的三条路，按成本排序： 1）依赖瘦身：node_modules 走 prune、Python 只装生产依赖、排除测试与文档——实际业务里 80% 的超包是依赖没清理，先做这个再评估架构； 2）用「层」（Layer）拆分：把大依赖（numpy/pandas、puppeteer 的 chromium、字体文件）放到层里，多个函数共享引用，主包只留业务代码——层不计入代码包大小； 3）改容器镜像部署：SCF 支持镜像部署，上限大得多，适合真带大依赖（AI 模型文件、headless 浏览器）的场景，代价是冷启动变慢，要配合预留实例。 另外注意两点：压缩包先优化再动架构（zip 的 128M 是压缩后限制，文本类依赖压缩率很高）；冷启动敏感的函数慎用大镜像，预留实例与并发限流要配套。... 展开详请

这俩不是二选一，而是解决不同瓶颈。前缀缓存（Prefix Caching）降低的是重复计算的浪费，适合长上下文、多轮对话、批量相似请求的场景，收益立竿见影且几乎无损精度。量化（INT8/INT4/FP8）降的是单次推理的显存和算力占用，但可能带来精度损失和推理异常。 建议顺序：先上前缀缓存。它不改模型、不碰训练 pipeline，部署层就能做，ROI 最高。等缓存红利吃完，再按业务敏感度做分级量化——对精度容忍度高的链路用低比特，核心链路保持 FP16。别一上来就全量量化，出了问题不好定位是模型本身还是量化造成的。... 展开详请

已解决，记一下原因和处理方法，给遇到同样问题的人参考。 原因：这个站点 2026 年 9 月 9 日在控制台开启过"源站防护"。工单确认免费版不支持这个功能，开着的时候域名会卡在"部署中"，续期的证书下发不到边缘，域名配置也改不了。（提问里说"从 2025 年 8 月底起"不准确，那是域名的最后修改时间。） 处理： 1. 调用 DisableOriginACL（参数只有 ZoneId）关闭源站防护。约 2 分钟后所有域名恢复"已生效"。 2. 对每个域名分别调用 ModifyHostsCertificate（Mode=eofreecert）。一次只能传一个域名，传多个会报 HostsCertificateInconsistency。约 2 分钟后边缘换上了新证书。 注意：关闭源站防护后，EdgeOne 回源 IP 会马上换成原白名单以外的网段，我们观测到约 95% 的回源请求来自名单外。如果源站用源站防护给的 IP 白名单做了拦截，关闭前要先放开，否则整站 403。之后可以改用规则引擎的"修改 HTTP 回源请求头"加一个密钥头，源站按这个头放行。... 展开详请

正：从架构视角，K8s调度开源文生视频模型可行，但要把推理拆成预处理、文本编码、DiT去噪、VAE解码四段，用GPU Operator、MIG或时间片隔离显存，再通过Triton或TensorRT承接并发；短任务走在线池，长任务走离线池，模型权重放对象存储并预热。 反：边界在于文生视频单请求显存和时长远高于LLM，K8s原生调度不看显存碎片，Pod频繁漂移会引发冷启动和OOM；CogVideoX、Wan2.1、Mochi-1的并行策略各异，统一镜像容易变成伪共享，跨节点NVLink缺失时扩卡收益会骤降。 定：可执行验证是搭一个双节点8卡集群，固定16条prompt，分别测单卡、张量并行、流水并行三组，采集P95延迟、显存碎片率、Pod重启次数和队列等待；若P95超过SLA两倍或OOM率高于1%，就退回单模型单池部署，不强行上K8s多租。... 展开详请

目前没有单独提供现成的 ARM 镜像包。如果是内网环境，可以先在有网络的环境下，通过 Docker 指定 ARM 架构拉取 qData 部署所需镜像，再使用 `docker save` 将镜像导出成镜像包，传到内网服务器后通过 `docker load` 加载。镜像加载完成后，就可以按照正常的部署流程启动使用。... 展开详请

门槛不在安装，在后期的运维和效果。跑起来很简单，Ollama或vLLM一行命令，7B量化模型一张24G的4090就能跑。真正的门槛分三层：模型层，想效果好得自己微调，数据准备、训练卡时、评估都是持续投入；硬件层，并发上去以后显存和吞吐是硬指标，vLLM多卡部署、KV cache优化都得懂；运维层，模型升级、监控、灰度没人给你兜底。我的判断：个人玩，API或家用机跑小模型足够；企业内部知识库这类场景，本地部署7B到14B做RAG是划算的，但一定要算隐形成本，一台8卡机的电费加运维人力，一年下来未必比API便宜。先把调用频次和并发摸清楚再决定。... 展开详请

3.6B激活参数跑本地Agent，工具调用和短链路任务够用，1M上下文对代码库级RAG有价值，但长上下文内存占用要实测，满上下文时KV cache照样能把RTX PC显存打爆，官方标的670 tokens/s多半是小上下文数据。选型测试建议固定一套任务：工具调用成功率，连续十次工具链不出错的比例；首字延迟；故障注入后的恢复表现。经验上，路由分发、信息抽取、单文件改写这类任务交给它没问题，多步规划、跨文件重构还是路由给云端大模型，小激活模型规划步数一多容易跑偏。先用vLLM或llama.cpp部署测工具调用，再测长上下文，别只看吞吐数字。... 展开详请