如果你做过 FreeSWITCH 和业务系统集成，大概率会遇到一个绕不开的问题：ESL 很强大，但业务系统真正接入时，工程复杂度并不低。你需要维护 ESL 长连接，需要处理断线重连，需要从大量底层事件里还原通话状态，还要把 `uuid_kill`、`uuid_transfer`、`uuid_record`、`originate` 等命令再封装成业务接口。等到项目进入 AI 外呼、智能客服、语音机器人这类实时语音场景时，事情会更复杂：呼叫控制、通话状态、音频推流、播放打断、PCM 回灌，往往会分散在多个服务和多层逻辑里。所以我做了一个 FreeSWITCH 原生模块：`mod_fcc`。 它想解决的问题很明确：让业务系统不用直接面对 ESL，而是像调用普通服务接口一样使用 FreeSWITCH 的呼叫能力。
Oracle's sharp pullback does not prove that AI is over. It shows that markets are repricing the cash-flow risk behind AI infrastructure.
甲骨文股价回撤不等于 AI 破灭，它更像市场开始重新定价 AI 基础设施的现金流风险。真正的问题是企业利润、岗位结构和社会分配如何重写。
vLLM tuning should not stop at checking whether the API returns an answer. TTFT, TPOT, throughput, KV Cache usage, queue length, and tail latency form the real feedback loop.
vLLM 调优不能只看服务是否返回答案，而要围绕 TTFT、TPOT、吞吐量、KV Cache 使用率和尾延迟建立监控闭环。本文用本地脚本串起启动、测量、压测和指标采集。
Speculative decoding does not let the model guess blindly. A cheap draft model proposes tokens, while the target model verifies them in parallel. The real question is whether acceptance rate and batch size make it worthwhile.
推测解码不是让大模型乱猜，而是用草稿模型先给候选，再由目标模型一次性验证。理解 Medusa、EAGLE 和大 Batch 的关系，才能判断它在生产高并发里是否真的划算。
LuminaRAG is not positioned as another RAG demo. Its real value is treating enterprise AI search as governed, auditable knowledge infrastructure.
LuminaRAG 不是一个只追求问答效果的 RAG Demo，而是把文档审核、权限隔离、混合检索、引用来源和内网部署放在一起思考的企业知识库开源模板。
