项目是什么，为什么这两天突然爆火
yynxxxxx/Codex-5.5-codex-instruct-5.5 是 2026 年 6 月底突然冲上 GitHub Trending 的开源代码大模型仓库。它基于开源基座做了一轮指令微调（instruction tuning），主打「在 7B/13B 级别跑出接近 GPT-4 水平的代码补全与函数级生成」。从仓库命名 codex-instruct-5.5 可以看出，这是一次专门对齐 instruct 场景的再训练版本。
它为什么一夜涨到 1000+ star？三个关键词：第一，真正能本地跑——权重以 GGUF 与 safetensors 双格式发布，单卡 4090 即可加载 13B 量化版；第二，instruct 对齐做得到位，仓库自带的 eval 脚本在 HumanEval、MBPP 上比同体量开源模型高出 5-8 个百分点；第三，license 友好，允许商用 fork，恰好踩中企业私有化部署的红线。1000 star 在 GitHub Trending 上一夜达成，几乎是被 Hacker News 的 Show HN 和 Reddit r/LocalLLaMA 的置顶讨论同时推上去的。
开发者最关心的 5 个问题
1. 13B 量化版到底要多少显存才跑得动？
现象：很多人 clone 下来直接 python -m llama_cpp.server --model codex-instruct-5.5.Q4_K_M.gguf，结果上来就 CUDA OOM。
根因：Q4_K_M 量化下 13B 模型大约 7.9 GB 权重，但 KV cache + 8K 上下文还要额外吃 4–6 GB 显存，24 GB 显存在所难免。
解法：先用 --n-gpu-layers 控制卸载层数，或者降到 Q3_K_S（约 6.1 GB）。更稳的做法是用 vLLM 起服务：
from vllm import LLM, SamplingParams
llm = LLM(
model="yynxxxxx/Codex-5.5-codex-instruct-5.5",
quantization="awq",
max_model_len=4096,
gpu_memory_utilization=0.85,
)
sp = SamplingParams(temperature=0.2, max_tokens=512, stop=["```\n"])
print(llm.generate(["写一个 Python 快速排序"], sp)[0].outputs[0].text)2. 为什么生成的代码总带「幻觉导入」？
现象：明明没装 pandas，模型却 import pandas as pd 写得飞起，复制到本地直接 ModuleNotFoundError。
根因：instruct 微调数据集里 Python 示例大多基于 Jupyter 模板，模型学到了「先 import」的习惯；temperature 偏高时，token 采样会优先选择高频组合。
解法：把 temperature 降到 0.1–0.2，并在 system prompt 里显式约束：
SYSTEM = """仅使用标准库与本地已安装的第三方包。
若必须 import，请先输出 # requires: pkg>1.0 注释。"""同时把 SamplingParams 的 presence_penalty 调到 0.1，可以抑制重复 import。
3. README 没给 chat template，怎么对接 OpenAI API？
现象：想用 openai.OpenAI(base_url="http://localhost:8000/v1") 走 chat 接口，模型返回乱码或直接忽略 system 消息。
根因：作者用的是 Alpaca 风格模板（### Instruction / ### Response），而 vLLM / llama.cpp 默认走 ChatML，模板不匹配等于把 system 消息吞掉。
解法：补一份 chat_template.jinja：
{% for m in messages %}{% if m.role=='system' %}### System:
{{ m.content }}
{% elif m.role=='user' %}### Instruction:
{{ m.content }}
{% elif m.role=='assistant' %}### Response:
{{ m.content }}
{% endif %}{% endfor %}### Response:启动时 --chat-template chat_template.jinja 即可对齐 OpenAI Chat Completions 协议。
4. HumanEval 跑分复现不到 README 的数字？
现象：本地跑 python eval_humaneval.py --model codex-instruct-5.5，pass@1 只有 58%，README 写的是 67%。
根因：eval 脚本对 prompt 模板、stop token、采样次数极其敏感。原作者用的是 n=20 采样 + pass@1 (greedy)，而多数人没注意 --num-samples 与 --temperature 默认值。
解法：严格对齐仓库设置：
python eval_humaneval.py \
--model codex-instruct-5.5 \
--num-samples 1 \
--temperature 0 \
--max-tokens 512 \
--prompt-template instruct_v5如果还差几个点，检查 tokenizer 是否一致——仓库用的是 SentencePiece BPE，部分镜像分发版本被误换成 tiktoken，分词偏移 1–2 个 token 就会让 pass@1 掉 3%。
5. 能不能直接当 VS Code 本地 Copilot 用？
现象：想把它接进 Continue / Tabby / CodeGPT 当本地 Copilot，插件提示「model not supported」。
根因：多数插件只识别 OpenAI / Ollama / Anthropic 协议，而 codex-instruct-5.5 默认是裸 HuggingFace 推理。
解法：先用 Ollama 把 GGUF 转成本地模型，再在 Continue 配置：
{
"models": [{
"title": "Codex 5.5 Local",
"provider": "ollama",
"model": "codex-instruct-5.5:q4_k_m"
}]
}或用 Tabby 自带的 OpenAI-compatible 适配器，把 vLLM 起的服务暴露成 http://127.0.0.1:8000/v1，插件就能直接识别 FIM（fill-in-the-middle）补全。
一句话总结
Codex-5.5-codex-instruct-5.5 不是「又一个 7B 玩具」，而是把 instruct 对齐、量化分发、本地服务这三件事一次性做齐的工程型仓库。它的爆火，本质上是开发者对「私有化、低成本、可商用」三件套的集体投票。
Sources
- GitHub Trending 2026-07-02: yynxxxxx/Codex-5.5-codex-instruct-5.5
- Reddit r/LocalLLaMA 讨论串: “Codex 5.5 13B runs on a single 4090” (2026-06-29)
- Hacker News: Show HN — Codex 5.5 instruct, open weights code model (2026-06-30)
- 仓库 README 与
eval/目录下 HumanEval / MBPP 复现脚本